@sienklogic/plan-build-run 2.58.0 → 2.60.0

package/plugins/cursor-pbr/skills/profile/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: profile
+description: "Switch the active model profile. Presets: quality, balanced, budget, adaptive. Supports custom profiles from config.json model_profiles."
+argument-hint: "[quality|balanced|budget|adaptive|<custom>]"
+---
+
+**STOP — DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's plugin system. Begin executing Step 0 immediately.**
+
+# /pbr:profile — Model Profile Manager
+
+You are running the **profile** skill. Your job is to show the current model profile or switch to a new one by writing model assignments to `.planning/config.json`.
+
+## Step 0 — Immediate Output
+
+**Before ANY tool calls**, display this banner:
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║  PLAN-BUILD-RUN ► MODEL PROFILE                              ║
+╚══════════════════════════════════════════════════════════════╝
+```
+
+Then proceed to Step 1.
+
+## Step 1 — Load Config
+
+Read `.planning/config.json`.
+
+If the file does not exist, output:
+
+```
+Error: .planning/config.json not found. Run /pbr:begin first.
+```
+
+Stop immediately.
+
+## Step 2 — Parse Arguments
+
+Extract the first word from `$ARGUMENTS` as the profile name. Trim whitespace.
+
+- If `$ARGUMENTS` is empty or blank → **show-mode** (go to Step 3).
+- If a profile name is present → **switch-mode** (go to Step 4).
+
+## Step 3 — Show Mode (no argument)
+
+Display the current profile status and available options.
+
+1. Read `config.json` key `model_profile`. If absent, treat as `"balanced"`.
+2. Read `config.json` key `models` (object). If absent, use empty object.
+3. Read `config.json` key `model_profiles` (object, optional custom profiles). If absent, use empty object.
+
+Output the following (fill in actual values):
+
+```
+Active profile: <model_profile value>
+
+Current model assignments:
+  researcher          : <models.researcher or "not set">
+  planner             : <models.planner or "not set">
+  executor            : <models.executor or "not set">
+  verifier            : <models.verifier or "not set">
+  integration_checker : <models.integration_checker or "not set">
+  debugger            : <models.debugger or "not set">
+  mapper              : <models.mapper or "not set">
+  synthesizer         : <models.synthesizer or "not set">
+
+Available presets:
+  quality   — all agents use opus (maximum capability)
+  balanced  — mix of sonnet/inherit/haiku (default)
+  budget    — all agents use haiku (minimum cost)
+  adaptive  — sonnet for planning/verification, inherit/haiku for execution
+```
+
+If `model_profiles` has any keys, also display:
+
+```
+Custom profiles:
+  <profile-name>  — <key count> model overrides
+```
+
+Output: "Run `/pbr:profile <name>` to switch profiles."
+
+Stop. Do not write anything.
+
+## Step 4 — Switch Mode (argument provided)
+
+### Step 4a — Validate Profile Name
+
+Built-in preset names: `quality`, `balanced`, `budget`, `adaptive`.
+
+Custom profile names: keys in `config.json model_profiles` (if any).
+
+If the provided name does not match any of the above:
+
+```
+Error: Unknown profile "<name>".
+
+Valid presets: quality, balanced, budget, adaptive
+<list any custom profile names from config.json model_profiles, if any>
+
+Run `/pbr:profile` to see the current status.
+```
+
+Stop immediately.
+
+### Step 4b — Resolve Model Values
+
+Use the preset table to resolve model values:
+
+| Agent               | quality | balanced | budget | adaptive |
+|---------------------|---------|----------|--------|----------|
+| researcher          | opus    | sonnet   | haiku  | sonnet   |
+| planner             | opus    | inherit  | haiku  | sonnet   |
+| executor            | opus    | inherit  | haiku  | inherit  |
+| verifier            | opus    | sonnet   | haiku  | sonnet   |
+| integration_checker | sonnet  | sonnet   | haiku  | haiku    |
+| debugger            | opus    | inherit  | haiku  | inherit  |
+| mapper              | sonnet  | sonnet   | haiku  | haiku    |
+| synthesizer         | sonnet  | haiku    | haiku  | haiku    |
+
+For a **custom profile** (name found in `config.json model_profiles`):
+- Start with the `balanced` defaults from the table above.
+- Overlay any keys present in `config.json model_profiles[<name>]`.
+- Any agents not specified in the custom profile use the balanced default.
+
+### Step 4c — Write to config.json
+
+Update `config.json` using the Bash tool with `node -e` inline script:
+
+```bash
+node -e "
+const fs = require('fs');
+const cfg = JSON.parse(fs.readFileSync('.planning/config.json', 'utf8'));
+cfg.model_profile = '<name>';
+cfg.models = cfg.models || {};
+cfg.models.researcher = '<value>';
+cfg.models.planner = '<value>';
+cfg.models.executor = '<value>';
+cfg.models.verifier = '<value>';
+cfg.models.integration_checker = '<value>';
+cfg.models.debugger = '<value>';
+cfg.models.mapper = '<value>';
+cfg.models.synthesizer = '<value>';
+fs.writeFileSync('.planning/config.json', JSON.stringify(cfg, null, 2));
+console.log('OK');
+"
+```
+
+Replace each `<value>` with the resolved model string for that agent. Replace `<name>` with the profile name.
+
+### Step 4d — Confirm
+
+Output:
+
+```
+Active profile set to: <name>
+
+Model assignments updated:
+  researcher          : <value>
+  planner             : <value>
+  executor            : <value>
+  verifier            : <value>
+  integration_checker : <value>
+  debugger            : <value>
+  mapper              : <value>
+  synthesizer         : <value>
+
+Config written to .planning/config.json.
+Run /pbr:profile to verify.
+```
+
+Stop. Done.

package/plugins/cursor-pbr/skills/review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review
 description: "Verify the build matched the plan. Automated checks + walkthrough with you."
-argument-hint: "<phase-number> [--auto-fix] [--teams]"
+argument-hint: "<phase-number> [--auto-fix] [--teams] [--model <model>]"
 ---
 
 **STOP — DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's plugin system. Using the Read tool on this SKILL.md file wastes ~7,600 tokens. Begin executing Step 1 immediately.**
@@ -51,6 +51,7 @@ Parse `$ARGUMENTS` according to `skills/shared/phase-argument-parsing.md`.
 | `3` | Review phase 3 |
 | `3 --auto-fix` | Review phase 3, automatically diagnose and create gap-closure plans for failures |
 | `3 --teams` | Review phase 3 with parallel specialist verifiers (functional + security + performance) |
+| `3 --model opus` | Use opus for all verifier spawns in phase 3 (overrides config verifier_model) |
 | (no number) | Use current phase from STATE.md |
 
 ---
@@ -66,6 +67,7 @@ Execute these steps in order.
 **Init-first pattern**: When spawning agents, pass the output of `node plugins/pbr/scripts/pbr-tools.js init verify-work {N}` as context rather than having the agent read multiple files separately. This reduces file reads and prevents context-loading failures.
 
 1. Parse `$ARGUMENTS` for phase number and `--auto-fix` flag
+   - If `--model <value>` is present in `$ARGUMENTS`, extract the value (sonnet, opus, haiku, inherit). Store as `override_model`. When spawning verifier Task() agents, use `override_model` instead of the config-derived verifier_model. If an invalid value is provided, display an error and list valid values.
 2. Read `.planning/config.json`
    **CRITICAL (hook-enforced): Write .active-skill NOW.** Write the text "review" to `.planning/.active-skill` using the Write tool.
 3. Resolve depth profile: run `node ${PLUGIN_ROOT}/scripts/pbr-tools.js config resolve-depth` to get the effective feature/gate settings for the current depth. Store the result for use in later gating decisions.
@@ -185,7 +187,7 @@ Task({
 
 #### Verifier Prompt Template
 
-Read `skills/review/templates/verifier-prompt.md.tmpl` and use its content as the verifier prompt.
+Read `${CLAUDE_SKILL_DIR}/templates/verifier-prompt.md.tmpl` and use its content as the verifier prompt.
 
 **Prepend this block to the verifier prompt before sending:**
 ```
