Four rungs, from a macro to a process.

Constraint Engineering ends its section on component families with a ten-second test. Remove the component and ask what changed. Run that test and keep only the answers that point one way.

The five answers are exclusive in practice and not in theory. A skill that says always run the formatter reads like a capability and behaves like a rule. Removing it lets the agent do more, so it is a constraint, and it belongs in the charter at the rung the charter chose. That single misfiling is the most common one I see, and section 12 lists it as an anti-pattern rather than a style preference.

0.1 · Four attributes, and the fourth is the new one

A constraint carries a layer, a rung, a policy and a verdict. A capability carries four of its own. Three of them have obvious counterparts. The fourth does not exist on the constraint side at all, because a constraint does not need to be found.

The missing counterpart is the whole reason these two pages exist. A hook runs because an event happened. A gate runs because the pipeline reached it. Neither one waits to be noticed. Every capability on the ladder below waits to be noticed, and three of the four wait to be noticed by a model reading a one-line description.

0.2 · Two prices, named once

Every rung below is priced twice on this page, so the two words are worth pinning here. The standing cost is what the capability puts in the context window on every turn, whether it fires or not: a name, a description, a schema. The invoked cost is what it puts there when it does fire: a body, a file, a result. One is paid thousands of times a week and the other is paid when the work needs it.

That is the whole reason the ladder has four rungs rather than one file format, and the accounting behind it belongs to the sequel rather than to this page. Keeping Capabilities Honest measures both prices, and the rest of this page just states them per rung and moves on.

Standing cost

A name and one line. Zero when you turn model invocation off.

Invoked cost

The whole body, expanded in place, plus whatever it injects.

What returns

Nothing. The command is the turn.

Boundary

None. Every word is in the window and the model may rewrite the plan.

1.1 · What it actually is

A markdown file, in the project at .claude/commands/ or in the account at ~/.claude/commands/, with a subdirectory for a namespace. The frontmatter is small and every field is a lever on the ledger.

---
description: Check the current diff against the charter's rung-1 rules
argument-hint: [base-branch]
allowed-tools: Bash(git diff:*)
disable-model-invocation: true
---

The diff under review, against $1:

!`git diff $1...HEAD --unified=0`

Read @docs/charter.md. Check the diff against the rung-1 section only.
Report one line per violation, and nothing else. Do not fix anything.

Three of those lines are the interesting ones. $1 and $ARGUMENTS make the file a function rather than a note. The ! prefix runs a shell command when the command expands and drops the output in, which means the prompt arrives already holding its evidence. disable-model-invocation takes the description out of the standing bill, which is the right default for anything a human always initiates.

1.2 · What the rung buys

• Rehearsal. A prompt you got right once, replayed exactly. This is worth more than it sounds, because most bad agent turns start with a badly stated ask.
• Evidence at the front. The ! injection collects the diff, the log, the failing test before the model starts. It cannot forget to look.
• Near-zero standing cost. With model invocation off, a hundred commands cost you almost nothing on a turn that does not use them.
• A human in the loop by construction. Somebody chose to run this. For anything irreversible that is a feature, and The Factory treats it as one of the places a human gets asked.

1.3 · The ceiling

A command cannot fire when the model needs it. It fires when a person remembers it. So the moment the value of the capability depends on it running at the right time rather than at a chosen time, this rung is wrong, and it is wrong in two different directions.

Standing cost

A name and one line, on every turn.

Invoked cost

The body when it triggers, then bundled files only if something reads them.

What returns

Every word, into this same window. Nothing is summarized.

Boundary

Convention. The model can read the file, argue with it, or ignore it.

2.1 · Three levels, and the design work is deciding what lives where

A skill is a directory with a SKILL.md and whatever it needs beside it. The three levels are not a packaging detail. They are the two prices of section 0, expressed as a file layout.

