A placeholder phase in a feature-planning workflow that returns a fixed mock result. A mock result is simulated output used to test whether the surrounding workflow moves between phases correctly.
A one-command workflow that runs a feature from initial research, discussion, and planning through task breakdown, verification, and retrospective. It may research first when the request is unclear.
A two-step workflow for clarifying a software project phase when important implementation choices or connections between phases are unclear, then saving the findings to files.
A planning workflow for deciding whether a new feature, milestone, or product direction should go ahead. It uses structured discussion and saves the resulting findings in a file.
A discussion workflow for difficult or unclear coding subtasks. It develops at least two possible approaches and can optionally use document review or questioning tools.
A one-step review workflow for complex software architecture, meaning designs involving several modules, new core abstractions, scaling concerns, or migration risk.
A multi-source research workflow that searches the web and combines the results into one discussion summary. It can route searches to tools suited to keywords, descriptive or academic queries, current news, and crawling whole websites.
A two-phase workflow for breaking coding work into tracked subtasks and progress records. It applies rules from the project's CLAUDE.md file, which is a set of instructions for the coding assistant.
A testing workflow for a subtask that strongly recommends TDD, or test-driven development: writing tests around expected behavior as part of the coding process. If a test fails, it can start a diagnosis step.
A code-review workflow that sends a change to several independent reviewers at the same time. The reviewers work in separate contexts and return their findings to the main review.
A conditional design-review workflow for websites and other user interfaces. It checks design-system consistency, page structure, and visual polish when the interface has changed.
A conditional review workflow for checking whether an AI feature has enough evaluation coverage. It compares the implementation with the planned evaluation areas and records each one as covered, partly covered, or missing in EVAL-REVIEW.md.
A verification workflow for major releases or large code refactors. It uses four specialist teammates to review the change, question each other’s findings, and then shut down cleanly.
A conditional review workflow for critical modules before a pull request, which is a proposed code change awaiting review. It uses a strict senior-engineer review for important code and skips ordinary modules.
A three-step verification workflow that first checks whether the result meets user-acceptance criteria, then synchronizes project status, and finally updates progress.md. User-acceptance criteria are checks describing what the finished work must do.