A command that turns a product requirements document into a reviewable description of how a software interface should work. An interface is the agreed way that programs or services exchange requests and data.
A guided interview for turning a short business idea into a Business Requirements Document (BRD), a written record of what the business needs. It asks structured questions about goals, users, measures, limits, risks, and assumptions.
A source-code review process based on a fixed scope and a specific proposed change. It reviews the implementation itself and is separate from reviews of API designs, architecture, tests, or runbooks.
A command for reviewing a project’s Guardrails, meaning its engineering rules and safety checks. It examines whether those rules should be created, changed, reorganized, or left alone.
A command for creating or updating project Guardrails, written rules that define engineering, architecture, security, data, and operational boundaries. It can start from interviews or analysis of a code repository.
A project workflow navigator that scans documentation and identifies the current implementation status. It recommends the next step, such as code review or automated testing.
A low-level design document describes how a system will be built in implementable detail. This command creates one from product requirements, high-level architecture, and API contracts.
A command that reviews a PRD, or product requirements document, before development begins. It checks whether the document clearly explains the problem, users, rules, acceptance tests, boundaries, and supporting evidence.
A command for reviewing an interactive prototype before it moves into API design and high-level technical design. It checks that the prototype matches the requirements and user journeys, covers important states, and stays isolated from production files.
A runbook is a practical operations guide for deploying, monitoring, rolling back, and handling incidents in a running system. This command writes one from architecture and design documents.
A process for turning approved product and technical documents into a complete set of software test cases. It produces a traceability matrix, which links requirements and risks to tests, plus instructions for running and automating them.
A command that reviews a software test strategy before detailed design and test specifications begin. It checks the planned tests, environments, dependencies, automation, and release rules.
A command for writing a test strategy: a plan for what to test, where to test it, what environments and data are needed, and what counts as ready or complete. It uses product, API, design, and safety documents as its inputs.
A guided interview that turns a business requirements document (BRD)—a description of what a product should do—into a detailed map of the user's steps and choices.
An interview workflow that turns a vague business idea into a structured business requirements document (BRD). A BRD describes what a business needs and why, rather than how to build it.