afk

Use when a plan or spec splits into many independently-mergeable units — a codebase-wide migration, rename, or repeated pattern change — and the user wants them implemented in parallel as separate PRs rather than one sequential pass. The fan-out alternative to afk:implement.

Use when the user says "grill me", asks to stress-test a plan, wants to be interviewed or asked the questions needed before building, offers a vague feature idea, or wants grounded planning before non-trivial implementation

Use when the user asks to run the whole AFK flow, ship a feature, take work from idea or plan to verified evidence, resume an AFK workflow, or make a final ship/no-ship call across planning, implementation, cleanup, and QA

Use when a task needs to read or write the persistent brain/ vault — adding a principle, codebase gotcha, or note, or grounding work in existing memory; triggers include "add to brain", "remember this in the brain", or any direct brain/ edit.

Use when the user asks for help, afk help, what to do next, where am I, which AFK skill to use, AFK workflow orientation, or a broad catalog explanation

Use when the agent is about to implement, edit code, execute a plan, fix a bug, build a feature, or make repo changes, especially when task complexity or orchestration needs are unclear. Do not start editing code, writing tests, or running build or test commands directly — load this skill first to triage and route.

Use when setting up a project for AFK for the first time — scaffolds the brain/ vault and authors a tight CLAUDE.md (with an AGENTS.md symlink) that points at the brain; triggers include "init brain", "set up the brain", "create the brain vault", or "generate a CLAUDE.md to onboard the agent to this repo".

Use when you want a durable, reusable map of how an existing part of the codebase works as-is — "map the codebase", "document how auth is wired today", "survey this module", "how is X wired in this repo" — persisted to brain/codebase/ for future sessions. Produces neutral reference, never a plan; not for planning or stress-testing intent (grill/plan), judging quality or finding bugs (review/simplify), or external prior art (research).

Use when auditing and evolving the brain vault — pruning outdated or low-value notes, discovering cross-cutting principles, and reviewing skills for structural encoding opportunities; triggers include "meditate", "audit the brain".

Use when breaking a medium-to-large task into phased, principle-grounded plans written to brain/plans/ — new features, multi-file refactors, or architectural changes, not small fixes; triggers include "plan this", "break this down".

Use when the user wants a throwaway prototype, mockup, playable state model, UI variations, or to sanity-check logic/API shape before committed planning or implementation.

Use when implementation is done, before shipping, or when the user asks to QA, dogfood, verify that a change actually works, or make a ship/no-ship call on a specific change.

Use when wrapping up a session, after a mistake or correction, or when significant codebase knowledge was gained, to persist learnings into the brain; triggers include "reflect", "remember this".

Use when planning or grilling needs external grounding the codebase and brain can't provide — prior art, competitor or library patterns, cross-domain analogies, or current market/version facts; triggers include "research this", "what's the prior art", "how do others solve this", "scan the landscape", "external best practice". Not for exact API-signature lookups (that's documentation-lookup/Context7).

Use when asked to review, critique, or assess the quality of code changes, PRs, or plans against the brain's principles, producing numbered findings and a verdict without making changes.

Use when mining past Claude Code conversations for patterns, corrections, and knowledge that reflect missed and that were never written into the brain; triggers include "ruminate", "mine my history".

Use when afk:implement has landed, when the user asks to simplify or clean up changed code, or when they ask to deduplicate, DRY, or review quality without hunting for bugs

Use when the user wants to generate behavioral evals, LLM-judge tests, or eval cases for a skill, agent, prompt, or feature, write a failing eval before implementing, or scaffold an eval harness in a repo that has none

Use when the user asks to write, refine, draft, or validate a /goal, completion condition, objective, success criteria, definition of done, or bounded outcome for long-running agent work

Use when [specific trigger, symptom, user request, or workflow state]