skills-ef

A simple, repeatable way of working with Claude

Each skill does one job well, and they fit together into a loop you can learn once and reuse everywhere.

For finance, files, code, and the writing around them. You don't need to be technical — every skill has a plain-language card with an everyday example, and the search box above jumps to anything by name.

47
skills
6
groups
1
loop
How you trigger a skill:you type ityou run it yourselfClaude autoClaude reaches for it automatically
The groups:financefoldersengineeringproductivitymetamisc

Two tracks share the same four steps — Folders and Workbook — and both run end to end; bigger work has its own flow further down the page.

The workflow loop at a glance The loop's 4 phases run down a trunk with a return arc looping back to the start. Each phase branches to its Folders and Workbook skills; the full tree is drawn in the loop section below. Explore folder-explore +2 workbook-explore +2 1 Plan folder-plan workbook-plan 2 Build folder-build workbook-build 3 Log folder-log workbook-log 4 run the 4 steps, then begin again ↻

Everyday tools — reach for them anytime

Not steps in any flow — self-contained tools you use on their own whenever they help: session summaries, titles, polished messages, plus the pieces for setting up and maintaining the system itself.

daily-note productivity Claude auto

Turn a work session into a short, skimmable summary for your manager — the outcomes, not the play-by-play.

e.g. End of day, you capture what you solved in a few lines your manager can read in fifteen seconds.

Reach for it: When you want a quick, manager-facing recap of what got done.

chat-title productivity you type it

Give the current chat a short, clear title that's easy to spot in the sidebar list.

e.g. After a working session, you have it name the chat by what it accomplished so you can find it later in a crowded project list.

Reach for it: When you want the current chat labeled by its outcome, so it's easy to find later.

retitle-sessions productivity you type it

Batch-fix the titles of past chats so your sidebar tells you at a glance what each old session did.

e.g. Your project list is full of vague or auto-generated titles, so you run it to get a table of better names for the bad ones and apply the ones you like.

Reach for it: When your list of past chats has gone stale and you want to retitle the worst offenders in one pass.

work-coms productivity Claude auto

Polish a rough draft or brain-dump into a clean, professional message in your own voice.

e.g. You paste your rough thoughts for a reply and get back a clear, ready-to-send message matched to the channel.

Reach for it: When you need to send a polished email or chat message fast.

meeting-notes productivity Claude auto

Turn a raw meeting transcript into a clean debrief: what happened, what was decided, and who owes what — never inventing what it can't hear.

e.g. You paste a punctuation-free voice-memo transcript and get back a saved debrief with decisions and action items, unclear spots flagged instead of guessed.

Reach for it: When a meeting recording or transcript needs to become notes and action items.

teach productivity you type it

Learn a new topic over several sessions, with lessons and a learning path that remembers your progress.

e.g. You want to get good at a topic, so it sets up a workspace and walks you through it step by step over time.

Reach for it: When you want to learn something gradually, not in one sitting.

writing-great-skills meta you type it

The style guide for writing clear, predictable skills — the rules that keep them short and easy to use.

e.g. You're writing or tidying a skill and want to know how to keep it unambiguous and free of clutter.

Reach for it: When you're authoring or editing a skill yourself.

git-guardrails misc Claude auto

Set up guardrails that block risky version-control commands before they can run.

e.g. You want to work in a project without worrying that a destructive command slips through.

Reach for it: When you want a safety net against dangerous git operations.

Helpers Claude weaves in

Claude weaves these into the loop and the bigger-work flow further down the page — and you can reach for any of them yourself, at any stage. They're never stops you ride through.

grill-me productivity you type it

Start the relentless grilling interview to stress-test a plan or design before you build.

e.g. Before a big reorganization, you have it poke holes in your approach so you fix them now, not later.

Reach for it: When you want to pressure-test a plan from memory — no files needed.

grilling productivity Claude auto

Reach clarity on a decision before you start — it works through every angle, one question at a time.

e.g. Designing something with lots of moving parts, you walk each decision to a clear answer before starting.

Reach for it: The engine behind the grill skills — reach for it when you want the full decision-tree interview.

grill-with-files productivity Claude auto

Stress-test a plan against the actual files it touches — it opens them and challenges you with what's really there.

e.g. Before editing a workbook or restructuring a folder, it reads the real contents and catches problems instead of asking you to describe them.

Reach for it: When the plan touches files and you want it grounded in what's on disk.

