wf

Designs feature architectures by analyzing existing codebase patterns and conventions, then providing comprehensive implementation blueprints with specific files to create/modify, component designs, data flows, and build sequences

Deeply analyzes existing codebase features by tracing execution paths, mapping architecture layers, understanding patterns and abstractions, and documenting dependencies to inform new development

Reviews code for bugs, logic errors, security vulnerabilities, code quality issues, and adherence to project conventions, using confidence-based filtering to report only high-priority issues that truly matter

Stage 2 of the wf workflow. Translate an approved brainstorm spec into a PRD and ADRs. Produces .wf/plans/PRD-<feature_id>.md and .wf/adr/ADR-NNN-*.md. Slash-only — does not auto-commit and does not auto-invoke /wf:code.

Stage 4 of the wf workflow. Independent quality review applying five-tier confidence scoring. If any issue scores >= 80 confidence, hard-resets STATE phase to `coding` and ends the session — the user must run /wf:code to continue. Only zero >=80 findings advance to `done`. Slash-only.

Stage 3 of the wf workflow. Implement the feature according to the approved PRD and ADRs. Dispatches code-explorer / code-architect / code-reviewer in parallel for codebase understanding, implementation blueprint, and inner-loop self-review. Slash-only.

Optional cleanup after the wf workflow completes. Moves a finished feature's artifacts (brainstorm, plans, reviews) into .wf/archive/<feature_id>/ and resets STATE.md so the next /wf:brainstorm can start fresh. ADRs are kept in .wf/adr/ since they remain project-level decisions. Slash-only.

Stage 1 of the wf workflow. Turn an idea into an approved design through Socratic dialogue. Produces .wf/brainstorm/<feature_id>.md and optional self-contained HTML mockups. Slash-only — does not auto-commit and does not auto-invoke downstream skills.