adamlinscott-claude-skills

🧩 claude-skills

Each skill lives under skills/<name>/SKILL.md and is the single source of truth; an install script links them into the global skills directory (~/.claude/skills/) so Claude loads them in every session, on every machine.

✨ Latest update — recalibrated for Claude Opus 5 and Fable 5.1

Prompting advice ages, and some of it inverts. The whole collection has been read back through against Anthropic's current guidance: newer models already check their own work, delegate, and reason without being told to, so the effort moves earlier — into planning and scoping, which is also what lets a run sit at a lower thinking effort and still land it.

• New — /build-it. Point it at a ticket, a plan file, or just say what you want built. It asks what the source and the code can't answer, pins what will and won't change, then builds.
• New — model-calibration. Anthropic's own prompt snippets, verbatim, in your global CLAUDE.md: reply length, narration, delegation, scope.
• Updated — /context-audit now flags instructions in your repo that have aged the same way. /fresh-eyes fans out less, /ttp reaches written files, reports got shorter.
• Retired — /goal-workflow and /assumption-inventory, both superseded by /build-it. Nothing is deleted when it retires: it stays working and says what to use instead.

Already installed? git pull is the whole update — the skills are linked, not copied.

[!TIP] Not a developer? Start here → SETUP-FOR-A-COLLEAGUE.md. The honest answer is that you should ask a developer to set this up for you: it takes a terminal, two clones, and a paid Claude seat to get going. That page is the checklist for them to work through on your machine. It ends with the one thing you type: /raise-issue.

[!NOTE] These work best alongside other skill collections. I run them next to Matt Pocock's skills and Garry Tan's gstack for in-depth planning; the skills here add lifecycle gates around them. The installer can run both of their installers for you — off unless you tick them.

🎯 What these are for

A skill is not a way to make the model cleverer. It is already cleverer than the instructions most people have time to write, and every model release moves more of that work inside the model — the patterns that used to need spelling out are now the default, and some of the spelling-out has started to actively get in the way.

What has not moved inside the model is the two ends of the conversation:

• Getting what only you know out of your head. The model cannot read the ticket you did not write, the reason behind the decision, or the boundary you assumed was obvious. Most of these skills are shaped around asking the right small number of questions at the right moment — /build-it before the code, /raise-issue before a report reaches your team, /are-we-done before a session closes.
• Giving it back in a form a human can act on. A correct answer nobody finishes reading has not been delivered. Hence the length caps, the plain-English rules, the ban on showing raw diffs to someone who does not read code, and /ttp.

So the reliable ones here are less "Claude can now do X" and more "the prompt you would have written, if you'd had twenty minutes and remembered everything". That is why so much of this collection is questions and report formats rather than clever machinery — and it is the reason a skill gets retired here when the model stops needing it.

🧭 A workflow to try

A good way to feel how these fit together, end to end. The planning step can be whatever planning command, skill, or process you like; the rest are from this repo. Run them in order — though most are useful on their own, too.

Command	What it does in the flow
/seatbelt (beta)	Set the permissions. Once per repo, before anything else. Decides what Claude can do here without asking and what it can never do, so the rest of this flow can run on auto instead of stopping to ask you. Skip it and /build-it either interrupts constantly or runs with no brakes.
/raise-issue (as needed)	Where the work comes from. Whoever noticed the problem — usually not you — turns what they saw into an issue that names the actual code, so the plan below starts from something real instead of a forwarded message.
Any planning command, skill, or process	Plan. Start with a planning session — however you prefer to do it — and write the plan and any supporting docs to files.
/ttp	Switch to implementation mode. The decisions are made — turn on To the Point so replies lead with the substance and stay focused on shipping, not re-litigating. This is where it shines: mid-build, you want progress, not discussion.
/build-it 412	Build. Point it at the work — a ticket number, the plan file you just wrote, or nothing at all, in which case it takes the plan agreed above. It reads the source and the code, asks whatever neither of those answered — the why, above all — pins in writing which files will change and which will not, then builds to that. The scope note is a real file, so the review below has something concrete to check against.
/fresh-eyes	Verify. Confirm the build actually completed to spec, and surface any bugs or oversights that slipped in, via a blind reconciliation against the intent.
/are-we-done	Close the loop. Before you call it a session, confirm nothing is still undecided — no half-decided suggestion, no unanswered question, no marker the diff left behind. A clean sweep answers in one line; otherwise it names the blockers or asks you about the open calls.
/ship-it	Ship. Get the verified work all the way out — merged, released, and confirmed running in every environment, production last. If the release would also carry unreleased work by other people, it names whose and asks before production.
/reground	Recover (as needed). On longer follow-on sessions, if you start drifting from the main task, halt and re-anchor to codebase evidence before continuing.
/brief-me	Re-enter (as needed). You came back on Monday to a session you left on Friday. Get a plain-English briefing on what it is, where it got to, and what it is waiting on from you, before you touch anything.

