The Pruning Discipline

Lesson 3 · Building Better Skills & Agents · ~15 minutes

Every line in a skill file has a cost. Not just the obvious cost (tokens consumed) but two hidden costs that compound silently: maintenance burden and inflated importance. This lesson gives you the discipline to cut — confidently, methodically, and without fear of breaking what works.

The Cost Model

A single line in a skill file pays three costs simultaneously:

1. Token Cost

Every line occupies context window space. With 30+ skills, each unnecessary line is multiplied across every session. A 10-line no-op section across 30 skills is 300 lines of dead weight — every turn.

2. Maintenance Cost

Every line must be kept consistent with the rest. When you change the skill's behaviour, you must update every line that references that behaviour. More lines = more places to forget.

3. Inflated Importance

The model treats all content with roughly equal weight. A no-op instruction sitting next to a critical steering rule dilutes the critical rule's signal. The more noise, the less the agent attends to what matters.

The math is simple

If you can remove a line without changing behaviour, keeping it actively hurts the skill. It's not neutral — it's negative value. You're paying three costs for zero benefit.

Three Failure Modes

Lines accumulate in skills through three distinct mechanisms. Recognising which one you're looking at determines the remedy.

Sediment

Definition: Old content that was relevant once but never got cleared. It accumulates because adding feels safe while removing feels risky.

How to spot it: Read each line and ask "Does this reflect how the skill currently works?" If it reflects a previous version of the skill's behaviour, it's sediment.

Pattern to grep for: Rules that contradict other rules. Instructions that reference features or workflows that no longer exist. Caveats about edge cases you've since handled differently.

Duplication

Definition: The same meaning expressed in multiple places. Often one in the objective, another in the workflow, a third in the rules.

How to spot it: The single-source test — "Is this meaning stated anywhere else in this file?" If yes, pick one location and delete the rest.

Pattern to grep for: Paraphrased versions of the same instruction. An objective that restates what the workflow already says step-by-step. Rules that echo what the success criteria already require.

No-Op

Definition: An instruction that changes nothing because the model already does it by default. You pay token cost for zero behavioural change.

How to spot it: The deletion test — "If I remove this line, what changes?" If the answer is "nothing, the model would do this anyway," it's a no-op.

Pattern to grep for: "Write clean code", "Be helpful", "Follow best practices", "Use proper error handling", "Think step by step", "Be thorough".

The Two Tests

The Deletion Test

For every line: "If I remove this, what changes in the skill's output?"

The Single-Source Test

For every line: "Is this meaning stated anywhere else in this skill?"

Live Example: The architect Skill

Let's apply pruning discipline to a real skill. Here's an excerpt from the architect skill's workflow "During the session" section:

~/.kiro/skills/architect/SKILL.md — "During the session" rules - **Challenge assumptions** — When the user assumes a technology or pattern, ask why. There may be a simpler path. - **Deletion over addition** — Propose removing existing complexity when simpler alternatives exist. - **AWS-native by default** — Reach for AWS managed services before custom implementations. A managed service you don't operate is always simpler than one you do. - **Ask which language** — Confirm the implementation language before designing. Don't assume. - **Cross-reference with code** — When the user states how something works, check whether the code agrees. - **Update CONTEXT.md** — When new terms or bounded contexts emerge, capture them immediately. - **Offer ADRs** — When a design decision is hard to reverse, surprising without context, and the result of a real trade-off. - **Mark deliberate simplifications** — Note where the design is intentionally simple with the ceiling and upgrade path.

Let's classify each rule:

RuleTest ResultVerdict
"Challenge assumptions" Deletion test: would the model challenge assumptions without this? Partially — but the specific framing "ask why, there may be a simpler path" steers toward a behaviour the model might not default to. Keep Load-bearing — shapes a specific conversational behaviour.
"Deletion over addition" Single-source test: Is this stated elsewhere? Yes — the architecture ladder step 1 ("Does this component need to exist?") and the ponytail dependency both convey this principle. Delete Duplication — the ladder already embodies this principle structurally.
"AWS-native by default" Deletion test: Without this, would the model reach for AWS services? Only if the user context implies it. This rule creates a default preference. Keep Load-bearing — sets a default that wouldn't exist otherwise.
"Ask which language" Deletion test: Would the model ask? Maybe. But this is a one-liner that prevents a common failure (assuming Go). High value per token. Keep Load-bearing — prevents a specific, known failure.
"Cross-reference with code" Deletion test: Would the model verify claims against code? Not reliably. This makes verification a habit, not an afterthought. Keep Load-bearing — models often accept user claims at face value.
"Update CONTEXT.md" Deletion test: Would the model proactively update CONTEXT.md? No — this is a side-effect instruction that creates a valuable habit. Relocate Right content, wrong place — should be a workflow step, not a bullet in "during the session."
"Offer ADRs" Same as above — a proactive side-effect. But the criteria are clear and specific: "hard to reverse, surprising, real trade-off." Keep Load-bearing — specific trigger criteria the model wouldn't infer.
"Mark deliberate simplifications" Single-source test: The output format template already has a "Deliberate Simplifications" table with columns for Ceiling and Upgrade When. Delete Duplication — the output template already enforces this.

