architecture-critiqueRead-only critique of a proposed technical breakdown against the plan, before it is accepted. Checks alignment, necessary contracts, feasibility, simplicity and readability. Requested when worth challenging, never scheduled; reports blockers without scoring or rewriting.
architectureWork out the technical shape of an agreed plan — contracts, types, schemas, dependency order — and propose it as tasks and decisions. Use only where scope and complexity make those definitions necessary. Never decides how the program works; that is the plan's job.
designDecide consequential UX/UI behavior for an agreed task. Use when a changed user-facing surface is not already determined by an existing approved pattern and a design system is configured. Skip backend/infra and trivial pattern-following changes.
loreCapture, scan, or index terse, currently actionable tribal knowledge about non-obvious cross-cutting constraints, workarounds, and gotchas. Use when missing context would cause a future mistake; never use lore as history, a changelog, or a second requirements system.
orchestrateDrive one or more tasks to a CI-green PR, through whatever shape each one actually needs. Runs the interviews itself, breaks the work into goals with the maintainer, and dispatches the rest. Never creates scope.
program-designInterview the maintainer about how the program should work, and write it into the plan in plain words. Use when the approach is not obvious. Produces the how-it-works half of the plan — no contracts, types, or schemas.
refineInterview the maintainer about what they need from a task, and write it into the task in their words. Use when a dropped task's value, boundary, or a load-bearing noun is not already settled. Skip when it is already clear enough to build from.
retroRecord concrete successes and friction after a task, session, or pipeline run. Observe from artifacts and trajectories without fixing, assigning work, or changing process.
reviewRead-only review of implemented work against its task's goal or an explicit changed-file scope. Judges whether the goal is reached, applicable constraints/rules, regressions, and plausible changed risks. Produces operational findings and a verdict; never edits code.
self-improveReview accumulated retros, outcomes, interviews, and decisions to identify recurring evidence-backed patterns and propose surgical rule, memory, or skill changes for human approval. Works both when triggered manually and on a weekly schedule. Never applies changes automatically.
setupConfigure evidence-backed, maintainer-approved pipeline rule slots and design-system paths for this repository. Use during installation or when repository conventions change; do not promote generic best practices into binding policy automatically.
shipTurn completed work into a clean CI-green merge-ready PR. Verifies, commits, updates the PR, and waits for CI; does not merge. Review belongs to the orchestrate skill.
write-codeImplement a claimed task with the smallest clear solution that reaches its goal. Use after the plan is agreed and the task is yours.
write-docsWrite or review user-facing documentation when it is an explicit deliverable or when an implementation makes authoritative documentation false. Preserve project voice and factual accuracy; use reading-funnel craft proportionately to page type.
write-testsCreate proportionate failing evidence for a task's goal before implementation when behavior is regressible and an automated test is appropriate. Use in the build phase; do not let tests create requirements.