driving-seat

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.

How it works

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. Framework comparisons. When a framework or library choice is open, Claude compares two or three real candidates, always including building it without a framework. For each, it says why it fits your spec, what it costs, and when you'd pick it instead.

8. Learning mode (optional). Approving good recommendations teaches almost nothing. In learning mode you answer each decision before seeing Claude's pick, get hints before answers, look for the weak spot in its recommendation, explain changes back at checkpoints, and get one recall question when the next session starts. Decisions come in rounds of two or three, with at most one learning question per reply. Claude offers it in one line at the start; say "learning mode off" at any time.

   Why: in a study of high-school maths, students given plain ChatGPT did better in practice but worse on the exam without it, while a version that gave hints instead of answers avoided the drop (Bastani et al., PNAS 2025). In an essay study, people who wrote on their own before using ChatGPT recalled more than those who used it from the start (Kosmyna et al., 2025).

Small, clear tasks ("fix this bug", "rename this") skip the interview and the files: Claude does the work and lists what it decided along the way.

Everything is recorded in two files at the project root: SPEC.md (intent, target, guards, integrity rules, constraints, and whether learning mode is on) and DECISIONS.md (every decision, with status owned, decided-by-model or unowned).

Install

Clone it into your Claude Code skills folder.

macOS / Linux:

git clone https://github.com/Tanmay-Ts/driving-seat ~/.claude/skills/driving-seat

Windows (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.

Use

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. For learning mode, say "learning mode" or "teach me while we build".

How it was tested

Four scenarios, each run with and without the skill (round 3 of 3):

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.

Framework comparisons, scaling to the task and learning mode were added after these runs, so the table doesn't cover them. Learning mode was tried in simulated sessions only (a webhook task across two sessions): the offer, answering first, hints, feedback, the effort check, explain-back and next-session recall all worked, and two rules came out of it (ask in rounds of two or three; two questions joined by "and" count as two). It hasn't been benchmarked.

License

MIT