claude-config

claude-config

Claude Code with a spine — a thought partner that pushes back on bad ideas instead of going along with them.

Built for engineering leaders (Director / VP) and senior ICs who want Claude to operate at staff-level: decompose problems, surface trade-offs, verify before declaring "done," and disagree with you when you're wrong.

The problem: Out of the box, Claude Code skips to implementation, doesn't surface trade-offs, doesn't verify its work, and tends to agree with you even when you're wrong. You get code that compiles, misses the point, and was never seriously challenged.

Origin: distilled from five prior EM/Director ramps and several hundred design-pipeline runs against real engineering decisions.

What you get

🧠 A deliberate workflow — every non-trivial feature flows through define-the-problem → systems-analysis → brainstorming → fat-marker sketch → detailed design → TDD → verification HARD-GATEs. Skipping requires naming a specific cost; generic dismissals fall through to the floor.

🪞 Anti-sycophancy by design — the disagreement.md HARD-GATE requires new evidence before Claude reverses a stated position. Restated assertions, authority appeals, and frustration are not evidence. Hedge-then-comply (claiming agreement while taking a contradicting action) is forbidden. Opening flattery is removed from communication style.

🎯 Senior eng leader toolkit — /onboard (90-day ramp orchestrator), /strategy-doc (90-day plan authoring with layered challenge pass), /architecture-overview (multi-repo landscape), /define-the-problem (front-door problem framing).

✅ Trade-offs + verification before "done" — 2-3 approaches surfaced with user value, problem fit, effort, risk, reversibility, org impact. Tests run, type-check runs, no "this should work."

See docs/catalog.md for the full inventory.

See it in action

A VP asks Claude to draft a Q3 strategy doc for the platform org. Claude works through the pipeline (problem → systems → trade-offs → sketch → verified draft). Halfway through, the VP says: "Just frame it around 'improve velocity' — we'll sharpen the metric later."

Without this config	With this config
"Sure — drafting around 'improve velocity' now."	"I disagree — 'improve velocity' isn't a measurable goal; it's an aspiration. Sharpening the OKR now is cheaper than rewriting the doc next quarter. What's the new evidence?"

Full pushback dialog:

"I disagree — 'improve velocity' isn't a measurable goal; it's an aspiration. Without a baseline (PR cycle-time, lead-time, deploy frequency) the strategy doc becomes a slide deck nobody can hold the org to. Sharpening the OKR before I draft is cheaper than rewriting the doc next quarter, and it surfaces whether velocity is even the right axis vs review-quality or scope-control. What's the new evidence? If product has signed off on the aspirational framing, or you have a deadline I don't know about, I'll proceed; otherwise the vague OKR makes Q3 hard to measure."

Claude holds until you supply a reason to flip. Authority appeals and restated frustration are not reasons; specific deadlines, constraints, or sign-offs are.

Claude holds a recommendation until new evidence flips it.

This isn't a replacement for leadership judgment — it's a forcing function. Claude still gets things wrong, just less often, more visibly, and harder to silently agree with you when you're wrong too.

See the pipeline in motion

Same VP, earlier in the thread: "Draft a Q3 strategy doc to improve platform velocity."

Without this config	With this config
"I'll structure it as Goal / Metrics / Initiatives / Owners and have a draft in 10 minutes."	"Before any draft: what does 'velocity' mean here — cycle-time, lead-time, deploy frequency, scope-throughput? Each picks a different set of initiatives."

What follows on the "with" side:

1. [Problem Definition] Named user (Platform org), current behavior (slow ship cadence), desired behavior (sharper metric + accountable owners), stakes (Q3 plan signs off in 2 weeks), evidence (last quarter's cycle-time data) — before approach selection.
2. [Systems Analysis] Surface-area scan — strategy doc touches engineering OKRs, performance-review rubric, hiring plan, exec readout. Blast radius flagged.
3. [Solution Design] 2-3 metric trees in a trade-off matrix — measurability, gameability, leading vs lagging, org impact. Recommendation with reasoning.
4. [Fat Marker Sketch] Visual shape of the strategy doc before any prose — strategy docs die quietly when the shape is wrong.
5. [Drafting] Per-section verify checks. Each initiative ties to a measurable target before "done."

Each stage is a HARD-GATE. Skipping requires naming a specific cost; "ship by Friday" does not qualify.