Writes an architecture RFC for Piro under docs/rfcs/ — researches the real codebase first (dispatching investigation agents to read the relevant Domain/Application/Infrastructure code), then produces a structured design document that cites actual file paths, line numbers, and interfaces rather than generic architecture. Use whenever the user asks to "write an RFC", "draft a proposal" for a new feature or integration, wants a design doc before implementing something non-trivial, or says things like "let's figure out how X would fit into Piro" for an architectural change. After the RFC is written, offers to open a linked GitHub issue and asks how to commit it.
Open a GitHub pull request for the Piro repo that always complies with the project's documented conventions. It fills .github/PULL_REQUEST_TEMPLATE.md exactly, writes a conventional-commit title, infers and applies the right labels from `gh label list` based on the diff, runs the verification that matches what changed (dotnet test, pnpm exec tsc -b), links the issue or RFC, and creates the PR as a draft. Use this whenever the user wants to open, create, raise, or "put up" a PR or pull request, or says they're ready to push a branch for review, even if they don't mention the template or labels. Prefer this over a bare `gh pr create` so the PR never lands non-compliant.
Conducts a deep, module-by-module Release Candidate audit of Piro — reads a module's code, reports findings, asks the user which to fix, fixes only confirmed items, verifies with build/tests, commits, and opens a linked GitHub issue against the running audit PR. Use when the user says "audit <module>", "let's audit X", or asks to continue/resume the RC audit.