handoff productivity you type it

Write a session summary the next agent can trust — stated facts only (what you confirmed this session, not guesses), pointing at prior docs instead of duplicating them.

e.g. After a long working session, you write a standalone brief of what's settled, what's still a lead, and what comes next.

Reach for it: When you need to pause and hand off cleanly, so the next session resumes without re-deriving or inheriting wrong assumptions.

domain-modeling meta Claude auto

Pin down what your project's words actually mean, and record the big decisions as you make them.

e.g. You realize a term means different things to different people, so you write down the one precise definition everyone will use.

Reach for it: When fuzzy terminology or undocumented decisions are causing confusion.

The workflow loop

Most work follows the same four-step shape: get your bearings, make a plan, do the work carefully, then close it out. Learn this once and it applies whether you're working in a folder of files or an Excel workbook. Every branch is a skill — click one to open its card; each track's full story is drawn in its own section below.

The workflow loop — a true cycle Explore, Plan, Build and Log run down the trunk and a return arc loops back to Explore. Each phase branches into its Folders (prefix F) and Workbook (prefix W) skills; each loop's full story is drawn in its own section below. F = Folders W = Workbook 1 · Explore F· folder-explore W· workbook-explore F· folder-pickup W· workbook-onboarding F· folder-onboarding W· workbook-pickup 2 · Plan F· folder-plan W· workbook-plan 3 · Build F· folder-build W· workbook-build 4 · Log F· folder-log W· workbook-log begin again ↻ The workflow loop — a true cycle The cycle stacked for narrow screens: Explore, Plan, Build and Log run down the trunk and a return arc loops back to Explore. Each phase branches into its Folders (prefix F) and Workbook (prefix W) skills; each loop's full story is drawn in its own section below. F = Folders W = Workbook 1 · Explore F· folder-explore F· folder-pickup F· folder-onboarding W· workbook-explore W· workbook-onboarding W· workbook-pickup 2 · Plan F· folder-plan W· workbook-plan 3 · Build F· folder-build W· workbook-build 4 · Log F· folder-log W· workbook-log run the four steps, then begin again ↻

1 · Explore

Get your bearings — what's here, what's in progress, what to do next.

2 · Plan

Decide the approach before touching anything — and name the checks that prove it worked.

3 · Build

Do the work one step at a time, verifying as you go and confirming before anything risky.

4 · Log

Record what changed as durable history and update the status.

The Folders loop, up close

The tree above teaches the shared four-step shape; this is how a folder task actually rides it. The extra machinery is what carries between sessions: the in-flight signal build opens and log completes, the three signs of unfinished work explore checks when you return, and the door at plan for work too big for one session. Click any stop to open its card.

The Folders loop, up close — the loop's full topology The loop's main line runs folder-explore → folder-plan → folder-build → folder-log, and a return arc loops back to the first station for the next session. folder-pickup and folder-onboarding branch off folder-explore as its orientation spur. Resume — what explore checks first: dirty Git tree, open LOG.md stub, parked handoff. A dashed arc from folder-build to folder-log marks the LOG.md stub — build opens it · log completes it. handoff sits beside the loop as a peer siding (borrowed from Helpers). At folder-plan, a door links to the bigger-work flow: spans sessions? → the bigger-work flow. At folder-log: settled a structural decision? → docs/adr/ (offered, gated). ↻ handoff borrowed from Helpers RESUME — WHAT EXPLORE CHECKS FIRST dirty Git tree parked handoff open LOG.md stub folder-explore get your bearings folder-plan decide the approach folder-build do the work folder-log record & close out ORIENTATION folder-pickup back in a familiar folder folder-onboarding first time in this folder spans sessions? → the bigger-work flow LOG.md stub build opens it · log completes it settled a structural decision? → docs/adr/ (offered, gated) next session starts at explore ↻ The Folders loop, up close — the loop's full topology The loop's main line runs folder-explore → folder-plan → folder-build → folder-log, and a return arc loops back to the first station for the next session. folder-pickup and folder-onboarding branch off folder-explore as its orientation spur. Resume — what explore checks first: dirty Git tree, open LOG.md stub, parked handoff. A dashed arc from folder-build to folder-log marks the LOG.md stub — build opens it · log completes it. handoff sits beside the loop as a peer siding (borrowed from Helpers). At folder-plan, a door links to the bigger-work flow: spans sessions? → the bigger-work flow. At folder-log: settled a structural decision? → docs/adr/ (offered, gated). RESUME — WHAT EXPLORE CHECKS FIRST dirty Git tree open LOG.md stub parked handoff ↻ handoff borrowed from Helpers folder-explore get your bearings folder-plan decide the approach folder-build do the work folder-log record & close out ORIENTATION folder-pickup back in a familiar folder folder-onboarding first time in this folder spans sessions? → the bigger-work flow LOG.md stub build opens it log completes it settled a structural decision? → docs/adr/ (offered, gated) next session starts at explore ↻
True of the whole loop — not one station

