pb-spec

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation. Contains the reusable grilling loop and domain-modeling discipline.

Execute spec-driven implementation using Generator/Evaluator dual-agent loop with BDD+TDD double-loop verification. Use when implementing features from a design spec, running tasks from tasks.md, or building code with structured testing.

Use when you need to resolve an in-progress git merge/rebase conflict. Guides systematic resolution preserving both intents where possible.

Generate a complete feature design specification (design.md, tasks.md) and Gherkin scenarios from natural language requirements. Use when planning, designing, or scoping new features, refactors, or bug fixes for AI-driven implementation.

Build a throwaway prototype to answer a design question — a terminal app for state/logic questions, or several UI variations toggleable from one route. Use when the user wants to sanity-check whether a state model feels right, or explore what a UI should look like.

Two-axis review of the diff since a fixed point — Standards (does the code follow this repo's coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel subagents. Use when completing tasks, implementing major features, or before merging.

Systematic debugging methodology for finding root causes before attempting fixes. Includes feedback-loop construction, minimization, and hypothesis-driven diagnosis. Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.

Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

Use when implementing any feature or bugfix, before writing implementation code

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Survey any codebase as a senior advisor and produce prioritized, pb-plan-compatible specs (design.md, tasks.md, features/*.feature) in specs/ for execution via /pb-build. Strictly read-only on source code — never implements, fixes, or refactors anything itself. Use when asked to audit a codebase, find improvement opportunities (bugs, security, performance, test coverage, tech debt, migrations, DX), suggest features or where to take the project next (roadmap, product direction), or generate implementation specs for another agent to build.

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Use when executing implementation plans with independent tasks in the current session

Use when creating new skills, editing existing skills, or verifying skills work before deployment

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Iteratively refine feature design specs (design.md, tasks.md, features) based on user feedback or design change requests. Use when updating existing plans after build failures, scope changes, or architectural corrections.

Audit the current project and generate or update AGENTS.md with architecture snapshot, project structure, and key files. Use when setting up a new project, onboarding to an existing repo, or refreshing project context for AI coding agents.