Question 1

What is a skill and when would you create one?

Accepted Answer

Start from the mechanism: "A skill is a package of instructions loaded on demand — a SKILL.md file: frontmatter plus instructions. It triggers two ways: I invoke /name, or the agent invokes it when the task matches the description." The key point — token economics: "CLAUDE.md loads in full on every request; a skill loads only when used. So keeping a 400-line release checklist as a skill is practically free, while keeping it in CLAUDE.md eats every session's budget." When I create one: when I type the same instructions a third time. Concrete examples: a Compose review checklist, creating a new feature module, a release check. A practical detail that shows experience: "I don't invent skills — I port the team's existing checklist. That way it reflects the real process and actually gets used." The boundary: "A one-line fact stays in CLAUDE.md. Skills are for multi-step procedures."

Question 2

Explain MCP: what it is and how its architecture works.

Accepted Answer

Start from the problem, then the architecture — that order works better: The problem: "MCP is an open standard for connecting AI applications to external systems. It solves the N×M problem: with 5 tools and 10 systems you needed 50 separate integrations. With MCP each tool speaks client and each system exposes one server — 15 components." The architecture: Host — the AI application (Claude Code). It manages the clients. Client — maintains the connection to one server. The host creates one client per server. Server — supplies context and tools. It can be local (stdio) or remote (HTTP). Two layers: the data layer (built on JSON-RPC 2.0 — message structure, primitives) and the transport layer (stdio or Streamable HTTP). Primitives: on the server side, Tools (action), Resources (data), Prompts (templates). A practical nuance that shows depth: "The model doesn't see a tool's code — only its name, description and input schema. So tool descriptions have to be written like an interface. If a tool is connected but never called, the problem is almost always the description."

Question 3

You want to bring MCP into the company. What will security ask, and how will you answer?

Accepted Answer

Pre-empt the questions — that shows preparation. What they'll ask: 1. "What does this server have access to?" → I prepare a permission list per server. 2. "Who wrote it?" → Prefer official/first-party servers; code review for our own. 3. "Where does data go?" → What the server returns enters the model request. That flow has to be stated plainly. 4. "Can we trace who did what?" → Audit logging on the server side. 5. "What could a malicious PR do?" → .mcp.json lives in the repo; project-scoped servers need approval, but that doesn't replace reviewing the file change. How I structure the answer: I list the risks myself: trust, prompt injection, over-privilege, secret leakage. I propose a control per risk: an approved-server list, a separate least-privilege token, write tools in ask, CODEOWNERS on .mcp.json. A staged plan: read-only servers first, then an assessment, then writes. Tone: "The decision isn't mine — my job is to present the options and the controls." That is the senior position and builds a working relationship with security.

Question 4

If you had to write an MCP server for an Android team, where would you start?

Accepted Answer

Start from the criterion: information the model doesn't have that gets copied by hand every time. My pick is an internal API schema server: The agent guesses backend endpoints, one of its most error-prone areas. The schema changes often; documentation lags. It is read-only — low risk. Tool design: narrow tools, small results — list_endpoints(service?) get_endpoint_schema(path, method) search_schema(field_name) Approach: start on stdio (prototype, no deployment), move to HTTP when the team needs it. Design rules: Filter results server-side — a tool's output enters the context, and unfiltered large JSON eats the budget in one call. Keep read and write tools separate so permission rules can govern them independently. Write descriptions like an interface — they are all the model sees. Measurement: "the server's value shows as how much less often the agent writes a wrong field name — a concrete signal visible in PR reviews."

Question 5

How do you choose between CLAUDE.md, .claude/rules/, skills and MCP?

Accepted Answer

Build the answer on two axes: when it loads and what it provides. When it loads: CLAUDE.md — every session, always. Hence it must stay short (under 200 lines). .claude/rules/ with paths: — when matching files are in play. Ideal for area-scoped rules: testing rules only when test files are open. A skill — when invoked, or when it matches the task. What it provides: The first three are instruction — they tell the agent how to work. MCP is connectivity — it tells the agent what it can reach. A practical decision tree: A one-line fact, always needed → CLAUDE.md An area-scoped rule → .claude/rules/ with paths A multi-step procedure → a skill Access to an external system → MCP (but ask first: would a CLI do?) Close with the general principle: "every mechanism's cost is context. The cheapest is the one that doesn't load when it isn't needed. So my default is the most narrowly-loading option available."

Question	The answer's key point
What is a skill?	Instructions loaded on demand — the token economics
Skill versus CLAUDE.md?	Always versus on demand; fact versus procedure
What is MCP?	The N×M integration problem; an open standard
MCP architecture?	Host / client (one per server) / server; JSON-RPC
MCP risks?	Trust, prompt injection, over-privilege, secret leakage
Skill versus MCP?	A skill is how; MCP is access to what

Technical questions on Skills and MCP

📚 Sources and documentation