The whole loop speaks the folder's own vocabulary: when a CONTEXT.md glossary exists, plan and build use its canonical terms, and log records any term the work sharpened — a folder only earns a glossary when it has words worth pinning.

Big reorganizations get sliced: plan orders the work as thin end-to-end units — move the files, rewire what points at them, check it worked — and build closes each slice before opening the next, so a wrong turn surfaces after one slice, not after all of them.

History is chosen once, at onboarding: Git by default, a LOG.md file for a named reason. The loop adapts — on Git the dirty working tree is the in-flight signal and the record is a commit; on a file-based folder, the stub drawn above is the signal and the completed entry is the record.

The docs/adr/ deposit drawn at log isn't log's alone: folder-onboarding makes the same offer when a first visit surfaces a settled structural decision — both gated the same way, and the default is no offer.

The skills on this loop
folder-explore folders you type it

Get your bearings in a folder at the start of a session — it checks the state and offers you the right next step.

e.g. You open a project folder you haven't touched in weeks and need to know what's there and what's unfinished.

Reach for it: At the start of any session working in a folder.

folder-pickup folders you type it

A quick catch-up on a folder you've worked in before — the essentials, then it stops.

e.g. You're back in a familiar folder and just want a short 'what changed, anything in progress?' summary.

Reach for it: Returning to a folder you've already set up.

folder-onboarding folders you type it

Open a brand-new folder and make it understandable — it writes a plain-English guide plus working notes, and starts tracking history.

e.g. Someone hands you a messy shared drive and says 'make sense of this' — this documents what's there and how it's organized.

Reach for it: The first time you set a folder up for ongoing work.

folder-plan folders you type it

Draft a clear plan before you move or change a batch of files — goal, steps, and the checks that prove it worked.

e.g. Before reorganizing a folder and updating links across many files, you lay out the plan so a wrong turn gets caught early.

Reach for it: Before any multi-file folder change.

folder-build folders you type it

Carry out a folder plan carefully — one step at a time, checking as it goes and asking before anything risky.

e.g. Your plan is ready; this moves the files, verifies links still work, and confirms with you before deleting anything.

Reach for it: When a folder plan is ready to execute.

folder-log folders you type it

Wrap up folder work — record it in the history with a clear note and refresh the folder's status.

e.g. You've reorganized and updated docs; this commits everything in one tidy, well-described checkpoint.

Reach for it: When you finish a unit of folder work.

The Workbook loop, up close

The tree above teaches the shared four-step shape; this is how an Excel workbook task actually rides it. Here the between-sessions machinery lives inside the workbook itself: the in-flight stub plan writes to the Audit Log and log completes at close, the Handoff sheet that carries a paused task to the next session, and the two audits waiting beside the line for when the numbers deserve a harder look. Click any stop to open its card.