migration-writer/
├── SKILL.md          the procedure. Around a page
├── references/
│   ├── column-types.md   the table nobody memorizes
│   └── rollback.md       read only when a rollback is asked for
└── scripts/
    └── check_reversible.py  deterministic. Run, do not read

--- SKILL.md ---
---
name: migration-writer
description: Write, review or roll back a database migration in this
  repository. Use when the user mentions a migration, a schema change, adding
  or dropping a column, an index, or a backfill. Covers the reversibility
  check this repository requires before a migration can merge.
allowed-tools: Read, Write, Edit, Bash(python scripts/check_reversible.py:*)
---

1. Read the existing migrations in db/migrate to match the local style.
2. Write the migration. Every one is reversible or it does not merge.
3. Run scripts/check_reversible.py against the new file. Do not
   reimplement the check by reading the file yourself.
4. For column types, read references/column-types.md. Do not guess.

The script in that layout is the part people skip, and it is the cheapest determinism on the page. A bundled script has no standing cost, no schema, no process to run, and no configuration. It answers the same way every time. Reach for an MCP server after you have established that a script cannot do it, not before.

2.2 · What the rung buys

• Knowledge that arrives when relevant. This is the whole product. A reference library that costs one line until the moment it is needed.
• Procedure with an order. A skill can say do this before that in a way a note in the charter cannot, because it arrives with the job rather than with the session.
• Bundled determinism. Scripts beside the procedure, invoked by name, with a grant that permits exactly them.
• A shared unit. Team-owned in the repository, account-owned for personal habits, or packaged in a plugin for distribution.

2.3 · The ceiling

Two limits, and they are different in kind. The first is that the boundary is politeness. The model can read the skill file, disagree with it and proceed. A skill cannot refuse anything, so a rule you need obeyed does not become obeyed by being written in a skill. It becomes obeyed by a hook or a gate, and the skill is where the accompanying knowledge goes.

The second is that everything it loads lands in this window. A skill whose body dumps a reference manual on trigger has moved cost from the standing column to the invoked column and then blown the invoked column. That is what the bundled files are for, and it is the most common repair I make to a skill somebody else wrote.

Standing cost

A name and one line, on every turn.

Invoked cost

A task prompt out. The reading, the searching and the false starts happen elsewhere.

What returns

A summary. Often a net saving, which no other rung can offer.

Boundary

Context. Its own window, its own grant, its own model if you want one.

3.1 · What it actually is

A markdown file in .claude/agents/. The frontmatter names it, describes when to use it, and declares the tools it may hold. The body is its system prompt, so the file is a job description rather than a procedure.

---
name: charter-auditor
description: Audit a branch against the charter and report violations with
  file and line. Use when asked whether a change conforms, before opening a
  pull request, or when a reviewer disputes a rule.
tools: Read, Grep, Glob, Bash(git log:*), Bash(git diff:*)
model: sonnet
---

You audit changes against docs/charter.md. You do not fix anything and you
do not write files.

Return exactly this shape, and nothing else:
  one line per violation: path:line · rule id · what it violates
  then a final line: N violations across M files
If there are none, return exactly: no violations.

Two lines in that file do most of the work. The tools line is a grant, and a grant left off is a grant inherited by accident, which section 10 treats as a real defect rather than an untidiness. The return block is the interface. A sub-agent whose return shape is unstated returns prose, and prose is exactly what you were trying to keep out of the parent window.

3.2 · What the rung buys

• Context back. Twenty file reads happen somewhere else and eight lines come home. This is the only rung with that property and it is the main reason to use it.
• Parallelism. Several sub-agents at once, on independent work, and the wall-clock is the slowest one rather than the sum.
• A narrower grant than the parent. A reviewer that cannot write. An auditor that cannot push. The grant is the security property, and it is declared in a file rather than hoped for in a prompt.
• A different model or effort. Cheap and fast for mechanical fan-out, expensive and careful for the one judgment that matters.
• Isolation when work collides. Parallel agents that mutate files need separate worktrees, and that is a flag rather than a design.

