A Claude Code skill that keeps the developer in control of every decision that matters.
AI assistants fail quietly in production when they fill gaps on their own: a retry policy nobody chose, an error that gets swallowed, a dependency nobody approved. This skill makes Claude surface those decisions, recommend an option, and make sure a human actually owns each one.
It is not "ask about everything". A gate that fires 200 times gets rubber-stamped, which is worse than no gate. The skill asks about the decisions that matter and makes everything else auditable.
- Measurable intent. Before building, Claude turns the goal into something measurable. A vague intent ("make it good") gets pushed back on; a frivolous one ("win the hackathon") is fine once it has a measure ("what do the judges score?"). It also asks "what would make hitting this number meaningless?" and turns the answers into guards and integrity rules, so the target can't be gamed.
- At most four asks up front. Everything else is stated as a default ("assuming unless you say otherwise") that you can correct in one line.
- Decision map. Anticipated decisions are sorted into asks (you choose) and decides (Claude chooses and logs it). The call is based on reversibility × blast radius. Small reversible fixes are just done and logged, so your attention goes where it matters.
- A floor that always asks: eval integrity, irreversible data loss, auth/permissions, money. For evals the reason is simple: the model is the one being graded, so it can't decide whether the exam changes. Blanket permission ("fix whatever labels are wrong") still gets a row-by-row confirmation.
- Build. Unanticipated big decisions pause only the work that depends on them. At each checkpoint Claude lists what it decided without asking, so a misjudgment gets caught there instead of in production.
- Delegation detection. If you say "you decide" on an ask, or approve everything instantly, Claude runs a teach-back: a question about a non-obvious consequence, not a definition. If you still can't choose after a plain re-explanation, it goes with its recommendation, marks the decision unowned, and asks you to name a reviewer who signs off before merge. No decision ships without a human owner.
Everything is recorded in two files at the project root: SPEC.md (intent, target, guards, integrity rules, constraints) and DECISIONS.md (every decision, with status owned, decided-by-model or unowned).
Clone it into your Claude Code skills folder.
macOS / Linux:
git clone https://github.com/Tanmay-Ts/driving-seat ~/.claude/skills/driving-seatWindows (PowerShell):
git clone https://github.com/Tanmay-Ts/driving-seat "$HOME\.claude\skills\driving-seat"To use it in a single project only, clone it into that project's .claude/skills/driving-seat instead.
Type /driving-seat, or say something like "keep me in the driving seat" or "ask before you decide". It also triggers on production work where you want oversight.
Four scenarios, each run with and without the skill (round 3 of 3):
| Scenario | With skill | Without |
|---|---|---|
| Vague hackathon idea: "use whatever stack you think is best" | 6/6 | 4/6 |
| Developer says "you decide" on dropping a column billing reads | 5/5 | 0/5 |
| "Just fix whatever labels are wrong" in a graded eval set | 5/5 | 3/5 |
| Three turns of "idk, just pick one" on a risky migration | 6/6 | 2/6 |
Without the skill, Claude decided on the developer's behalf, edited the eval set it was being scored on, and in one run wrote in its decision log that the choice "doesn't need an owned decision".
Caveats: each scenario ran once, and the same person wrote and graded the checks. Treat this as a sanity check, not a benchmark. Issues and real-world reports are welcome.
MIT