[!TIP] Most of these skills are useful standalone — you don't have to run the whole chain. Reach for /build-it whenever a ticket is ready, or /fresh-eyes after any finished diff.

🧰 Skills

/build-it

A ticket is a compressed message. It records what somebody decided and almost never why — because the why was obvious in the room, and the room is gone by the time anyone implements it. Build straight from the ticket text and you are building from the compression artefact.

Point it at the work. A ticket number is the tidiest input — it reads the whole issue, body, comments and linked tickets, because the comment that reversed the decision is rarely folded back into the description — but a plan file, a description typed straight after the command, or nothing at all (in which case it takes the plan agreed in the conversation above) all work the same way. No issue tracker is required.

Then it reads the code those words actually name, and only then asks you anything — and only what neither the source nor the code could answer. There is no question quota: a well-written ticket often gets none, a one-line request earns as many as it genuinely takes. What is fixed is the rule, not the number — never ask what you could have read.

If what you have handed it turns out to be big and still foggy, it says so rather than building into the fog, and points at a planning pass first: /wayfinder when the decisions are not made yet, /grilling when the idea needs stress-testing. That is a recommendation, not a refusal — say build it anyway and it will.

Then it writes the scope down before it writes any code: what will change, and — the part that earns the file — what will not, each with a line on why not and where it goes instead. Scope does not creep because someone decides to expand it. It creeps because nobody wrote down where the edge was, so every individual step past it looked like ordinary diligence. A written edge turns those steps back into visible decisions. It goes to disk, so it survives compaction on a long build and gives /fresh-eyes a concrete bar to check against rather than the implementer's memory of intent.

Then it builds that, and stops — naming the next step rather than running it. --scope-only pins the scope and writes no code. --commit turns on commits; without it, version control stays with you.

When to use: something is ready to implement — most often a ticket you want a fresh session to pick up, but equally the plan you just finished agreeing, or a change you can describe in a sentence. It is the natural partner to whatever files your tickets — /raise-issue here, or Matt Pocock's /wayfinder and /to-tickets.

/fresh-eyes

A subagent with zero conversation history reads your finished diff blind; the main context then reconciles that read against the work's actual intent — the divergence is the signal. Report-only by default; --fix / --iterate apply changes.

When to use: work is complete and you want unbiased confirmation nothing was missed before shipping.

/are-we-done

A close-out gate, not a review. It asks one question — can this session close? — where done means nothing is still undecided, not that everything is finished. An item parked with a reason is closed; an item nobody ruled on is not, however small.

It sweeps the same six sources every run: the todo list, the promises the session made to itself ("leaving that for now", questions you never answered), the state of the work tree, TODO markers the diff itself introduced, whether tests actually ran after the last edit, and every issue or PR number mentioned — each resolved to its real title, never left as a bare #123. Then each hit lands in exactly one bucket: done, won't do, deferred, blocker, or undecided.

It is strict by default — a dirty tree and a suite not re-run since the last edit are open points — but the floor lifts on evidence about how your project actually works: if CI runs the suite on every push and this session pushed, testing was not left undecided. Where it sees a stable pattern it can offer, once, to remember it for the project, so later sessions inherit the floor. It never assumes; and if the session was compacted it says so rather than reporting a source it can only half-read as clean.

A clean sweep gets two lines and no more, plus a paste-ready Parked: block if anything was deferred, so the parking outlives the session that decided it (/raise-issue files whatever deserves a tracked issue). Blockers get a flat list — what broke, where, what it blocks. Genuinely open calls come back as questions with real options — do it now, defer, won't do — so the decision is yours to make rather than to approve. Read-only: it fixes nothing and decides nothing for you.

When to use: the work looks finished and you are about to end the session, ship, or hand off.