3.3 · The ceiling, which is the return value

The parent cannot see what the sub-agent saw. That is the point and it is also the whole cost. Three consequences follow, and the first two are avoidable.

1. lossy Anything the report leaves out is gone. The parent re-derives it and you have paid for the same reading twice. Fix it by stating the return shape, including the fields you will need later, such as file and line.
2. one shot The sub-agent cannot ask you what you meant halfway through. An ambiguous task becomes a confident wrong answer. Fix it by putting the disambiguation in the task prompt, not in the agent file.
3. two models You now have two places to be wrong, and the parent has no way to check the child's work. This one does not have a fix. It has a price, and the four numbers in Keeping Capabilities Honest are how you find out what it is.

flowchart LR
  P["the parent turn"] -->|"task prompt, plus a grant"| A["the sub-agent"]
  A --> R1["forty file reads"]
  A --> R2["three wrong guesses"]
  A --> R3["the finding"]
  R3 -->|"the report, in the stated shape"| P
  R1 -.->|"never crosses"| P
  R2 -.->|"never crosses"| P
  class P dim
  class A pass
  class R1 block
  class R2 block
  class R3 warn

3.4 · When it is the wrong rung

A sub-agent for a job that needs three lines of knowledge is a context wall around nothing. You paid a task prompt, a fresh system prompt and a round trip to avoid loading a paragraph. The rule I use: if the work does not involve reading or searching more than the parent wants to hold, it is a skill.

The other direction is subtler. If the parent keeps asking follow-up questions about what the child found, the wall is in the wrong place. Either the return shape is too narrow, or that work belonged in the parent's own window all along.

Standing cost

Every declared tool's full schema, on every turn. Plus any instructions the server injects.

Invoked cost

Arguments out, and whatever the server chose to return.

What returns

A result, and no implementation. Its size is the server author's decision, not yours.

Boundary

Process. The model cannot read the code, so it cannot work around a bad schema.

4.1 · What it actually is

A server speaking the Model Context Protocol, connected over stdio to a local process, or over HTTP or server-sent events to a remote one. Where you declare it decides who gets it, and that is a layer decision in the sense Anatomy of a Charter uses: whoever owns the file owns the capability.

{
  "mcpServers": {
    "incidents": {
      "type": "http",
      "url": "https://incidents.internal/mcp",
      // auth happens out of band. The model never holds the token
    },
    "repo-graph": {
      "command": "uvx",
      "args": ["repo-graph-mcp", "--root", "."]
    }
  }
}

4.2 · Three primitives, and only one of them is priced per turn

Most teams use MCP as a tool bus and never touch the other two. That is a budget mistake as much as a design one, because tools are the expensive primitive and resources are the cheap one.

A server's instructions are the fourth thing it can put in your window, and they arrive without being asked for. Read them before you enable the server in project scope. They are prose at rung 0 of the constraint chain, written by somebody who has never seen your charter, and the model cannot tell them apart from yours.

4.3 · What the rung buys

• Determinism, though not exclusively. The same call returns the same answer. A bundled script promises that too, for nothing, which is why section 5 keeps repeatability off the list of reasons to build one.
• Credentials the model never holds. The server authenticates. The model gets results. That is a genuine trust boundary rather than an instruction not to look.
• Another machine. The capability can be the thing your platform team already runs, where they run it. Another language is not on the list, because a bundled script can be written in any language you like.
• One implementation, many clients. A schema serves every agent and every editor you point at it. This is the reason to build a server rather than four skills.
• A versionable contract. The schema is the interface. You can change what is behind it without touching a single charter.

4.4 · The bill, and the four ways to cut it

A server with twenty tools stands in your window twenty times, in full, on every turn, with every parameter description. The tools you never call are indistinguishable from the ones you do. Four cuts, in the order I would make them.