The Workbook loop, up close — the loop's full topology The loop's main line runs workbook-explore → workbook-plan → workbook-build → workbook-log, and a return arc loops back to the first station for the next session. workbook-pickup and workbook-onboarding branch off workbook-explore as its orientation spur. A dashed arc from workbook-plan to workbook-log marks the In-progress stub — plan writes it to the Audit Log · log completes it in place. The Handoff sheet rides a triangle: workbook-handoff — the peer siding, pause mid-task — writes it, workbook-explore detects it next session, and workbook-log clears it at close. Off workbook-explore, an escalation siding runs formula-audit then logic-audit — escalation targets, not stops on the line. Handoff sheet ↻ workbook-handoff pause mid-task writes it explore detects it workbook-explore get your bearings workbook-plan decide approach & tie-outs workbook-build do the work workbook-log record & close out ORIENTATION workbook-pickup back in a familiar workbook workbook-onboarding first time in this workbook In-progress stub plan writes it to the Audit Log · log completes it in place AUDIT ESCALATION — IN ORDER formula-audit mechanical errors first logic-audit then the business logic escalation targets, not stops on the line log clears it at close next session starts at explore ↻ The Workbook loop, up close — the loop's full topology The loop's main line runs workbook-explore → workbook-plan → workbook-build → workbook-log, and a return arc loops back to the first station for the next session. workbook-pickup and workbook-onboarding branch off workbook-explore as its orientation spur. A dashed arc from workbook-plan to workbook-log marks the In-progress stub — plan writes it to the Audit Log · log completes it in place. The Handoff sheet rides a triangle: workbook-handoff — the peer siding, pause mid-task — writes it, workbook-explore detects it next session, and workbook-log clears it at close. Off workbook-explore, an escalation siding runs formula-audit then logic-audit — escalation targets, not stops on the line. ↻ workbook-handoff pause mid-task Handoff sheet writes it explore detects it workbook-explore get your bearings workbook-plan decide approach & tie-outs workbook-build do the work workbook-log record & close out ORIENTATION workbook-pickup back in a familiar workbook workbook-onboarding first time in this workbook AUDIT ESCALATION — IN ORDER formula-audit mechanical errors first logic-audit then the business logic escalation targets, not stops on the line In-progress stub plan writes it to the Audit Log log completes it in place log clears it at close next session starts at explore ↻
Composed in when needed — reference know-how & the fresh-eyes review
excel-finance-workbooksresilient workbook architecture velixo-formulaslive Acumatica data, kept fast workbook-reviewfresh-eyes pass on a build's changes

plan names the reference skills the task calls for and build inherits them — background know-how Claude draws on while it works; workbook-review is different: you run it yourself, in a fresh chat, when a build's close offers it. None of these are stops you ride through.

True of the whole loop — not one station

The arcs above ride two of the workbook's four AI-scaffolding sheets — the Audit Log the stub lives on, and the Handoff sheet the triangle carries between sessions. The other two work every phase without an arc of their own: the Instructions sheet is the workbook's human manual and vocabulary, and the Agent sheet holds the standing guidance, active risks, and open decisions a session reads before acting.

Explore's Full orientation is the deep read for when you'll do real work — and it ends by offering /grill-with-files, which stress-tests the plan against the workbook's actual contents instead of your memory of them.

Close-out is more than the log entry: workbook-log refreshes the Workbook Snapshot only when the task materially changed what it reports, and proposes Agent-sheet updates only when the work surfaced standing guidance — "nothing to propose" is the common, correct outcome.

The skills on this loop
workbook-explore finance you type it

Get oriented in an Excel finance workbook at the start of a session, and find the right next step.

e.g. You open a cash-flow workbook for the first time this week and need to know what's unfinished.

Reach for it: At the start of a session in a finance workbook.

workbook-onboarding finance you type it

Read a new workbook end to end and document how it works, so anyone can use it later.

e.g. You inherit a complex variance workbook and write up how its sheets and numbers flow.

Reach for it: The first time you take on a workbook you'll work in repeatedly — for return visits, use workbook-pickup instead.

workbook-pickup finance you type it

Quick re-orientation for a workbook you've worked in — read the existing notes, give a short summary, flag anything in-flight, then stop (it won't propose extra work).

e.g. You return to a monthly reconciliation and want a short 'what changed' summary.

Reach for it: Returning to a workbook you've already onboarded.

workbook-plan finance you type it

Draft a clear plan before changing a finance workbook — goal, steps, and the tie-out checks that prove the numbers still balance.

e.g. Before reworking a reconciliation's formulas, you lay out the plan and the checks so a mistake gets caught before it ships.

Reach for it: Before any non-trivial workbook change.

workbook-build finance you type it

Carry out a workbook plan carefully — step by step, running the tie-out checks as you go and confirming before anything risky.

e.g. Your plan is ready; this makes the changes and verifies the totals still reconcile before you call it done.

Reach for it: When a workbook plan is ready to execute.

workbook-log finance you type it

Close out a workbook task — write it to the Audit Log sheet as a dated record, and capture any standing guidance worth keeping.

e.g. You've finished a reconciliation change; this records what changed, the checks you ran, and anything the next person should know.

Reach for it: When you finish a unit of work in a finance workbook.

The toolkit drawn beside it — audits, review, handoff & reference know-how
formula-audit finance you type it

