blauwtje
UserClaude Code plugin: one engineering process, skills that take turns, and agents that keep discovery off the main context.
Categories
Indexed Skills (41)
configure
Use when the user asks to set up or configure exo, or to see or change one exo setting, such as where specs go, the savings counter or the read guard, for every project, one repository or this machine. Not for the harness's own settings.json, permissions or hooks.
file-issues
Use when the user asks in plain words to file, open, write or split GitHub issues. Not for a brief define-scope stores, closing or editing an existing issue, a plan, or a repository the working directory does not point at.
remember
Use when the user wants a correction about this repository kept, or asks what exo remembers here, what still holds, or to forget a line. Not for a plan another session runs, which define-scope owns, or a build or test command, which find-cause writes to AGENTS.md or CLAUDE.md.
show-savings
Use when the user asks what exo saved, what the read guard kept out of context, or for the savings report or totals. Not for switching the counter or the guard, which configure owns, or one diff's size, which git shows.
issuing
Use when the user asks in plain words to file, open, write or split GitHub issues. Not for a brief shaping stores, closing or editing an existing issue, a plan, or a repository the working directory does not point at.
savings
Use when the user asks what exo saved, what the read guard kept out of context, or for the savings report or totals. Not for switching the counter or the guard, which settings owns, or one diff's size, which git shows.
settings
Use when the user asks to set up or configure exo, or to see or change one exo setting, such as where specs go, the savings counter or the read guard, for every project, one repository or this machine. Not for the harness's own settings.json, permissions or hooks.
memory
Use when the user wants a correction about this repository kept, or asks what exo remembers here, what still holds, or to forget a line. Not for a plan another session runs, which planning owns, or a build or test command, which debug writes to AGENTS.md or CLAUDE.md.
build-change
Use when a decided change built this session touches over two files, a dependency, a public signature, a persisted format or security boundary, or is test-first: TDD, a bug with a reproduction. Not for a plan file, another change of at most two files, a version bump, or an unproven failure.
check-docs
Use when a code decision hinges on how a pinned external library, framework, API or service behaves, and a wrong recalled answer would still compile or type-check yet fail at runtime. Not for what the repository's own code answers, a version bump alone, or a concept explanation.
check-impact
Use when asked to merge or ship a diff if safe, what a change could break, or to build on a claim code handles X or nothing uses Y. Not for how or why code is so (explain-code), failures (find-cause), plan conformance (review-branch) or one-function edits.
compare-renders
Use when the user invokes it to prove that a refactor, migration or dependency bump leaves every rendered surface pixel-identical. Not for a change meant to look different, which design-ui owns, or a behavior pin with no rendered surface, which refactor owns.
define-scope
Use when a request, or new wishes for a stored brief, issue or plan, leaves a product decision open: what counts as done, data, architecture or a trade-off. When a new visual surface does not name its displayed data, settings, or behavior, define-scope decides those first; design-ui follows for presentation. Not for a clear goal, a failure, or visual-only work.
design-ui
Use when a page, component, or visual axis changes (type, color, spacing, motion, copy), including a redesign or a surface called empty, boring, or generic. When a new visual surface does not name its displayed data, settings, or behavior, define-scope decides those first; design-ui follows for presentation. Not for typo-only fixes or behavior with no visual effect.
edit-skills
Use when creating, editing or sizing a skill or agent, before the edit and before it is called done. Not for CLAUDE.md, a rule or an output style.
explain-code
Use when asked how X works or why it is so, to explain, teach or confirm it, if a stated reason holds even when a comment gives it, for a PR verdict, runbook, ADR or doc. Not for locations (exo:locate-code), libraries (check-docs), unproven failures (find-cause) or restructuring (audit-architecture).
find-cause
Use when existing behavior is reported wrong (bug, error, crash, regression, broken output, slowdown) and no evidence yet shows one causal line plus a mechanism predicting the symptom. Not when a diagnostic's file, line and symbol match the source, when the stated cause checks out, or for a feature complaint.
refactor
Use when a named refactor, rename, move or internal API reshape must keep behavior unchanged, or a shim or compatibility re-export tempts. Not for finding what to refactor, which audit-architecture owns, a behavior change, which build-change builds, or an unproven failure, which find-cause owns.
route-skills
Use when the user invokes it to see how the exo skills are named, found and ordered. Not for a turn already holding its rules, which the session hook injects at every start, clear and compaction.
run-parallel
Use when the user invokes it to fan one job out to parallel workers for split coverage, a race, a gauntlet of checks, or a contest of rubric-judged candidates. Not for a plan's tasks, which run-plan runs in waves, or one lookup, which exo:locate-code answers.
run-plan
Use when a session opens on a plan file to run, after a clear, or when the user says to run or resume a plan. Not for authoring or repairing a plan, or a decided change with no plan file, which build-change owns.
save-session
Use when the user invokes it to save an unfinished session's state for a fresh session after a clear. Not for a plan another executor runs, which define-scope owns, or finished work, which the commit and pull request record.
ship
Use when a code-changing run ends with commits that may leave the machine, or the user asks to push, open, watch or merge a pull request, fix its failing checks or conflicts, or address its review comments. Not for reviewing code, a PR the user did not name or list, deleting a branch, or cutting a release.
try-idea
Use when a logic or data-flow decision needs running code first: a state model, an algorithm, an untried integration, a prototype, throwaway or proof of concept, or the urge to build it for real to find out. Not for a decided change, which build-change builds, or a look, which design-ui owns.
tune-metric
Use when the user invokes it to push one measured metric toward a target in an unattended keep-or-revert loop. Not for one decided change, which build-change builds, an unproven failure, which find-cause owns, or choosing what to improve, which audit-architecture owns.
write-docs
Use when writing or editing prose read later: a README or doc page, a PR, issue or commit body, a changelog line, a brief or spec. Not for chat replies (the output style), code comments (the code standard), or fields ship, file-issues and define-scope set.
debug
Use when existing behavior is reported wrong (bug, error, crash, regression, broken output, slowdown) and no evidence yet shows one causal line plus a mechanism predicting the symptom. Not when a diagnostic's file, line and symbol match the source, when the stated cause checks out, or for a feature complaint.
deepen
Use when the user asks where or how to improve architecture without naming one change: tech debt, coupling, shallow modules, refactor candidates, also in a read-only planning mode. Not for a single named refactor or rename, failing existing behavior, or a security or dependency audit.
designing
Use when a page, component, or visual axis changes (type, color, spacing, motion, copy), including a redesign or a surface called empty, boring, or generic. When a new visual surface does not name its displayed data, settings, or behavior, shaping decides those first; designing follows for presentation. Not for typo-only fixes or behavior with no visual effect.
implementing-batch
Use when a decided change built this session touches over two files, a dependency, a public signature, a persisted format or security boundary, or is test-first: TDD, a bug with a reproduction. Not for a plan file, another change of at most two files, a version bump, or an unproven failure.
implementing
Use when a session opens on a plan file to run, after a clear, or when the user says to run or resume a plan. Not for authoring or repairing a plan, or a decided change with no plan file, which implementing-batch owns.
merge-prs
Review and merge the open pull requests of this repository one at a time behind hard gates read from the GitHub API. Use when the user asks to merge open or listed PRs. Not for reviewing code, for a PR the user did not name or list, or for anything that deletes a branch.
planning
Use when a read-only planning mode is active, a plan is requested, another session runs the work, or edits have two or more order dependencies. Not for same-session work with at most one dependency, one-file edits, git-only work, an unproven failure outside planning mode, or an architecture audit.
research
Use when a code decision hinges on how a pinned external library, framework, API or service behaves, and a wrong recalled answer would still compile or type-check yet fail at runtime. Not for what the repository's own code answers, a version bump alone, or a concept explanation.
shaping
Use when a request, or new wishes for a stored brief, issue or plan, leaves a product decision open: what counts as done, data, architecture or a trade-off. When a new visual surface does not name its displayed data, settings, or behavior, shaping decides those first; designing follows for presentation. Not for a clear goal, a failure, or visual-only work.
skills-tool
Use when creating, editing or sizing a skill or agent, before the edit and before it is called done. Not for CLAUDE.md, a rule or an output style.
handoff
Use when the user invokes it to save an unfinished session's state for a fresh session after a clear. Not for a plan another executor runs, which planning owns, or finished work, which the commit and pull request record.
prototyping
Use when a logic or data-flow decision needs running code first: a state model, an algorithm, an untried integration, a prototype, throwaway or proof of concept, or the urge to build it for real to find out. Not for a decided change, which implementing-batch builds, or a look, which designing owns.
shipping
Use when a code-changing run ends with commits that may leave the machine, or the user asks to push, open a pull request, or merge open or listed PRs. Not for reviewing code, a PR the user did not name or list, deleting a branch, or cutting a release.
start
Use when the user does not remember a skill's name, wants the list of exo skills in plain words, or names a goal and wants exo to pick. Not for a session's own routing rules, which route-skills owns and loads by itself.
using-exo
Use when a session starts, after a clear and after a compaction, before any other action, to know how the exo skills are named, found and ordered. Not for a turn that already holds its rules in context.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.