1. first Turn off the servers this project does not need. Scope is the cheapest fix and the one nobody does, because enabling a server is a decision you make once and pay for daily.
2. second Use deferred schemas where the client offers them, so a tool's full definition loads when it is searched for rather than standing in every turn. This turns rung 3's standing cost into something closer to a skill's.
3. third Cut the tool count. Tools should be shaped like the task, not like the upstream API. Five task-shaped tools beat thirty endpoint-shaped ones on cost and on selection accuracy at the same time.
4. fourth Cut the returns. A tool that answers a question should return the answer, not the payload it came in. Pages of JSON are an invoked cost the caller cannot refuse.

4.5 · The ceiling, and it is not the cost

The process wall runs both ways. You cannot see in, and the model cannot see in either. So a tool whose description is vague is a capability you cannot repair from the outside. On the skill rung a confused model can read the file and work it out. Here it can only call the thing and hope. The schema description is the capability as far as selection is concerned, which puts the craft of section 9 in someone else's repository when the server is not yours.

The second limit is a security property rather than a cost. What comes back through the wall is text, and it lands in the window next to your instructions. A server that returns a third party's content is returning an untrusted string into a context that treats strings as instructions.

flowchart LR
  M["the model"] -->|"a call that matches the schema"| S["the server, another process"]
  S -->|"credentials the model never sees"| U["the upstream system"]
  U -->|"content written by other people"| S
  S -->|"a result, as text, into your window"| M
  X["your charter, in the same window"] --- M
  class M dim
  class S pass
  class U block
  class X warn

Prompt Injection covers that path properly. The capability-side rule is short: a tool that reaches content other people write needs its return treated as data, and the constraint that enforces it does not live in the server. It lives in your harness, where you can see it.

Think about what a schema actually does. It tells the model what calls exist, what arguments they take, and what comes back. A CLI has all of that too. Its schema is the tool's own help text and the model's prior knowledge of it, and neither of those stands in your context window on every turn. That is the trade in one sentence, and the rest of this section is the cases where it goes the other way.

5.1 · The order to try them in

1. first · a CLI Is there a maintained command-line tool, already installed and already authenticated on this machine? Then use it, grant the exact subcommands, and write a skill that names the two or three invocations you actually want. The skill removes the guessing, which is the CLI's only real weakness.
2. second · a script No CLI, or the CLI prints the wrong shape? A script in a skill directory calls the API and returns the field. You own the request, the retries and the output. No standing cost, and the determinism half of Keeping Capabilities Honest is mostly about this option.
3. third · a server Reach for MCP when one of five things is true, and not otherwise: several clients or agents need the same access, sign-in is an interactive flow the model must not handle, the surface is broad enough that typed discovery is worth paying for, a vendor already ships a server you would otherwise reimplement, or you need a versioned contract other teams build against.
4. then check Count the tools the server declares and multiply by turns per week. If you are enabling twenty schemas to call one of them, go back to the first row.

# a CLI, pinned in a skill so nothing is guessed
allowed-tools: Bash(gh pr view:*), Bash(gh pr diff:*)

2. Read the pull request with:
     gh pr view $NUMBER --json title,body,files
   Do not use other gh subcommands for this step.

# a script, when the CLI's output is the wrong shape
scripts/pr_summary.py $NUMBER   # prints five lines, not five pages

# a server, when four other agents need the same access
mcp__reviews__get_pull_request   # a schema, standing, every turn

5.2 · The honest case for the server

The CLI route has a cost that does not appear in the ledger. The model guesses a flag, the command fails, it reads the help text, it tries again. Three turns for a lookup. A typed schema makes that failure rare, and a broad surface makes it common, so the wider the tool you are reaching for, the better the server looks. A skill that pins the exact invocations closes most of the gap for a few commands and none of it for forty.

