healthMaintenance audit of the repository (outdated and vulnerable dependencies, skipped and slow tests, stale docs, old TODOs and large files, failing CI runs, abandoned plans) as one table of coded findings, with optional fixes applied behind preflight.
kickoffTurn a feature description into a grounded plan (goal, complete scope, ordered touchpoints naming real files, tests to add, docs impact, risks quoting gotchas, verification commands) written under docs/plans/, and start the branch for it.
lessonRecord a non-obvious cause, decision, or convention in the wiki the moment it is learned, as symptom, cause, rule, and evidence, plus a path-scoped rule when the lesson has a clear file scope.
onboardGenerate a router CLAUDE.md, a verified wiki under docs/wiki, and path-scoped rules for the current repository by analysing it, running its commands, and verifying every page against the code.
preflightRun the repository's verification checks (typecheck, lint, test, build, resolved from commands.md, CI, or stack detection) in an isolated agent and report exactly what failed, with the failure tail and the log path. Read-only.
releaseCut a version from the default branch: bump the version source, write the Keep a Changelog section from the commits since the last tag, re-stamp the wiki pages that cover the changed files, run preflight, commit "release: vX.Y.Z", tag it (claude plugin tag in a plugin repository), then publish with
reviewReview the current branch's diff against this repository's own documented rules (conventions, gotchas, architecture decisions, matching recipes), not generic best practice, and print findings coded R1..Rn with the quoted rule and a fix.
shipTurn this session's work into a pull request. Build the commit in a worktree of its own whenever a new branch is needed, so the checkout never switches branch, and when other sessions share the checkout take only this session's changes; run preflight, sync the docs the change touches, review against
sync-docsBring stale wiki pages back to true by re-checking their claims against the code that changed, re-verify them at HEAD, and add coverage for new behaviour no page describes.