Building Flight Deck, a skill package for Claude Code
Claude Code barely delegates, forgets what it already knows, and calls things done too soon. I packaged my answer to those seven default weaknesses into an open source skill and shipped it. Here is how.
Key takeaways
- Identified seven recurring Claude Code defaults: no delegation, no model-tier routing, fixed reasoning effort, over-engineering, and unverified done claims.
- Also flagged: ignoring existing memory and docs before planning, and no awareness of cost across a session.
- Packaged the fixes as an open source skill, Flight Deck, released under the MIT license on GitHub.
- The package ships two skills, mission-control and test-discipline, plus two optional hooks for verification nudges and tier enforcement.
- The install prompt reads the existing project instructions first, shows the exact diff, and waits for explicit approval before changing anything.
Claude Code is good software. It writes code, runs commands, reads files, and mostly does what I ask. What it does not do, out of the box, is work the way I want to work.
Over a few months of daily use I kept hitting the same seven cracks, and I got tired of papering over them by hand at the start of every session. So I wrote down how I actually work and packaged it as a skill: Flight Deck. It is open source now, and this is the story of building it and putting it out.
Seven ways the defaults let me down
Used long enough, Claude Code shows the same seams every time. Trivial edits get overthought and hard problems sometimes do not get thought about enough, because the reasoning effort never changes. A five-minute fix and a two-hour investigation get the same budget of attention, because nothing is tracking what a session spends. Here are the seven, each next to the behavior Flight Deck puts in its place.
| Axis | Default | Flight Deck |
|---|---|---|
| Delegation | Runs everything itself, one thread at a time | Split into lots, one subagent each, run in parallel |
| Model tier | Same tier for a typo fix and an architecture decision | Cheap for mechanics, default for most, top for judgment |
| Reasoning effort | One fixed level for everything | Calibrated per lot, alongside the tier |
| Over-engineering | Adds a layer, a guard, a test nobody asked for | No layer until a second real use case, no impossible-input guard |
| Testing discipline | Calls it done from the diff, nothing run or cited | Proof first, run the project check, cite output |
| Memory and docs | Re-derives what it was already told | Memory and notes read before planning |
| Cost | No notion of session spend | Top tier plans and verifies, cheapest workable tier runs |
None of these are bugs. They are defaults, right down to the assumption that more code reads as more thorough. Defaults are exactly the kind of thing you can override with the right instructions, if you write them down once instead of re-explaining them every session.
Seven axes, packaged
Flight Deck is that write-up, turned into a skill, one replacement behavior per weakness. Each lot goes to the tier its difficulty earns. Memory and the project's own notes get read before planning anything substantial. The check it runs is the repository's own named one, cited rather than asserted from memory.
That is the whole package: plan, delegate, verify, at whatever tier each part of that loop actually needs.
Mission control, lightly
The name comes from a metaphor I was already using, so I made it explicit instead of leaving it implicit. A session running the skill acts like mission control: it plans the work and hands each piece to the crew at their console, rather than flying the whole mission solo. A pre-flight checklist decides whether a change is actually done, the same way you would not call a launch ready because the fuel gauge looked fine from a distance. And cost is treated as fuel, not an afterthought: you do not burn the expensive tier on a lot a cheaper one could clear just as well.
I kept the metaphor loose on purpose. It is there to make the routing rules memorable, not to dress up a simple idea: plan at the top, execute at the cheapest tier that works, verify before calling anything done.
What is actually in the package
Two skills and two optional hooks.
| Piece | What it does |
|---|---|
skills/mission-control | On a capable session: plans, delegates, verifies, executes nothing else |
skills/test-discipline | The testing half, on its own or from a mission-control code lot |
| verify-reminder hook | Nudges verification before a push, without blocking it |
| fanout-guard hook | Enforces model-tier routing at the tool-call level |
The hooks are mechanical rather than behavioral, and the fanout-guard holds whether or not the skill happened to load that session. Both need jq on PATH and fail open without it.
Shipping it
Writing the skill was the easy part. I wanted it usable by someone who is not me, so the last stretch went into the packaging rather than the doctrine. The repo is public at github.com/CaseReed/flight-deck, under MIT. There is also a dedicated Flight Deck page on this site walking through the seven axes and the install steps, for anyone who would rather read than clone.
The part I spent the most time on is the install prompt: one block you paste into a fresh Claude Code session that clones the repo, checks whether mission-control and test-discipline are already installed, and only then copies the skill folders over.
It reads your existing CLAUDE.md before touching it, shows the exact diff it wants to append, and waits for a yes. Hooks are offered the same way, shown in full with the settings.json change they would make, never installed silently.
If everything is already in place, it says so and stops. I would rather the installer under-do something and ask than quietly overwrite a CLAUDE.md someone else spent months tuning.
Try it
If any of the seven weaknesses above sound familiar, the Flight Deck page has the full breakdown and the install prompt, and the source is on GitHub. It is a small package. It just encodes a way of working I was already doing by hand, so I stopped having to explain it every time.