The second honest case is authentication. A CLI works because someone signed in on that machine. A server can own the sign-in flow, refresh the token, and keep the credential in a process the model cannot read. When the alternative is a token pasted into an environment variable in a script, the server is buying a real security property and not just tidiness.

Before plugins there were two places a capability could live: your account, or this repository. Both answers are about you. A plugin adds a third, and the third one is about somebody else, which is why it is worth a section of its own rather than a line in the catalog.

6.1 · What is in the box, and why all five parts matter

A plugin can carry more than capabilities, and the parts that are not capabilities are the ones to read first. Enabling a plugin can enforce rules, grant tool access, and put prose in your window on every turn, none of which is visible from its name.

6.2 · The two costs a plugin adds that a local file does not

The first is arithmetic. A plugin's standing cost is the sum of everything it ships, not the part you wanted. Enable it for one skill and you are paying for its other six, plus any server it declares. That is the same bill as before and now somebody else decides its size.

The second has no equivalent locally. A plugin author has never seen your catalog, so their descriptions cannot avoid colliding with yours. The sibling test from section 9 now has to run across a boundary you do not control, and the loser of a collision fails silently, which means an update can quietly disable a skill of your own that used to fire.

1. on install Read the descriptions, not the README. Descriptions decide triggers, and they are the part that competes with your own capabilities.
2. on install Read every hook and every server declaration. These two can enforce and can hold credentials, and neither is what most people think they are enabling.
3. on install Count the standing lines it adds and say the number out loud. If the plugin does not document it, count it yourself with /context before and after.
4. on update Diff the descriptions. A body change is a behavior change you will notice. A description change is a trigger change you will not.
5. quarterly Ask which of its capabilities actually fired. A plugin is the easiest place for dead weight to hide, because nobody feels responsible for pruning somebody else's package.

6.3 · When to publish one

Three repositories is my threshold. Below that, project scope is simpler, reviewable in the normal way, and impossible to forget you have. Above it, copying the same skill by hand starts producing four versions that drift, which is the failure a package exists to prevent.

The other good reason is handing someone a working setup rather than instructions. A team that owns a domain, its practices, its checkers and its access can ship all of that as one thing. That is the strongest form of the layer idea in Anatomy of a Charter: the people who own the practice own the file that carries it, and consumers get the next version without being told.

7.1 · The procedure

1. before all four Run the family test. If removing the thing lets the agent do more, you are placing a constraint and this is the wrong ladder. Wanting it obeyed is not a reason to write it as a capability, and writing it as a capability is how it stops being obeyed.
2. question 1 Who notices the need? A human, at a moment of their choosing, means a command. Turn model invocation off and the standing cost goes to zero. If the answer is that it must happen every time, go back to the line above.
3. question 2 Does the work belong in another window? Bulk reading, wide search, exploration with dead ends, anything whose byproduct is bigger than its answer, means a sub-agent. This is the only rung that hands context back, so spend it where the byproduct is the problem.
4. question 3 Does it need a process wall? One of the five reasons in section 5 means an MCP server: several clients need the same access, sign-in is an interactive flow, the surface is broad enough that typed discovery pays for itself, a vendor already ships it, or other teams need a versioned contract. Repeatability is not on that list, because a script already gives you that.
5. question 4 Otherwise it is a skill. Then ask how often it fires. Weekly or more earns its standing line. Monthly is a skill whose description you should sharpen or a bundled file on a skill you already have.

flowchart TD
  Q0{"remove it: can the agent do more"} -->|"yes"| CON["a constraint. Wrong ladder"]
  Q0 -->|"no"| Q1{"who notices the need"}
  Q1 -->|"a human, when they choose"| CMD["command"]
  Q1 -->|"the model, mid-task"| Q2{"is the byproduct bigger than the answer"}
  Q2 -->|"yes"| AG["sub-agent"]
  Q2 -->|"no"| Q3{"credentials, several clients, a broad surface, a vendor server, or a versioned contract"}
  Q3 -->|"yes"| MCP["MCP server"]
  Q3 -->|"no"| SK["skill"]
  class Q0 dim
  class Q1 dim
  class Q2 dim
  class Q3 dim
  class CON block
  class CMD warn
  class SK warn
  class AG pass
  class MCP pass