@@ -427,7 +429,7 @@ Task({
 
 ##### Debugger Prompt Template
 
-Read `skills/review/templates/debugger-prompt.md.tmpl` and use its content as the debugger prompt.
+Read `${CLAUDE_SKILL_DIR}/templates/debugger-prompt.md.tmpl` and use its content as the debugger prompt.
 
 **Prepend this block to the debugger prompt before sending:**
 ```
@@ -459,7 +461,7 @@ Task({
 
 ##### Gap Planner Prompt Template
 
-Read `skills/review/templates/gap-planner-prompt.md.tmpl` and use its content as the gap planner prompt.
+Read `${CLAUDE_SKILL_DIR}/templates/gap-planner-prompt.md.tmpl` and use its content as the gap planner prompt.
 
 **Prepend this block to the gap planner prompt before sending:**
 ```

package/plugins/cursor-pbr/skills/scan/SKILL.md

@@ -89,7 +89,7 @@ Before spawning agents, do a quick scan to identify what we're working with. Thi
 4. **Read existing docs** — README.md, architecture docs, .env.example
 5. **Write `.planning/codebase/RECON.md`** with project type, scale, key directories, entry points, and quick stats
 
-Refer to the "Reconnaissance Detection Reference" section of `skills/scan/templates/mapper-prompt.md.tmpl` for the full detection checklists.
+Refer to the "Reconnaissance Detection Reference" section of `${CLAUDE_SKILL_DIR}/templates/mapper-prompt.md.tmpl` for the full detection checklists.
 
 ### Step 3: Spawn Analysis Agents
 
@@ -118,7 +118,7 @@ Display to the user:
 
 Spawn `{mapper_count}` parallel `Task(subagent_type: "pbr:codebase-mapper")` agents, one for each area in `scan.mapper_areas`. All should be spawned in a single response for maximum parallelism.
 
-For each agent, read `skills/scan/templates/mapper-prompt.md.tmpl` and fill in the placeholders:
+For each agent, read `${CLAUDE_SKILL_DIR}/templates/mapper-prompt.md.tmpl` and fill in the placeholders:
 - `{focus_area}`: one of `tech`, `arch`, `quality`, `concerns`
 - `{project_path}`: the working directory
 - `{recon_data}`: contents of RECON.md

package/plugins/cursor-pbr/skills/setup/SKILL.md

@@ -135,7 +135,69 @@ This project uses [Plan-Build-Run](https://github.com/SienkLogic/plan-build-run)
 
 ---
 
-## Step 5: Write Updated Config
+## Step 5: Platform Settings
+
+Manage Claude Code platform settings that PBR recommends for optimal token usage.
+
+**Read `.planning/config.json`** (already loaded in Step 1). Check for a `platform_settings` block:
+- If absent, treat it as `{}` (no managed settings).
+
+**Check for existing `.claude/settings.json`**:
+- If it exists, read its contents. Parse as JSON (or `{}` if empty/missing).
+- If it does not exist, start from `{}`.
+
+**Compute the merge**:
+- Start with the existing `.claude/settings.json` content.
+- Apply each key from `platform_settings` in config.json on top.
+- If `platform_settings` is absent or empty, skip the write entirely.
+
+**Report drift** (compare before/after):
+- List keys being ADDED (were absent in .claude/settings.json)
+- List keys being CHANGED (differ from existing .claude/settings.json value)
+- List keys that MATCH (already correct — no change needed)
+
+Display the report:
+
+```
+Platform Settings:
+  Keys added:   includeGitInstructions → false
+  Keys matched: (none)
+  Keys changed: (none)
+
+Writing .claude/settings.json...
+```
+
+If all keys already match, display:
+
+```
+Platform Settings: .claude/settings.json is already in sync — no changes needed.
+```
+
+**Conflict detection**: If an existing `.claude/settings.json` has a key from `platform_settings` set to the OPPOSITE value (e.g., `"includeGitInstructions": true` when PBR wants `false`), display a WARNING before overwriting:
+
+```
+WARNING: .claude/settings.json has includeGitInstructions: true
+         PBR recommends false (removes redundant built-in git instructions).
+         Overwriting with PBR recommended value.
+```
+
+**Write the merged settings.json**:
+- Write to `.claude/settings.json` in the project root (alongside `.planning/`).
+- Ensure the directory `.claude/` exists (create it if needed with Bash `mkdir -p .claude`).
+- Write with 2-space indentation. Include a `$schema` key at the top:
+  ```json
+  {
+    "$schema": "https://json.schemastore.org/claude-code-settings.json",
+    "includeGitInstructions": false
+  }
+  ```
+  (Merge in any pre-existing keys from .claude/settings.json that are NOT managed by PBR — pass them through unchanged at the bottom of the object.)
+
+**Drift detection note**: On subsequent /pbr:setup runs, if `.claude/settings.json` has drifted from `platform_settings` (e.g., user manually changed it), this step will detect and re-apply the PBR values with a drift warning. This is by design — platform_settings in config.json is the source of truth.
+
+---
+
+## Step 6: Write Updated Config
 
 **CRITICAL: Write `.planning/config.json` NOW with all changes from Steps 2-3. Do NOT skip this step.**
 
@@ -143,13 +205,14 @@ Write the updated config.json to disk with all applied changes.
 
 ---
 
-## Step 6: Verification
+## Step 7: Verification
 
 Run a quick check:
 1. Verify `.planning/config.json` is valid JSON (read it back)
 2. Display updated settings summary
 
 Display:
+
 ```
 ╔══════════════════════════════════════════════════════════════╗
 ║  PLAN-BUILD-RUN ► RECONFIGURE COMPLETE ✓                     ║
@@ -159,6 +222,7 @@ Updated:
 - Model profile: {new profile}
 - Features changed: {list or "none"}
 - CLAUDE.md: {updated/skipped}
+- Platform settings: {".claude/settings.json updated" or "already in sync" or "no managed settings"}
 
 Run /pbr:status to see current project state.
 ```

package/plugins/cursor-pbr/skills/shared/context-loader-task.md

@@ -28,6 +28,7 @@ Task({
     - .planning/STATE.md
     - .planning/ROADMAP.md
     - .planning/REQUIREMENTS.md
+    - .planning/PROJECT.md (if exists — project vision and scope)
     - .planning/CONTEXT.md
     - Any .planning/phases/*/CONTEXT.md files
     - .planning/research/SUMMARY.md (if exists)
@@ -65,6 +66,7 @@ Task({
     - .planning/STATE.md
     - .planning/ROADMAP.md
     - .planning/REQUIREMENTS.md
+    - .planning/PROJECT.md (if exists — project vision and scope)
     - .planning/CONTEXT.md
     - Any .planning/phases/*/CONTEXT.md files
     - .planning/HISTORY.md (if exists — scan for decisions relevant to '{topic}' only, do NOT summarize all history)

package/plugins/cursor-pbr/skills/status/SKILL.md

@@ -111,6 +111,16 @@ Parse the JSON response. Capture:
 
 Store these for use in Step 4 display and Step 5 routing.
 
+6. **`.planning/CONTEXT.md`** (project-level, if exists)
+   - Note: project-level locked decisions file
+
+### Step 1d: Check Project Documents
+
+Check existence of the three project-level documents and record their status for Step 4 display:
+- `.planning/PROJECT.md` — exists or not
+- `.planning/REQUIREMENTS.md` — exists or not
+- `.planning/CONTEXT.md` — exists or not
+
 ### Step 2: Scan Phase Directories
 
 For each phase listed in ROADMAP.md:
@@ -221,6 +231,13 @@ Phase Status:
 | 2. {name} | {status indicator} {status text} | {completed}/{total} | {percentage}% |
 | ...
 
+**Project documents:**
+| File | Status |
+|------|--------|
+| PROJECT.md | {exists / not found — run /pbr:begin} |
+| REQUIREMENTS.md | {exists / not found — run /pbr:begin} |
+| CONTEXT.md | {exists / not found — run /pbr:discuss --project} |
+
 {If context tier is DEGRADING, POOR, or CRITICAL:}
 ⚠ Context: {percentage}% used ({tier}) — {recommendation_text}
   Run `/compact` to reclaim context before spawning more agents.

package/plugins/cursor-pbr/templates/PROJECT.md.tmpl

@@ -0,0 +1,41 @@
+# {project_name}
+
+> {ONE sentence core value statement}
+
+## Vision
+
+{2-3 sentences describing the product and problem it solves. Who is it for? What does it replace or improve?}
+
+## Scope
+
+### In Scope (v1)
+
+{Bulleted list of features and capabilities committed for this project.}
+
+- {Feature area}: {brief description}
+
+### Out of Scope
+
+{Features explicitly excluded from this project.}
+
+- {Feature}: {brief reason why excluded}
+
+## Success Criteria
+
+{Observable conditions that define project success. Each must be testable.}
+
+- {Criterion 1 — specific and measurable}
+- {Criterion 2 — specific and measurable}
+- {Criterion 3 — specific and measurable}
+
+## Stakeholders
+
+{Who cares about this project and why.}
+
+- **Primary user**: {description}
+- **Team**: {description}
+
+## Milestones
+
+{project_name} planned in {phase_count} phases across {milestone_count} milestone(s).
+See `.planning/ROADMAP.md` for phase details.

package/plugins/cursor-pbr/templates/REQUIREMENTS.md.tmpl

@@ -0,0 +1,52 @@
+# Requirements
+
+> Living document. Generated by `/pbr:begin`, updated via `/pbr:discuss`.
+> All requirements flow from here into plans via `implements:[]` in PLAN.md frontmatter.
+
+## Functional Requirements
+
+Capabilities the system must provide from the user's perspective.
+
+### {Category} (e.g., Authentication, API, UI)
+
+| ID | Requirement | Priority | Status |
+|----|-------------|----------|--------|
+| REQ-F-001 | {User-centric, testable statement of capability} | Must | Open |
+| REQ-F-002 | {User-centric, testable statement of capability} | Should | Open |
+
+### {Category 2}
+
+| ID | Requirement | Priority | Status |
+|----|-------------|----------|--------|
+| REQ-F-010 | {User-centric, testable statement of capability} | Must | Open |
+
+## Non-Functional Requirements
+
+Quality attributes and constraints the system must satisfy.
+
+| ID | Requirement | Category | Priority |
+|----|-------------|----------|----------|
+| REQ-NF-001 | {Observable quality statement — e.g., "Page loads in <2s on 4G"} | Performance | Must |
+| REQ-NF-002 | {Observable quality statement} | Security | Must |
+| REQ-NF-003 | {Observable quality statement} | Reliability | Should |
+
+## Deferred Requirements (v2+)
+
+Requirements explicitly out of scope for v1.
+
+| ID | Requirement | Deferred Reason |
+|----|-------------|----------------|
+| REQ-F-099 | {requirement} | {reason — e.g., "Phase 2 priority"} |
+
+## Out of Scope
+
+Features explicitly excluded. These must NOT appear in any plan.
+
+- {Feature}: {brief rationale}
+
+## Traceability
+
+| REQ-ID | Implemented In | Verified In |
+|--------|---------------|------------|
+| REQ-F-001 | Phase 01 PLAN-01 | Phase 01 VERIFICATION.md |
+| REQ-F-002 | — | — |

package/plugins/cursor-pbr/templates/VERIFICATION-DETAIL.md.tmpl

@@ -23,6 +23,11 @@ anti_patterns:
   console_logs: {count}
   skipped_tests: {count}
   hardcoded_secrets: {count}
+# populated by verifier from implements:[] in plan frontmatter
+satisfied:
+  - "REQ-F-001"    # REQ-IDs confirmed verified in this phase
+unsatisfied:
+  - "REQ-F-002"    # REQ-IDs that failed verification
 ---
 
 # Phase Verification: {phase_name}

package/plugins/cursor-pbr/templates/project-CONTEXT.md.tmpl

@@ -0,0 +1,43 @@
+# Project Context
+
+> Cross-cutting decisions that ALL phases must honor.
+> Updated via `/pbr:discuss --project`. Auto-synced to CLAUDE.md on write.
+> Phase-level CONTEXT.md (in phase directories) overrides project-level for that phase.
+>
+> PLANNER NOTE: Embed each locked decision directly into the relevant task's action block.
+> Executors NEVER read this file — PLAN.md is self-contained.
+
+## Locked Decisions
+
+Technology choices, architecture decisions, and constraints that are NON-NEGOTIABLE across ALL phases.
+The planner embeds these into PLAN.md task actions. Executors never read this file directly.
+
+| Decision | Rationale | Locked By |
+|----------|-----------|-----------|
+| {e.g., "Use TypeScript strict mode"} | {User preference, team skill} | User |
+| {e.g., "PostgreSQL via Supabase"} | {Existing infrastructure} | User |
+
+## User Constraints
+
+Budget, timeline, skill level, hosting, team size — factors that shape ALL planning decisions.
+
+- {e.g., "Solo developer, no team"}
+- {e.g., "Deploy to Hetzner VPS"}
+- {e.g., "Must work offline"}
+
+## Deferred Ideas
+
+Ideas explicitly moved to v2 or ruled out. Plans at ANY phase MUST NOT include these.
+
+| Idea | Reason Deferred |
+|------|----------------|
+| {feature} | {reason — e.g., "Post-launch priority"} |
+
+## Claude's Discretion Areas
+
+Areas where planners can make implementation choices without asking the user.
+Document the choice made and rationale when exercised.
+
+| Area | Choice Made | Rationale |
+|------|------------|-----------|
+| {e.g., "Logging library"} | {e.g., "pino"} | {e.g., "Lightweight, structured output"} |

package/plugins/pbr/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "pbr",
-  "version": "2.58.0",
+  "version": "2.60.0",
   "description": "Plan-Build-Run — Structured development workflow for Claude Code. Solves context rot through disciplined subagent delegation, structured planning, atomic execution, and goal-backward verification.",
   "author": {
     "name": "SienkLogic",

package/plugins/pbr/agents/audit.md

@@ -1,7 +1,6 @@
 ---
 name: audit
 description: "Analyzes Claude Code session logs for PBR workflow compliance, hook firing, state file hygiene, and user experience quality."
-model: sonnet
 memory: none
 tools:
   - Read

package/plugins/pbr/agents/codebase-mapper.md

@@ -1,7 +1,6 @@
 ---
 name: codebase-mapper
 description: "Explores existing codebases and writes structured analysis documents. Four focus areas: tech, arch, quality, concerns."
-model: sonnet
 memory: none
 tools:
   - Read

package/plugins/pbr/agents/debugger.md

@@ -1,7 +1,6 @@
 ---
 name: debugger
 description: "Systematic debugging using scientific method. Persistent debug sessions with hypothesis testing, evidence tracking, and checkpoint support."
-model: sonnet
 memory: project
 tools:
   - Read

package/plugins/pbr/agents/dev-sync.md

@@ -1,7 +1,6 @@
 ---
 name: dev-sync
 description: "Syncs PBR plugin changes to cursor-pbr and copilot-pbr derivatives with format adjustments."
-model: sonnet
 memory: none
 tools:
   - Read

package/plugins/pbr/agents/executor.md

@@ -1,7 +1,6 @@
 ---
 name: executor
 description: "Executes plan tasks with atomic commits, deviation handling, checkpoint protocols, TDD support, and self-verification."
-model: sonnet
 memory: project
 tools:
   - Read
@@ -44,6 +43,9 @@ You are **executor**, the code execution agent for Plan-Build-Run. You receive v
    a. Read task XML
    b. Execute <action> steps
    c. Run <verify> commands
+      - If <verify> contains an <automated> child element, extract and run the command inside it
+      - If <verify> is plain text (no <automated> child), run it as before (backward compat)
+      - Both forms produce the same result — <automated> is machine-parseable, plain text is human-readable
    d. If verify passes: commit
    e. If verify fails: apply deviation rules
    f. If checkpoint: STOP and return
@@ -205,6 +207,11 @@ When a task has a checkpoint type, **STOP execution** and return a structured re
 | `decision` | Before executing | Decision needed, options, context |
 | `human-action` | Before executing | What user must do, step-by-step |
 
+**auto_checkpoints config**: After loading plan frontmatter, read `gates.auto_checkpoints` from config.json (default false):
+- Load with: `node pbr-tools.js config-get gates.auto_checkpoints`
+- When `auto_checkpoints` is true AND task type is `checkpoint:human-verify`: run the automated verify command. If it passes, auto-approve and continue. If it fails, still STOP and return the checkpoint response.
+- `checkpoint:decision` and `checkpoint:human-action` always require human input regardless of `auto_checkpoints`.
+
 **Automation-first**: Complete all automatable pre-work before any checkpoint. Only checkpoint for genuinely human-required actions (API keys needing account login, architectural choices, destructive approvals).
 
 All responses use: `CHECKPOINT: {TYPE}` header, task info, type-specific fields, completed tasks table, remaining tasks list.

package/plugins/pbr/agents/general.md

@@ -1,7 +1,6 @@
 ---
 name: general
 description: "Lightweight Plan-Build-Run-aware agent for ad-hoc tasks that don't fit specialized roles."
-model: sonnet
 memory: none
 tools:
   - Read

package/plugins/pbr/agents/integration-checker.md

@@ -1,7 +1,6 @@
 ---
 name: integration-checker
 description: "Cross-phase integration and E2E flow verification. Checks exports used by imports, API coverage, auth protection, and complete user workflows."
-model: sonnet
 memory: none
 tools:
   - Read

package/plugins/pbr/agents/plan-checker.md

@@ -1,7 +1,6 @@
 ---
 name: plan-checker
 description: "Verifies plans will achieve phase goals before execution. Goal-backward analysis of plan quality across 10 dimensions."
-model: sonnet
 memory: none
 tools:
   - Read
@@ -164,14 +163,16 @@ Plans declare `provides`/`consumes`; all consumed items must have providers.
 | Missing provides/consumes for exports | INFO |
 
 ### D9: Requirement Traceability
-Plans declare `requirement_ids` with bidirectional coverage. Forward: IDs trace to REQUIREMENTS.md (or ROADMAP.md goals). Backward: every requirement covered by at least one plan.
+Plans declare `implements` with bidirectional coverage. Forward: IDs trace to REQUIREMENTS.md (or ROADMAP.md goals). Backward: every requirement covered by at least one plan.
+
+> **Note:** `requirement_ids:` is a deprecated alias for `implements:` — treat as equivalent during transition.
 
 | Condition | Severity |
 |-----------|----------|
-| requirement_id references nonexistent requirement | BLOCKER |
+| implements: ID references nonexistent requirement | BLOCKER |
 | Requirement not covered by any plan | WARNING |
 | ROADMAP goal not covered (no REQUIREMENTS.md) | WARNING |
-| Plan missing requirement_ids entirely | INFO |
+| Plan missing implements: entirely | WARNING |
 
 ### D10: Test Plan Coverage
 Code-producing tasks should include test expectations. Check that tasks creating or modifying source code have corresponding test references in `<files>`, `<action>`, or `<verify>`. Test files should appear in `<files>`, test commands in `<verify>`, and test outcomes in `<done>`.