A test-driven development workflow for building features or fixing defects. Test-driven development, or TDD, means writing a small test that fails, making the code pass it, and then improving the code.
A workflow for breaking a plan, specification, or product requirements document into small, complete work items called issues, then publishing them to an issue tracker.
A workflow for turning the current conversation into a product requirements document and publishing it to an issue tracker. A product requirements document explains what should be built, and an issue tracker records work for a development team.
A tool for turning a complex coding goal into a structured specification for an automated improvement loop. It checks the repository for existing tests and commands, then separates requirements into machine-checked goals, safeguards, manual checks, and excluded work.
A review workflow for a completed software run. A separate read-only agent examines the frozen requirements, code changes, run history, and evidence, then suggests whether to accept, abandon, revise, or escalate.
A workflow for turning raw requirements—such as documents, spreadsheets, interview notes, or rough drafts—into a structured product-requirements workspace. It can organize modules, trace requirements, define states, fields, permissions, acceptance checks, and unresolved questions.
A maintenance workflow for an existing PRD work tree written in Chinese. A PRD, or product requirements document, describes what a product or feature should do and how it will be accepted.
A synchronization workflow that imports a new version of an external requirements source, such as a maintained Excel file, into an existing product-requirements workspace. It compares versions, reconciles differences, and records human decisions without directly changing the main requirements documents.