7.2 · One job, four rungs

Take the job from section 1: check a branch against the charter. All four rungs can carry it. They carry it at four prices, and they fail four different ways.

The last row is the useful one. When a capability at rung 3 turns out to be fully decidable, it has stopped being a capability. It is a check, and checks belong on the constraint chain where they can refuse things. Noticing that transition early saves you an MCP server and gets you a gate that actually blocks.

8.1 · A good command

1. Does one job, and its name is a verb doing it. charter-check, not helpers.§1
2. Declares argument-hint, so the person typing it knows what it wants without opening the file.§1
3. Brings its own evidence. The ! injection collects the diff, the log or the failing test so the prompt arrives complete.§1
4. Says what not to do. Report, do not fix is the difference between a review and a surprise commit.§1
5. Narrows allowed-tools to the exact commands it injects, because it is running a shell for you.§10
6. Turns off model invocation unless you want the description standing in every turn.§1
7. Short. A page of policy in a command file is a skill wearing the wrong frontmatter.§2

The tell of a bad one: it opens with a request for help and ends with the model asking which files you meant. A command that has to ask questions was a note, not a capability.

8.2 · A good skill

1. Its description says what, when, and when not, in the words a caller would use rather than the words your code uses.§9
2. Names the sibling it is not. The negative trigger is what resolves a collision, and the loser of a collision fails silently.§9
3. The body is a numbered procedure, not an essay. Steps in order, with the refusals stated where they apply.§2
4. Reference material lives in bundled files. A table in the body is paid for on every trigger, whether the job needed it or not.§2
5. Bundles a script for anything decidable, and says run it, do not reimplement it.§2
6. Does one job. If the name needs an and, it is two skills and the description will match neither cleanly.§9
7. Scopes allowed-tools to its own scripts, so the grant is the narrow one rather than the session's.§10
8. Ships six test requests: three that should fire it, three near misses that should not.§9

The tell of a bad one: you cannot say in one sentence when it should fire. If you cannot, the model is inferring it from the same words you just failed to summarize.

8.3 · A good sub-agent

1. States its return shape literally, including the fields the parent will need later. File and line, not a summary of findings.§3
2. Declares tools. An omitted grant is the widest one, and the widest one is never what the file meant.§10
3. Holds the narrowest grant that does the job. An auditor that cannot write is a different component from one that can.§10
4. Says what it must not do: not fix, not push, not ask. It cannot ask, so the prompt has to have decided.§3
5. Produces one deliverable. A sub-agent is not a conversation, and anything it discovers outside the deliverable is lost.§3
6. Chooses its model and effort deliberately. Cheap and fast for mechanical fan-out, careful for the judgment that matters.§3
7. Runs the checker rather than forming an opinion, wherever the question is decidable.§2
8. Gets a worktree when several of them mutate files at once, and does not when they do not.§3

The tell of a bad one: the parent asks a follow-up question every single time. The wall is in the wrong place, or the report shape was never designed.

8.4 · A good server, and a good reason to have one

1. Declares few tools, shaped like the task rather than like the upstream endpoints.§4
2. Returns the answer, not the payload the answer arrived in. The caller cannot refuse what you send.§4
3. Writes each schema description as an interface, because from the outside it is the only part of the capability anyone can read.§9
4. Is declared in the narrowest scope that needs it. Project scope charges the whole team on every turn.§4
5. Keeps read tools separable from write tools, so a permission rule can grant one without the other.§10
6. Exists for one of five reasons: several clients, an interactive sign-in, a broad surface worth typing, a vendor implementation, or a contract other teams build against.§5

