auto-pi

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Maintain and improve a Pi coding agent setup over time — prevent drift AND find new leverage. Use when auditing setup health, before adding a package/extension, before publishing, or when asked "is my setup healthy" / "audit my setup" / "how do I keep this sharp".

Find semantic duplicates (same intent, different implementation) and shallow modules (thin wrappers spreading complexity). Read-only advisory — changes route through BUILD with full gates. Use when auditing code quality, before refactoring, or when a codebase feels bloated.

Treat documentation as a first-class deliverable of every BUILD phase. Classify the diff's doc impact across 3 layers (business/technical/audit) and write only the updates genuinely needed. Use after BUILD completes, before a commit/PR, or when asked "are docs up to date".

Review and sharpen persistent memory so it compounds instead of accumulating. Use when pruning pi-hermes-memory entries, doing monthly memory hygiene, or when the same lesson has been recorded multiple times.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation