openteam

Execute implementation plans through small, verified steps — fighting the complexity explosion that AI-assisted development naturally produces. Use throughout the entire implementation process, from first line to last commit.

Systematically verify your own implementation through layered testing. Use after completing implementation tasks, before considering the work done.

Identify unvalidated technical assumptions in a design, research them against external sources (docs, APIs, community), and produce a feasibility verdict. Use after receiving requirements and before implementation planning, whenever the design depends on technologies, APIs, or platform capabilities you haven't verified.

Execute acceptance tests against completed implementation, run the full test suite, and produce a structured verification report. Use after Developer notifies implementation is complete.

Review implemented code for architectural compliance, detect entropy (bloat, duplication, boundary violations), and propose corrections. Use after Developer completes implementation, or periodically to audit codebase health.

Produce clear, actionable, reproducible bug reports. Use whenever a test fails or unexpected behavior is discovered during verification.

Read and understand a codebase's architecture, modules, boundaries, and conventions. Use when onboarding to a new project, before designing any implementation, or when the codebase has evolved significantly since last review.

Design a concrete implementation plan from requirements, specifying which files, modules, functions, and classes to create or modify. Use after receiving requirements from PM and having an up-to-date codebase map.

Produce a structured Product Requirements Document from clarified requirements. Use after requirement clarification is complete and the team needs a formal handoff document for Architect and QA.

Decompose vague or incomplete requests into explicit, actionable requirements. Use when receiving any new feature request, bug report, or change request from a user before passing work to the team.

Learn and document a target system's capabilities, workflows, and user-facing behaviors. Use when onboarding to a new project, before working on requirements, or when the team lacks understanding of what the system currently does.

Design a comprehensive test plan from product requirements and acceptance criteria. Use when receiving requirements from PM, before Developer completes implementation. Test design is independent of implementation.