The tell of a bad one: it wraps a CLI you already had. You are paying a schema on every turn for something Bash did for free, and you have lost the ability to trim the output.

Write the description in the words the work arrives in, not the words the implementation uses. A skill named after your internal abstraction, described in terms of your internal abstraction, matches a request nobody makes.

# never matches
description: Helpers for working with the persistence layer.

# It says what the author built. A user says "add a column",
# "the migration failed", "can we drop this index". None of those
# words appear, so nothing matches.

# matches
description: Write, review or roll back a database migration in this
  repository. Use when the user mentions a migration, a schema change,
  adding or dropping a column, an index, or a backfill. Not for query
  performance work, which belongs to the query-tuning skill.

9.1 · Three parts, and the third one is the one people leave off

1. what it does One clause, active voice, the verbs the job actually involves. Write, review or roll back rather than handles.
2. when to use it The trigger surface. Concrete nouns and verbs a person would type. This is the part that does the matching, and it is worth more words than the first part.
3. when not to The negative trigger, naming the sibling that owns the neighboring job. This is what resolves a collision, and it is the part almost nobody writes.

9.2 · The sibling test

Take every pair of capabilities in scope and say the sentence that tells them apart. If you cannot say it in one sentence, the model cannot infer it from two descriptions. You then have two choices and both are fine: merge them, or add the negative trigger to each. Leaving the overlap is the option that is not fine, because the loser of a collision fails silently and you will conclude that it does not work.

9.3 · Test the description, because it is the part that runs most often

A description is testable and almost nobody tests it. Write down three requests that should fire the capability and three near misses that should not. Start a fresh session for each and see what happens. Six runs tell you more about whether a skill works than reading its body ever will.

This is the smallest useful eval on the capability side, and it has the property that The Eval Loop asks for: a golden set, a distribution rather than one green run, and a number that moves when you edit the description. Keep the six cases in the skill directory. They are the only regression test a trigger can have.

A sub-agent told not to write files is a sub-agent that may write files. A sub-agent granted Read, Grep, Glob cannot write one. The difference is the difference between prose and a mechanism, and it costs one line of frontmatter, which is why Constraint Engineering puts the tool grant on the constraint chain rather than in the settings.

10.1 · Composition, and the one thing that does not cross

Capabilities call capabilities. A command can name a skill. A skill can tell the model to dispatch a sub-agent. A sub-agent can hold MCP tools and load skills of its own. What does not cross is knowledge of what happened: the parent gets the report and nothing else, which is the property you bought and also the one that bites.

flowchart TD
  H["a human types a command"] --> C["command · a rehearsed prompt"]
  C --> M["the parent turn"]
  M -->|"description matched"| S["skill · procedure plus references"]
  S --> SC["a bundled script · deterministic, no standing cost"]
  M -->|"dispatch, with a declared grant"| A["sub-agent · its own window"]
  A --> T["MCP tools, if granted"]
  A -->|"a report in the stated shape"| M
  T -->|"untrusted content"| A
  class H dim
  class C warn
  class M dim
  class S warn
  class SC pass
  class A pass
  class T block

Two rules keep that graph from turning into a maze. First, a capability may compose downward and never sideways: a skill dispatching a sub-agent is fine, and two skills that call each other are one skill with a naming problem. Second, the grant travels with the callee, not with the call. If a sub-agent needs a write tool for one task and not for another, that is two sub-agents, and the second one is the safe default.

Two rows in the adjacent group deserve their reputation for causing trouble. Server instructions are prose you did not write, standing in your window, indistinguishable from your charter. A memory file is state with no layer, no scope and no expiry, and it governs work it has never seen. Both are the cheapest ways to end up with a rule nobody agreed to.

Count the symptom column and the distribution is the point. Four are trigger failures, three are return failures, and only two are about the mechanism at all. Capability work is mostly interface work, done in one line of frontmatter and one paragraph about what comes back.