Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Start Development Work

Begin work on a feature, bug fix, or enhancement. Establishes scope through adaptive questions, then you work. No ceremony-just clarity.

Part of the ritual: /pb-start → code → /pb-review → decide → /pb-commit

Mindset: Apply /pb-preamble thinking (challenge assumptions) and /pb-design-rules thinking (verify clarity, simplicity, robustness). This command ensures you know what success looks like before writing code.

Resource Hint: sonnet - Scope detection and branch setup

Voice: Conversational. System asks clarifying questions naturally, like a peer reviewing your plan. See /docs/voice.md for how commands communicate.

Tool-agnostic: This command works with any development tool or agentic assistant. Claude Code users invoke as /pb-start. Using another tool? Read this file as Markdown and work through the phases with your tool. See /docs/using-with-other-tools.md for adaptation examples.

When to Use

  • Starting any new work (feature, fix, refactor)
  • Need to clarify scope before coding
  • Picking up work after a break (pair with /pb-resume)

The Quick Start: 5 Minutes

/pb-start "feature name"
  ↓ System asks 3-4 adaptive questions
  ↓ You answer (1-2 min)
  ↓ Branch created, scope detected
  ↓ You code

What the conversation looks like:

The system asks clarifying questions naturally-like a peer reviewing your approach before you dive in. Adapt to what you describe:

  1. What are you building? (outcome, not solution)

    • You: “Users can reset passwords via email”
    • System uses this to understand scope

  2. How complex? (files and LOC estimate)

    • You: “~200 LOC, 3 files, touches auth + email”
    • System detects: small/medium/large

  3. Scope mode? (expanding, holding, or reducing)

    • Expanding: New capability - building something that doesn’t exist yet
    • Holding: Hardening - bulletproofing, fixing, improving what exists
    • Reducing: Surgical minimalism - removing, simplifying, cutting scope
    • System adjusts review expectations: expanding gets architecture review, holding gets correctness review, reducing gets regression review

  4. Critical path? (production, security, payment, or nice-to-have)

    • You: “Payment processing, yes”
    • System prepares review depth accordingly

  5. Any blockers?

    • You: “Need staging DB access” or “None”
    • System pauses if blockers exist, otherwise proceeds

After You Answer

System detects complexity level, criticality, and affected domains. Creates a feature branch with conventional naming, saves your scope for /pb-review later, then gets out of your way. You code. No more decisions, no ceremony. System watches in the background, tracking change complexity as you work.

The Ritual is Simple

This command is part of a 3-command ritual:

/pb-start [what you're building]
  ↓ Answer 3-4 questions
  ↓ Branch created, scope recorded

[You code here-no interruptions]

/pb-review
  ↓ Detects review depth from your change
  ↓ Consults personas automatically
  ↓ Clean? Auto-commits. Issues? Preferences decide.
  ↓ Ambiguous? Asks you, then commits.

/pb-commit
  ↓ Usually automatic (triggered by /pb-review)
  ↓ Use explicitly if you want manual control

Total cognitive load: 3 commands. That’s a habit.

Pro Tips

Before you start:

  • Read the outcome question carefully. “What are you building?” means outcome, not solution
  • Be honest about complexity. Small estimate = lean review. Large = deep review.
  • If blockers exist, resolve them now, don’t start coding with unknowns

After branch is created:

  • Just code. Don’t think about the ritual yet.
  • System is watching (tracking your changes)
  • When done, run /pb-review

Branch Naming

System auto-creates branch with conventional naming:

  • feature/short-description for new features
  • fix/issue-description for bug fixes
  • refactor/what-changed for refactoring

You don’t need to think about this.

Migration from Old Workflow

If you’ve used the playbook before, here’s what changed:

OldNew
/pb-start (long ceremony)/pb-start (3-4 questions, 2 min)
/pb-cycle (self-review)/pb-review (auto-detects depth)
/pb-review-code (peer review)Built into /pb-review
/pb-security, /pb-performanceConsulted automatically by /pb-review
Manual persona selectionAutomatic (system decides who to consult)

No more commands to remember: just /pb-start, /pb-review, /pb-commit.

  • /pb-review - Quality gate (the second part of the ritual)
  • /pb-commit - Make the commit (the third part)
  • /pb-pause - Pause work, save context
  • /pb-resume - Get back into context
  • /pb-plan - Plan architecture before starting (optional, for complex work)

One ritual. Three commands. Automagic depth detection. Quality by default.