A fast mechanical check of a workbook's formulas — it hunts for errors, numbers typed into formulas, broken links, and ranges that miss a row, and lists what it finds.

e.g. Before sending a model, you run it to catch a stray error cell, a hardcoded figure buried in a formula, or a total that skips the last line.

Reach for it: As a quick check before you send a workbook, or any time you want to sanity-check a sheet's formulas.

logic-audit finance you type it

Decode the business logic hidden in a workbook's formulas — how raw records get sorted into the reported numbers — and check it's complete, doesn't double-count, and ties out.

e.g. You suspect a report quietly misses a category or counts something twice; this maps the rules behind the numbers and flags the gaps or overlaps.

Reach for it: When the reasoning behind the numbers lives in formulas you can't easily read. Run formula-audit first to rule out mechanical errors.

workbook-review finance you type it

A fresh look at what a workbook build actually changed — it compares the sheets against the before-image the build left, flags any change the record didn't mention, and points the audits at exactly the cells that moved.

e.g. A build rewrote formulas on your Forecast sheet; in a new chat, this walks the changes cell by cell, catches anything unreported, and hands the audits the exact ranges to check.

Reach for it: After a build that changed existing formulas — its close offers this exactly then — and before workbook-log clears the before-image.

workbook-handoff finance you type it

Pause a workbook task cleanly mid-stream — it writes a Handoff note inside the workbook so the next session, or the next person, picks up exactly where you left off.

e.g. You have to stop partway through a reconciliation; this records what's done, what's left, and what to watch, so resuming doesn't start from scratch.

Reach for it: When you need to stop mid-task in a finance workbook and hand it off without losing the thread.

excel-finance-workbooks finance Claude auto

Background know-how for building Excel finance workbooks that stay reliable and easy to check over time.

e.g. While building a budget-vs-actuals model, Claude draws on it to lay out the sheets so they don't turn fragile later.

Reach for it: Claude reaches for it automatically whenever you're building, reviewing, or reworking a finance workbook.

velixo-formulas finance Claude auto

Reference for the Velixo functions that pull live Acumatica data into Excel — and how to keep them fast.

e.g. When a report pulls actuals from Acumatica, Claude uses it to write formulas that refresh in seconds, not minutes.

Reach for it: Claude reaches for it automatically when a workbook pulls live data from Acumatica through Velixo.

Building small apps & tools — the code side

Sometimes the work is software itself — a small app or tool to build, a bug to hunt down, a codebase to tidy up. These skills bring the same careful, plan-first way of working to code: some you run yourself, and the rest Claude reaches for automatically.

implement engineering you type it

Take a finished plan — a spec or a set of issues — and build it: tests first at the agreed spots, checks run along the way, and a review at the end.

e.g. You've sliced a feature into issues; Claude works through them in small test-first steps, running the checks as it goes, then reviews the finished work before committing.

Reach for it: When planning is done and it's time to actually build — you have a spec or issues ready to become working, committed code.

prototype engineering Claude auto

Build a throwaway version to answer one design question — a tiny app to poke at when the question is how it should behave, or several different looks of one screen when it's how it should look.

e.g. You can't picture what your app's dashboard should look like, so it builds three genuinely different versions you flip between in the browser — you keep the winner and delete the rest.

Reach for it: When a design question is easier to answer by trying it than by debating it — the code is disposable; the answer is what you keep.

improve-codebase-architecture engineering you type it

Scan a whole codebase for spots where the structure causes friction, then lay out the best fixes — turning many tangled little pieces into fewer solid ones — in a visual report.

e.g. You sense every small change ripples through ten files; Claude explores the code, opens a before-and-after report in your browser, and stress-tests your chosen fix with you before anything changes.

Reach for it: When the code fights you on every change and you want structural fixes weighed up, not another quick patch. Bug hunts that keep landing in the same messy corner end up here too.

tdd engineering Claude auto

Build a feature or fix a bug in small proven steps — write one test that says what the code should do, add just enough code to pass it, then repeat.

e.g. You ask for a checkout feature; Claude writes a single failing test for the first behavior, makes it pass, then moves to the next — each step proven before the next begins.

Reach for it: Claude reaches for it automatically when you want something built or fixed test-first — and implement weaves it in at agreed points during a larger build.

code-review engineering Claude auto

Review a finished chunk of work along two separate axes — does the code follow this project's written standards, and does it actually do what the issue asked? Two independent reviewers report side by side, so a pass on one can't hide a failure on the other.

