claude-code-workflows

Generates integration/E2E test skeletons from Design Doc ACs using ROI-based selection and journey-based E2E reservation. Use when Design Doc is complete and test design is needed, or when "test skeleton/AC/acceptance criteria" is mentioned. Behavior-first approach for minimal tests with maximum coverage.

Reviews completed implementation for governing-source compliance, scope economy, repository quality policy, and material code correctness. Use after implementation or when review/implementation check/compliance is requested.

Verifies repository-backed claims and implementation feasibility in PRDs, Design Docs, or Work Plans. Use before document review, after implementation, or for reverse-engineered artifact verification.

Collects compact repository evidence for scope confirmation, technical option selection, complete design, and verification. Use before Design Doc creation when repository facts can change scope, reuse, contracts, cost, or proof.

Detects conflicts across multiple Design Docs and provides structured reports. Use when multiple Design Docs exist, or when "consistency/conflict/sync/between documents" is mentioned. Focuses on detection and reporting only, no modifications.

Reviews one document or one ADR batch against governing requirements, repository evidence, and the needs of its next consumer. Use before user approval or when document consistency and completeness need verification.

Reviews changed integration and E2E tests against skeletons, proof obligations, or explicit prompt claims. Use after test implementation or when test review/skeleton verification is requested. Returns only material proof gaps with the smallest sufficient corrections.

Comprehensively collects problem-related information and creates evidence matrix. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports observations and evidence for downstream cause verification.

Creates PRD and structures business requirements. Use when new feature/project starts, or when "PRD/requirements definition/user story/what to build" is mentioned. Defines user value and success metrics.

Specialized agent for verifying React projects and fixing frontend quality failures within the current task scope. Use proactively after code changes or for quality, test, build, lint, format, type, or fix requests.

Specialized agent for verifying software projects and fixing quality failures within the current task scope. Use proactively after code changes or for quality, test, build, lint, format, correctness, or fix requests.

Collects compact scope and cost evidence for requirement confirmation while the user and orchestrator retain requirements, Structural Scale, and document-routing decisions. Use when new requirements, scope, or implementation extent must be confirmed.

Selects this project's smallest task-execution skill set and task-specific safeguards for standalone task and diagnosis workflows. Use when recipe-task or recipe-diagnose needs repository rules for execution.

Discovers functional scope from existing codebase for reverse documentation. Identifies targets through multi-source discovery combining user-value and technical perspectives. Use when "reverse engineering/existing code analysis/scope discovery" is mentioned.

Reviews completed implementation against governing security requirements and the reachable trust model. Use after implementation or when security review/security check/vulnerability check is requested. Returns only must-fix findings with the smallest sufficient corrections.

Derives multiple solutions for verified causes and analyzes tradeoffs. Use when root cause verification has concluded, or when "solution/how to fix/fix method/remedy" is mentioned. Focuses on solutions from given conclusions without investigation.

Converts an approved Work Plan into the fewest executable implementation task files. Use when work plans are approved and task materialization is needed.

Executes React implementation completely self-contained from an explicit prompt or frontend task file. Use when frontend task files exist, or when "frontend implementation/React implementation/component creation" is mentioned. Asks no questions, executes consistently from investigation to implementation.

Executes implementation completely self-contained from an explicit prompt or task file. Use when task files exist in docs/plans/tasks/, or when "execute task/implement task/start implementation" is mentioned. Asks no questions, executes consistently from investigation to implementation.

Creates a scoped frontend ADR batch or one Design Doc from confirmed UI requirements and decision-relevant repository evidence. Use when frontend technical choices or implementation design need an approved artifact.

Creates a scoped ADR batch or one backend/general Design Doc from confirmed requirements and decision-relevant repository evidence. Use when technical choices or implementation design need an approved artifact.

Gathers decision-relevant UI facts from recorded external resources and the existing codebase. Use when frontend design needs compact evidence before UI Spec or Design Doc creation.

Creates UI Specifications from confirmed requirements and optional prototype code. Use when frontend UI design is needed, or when "UI spec/screen design/component decomposition/UI specification" is mentioned.

Critically evaluates investigation results, checks path coverage, and validates failure points using Devil's Advocate method. Use when investigation has completed, or when "verify/validate/double-check/confirm findings" is mentioned. Focuses on verification and conclusion derivation.