.claude/
└── spec-workflow/
    └── config.yaml         # Commented config with all options

.claude/
└── spec-workflow/
    ├── config.yaml         # Commented config
    ├── philosophy/
    │   ├── exploration.md  # Exploration guidance
    │   ├── spec-standards.md  # Spec quality standards
    │   └── review-criteria.md # Review focus areas
    ├── personas/
    │   └── example.md      # Example custom persona
    └── templates/
        └── spec.md         # Spec template (customize as needed)

.claude/
└── spec-workflow/
    ├── philosophy/
    │   ├── exploration.md
    │   ├── spec-standards.md
    │   └── review-criteria.md
    └── personas/
        └── example.md

# Spec Workflow Configuration
# See: https://github.com/ky1ejs/claude-plugins/tree/main/plugins/spec-workflow

# ─────────────────────────────────────────────────────────────
# PATHS
# ─────────────────────────────────────────────────────────────
paths:
  # Where specs are saved
  specs: "./specs"

  # Where git worktrees are created
  worktrees: "./worktrees"

# ─────────────────────────────────────────────────────────────
# SERVICES (your technology stack)
# ─────────────────────────────────────────────────────────────
# Auto-detected from your project. Customize as needed.
services:
  # Example service configuration:
  # backend:
  #   path: "./backend"
  #   build: "npm run build"
  #   test: "npm test"
  #   lint: "npm run lint"
  #   patterns: "./backend/ARCHITECTURE.md"  # Optional: architecture docs

# ─────────────────────────────────────────────────────────────
# SPEC FORMAT
# ─────────────────────────────────────────────────────────────
spec:
  # Naming pattern for spec files
  # Tokens: {date}, {topic}
  naming: "{date}-{topic}-spec.md"

  # Required frontmatter fields
  requiredFields:
    - status

  # Optional frontmatter fields (documented but not required)
  optionalFields:
    - worktree
    - branch
    - services

# ─────────────────────────────────────────────────────────────
# REVIEW PROCESS
# ─────────────────────────────────────────────────────────────
review:
  # Maximum revision cycles before escalating to human
  maxIterations: 3

  # Consensus level for auto-approval (0.0 to 1.0)
  # Set to 1.0 to always require human approval
  autoApproveThreshold: 0.8

  # Reviewer selection
  selection:
    # "auto" = select based on spec type
    # "all" = always use all personas
    # "explicit" = only use personas in spec frontmatter
    strategy: "auto"

    # Minimum/maximum reviewers per spec
    minimum: 2
    maximum: 4

# ─────────────────────────────────────────────────────────────
# EXECUTION
# ─────────────────────────────────────────────────────────────
execution:
  # Implementation steps per batch before checkpoint
  batchSize: 5

  # Checkpoint behavior
  checkpoint:
    # "pause" = always pause for user review
    # "continue" = auto-continue if no issues
    # "smart" = pause on warnings/errors, continue otherwise
    behavior: "smart"

  # Parallelization settings
  parallel:
    enabled: true
    maxAgents: 3

# ─────────────────────────────────────────────────────────────
# WORKTREE
# ─────────────────────────────────────────────────────────────
worktree:
  # Branch naming pattern
  # Tokens: {name}, {date}
  branchNaming: "{name}"

  # Default base branch (null = current branch)
  defaultBase: null

  # Hook script to run after worktree creation
  # Receives: WORKTREE_PATH, WORKTREE_NAME, SPEC_FILE, BASE_BRANCH
  onBootstrap: null
  # Example: onBootstrap: "./scripts/bootstrap-worktree.sh"

# Exploration Philosophy

Customize this file to guide how ideas are explored before becoming specs.

## When is exploration complete?

An idea is ready for spec writing when:

- [ ] The problem is clearly articulated
- [ ] We've identified who benefits and how
- [ ] Technical approach is outlined (not detailed)
- [ ] Major unknowns are called out
- [ ] Scope is bounded

## Questions we always ask

1. What's the simplest version that delivers value?
2. What existing patterns can we reuse?
3. What are we explicitly NOT doing?

## Red flags to surface

- Scope creep ("while we're at it...")
- Premature optimization
- Solutions looking for problems

# Spec Standards

Customize this file to define what makes a good spec in your project.

## What makes a good spec?

A spec is ready for review when:

- Someone unfamiliar with the context can implement it
- Edge cases are explicitly handled or explicitly deferred
- Testing strategy is clear
- Rollback plan exists for risky changes

## Our conventions

- Implementation steps should be atomic (one concern each)
- Prefer explicit over clever
- Include "Why" not just "What"

# Review Criteria

Customize this file to guide what reviewers focus on.

## What reviewers should evaluate

1. **Completeness**: Can this be implemented without guesswork?
2. **Correctness**: Does this solve the actual problem?
3. **Consistency**: Does this fit our existing patterns?
4. **Risk**: Are failure modes addressed?

## Review tone

- Assume good intent
- Ask questions rather than demand changes
- "Consider..." rather than "You must..."
- Distinguish blocking issues from suggestions

---
name: Example Reviewer
triggers:
  - example
  - demo
---

# Example Reviewer Persona

This is an example custom persona. Create your own by adding `.md` files to this directory.

## Your perspective

Describe the perspective this reviewer brings.

## What you look for

- Thing 1
- Thing 2
- Thing 3

## Your style

Describe how this reviewer communicates feedback.

## When to pass

If you don't have substantive feedback, respond: "No concerns from an example perspective—LGTM."