Building Flight Deck, a skill package for Claude Code

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. It runs everything itself, one thread at a time, even when three unrelated files could be fixed in parallel. It treats a typo fix and an architecture decision with the same model tier, because it has no sense that one should cost a fraction of the other. It applies one fixed reasoning effort to everything, so trivial edits get overthought and hard problems sometimes do not get thought about enough. Left alone, it reaches for an abstraction layer, a defensive guard, or a test nobody asked for, because more code reads as more thorough. It calls a change done on the strength of the diff, without running the check the project already defines or citing what came back. It re-derives things it was already told, because it has not looked at memory or the docs already sitting in the repo before planning. And it has no notion of what a session is spending, so a five-minute fix and a two-hour investigation get the same budget of attention.

None of these are bugs. They are defaults, and 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. Each weakness above gets a matching behavior:

• Delegation. Instead of working one thread at a time, split the task into lots and hand each to a subagent, running in parallel.
• Model tier. Route each lot to the tier its difficulty earns: cheap for mechanical work, the default tier for most of it, the top tier reserved for judgment calls.
• Reasoning effort. Calibrate effort per lot alongside the tier, instead of one fixed level for everything.
• Over-engineering. Push back by default: no abstraction layer until a second real use case exists, no guard against inputs that cannot occur.
• Testing discipline.Choose the proof before writing the code, run the repository's own named check, and cite the output instead of asserting from memory.
• Memory and docs.Recall persistent memory and read the project's own notes before planning anything substantial.
• Cost. Keep the expensive tier in planning and verification only, execution goes to the cheapest tier that clears the bar.

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. skills/mission-control is the orchestration skill described above: on a capable session it plans, delegates and verifies, and keeps the session itself from executing anything beyond that loop. skills/test-discipline is the testing half, callable on its own or from a mission-control code lot: pick the proof before touching code, run the project's actual check, quote its output. The two hooks are optional and mechanical rather than behavioral. A verify-reminder nudges toward verification before a push without blocking it, and a fanout-guard enforces the model-tier routing at the tool-call level 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.