romiluz13/auto-pi

brainstorming

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.

orchestration-layer

The auto-pi workflow procedure layer. ask-matt owns semantic routing; the deterministic workflow interpreter owns state transitions, evidence gates, persistence, autonomous continuation, bounded retries, review, and ship.

code-review

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/spec asked for?). Runs both reviews…

diagnosing-bugs

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

codebase-hygiene

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…

security-review

Security review of the diff — the third review axis alongside Standards and Spec. Reviews for injection, auth, secrets, deserialization, SSRF, path traversal, unsafe operations, and dependency confusion. Use as a parallel sub-agent with fresh context…

bearings

Generate a "pick up where I left off" status report across all active Pi sessions. Use when the user asks for bearings, a status report, morning brief, catch-up, "where did I leave off", or "what's in the works". Reads live session state, composes a scannable…

session-handoff

Hand off work to another Pi session — write a handoff doc, save key decisions to memory, and notify the target session via intercom. Use when a session is getting long, when you need to continue work in a fresh context, or when transferring work between…

decision-hold-lifecycle

Never lose an unresolved decision. Use when work discovers an open question that needs the user's input, before declaring that work complete. Persists decisions to ~/.pi/agent/decisions.json so they survive compaction and session restarts. Inspired by…

setup-maintenance

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…

verification-before-completion

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

diff-driven-docs

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…

memory-compounding

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.

receiving-code-review

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