e.g. You finish a feature branch and ask for a review since main; one reviewer flags a naming rule the project documents, the other spots a requirement from the issue that never got built — each reported on its own.

Reach for it: Claude reaches for it automatically when you ask to review a branch, a PR, or the changes since some point — and implement hands off to it when a build wraps up.

codebase-design engineering Claude auto

Background know-how for shaping code into deep modules — lots of behavior hidden behind a small, simple surface — so each piece is easier to use, change, and test.

e.g. You're adding a payments piece to your tool; Claude draws on this to give it one simple front door and tuck the fiddly logic behind it — sometimes sketching a few rival designs and comparing them.

Reach for it: Claude reaches for it automatically whenever code is being designed or restructured — and it supplies the shared vocabulary improve-codebase-architecture leans on.

diagnosing-bugs engineering Claude auto

A discipline for hard bugs: before guessing at causes, build a fast, repeatable check that fails on exactly this bug — then narrow suspects one at a time until the fix proves itself.

e.g. Your app crashes on export, but only sometimes; Claude first makes the failure happen on demand, then tests a short ranked list of suspects until the real cause is caught and locked in with a test.

Reach for it: Claude reaches for it automatically when you report something broken, throwing errors, failing, or slow. If the fix reveals a deeper design problem, it hands off to improve-codebase-architecture.

research engineering Claude auto

Hand a question to a background researcher — it digs through the primary sources (official docs, source code, specs), follows every claim back to where it came from, and leaves a cited write-up in your project while you keep working.

e.g. You need to know what an API actually charges per call before building around it; Claude sends a researcher to the official docs and keeps building with you — the cited notes file arrives a few minutes later.

Reach for it: Claude reaches for it automatically when you want a topic researched or reading legwork delegated — the write-up it leaves is something to carry into planning, not a replacement for it.

resolving-merge-conflicts engineering Claude auto

A disciplined way through a git merge conflict — when two sets of changes collide, it digs into why each change was made before deciding what stays.

e.g. You pull in another branch and git halts on lines edited two different ways; Claude reads each side's history, keeps both intents where it can, then runs the project's checks to prove nothing broke.

Reach for it: Claude reaches for it automatically whenever git stops mid-merge (or mid-rebase) on conflicting changes — it works through every conflict rather than backing out.

Bigger work — from idea to shipped

Bigger work follows one shape: shape the idea, decide whether it's a multi-session build, then build it — implement builds code; the Folders and Workbook loops build what lives in a folder or a workbook. Step one is a choice: grill-with-docs shapes an idea that fits one session's planning; when it's too big and foggy for that, wayfinder maps it instead, and its lane skips the junction and merges back at to-spec — a wayfinder effort is multi-session by definition. ask-ef is the guide that points you to the right step in this flow; the shelf underneath holds the helpers Claude weaves in along the way. Click any skill to open its card.

The flow at a glance
  1. shapegrill-with-docs — or wayfinder when the idea can't fit one session
  2. specto-spec
  3. ticketsto-tickets
  4. buildimplement for code; the Folders or Workbook loop otherwise — per ticket, fresh session
  5. reviewcode-review closes each build

Fits one session? Skip 2–3 and build inline.

How bigger work flows — a fork, not a loop ask-ef routes you in; triage and setup-skills-ef feed the flow. Step one is a choice: shape the idea with grill-with-docs when it fits one session, or map it with wayfinder when it can't — wayfinder's lane skips the junction and merges at to-spec. From grill-with-docs the multi-session junction opens two doors: yes runs to-spec then to-tickets; no builds inline. Both doors rejoin at Build, which hands code to implement — the code arm — and folder or workbook work to the two loops. Build runs once per ticket, and handoff — hanging off the Build node, not a stop on any rail — carries context between those ticket sessions. ask-ef — the guide that points you to the right step triage — sorts incoming requests setup-skills-ef — run once per project Yes · spans sessions No · build inline or wayfinder can't fit one session Shape the idea grill-with-docs Multi-session build? to-spec write the spec to-tickets cut the tickets Build ↻ handoff between sessions implement the code arm Folders loop Workbook loop pick the arm by what you're building — code, a folder, or a workbook How bigger work flows — a fork, not a loop The same fork redrawn for narrow screens as one top-to-bottom spine: ask-ef routes you in; triage and setup-skills-ef feed the flow. grill-with-docs — Shape the idea — anchors the spine as the default opener; wayfinder, the smaller station beside it, is the exception for ideas that can't fit one session, and its lane bypasses the junction and merges back at to-spec. Below grill-with-docs the multi-session junction opens two doors: yes continues down the spine through to-spec and to-tickets; no leaves on a bypass arc that skips both planning stations and rejoins just above Build. Build hands code to implement — the code arm — and other work to the two loops below. Build runs once per ticket, and handoff — hanging off the Build node, not a stop on the spine — carries context between those ticket sessions. ask-ef routes you in triage — sorts incoming requests setup-skills-ef — run once per project or Yes spans sessions No build inline Shape the idea grill-with-docs wayfinder can't fit one session Multi-session build? to-spec to-tickets Build ↻ handoff between sessions implement the code arm Folders loop Workbook loop pick the arm by what you're building — code, a folder, or a workbook

