Steering is the axis that determines runtime predictability — whether the agent does what you meant, every time, or drifts. Lesson 1 gave you the vocabulary. This lesson teaches you to wield three specific levers and cure two failure modes.
A leading word is a concept already in the model's pretraining that anchors behaviour cheaply. It buys you reliable steering without spending tokens explaining what you mean.
The model already knows what "bisect" means, what "tracer bullet" means, what "fog of war" means. Using these costs fewer tokens and gets more reliable behaviour than inventing your own vocabulary. Coined words carry no free priors — you have to pay to explain them.
Look at your diagnose skill. It's packed with leading words:
## Phase 1 — Build a feedback loop
**This is the skill.** If you have a fast, deterministic pass/fail signal,
you will find the cause. If you don't, no amount of staring at code will save you.
The phrase "feedback loop" does enormous work. The model already associates it with: iteration, fast cycles, measurable signal, tight cause-and-effect. One term anchors an entire phase's behaviour. Compare that to writing "repeatedly run the test and check if it passes" — same meaning, worse steering, more tokens.
More leading words in the same skill: "bisect", "regression test", "property/fuzz loop", "differential loop", "falsifiable hypothesis". Each one compresses paragraphs of instruction into a concept the model already owns.
A completion criterion tells the agent when a step is genuinely done. Without one, the agent decides for itself — and it will decide too early.
Contrast two skills:
7. Continue until all branches
are explored and shared
understanding is reached
Cannot build a loop? Stop and
say so. List what you tried.
Ask for: (a) access to the
reproducing environment,
(b) captured artifacts, or
(c) permission for temporary
instrumentation.
The grill-me criterion — "shared understanding is reached" — is unfalsifiable. The agent can declare it done at any point. It has no way to verify the claim.
The diagnose criterion is crystal clear: you either have a pass/fail signal or you don't. If you don't, the skill tells you exactly what to do (stop, list, ask). There's no room for premature completion.
Ask: "Could the agent declare this done fraudulently?" If yes, your criterion is too vague. Make it observable: a file exists, a test passes, a list has N items, the user explicitly confirmed.
Legwork is the work the agent does within a step instead of offloading it to the user. More legwork = the agent earns its keep.
In grill-me, step 4 from quick_start says:
If a question can be answered by exploring the codebase,
explore the codebase instead
This is excellent legwork instruction — it tells the agent to do the work rather than asking the user. But it's buried in a "quick start" section with no completion criterion. When does the agent stop exploring? What counts as "answered"?
The agent ends a step before it's genuinely done because attention slips ahead to the next step. Cure: sharpen the completion criterion, and only if that's insufficient, hide later steps via progressive disclosure.
Your grill-me skill is susceptible. Its workflow lists all 7 steps upfront. By step 3, the agent can see step 7 ("shared understanding reached") pulling it forward. The post-completion steps are visible and attractive — the agent wants to finish.
Naming what NOT to do drags it into the model's attention frame. The prohibited action becomes more available, not less.
From your handoff skill (lesson 1):
Do not duplicate content already
in PRDs, plans, ADRs, issues,
commits, or diffs
Reference existing artifacts by
path or URL instead of restating
their content
The reframe gives the agent a target (reference by path) instead of an avoidance (don't duplicate). The model now knows what to do, not what to avoid.
"Do NOT push to main" is a guardrail — a hard boundary. That's different from "don't duplicate content" which is a quality preference. Guardrails can stay negative because the consequences of violation are severe. Quality preferences should be reframed positively.
grill-meLet's apply what we've learned. Here's the current grill-me workflow:
1. Identify the plan or design being discussed
2. Map the decision tree — what are the major branches?
3. For each branch, ask targeted questions that expose assumptions
4. Provide a recommended answer with each question
5. Wait for user response before proceeding
6. Resolve dependencies between decisions sequentially
7. Continue until all branches are explored and shared understanding is reached
Problems:
Proposed refactor:
<workflow>
1. Identify the plan or design under examination
2. Map the decision tree — enumerate the major branches
(completion: a numbered list of branches is stated to the user)
3. For each branch, ask targeted questions that expose unstated assumptions
- Provide a recommended answer with each question
- Wait for user response before the next question
- If the question can be answered by exploring the codebase, do the legwork
(completion: user explicitly confirms the branch is resolved, or says "skip")
4. After all branches: state the resolved design as a single summary
(completion: user confirms the summary or requests corrections)
</workflow>
What changed:
Open ~/.kiro/skills/grill-me/SKILL.md and apply the refactor from this lesson. Then pick one more skill and:
writing-great-skills GLOSSARY.md — Matt Pocock. Read the "Steering" section entries: Branch, Leading Word, Completion Criterion, Legwork, Premature Completion, Negation. ~3 min read.