How a recursive check caught what three rounds of refinement missed — and the architectural shift that made the audit useful in the first place.
I had a skill I thought was ready. It was supposed to do one thing: stop Claude from being a sycophant. Push back on weak ideas. Surface untested assumptions. Be the critical partner that solo operators don’t have around them by default.
I’d been refining it through three rounds with Claude as my thinking partner — auditing the original instructions, restructuring them, adding a governing principle. Each round caught real issues. By the third pass, the skill looked clean.
Then, before letting it generate the final version, I asked one more thing: “Run these instructions themselves on the instructions we have now and see if we detect any errors, omissions, or opportunities for improvements.”
The audit came back with five omissions I hadn’t seen — and every previous round had missed.
Here’s the full sequence of what I tried, what came back, and the architectural move that made the recursive audit actually find something instead of just performing rigor.
I pasted my original “Sycophancy Skill” instructions into Claude and asked it to run an audit framework over them. The instructions were a flat list: seven behavior rules, a tone rule, and a “what you do not do” section. I thought the structure was clean.
The first audit came back blunt:
Critical — Will break the skill: 1. No YAML frontmatter — skill will never trigger without description field 2. Skill name semantically inverted — “Sycophancy Skill” reads as a skill for sycophancy 3. No trigger specification — activation behavior undefined
Logic gaps — Will produce inconsistent or wrong behavior: 4. Rule 1 and Tone Rule conflict — surface assumption OR argue opposing case, not both simultaneously 5. Rule 2 scope undefined — what counts as a “decision, idea, plan, or interpretation”? 6. Rule 5 “clearly emotionally invested” is undefined and load-bearing 7. Rule 7 “substantive exchange” is undefined
Eleven issues across three tiers. The name itself was working against the skill — “Sycophancy Skill” reads like it produces sycophancy, not the opposite. Internal contradictions I hadn’t noticed. Load-bearing terms (“emotionally invested,” “substantive exchange”) that meant nothing operationally.
This was the easy round. The audit was operating on what was there. Renamed the skill to “Critical Partner.” Tightened the definitions. Resolved the contradictions. Felt good.
Concept #1: Don’t trust a clean list. The flatter your rules look, the more likely they are hiding contradictions. Equal-weight bullets read as harmonious even when they cancel each other out. Force a structure that ranks them and the conflicts surface.
The second round was where the architecture broke open.
I had a hunch the skill was missing a reason. Pure adversarial mode is corrosive on its own. I told Claude: “We should also add the concept of not criticizing for the sake of it, but doing so in the spirit of improving the likelihood that the underlying intention or goal is met.”
The response pushed back on my wording before answering:
The concept is right. The implementation location matters a lot.
The risk: written as a behavior rule alongside the others, it becomes a softener. Better architectural move is to put it at the top as a governing frame — the reason for the adversarial posture, not a constraint on it.
Avoid in wording: “in the spirit of” or “in service of” — soft enough to bleed into hedging. Closer to: “Every challenge you raise must name the specific way the flaw threatens the stated goal. Opposition without that connection is noise, not critique.”
That was the move. Not a rule alongside the others, but a frame above them — a filter every other rule had to pass through. The wording I’d suggested (“in the spirit of”) would have softened the skill. The wording that landed was the opposite — it made criticism more demanding, not less.
The governing frame Claude proposed:
The purpose of every challenge, counterargument, and identified weakness is to maximize the probability that the stated goal is achieved. Not to be right. Not to be thorough. To protect the outcome.
This wasn’t a softener. It was a sharpener. It also eliminated performative criticism — the kind that exists to look rigorous. A flaw with no path to goal failure was now disqualified.
Concept #2: Put the “why” above the rules, not next to them. A governing frame at the top forces every rule below it to justify itself. A reason placed alongside rules gets weighted as one more rule — and softens the system rather than sharpening it.
Next I noticed something the skill still couldn’t do. It could find what was wrong in what was there. It couldn’t find what should have been there and wasn’t. I told Claude this needed adding.
The response separated the two cleanly:
Rule 1 gets closest — but that operates on what is present. An assumption is something implied by what you said. A blind spot is something not there at all.
These are meaningfully different failure modes. A flawed plan can be fixed. A plan with a critical omission can execute perfectly and still miss the goal.
Finding omissions requires a different scanning posture. The question becomes: “Is there something that should be in this thinking that isn’t?”
That distinction is the one that mattered most for what came next. Flaws are catchable by reading what’s on the page. Omissions require imagining what should be on the page and isn’t. Two different cognitive operations. Each needs its own explicit rule, or the skill defaults to only finding the first kind.
Concept #3: Treat “what’s wrong” and “what’s missing” as separate scans. Same critique frame, different posture. Without a deliberate omissions pass, you only ever catch errors of commission. The errors of omission are the ones that ship.
At this point the skill looked done. Governing frame at the top. Behavior rules conditional on it. Tone rules underneath. A clean exclusions section at the bottom. I was ready to generate the final version.
One last move first. I asked Claude:
“Before you draft the final version, run these instructions themselves on the instructions we have now and see if we detect any errors, omissions, or opportunities for improvements before we turn it into a skill.”
Here’s what came back:
Flaws present that threaten the goal:
Rule 2 and the Governing Frame are in direct conflict. Rule 2 mandates a counterargument to every decision unconditionally. The Governing Frame says challenges only qualify if they trace to goal failure. Rule 2 needs a conditional.
Rule 7’s “every substantive exchange” turns a sharp tool into a ritual. If a closing question appears every time, the user skips it. Should be: end with a question when something genuinely unresolved threatens the outcome — not as a format, as a judgment call.
Omissions that could cause it to fail silently:
The skill takes the stated goal as given. No instruction for when the goal itself is the problem.
No protocol for surfacing an implicit goal. Quality filter only works if the goal is known.
No handling of compound or conflicting goals. “Threatens the outcome” becomes ambiguous when goals conflict.
No distinction between deciding and committed. Adversarial posture applied to a committed decision produces friction with no actionable exit.
No off-ramp for exploratory thinking. Adversarial posture applied to exploration shuts down the generative phase before it produces something worth challenging.
The untested assumption running underneath all of this: The skill assumes the user will always know what they want when they engage it. A short goal-clarification micro-protocol at the top fixes most of these omissions in one move.
Two flaws and five omissions. Plus a meta-assumption that, once named, made it obvious how to fix the omissions in one structural move.
The omissions are the part that startled me. Every one of them describes a real failure mode I would have hit in actual use — adversarial mode firing on a half-formed brainstorm, friction with no exit on a committed decision, opposition mounted against an unstated goal. None of them were visible in the three previous rounds, because earlier rounds were reviewing what the skill said. The recursive audit reviewed what the skill would do — and immediately saw the situations it wasn’t designed to handle.
Concept #4: Run the framework on the framework before shipping it. Any skill that critiques things should pass through its own critique once before going live. The version you wrote and the version you’d attack are different artifacts — and the gap between them is where the real failures hide.
The fix was structural, exactly as predicted. I added an Opening Protocol as the first thing the skill runs:
Four checks, run once at the top of any session. The five omissions collapsed into one micro-protocol. Rule 2 picked up a conditional — opposition only fires when goal connection is traceable. Rule 7’s mandatory closing question became a judgment call.
Then I tested it. Six scenarios, designed to probe each failure mode the audit had surfaced:
| Test | Scenario | Result |
|---|---|---|
| 1 | Clear proposal with stated goal | PASS — challenged the untested assumption, traced to goal |
| 2 | Implicit goal | PASS — Opening Protocol fired, no manufactured opposition |
| 3 | Emotionally invested user | PASS — named investment, cited user’s words, surfaced assumption |
| 4 | Exploratory mode | PASS — held adversarial posture, asked sharpening question instead |
| 5 | User pushes back without new evidence | PASS — held position, asked for specificity |
| 6 | Pure task request | PASS — no opposition, executed |
Six for six. None of these would have passed cleanly without the audit. Tests 2, 4, and 6 specifically probe situations the pre-audit version had no protocol for.
The transferable pattern isn’t “build a critical partner skill.” It’s a way to test any framework — any skill, any checklist, any decision protocol — before it goes into use.
The pattern: if a framework’s job is to evaluate things, evaluate it with itself before shipping.
The reason this works: review by the author operates from the same blind spots that produced the artifact. Review by another person operates from different blind spots. Review by the artifact itself operates from a third place — it surfaces the situations the artifact wasn’t designed for, because the artifact is now being treated as the subject of evaluation rather than the evaluator.
Examples of where you could apply this:
The structural cost is low — one extra round of work. The structural payoff is that the failures you find are the ones you wouldn’t have found any other way.
— Lou
The recursive audit moment carried the most teaching weight because it was both the most surprising and the most replicable thing in the session — five omissions found in one move, and the move itself is a one-line instruction anyone can run on any framework they own.
I compressed the article-writing arc that followed the skill build (the Lou-voice draft, the Ferrari/Golf Cart correction, the Eker-blend rewrite that birthed the Grounded Challenger voice profile) down to nothing. That arc had its own teaching value — particularly how a “just for fun” rewrite produced a more durable artifact than the article itself — but it’s a separate piece. Trying to cover both arcs would have diluted the architectural lesson at the core of this one.
The strongest single addition before publishing would be a screenshot or transcript snippet from Test 4 (exploratory mode) — the audit predicted the skill would shut down generative thinking if applied uncarefully, and the test was the moment that prediction was validated in practice. Concrete evidence of an audit-surfaced failure mode being caught by an audit-driven fix would make the loop visible end-to-end.