Behind the Yes door, the build-arm runs once per ticket, in fresh context — implement for code, the loop for a folder or workbook; each ticket names the tickets that must finish before it, so any ticket whose blockers are done can be picked up; handoff carries what matters from one ticket session to the next.

implement is one skill, not a four-phase loop — it runs the whole code build: tests first at the agreed spots, checks along the way, a review at the end. The code-bench tools on the shelf below compose in.

Composes in · Helpers Claude weaves in
grill-methe same grilling, from memory — no files needed grillingthe engine under every grill step grill-with-filesgrills your plan against the real files domain-modelingwrites your definitions & decisions down
Composes in · Building small apps & tools — the code side
prototypeanswers a design question with throwaway code improve-codebase-architecturecodebase upkeep that feeds ideas back into the flow tddtest-first building at the agreed spots code-reviewchecks finished work against the rules and the ask codebase-designshapes code into deep modules diagnosing-bugsa proof-first discipline for hard bugs researchreads the primary sources while you keep working resolving-merge-conflictsdigs into why each side changed before deciding

Claude weaves the helpers into the steps above (and you can reach for them any time) — they're never stops you ride through. The code bench backs the code arm: implement composes those tools in as it builds.

The skills on this flow
grill-with-docs productivity you type it

Get grilled while it captures the decisions and definitions as written records along the way.

e.g. Kicking off a new area of work, you make the key calls and they're saved as decision records for the next person.

Reach for it: Starting bigger, multi-session work that deserves a paper trail.

to-spec meta you type it

Turn a conversation you've already had into a written spec, without being re-interviewed.

e.g. After talking through a new feature, you run it to capture everything you agreed on as one document the build can follow.

Reach for it: When a decision is big enough to span multiple sessions and needs a durable spec.

to-tickets meta you type it

Break a plan or spec into small tickets, each naming the tickets that must finish before it can start.

e.g. A spec describes a multi-part feature; this cuts it into standalone tickets, each finishable and checkable by itself, so anything whose blockers are done can be picked up next.

Reach for it: When a plan is too big to do in one go and you want bite-sized tasks with a clear order.

wayfinder meta you type it

Plan an effort too big and foggy for one sitting by keeping a shared map of open questions, answered one at a time.

e.g. A big project's path isn't visible yet; this charts the open decisions as a map on the tracker and works through them one per session until the way is clear.

Reach for it: When the work is so large you can't yet see the way to the destination, let alone write the spec.

triage meta you type it

Move incoming requests through clear states — sort them, verify they're real, and leave a brief so the next person can act.

e.g. A request comes in; you confirm it holds up, decide what kind it is, and write notes saying exactly what's settled and what's still needed.

Reach for it: When you have a queue of requests and need to decide what's ready to work on.

ask-ef meta you type it

A guide that points you to the right skill when you're not sure where to start.

e.g. You have something to do but don't know which skill fits — you ask, and it routes you to the right first step.

Reach for it: Any time you're unsure which skill or flow to use.

setup-skills-ef meta you type it

A one-time setup that tells the skills where your project keeps its tasks, what its labels mean, and where its notes live.

e.g. You add these skills to a new project and run setup once so the other skills know where everything is.

Reach for it: Once, before you first use the planning and issue skills in a new project.

For maintainers — how this was built

This page is generated: a small script reads the live list of shipping skills and merges it with hand-written teaching copy, then emits one self-contained file — so it can't drift out of date. When new skills land, re-running the script picks them up automatically.