The short version.
You’ve paired with an AI coding assistant by now. You know the two faces of it. For ten minutes it’s the sharpest junior engineer you’ve ever worked with. Then it confidently does the wrong thing, because it guessed at something it should have asked you about, and you spend the next hour unwinding the guess.
People assume the fix for that is a better model, or a cleverer prompt. Mine wasn’t. My Claude super tool is a folder of boring markdown files.
Over the past months I took the software-engineering habits I’d otherwise have to remember to apply, and wrote them down as Claude Code slash commands. Now the habits run themselves. I put the whole set on GitHub as claude-shipyard. Here is what a normal day with it looks like.
The plan is where the thinking happens
Got an issue to fix? I run /make-plan.
It explores the current state of the code, builds a plan, and actively hunts for open questions. When it finds one, it doesn’t guess, which is the whole point. It lays out the alternatives with their pros, cons, and implications, and lets me choose.
And the top of every plan lists the assumptions we’re making. That sounds like a formality. It isn’t. A wrong assumption doesn’t announce itself. It sits there quietly and turns into a wrong step three commits later, when it’s expensive to undo. Reading the assumptions first is the cheapest bug-catching I do all day. State your premises before you build on them. It’s the least glamorous idea in Jean-luc Doumont’s toolkit and the one I lean on most.
One command to start clean
/git-work-on-issue takes it from the very top. It marks the GitHub issue as “in progress”, prepares a worktree and a branch, then calls /make-plan for me.
One command, and I’m working in an isolated checkout with the plan already drafted. My main branch never gets touched. If the whole thing turns out to be a bad idea, I throw the worktree away and nothing else knows it happened.
Brainstorming is just interrogation
Not everything starts as a tidy issue. Sometimes it starts as a vague “I think we should build X, but I haven’t thought it through.”
For that I have /brainstorm, and /brainstorm interrogates me. It opens with “why”, and then it asks, and asks, and asks. Question after question, each one narrower than the last, until everything is clear. It’s slower than I’d like. That slowness is the point.
The reason I keep it around is that the relentless questioning is the only reliable way I know to surface the unknown unknowns: the decisions I didn’t even know I hadn’t made yet. Those are the ones that sink projects. Not the hard problems you can see coming, the small ones you never noticed you were quietly assuming.
From a fuzzy idea to merged PRs
The output of a /brainstorm doesn’t just sit in a document. It can become a GitHub milestone, split into issues. From there, /milestone-plan and /milestone-run take the whole pile and work it one issue at a time: plan, implement, review, merge, next. I go from “I have a fuzzy idea” to “there are merged PRs” without personally babysitting every step in between.
The unglamorous end, where the code actually gets good
The interesting part of software is the thinking. The part that decides whether the code is any good is the boring stuff at the end, and the boring stuff at the end is exactly what I skip when I’m tired. So I wrote that down too.
/git-pre-prself-reviews the diff before I open a PR: tests, leftover secrets, sloppy exception handling, the things I’d be embarrassed by in review./gh-code-reviewreads the review comments back to me grouped by severity, so I fix what matters before I go bikeshed a variable name./git-pr-mergemerges and cleans up the branches and worktrees behind it, so I don’t leave a graveyard of stale branches.
Why a folder of text files beats a better prompt
Here’s the part I didn’t expect. None of this is clever AI. There’s no fine-tuning and no secret prompt hiding in the repo. It’s years of software-development practice, written down as plain markdown.
What the markdown buys me is that the discipline stops depending on me being disciplined. On a good day I’d remember to list my assumptions, question my own plan, and review my diff before pushing. On a tired day, a Friday-afternoon day, I wouldn’t. The commands don’t have tired days. They carry the process so I don’t have to.
That, for me, is where AI-assisted coding actually pays off. Not a smarter model. A model that runs your process, the same way every time, including the times you would have cut the corner yourself.
The caveat
This fits how I work. It might not fit how you work, and some of these commands encode opinions you’d reasonably disagree with. I like worktrees; plenty of good engineers find them more trouble than they’re worth. So don’t adopt it wholesale. It’s all open source. Read it, take the two or three ideas that map onto habits you already have, and leave the rest.
Steal what’s useful.