My Coding Workflow with Claude

A week ago I told the story of how a handful of conventions I kept repeating turned into a plugin with eight skillsblog.orbitstack.casa. A lot has happened since, mostly on the coding side. So here's the tour: which skills I use for coding, what they do, and how you can tell the conventions behind them aren't just on paper.

Two plugins instead of one

Back then (ah yes, the good old days, before the war) everything lived in a single plugin called orbitstack. By now the coding skills have one of their own: orbittech. orbitstack takes care of the rest of my day-to-day — calendar, tasks, this blog. orbittech takes care of code.

Which also means: two plugins I get to build and upload to Claude Desktop myself after every change. How to get my private skill repo in there cleanly, without playing delivery guy every time, I still haven't figured out. grumble grumble

The skills

coding — The foundation everything else points to, now at revision 66. This is where the stack lives: Rust for backends, CLIs, MCP servers and libraries, Svelte for the frontend, cargo and bun as the only package managers, TOML for configuring my own tools. On top of that: logging, spec workflow, Git, tests and deployment, each in its own ref file. It's enforced through just check, which simply stays silent when everything is green — and anyone who deliberately deviates writes that down in the project's DEVIATIONS.md.

The boy likes structure, huh?

repo-sanity — Walks a repo through the conventions. It works out the project type from the files, runs medic (more on that in a moment) first, and checks by hand whatever medic doesn't know yet. Nothing gets fixed along the way: every finding becomes either a task in tracky or a deviation I deliberately keep. The skill has no rules of its own — just a checklist of how to check the rules from coding.

repo-todo — Brings order to a repo's open tasks; the directory name is the tag it filters on. It groups them by layer (#cli, #api, #mcp, #ui, #lib) and platform, reads what blocks what, and proposes an order. It also points out bundles of tasks better solved as one shared spec than one by one. Nothing gets written — only what I sign off on gets done.

Is "spec" an instrument too?

No Patrick, a spec is not an instrument. A spec is just a document that says: "Feature A should do this, and exactly like this."

task-solver — Takes a task from triage all the way to a tagged release. It does the triage itself; spec, implementation, review and fixes run as separate agents (spec-writer, coder, reviewer, fixer), each in its own worktree. The most important rule: code is never judged by the agent that wrote it. At the end it bumps, merges, tags and closes the tasks — only git push stays with me.

survey — The new kid on the block, revision 1. It reads existing code looking for less [l], more stable [s], faster [v] or deduplicated [d] code with the same result. As an "exploration" it answers a concrete question instead — say, "what if we used package A instead of package B?" — often with a prototype. Everything runs on its own branch, the result lands in a pad, and nothing gets merged before my review.

How it comes together day to day

The biggest difference is actually made by the two least flashy ones: repo-sanity and repo-todo.

When I get an idea for a project, I don't start writing code right away. First repo-sanity runs, then repo-todo, and then I slot the new task into what's already there — unless it's lying around as a task anyway. Sounds like a detour, but it's the opposite: I know where the repo stands instead of going by feel. I don't sit there wondering what's next. And the two mesh — repo-sanity produces findings, repo-todo sorts them.

On the side, it solves a problem I'd otherwise have: legacy. Every change to the conventions makes older repos a little more "wrong". Instead of doing a big sweep through every single project every few weeks, I simply bring a repo up to date whenever I touch it again anyway.

Once the task is slotted in, task-solver takes over.

And yes: I did try doing "one big sweep" for everything once … Updating all my tools to keel 0.34 — my shared Rust library — spontaneously spawned a grand total of 76 agents via task-solver. And every single one wanted something from me. My personal five minutes of fame sparkle sparkle — and it ate my usage for the entire week …

Conventions you can check

Why conventions as skills in the first place? The trigger — as told in the last post — was the endless repeating. But the real payoff lies elsewhere:

• Consistency. Every session sticks to the same rules without me having to explain them.
• Deviations become visible. Whatever doesn't match the convention is either a task or a deliberate decision with a reason.
• Same stacks. My projects behave the same at their core and can be coded the same way.

You see it most clearly in the justfile. Here's what it looks like in fach, my mail daemon:

The just recipes in fach — the same in every Rust project.

Same recipes, same names, in every Rust project: check as the gate, bump, commit, audit, hooks, install. Know one repo, know them all.

medic

Part of the conventions has since moved into a tool of its own: medic. It checks a repo mechanically against the rules, runs as the first step of just check, and as a pre-commit hook.

Here's what that looks like in wordmark, my logo generator:

medic check in wordmark: two ×, one ?

Three states: ✓ fine, × not fine, and ? means "I can't decide this on my own". The two × are real: the justfile is missing the audit recipe, and the gate skips cargo deny. So wordmark still needs some love — and not by gut feeling, but mechanically provable. That's exactly the point.

Does anyone still remember me saying last time "don't expect your own code to still be okay afterwards"? Ha-ha-ha!

By the way, this image comes from said wordmark project.

The ? on just/check-green is meant honestly: medic never builds anything itself, so it can't know whether just check is green. That's repo-sanity's job. And if you want to know why a check exists, just ask:

medic explain says where a check comes from.

Every check has a name

I already explained the markers [m], [g] and [j] — mechanical, grep, judgment — last timeblog.orbitstack.casa. What's new is that every check now has a fixed ID, <area>/<name>. This is how it appears in repo-sanity's checklist:

- [m] `just/check-runs-deny` In Rust, `check` runs `cargo deny --offline
  check bans licenses sources` (`../coding/ref/JUSTFILE.md`, "The gate is
  silent").

The same ID shows up in medic, and the same ID goes into DEVIATIONS.md when I deliberately keep a deviation. The marker isn't part of the ID — so a check can move up from "grep" to "mechanical" without breaking a single exception.

medic's catalog is a copy of this list. If the two drift apart, the list wins, and the difference is a task for medic — not a finding against the repo.

And who maintains all this?

Honestly: that's the price. coding is at revision 66, and every rule wants to be worded. The division of labour: I set what should apply, Claude writes the exact wording. And repo-sanity has something like a check for the checks — if something turns up during a run that medic doesn't catch yet, or the same problem keeps coming back, it becomes a new check.

insert Inception BWAAAAAMP

An example from this week

I got to watch a rule like that come into being live this week. The coder agents kept hanging forever on calls like this one:

find / -name "keel-*" -path "*registry/src*" 2>/dev/null | head

All they wanted was to look up what a function in keel looks like. To do that, they searched the entire disk. The skills did say what keel can do — but nowhere where the source code lives. The cache holds three versions side by side, the agent doesn't know which one the project uses, guesses, and ends up reaching for the sledgehammer.

The fix is a one-liner: cargo metadata tells you exactly which version the project uses according to Cargo.lock and where it lives — in 0.13 seconds instead of "eventually". A separate API doc for keel, on the other hand, deliberately doesn't exist. It would drift; the feature table in the skill was already one version behind. The doc comments in the code are the docs, you just have to find them.

The rule now lives in exactly one place in the coding skill, and all five agents point to it. From observation to commit: three messages.

The agents are remarkably disciplined about rules, by the way. But where there isn't one, out comes the sledgehammer.

So what now?

If I take one thing away from the past week, it's this: a rule that only lives in a skill is a request. A rule that gets checked is a rule.

Not every one can be checked — whether an agent types find / is something medic will never see. Then all you can do is write it down in the right place. But wherever you can: make it checkable.

Either way, wordmark now knows in black and white what it still has to do.