aaddrick The Improvement Loop
Overview
Improve the .claude/ pipeline after resolving the issue at hand — never during. When a skill, agent, hook, or script produces bad output, work through to the correct solution first, then update the pipeline with what you learned.
Core principle: Fix first, understand fully, improve last. Premature edits encode partial understanding.
When to Use
digraph when_to_use {
"Issue resolved successfully?" [shape=diamond];
"Root cause in pipeline file?" [shape=diamond];
"Worth encoding permanently?" [shape=diamond];
"Run improvement cycle" [shape=box style=filled fillcolor=lightgreen];
"Keep working on the issue" [shape=box];
"Skip - not a pipeline problem" [shape=box];
"Skip - one-off or too specific" [shape=box];
"Issue resolved successfully?" -> "Root cause in pipeline file?" [label="yes"];
"Issue resolved successfully?" -> "Keep working on the issue" [label="no - finish first"];
"Root cause in pipeline file?" -> "Worth encoding permanently?" [label="yes"];
"Root cause in pipeline file?" -> "Skip - not a pipeline problem" [label="no"];
"Worth encoding permanently?" -> "Run improvement cycle" [label="yes"];
"Worth encoding permanently?" -> "Skip - one-off or too specific" [label="no"];
}
Trigger conditions (suggest to user):
- An agent produced incorrect output that required manual correction
- A skill was missing guidance that caused a wrong approach
- The same mistake has occurred more than once across sessions
- A hook failed to catch something it should have
- A subagent asked questions that the agent definition should have answered
- Review feedback repeatedly flags the same class of issue
Do NOT trigger:
- While still debugging or iterating on the original issue
- For one-off problems unlikely to recur
- For issues outside the pipeline (user error, external service failures)
- When the fix is a code change, not a pipeline change
The Gate: Is the Issue Resolved?
This check is mandatory before any improvement work.
digraph gate_check {
"Original task/issue complete?" [shape=diamond];
"Tests passing?" [shape=diamond];
"User confirmed resolution?" [shape=diamond];
"GATE PASSED - proceed to improvement" [shape=box style=filled fillcolor=lightgreen];
"STOP - return to the issue" [shape=box style=filled fillcolor=salmon];
"Original task/issue complete?" -> "Tests passing?" [label="yes"];
"Original task/issue complete?" -> "STOP - return to the issue" [label="no"];
"Tests passing?" -> "User confirmed resolution?" [label="yes"];
"Tests passing?" -> "STOP - return to the issue" [label="no"];
"User confirmed resolution?" -> "GATE PASSED - proceed to improvement" [label="yes"];
"User confirmed resolution?" -> "STOP - return to the issue" [label="no/unclear"];
}
Verify ALL of these before proceeding:
- The original task or issue is functionally complete
- All tests pass (
zig build test) - The user considers the issue resolved (ask if unclear)
If ANY check fails, stop. Return to the issue. Do not start improvement work.
Proactive Detection
When you observe improvement opportunities during normal work, do not act immediately. Instead:
- Note the opportunity — mentally flag what went wrong and which pipeline file is involved
- Finish the current task — complete whatever you're working on
- Ask the user — suggest the improvement explicitly:
I noticed [specific problem] while working on [task]. The root cause appears to be
[skill/agent/hook/script name] which [lacks guidance on X / has an anti-pattern gap /
doesn't handle Y].
Would you like me to run an improvement cycle to update it? This would involve:
- [Specific change: e.g., "adding a Zig-specific anti-pattern for memory leaks"]
- [Estimated scope: e.g., "a one-line addition to the agent's anti-patterns section"]
Always ask before starting. The user may want to defer, batch improvements, or handle it differently.
The Five-Step Cycle
Step 1: Capture the Problem
Document what happened before details fade:
- What went wrong: The specific incorrect output or behavior
- Which pipeline file: The skill, agent, hook, or script involved
- Root cause: Why the pipeline file led to the wrong outcome
- Correct solution: What the right approach turned out to be
- How you discovered it: The debugging path (helps write better guidance)
Step 2: Classify the Improvement
| Type | Target | Example |
|---|---|---|
| Anti-pattern | Agent definition | "NEVER use page_allocator in tests — use testing.allocator" |
| Missing guidance | Skill content | Add edge case handling for cmark-gfm C FFI |
| New trigger | Skill description | Add symptom that should invoke this skill |
| Hook gap | settings.json / hook script | Build check not catching a file type |
| Missing skill | New skill file | Technique not documented anywhere |
| Missing agent | New agent file | Specialized role not defined |
Step 3: Make the Minimal Change
Write the smallest change that prevents the problem from recurring.
- Anti-pattern? Add one entry to the agent's anti-patterns section
- Missing guidance? Add one paragraph or code example to the skill
- Hook gap? Add one condition to the hook script
Do NOT:
- Rewrite entire files while you're "in there"
- Add speculative guidance for problems that haven't occurred
- Refactor surrounding code that isn't related to the issue
Step 4: Verify the Change
Depending on the type of change:
| Change Type | Verification |
|---|---|
| Agent anti-pattern | Grep for conflicting guidance in the agent file |
| Skill content | Read the skill end-to-end — does the new content fit? |
| Hook logic | Run the hook manually with test input |
| New skill/agent | Follow writing-skills or writing-agents skill (includes testing) |
Step 5: Commit and Communicate
git add .claude/[changed-file]
git commit -m "improve: [file] - [what was added and why]"
Tell the user what was changed and why:
Updated [file] with [change]. This prevents [problem] which occurred during [task].
Routing to the Right Tool
| What Needs Changing | How to Change It |
|---|---|
| Existing skill (small edit) | Edit directly |
| Existing agent (small edit) | Edit directly |
| New skill | Invoke writing-skills skill |
| New agent | Invoke writing-agents skill |
| settings.json | Edit directly |
For new skills and agents: The writing-skills and writing-agents skills have their own TDD cycles. Follow them — don't shortcut.
Preventing Improvement Drift
Improvements can spiral. Guard against these anti-patterns:
| Anti-Pattern | Prevention |
|---|---|
| Yak shaving — improving A leads to improving B leads to C... | One improvement per cycle. If you discover more, note them and ask the user about a separate cycle. |
| Speculative improvements — "while I'm here, let me also..." | Only fix the problem that actually occurred. YAGNI applies to pipeline improvements too. |
| Encoding partial understanding — improving before fully resolving | The gate check (Step 0) prevents this. Never skip it. |
| Over-engineering — turning a one-line anti-pattern into a new skill | Match the weight of the fix to the weight of the problem. |
| Stale improvements — guidance that was correct once but isn't anymore | When you notice outdated guidance during work, flag it as an improvement opportunity. |
Batching Improvements
When multiple improvement opportunities arise in one session:
- Note each one as you encounter it (don't act)
- Finish the current work completely
- Present the batch to the user:
I identified 3 potential pipeline improvements during this session:
1. [agent-name]: Missing anti-pattern for [X] (occurred during task Y)
2. [skill-name]: Edge case not covered for [Z] (caused wrong approach in task W)
3. [hook]: Not catching [file type] (missed formatting on 2 files)
Would you like me to address these? I can handle them as:
a) One batch (fastest, ~5 min)
b) Individual cycles (most thorough)
c) Skip for now
Red Flags
- Improving while the issue is unresolved — STOP. Fix the issue first. This is the #1 violation.
- Making changes without asking — Always ask the user before starting improvement work.
- Improving after a single occurrence — One instance rarely justifies a pipeline change. Note it and watch for recurrence.
- Rewriting instead of appending — Most improvements are additions (anti-patterns, guidance, examples), not rewrites.
- Skipping verification — An untested improvement can introduce new problems.
Key Insight
"When a skill or agent produces bad output, don't immediately edit it. Work through to the correct solution first. Then update the skill with what you learned."
The instinct to jump into the pipeline file and tweak is strong. Resist it. Partial understanding encoded as guidance creates more problems than it solves. The improvement only becomes reliable after full resolution.