Watch the GitHub PR for the current branch, wait for CI to finish, and autonomously fix failing jobs by reading logs, editing sources, and pushing. Stops cleanly when stuck.
Phase 1 of the SDLC pipeline (also usable standalone). Use when the user invokes /analyze with a feature request, bug report, or change description. Gathers requirements and maps the affected code surface, then presents the analysis inline in the conversation for the next phase to consume. Do NOT propose solutions or write code in this phase. Do NOT save the analysis to disk unless the user explicitly asks.
Phase 2 of the SDLC pipeline (also usable standalone). Use when the user invokes /design with either a prior /analyze in conversation context OR a direct problem description. Produces an implementation plan inline in the conversation. Do NOT write production code in this phase. Do NOT save the design to disk unless the user explicitly asks.
Phase 3 of the SDLC pipeline (also usable standalone). Use when the user invokes /implement after a /design in conversation context, OR with a direct task description. Executes the change list, editing source files. Reads design context from the conversation — not from disk. Does NOT run the full test suite (that is /test's job), but does sanity-check imports and syntax.
Phase 4 of the SDLC pipeline (also usable standalone). Use when the user invokes /test after a /implement, OR with a direct request to verify changes / run a specific test. Runs the test suite, type-checks, and linters against the changes, and reports a pass/fail verdict. Triages failures rather than blindly retrying.