The Pruning Decision Framework

Every line gets one of three verdicts:

VerdictMeaningAction
KeepLoad-bearing — removing it changes behaviour for the worseLeave it. Ensure it's in the right location.
RelocateRight content, wrong place — it belongs in a different sectionMove it. Often: from rules → workflow step, or from inline → REFERENCE.md
DeleteNo-op, sediment, or duplicate — paying cost for no valueRemove it. If nervous, check the deletion test one more time.

Before & After

Here's the architect's "During the session" section after pruning:

Before (8 rules, ~120 words)

- Challenge assumptions - Deletion over addition - AWS-native by default - Ask which language - Cross-reference with code - Update CONTEXT.md - Offer ADRs - Mark deliberate simplifications

After (5 rules, ~80 words)

- Challenge assumptions - AWS-native by default - Ask which language - Cross-reference with code - Offer ADRs

Three lines removed (37% reduction). "Update CONTEXT.md" was relocated to a workflow step. "Deletion over addition" and "Mark deliberate simplifications" were deleted as duplication. The remaining rules are all load-bearing — each one changes the model's behaviour in a way it wouldn't default to.

Check Your Understanding

A skill contains this rule: "Always validate user input before processing." You also have an objective that says "Process user requests safely and correctly." What failure mode is the rule?
Correct. Input validation is default model behaviour. The objective already implies it. This rule pays three costs (tokens, maintenance, dilution) for zero behavioural change. Delete it.
This is a No-Op. The model already validates input by default, and the objective covers "safe processing." The rule doesn't change behaviour — it just occupies space that dilutes the load-bearing rules around it.
Given this excerpt from a skill:

<objective> Produce concise, actionable code reviews. </objective>

Rules: - Keep reviews concise and actionable

What's the correct pruning verdict for the rule?
Correct. The single-source test catches this: the same meaning ("concise, actionable") is stated in both the objective and the rules. Pick one — the objective is the stronger location because it frames the entire skill. Delete the rule.
This is Duplication. The rule restates what the objective already says. "Reinforcement" is a myth — repetition doesn't make the model comply more, it just inflates the token cost and dilutes the surrounding content. One strong statement beats two weak ones.
Your architect skill has a rule: "Always consider scalability." Two months later you added the architecture ladder which explicitly asks "Does this handle real-world load?" at step 3. What's the old rule now?
Correct. This is sediment — it was genuinely useful before the ladder existed, but now the ladder structurally embodies the same concern in a stronger way. Sediment is content that was once load-bearing but got obsoleted by a better mechanism. Delete the old rule.
This is Sediment. It was legitimately load-bearing when first written, but the ladder's step 3 now handles scalability structurally. The old rule is now a leftover layer — it accumulated because adding the ladder didn't trigger a cleanup pass on existing rules.
You run the deletion test on this rule in a code-review skill: "Check the tests — Untested code is unfinished code. Missing tests for new logic is always a finding." Without this line, the model would sometimes skip test review. What's the verdict?
Correct. The deletion test is decisive: "If I remove this, what changes?" — the model sometimes skips test review. That means this line is load-bearing. It changes behaviour. Keep it.
The deletion test gives a clear answer here: removing the line changes behaviour (model skips test review). That makes it load-bearing. The rule earns its token cost by preventing a known failure. Keep it.

Your Exercise

  1. Pick your longest skill (by line count). Run wc -l ~/.kiro/skills/*/SKILL.md | sort -rn | head -5 to find it.
  2. For every rule or instruction, apply the deletion test: "If I remove this, what changes?"
  3. For anything that survives, apply the single-source test: "Is this meaning stated elsewhere?"
  4. Classify every line as Keep, Relocate, or Delete.
  5. Target a 20% line reduction. If you can't reach 20%, either your skill is already well-pruned or you're being too conservative with the deletion test.
📖 Primary Source

writing-great-skills GLOSSARY.md — Pruning section — Matt Pocock. The definitions of Sediment, Duplication, No-Op, Single Source of Truth, and Relevance. ~3 min read.

Questions? Paste any skill excerpt and I'll run the deletion test on every line — showing you which are load-bearing and which are paying rent for nothing.
← Prev Next →