@sienklogic/plan-build-run 2.21.1 → 2.21.2

package/plugins/pbr/skills/test/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: test
+description: "Generate tests for completed phase code. Detects test framework and targets key files."
+allowed-tools: Read, Write, Bash, Glob, Grep, Task, AskUserQuestion
+argument-hint: "<phase-number>"
+---
+
+**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.**
+
+# /pbr:test — Post-Phase Test Generation
+
+You are the orchestrator for `/pbr:test`. This skill generates tests for code that was built WITHOUT TDD mode. It targets key files from completed phases and creates meaningful test coverage.
+
+## Context Budget
+
+Reference: `skills/shared/context-budget.md` for the universal orchestrator rules.
+Reference: `skills/shared/agent-type-resolution.md` for agent type fallback when spawning Task() subagents.
+
+Additionally for this skill:
+- **Delegate** all test writing to executor subagents — never write test code in the main context
+- Read only SUMMARY.md frontmatter for `key_files` lists — do not read full summaries
+
+## Step 0 — Immediate Output
+
+**Before ANY tool calls**, display this banner:
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║  PLAN-BUILD-RUN ► GENERATING TESTS FOR PHASE {N}             ║
+╚══════════════════════════════════════════════════════════════╝
+```
+
+Where `{N}` is the phase number from `$ARGUMENTS`.
+
+**CRITICAL — DO NOT SKIP: Set active skill.** Write `.planning/.active-skill` with content `test`.
+
+Then proceed to Step 1.
+
+## Prerequisites
+
+- `.planning/config.json` exists
+- Phase has been built: SUMMARY.md files exist in `.planning/phases/{NN}-{slug}/`
+- If no SUMMARY.md files exist in the phase directory, display error and exit. Do not proceed without build output.
+- Phase should NOT already have TDD coverage (check if `features.tdd_mode` is false in config — if TDD mode is enabled, warn user that tests should already exist and ask to proceed anyway)
+
+---
+
+## Argument Parsing
+
+Parse `$ARGUMENTS` according to `skills/shared/phase-argument-parsing.md`.
+
+| Argument | Meaning |
+|----------|---------|
+| `3` | Generate tests for phase 3 |
+| (no number) | Use current phase from STATE.md |
+
+---
+
+## Step 1 — Gather Context
+
+**CRITICAL: Run init command to load project state efficiently.**
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/pbr-tools.js" init execute-phase {phase_number}
+```
+
+This returns STATE.md snapshot, phase plans, ROADMAP excerpt, and config — all in one call.
+
+The init command returns `files_to_read` context. Ensure SUMMARY.md files are read before spawning test agents.
+
+## Step 2 — Detect Test Framework
+
+Scan the project root for test framework indicators:
+
+1. Check `package.json` for `jest`, `vitest`, `mocha`, `ava` in devDependencies
+2. Check for `pytest.ini`, `pyproject.toml` (with `[tool.pytest]`), `setup.cfg` (with `[tool:pytest]`)
+3. Check for `jest.config.*`, `vitest.config.*`, `.mocharc.*`
+4. Check for existing test directories: `tests/`, `test/`, `__tests__/`, `spec/`
+5. Check for existing test file patterns: `*.test.*`, `*.spec.*`, `test_*.py`
+
+If no test framework is detected, ask the user:
+
+Use AskUserQuestion:
+  question: "No test framework detected. Which should I use?"
+  header: "Framework"
+  options:
+    - label: "Jest"      description: "JavaScript/TypeScript testing (most common)"
+    - label: "Vitest"    description: "Vite-native testing (faster, ESM-friendly)"
+    - label: "pytest"    description: "Python testing framework"
+  multiSelect: false
+
+## Step 3 — Collect Target Files
+
+Read SUMMARY.md frontmatter from each plan in the phase to extract `key_files`:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/pbr-tools.js" frontmatter .planning/phases/{NN}-{slug}/SUMMARY.md
+```
+
+Collect all `key_files` across all plans in the phase. Filter to only source files (exclude config, docs, assets). Group by:
+- **High priority**: Files with business logic, API endpoints, data models
+- **Medium priority**: Utility functions, helpers, middleware
+- **Low priority**: Config, types-only files, constants
+
+Present the file list to the user:
+
+Use AskUserQuestion:
+  question: "Found {N} source files from phase {P}. Generate tests for which?"
+  header: "Scope"
+  options:
+    - label: "High priority only"  description: "{X} files — business logic, APIs, models"
+    - label: "High + Medium"       description: "{Y} files — adds utilities and helpers"
+    - label: "All files"           description: "{Z} files — comprehensive coverage"
+  multiSelect: false
+
+## Step 4 — Generate Test Plans
+
+For each target file, create a lightweight test plan (NOT a full PBR PLAN.md — just a task list):
+
+```
+File: src/auth/login.js
+Tests to generate:
+  - Happy path: valid credentials return token
+  - Error: invalid password returns 401
+  - Error: missing email returns 400
+  - Edge: expired session handling
+Framework: jest
+Output: tests/auth/login.test.js
+```
+
+## Step 5 — Spawn Executor Agents
+
+**CRITICAL: Delegate ALL test writing to subagents. Do NOT write test code in the main context.**
+
+For each target file (or batch of related files), spawn an executor agent:
+
+```
+Spawn subagent_type: "pbr:executor"
+
+Task: Generate tests for the following file(s):
+
+<files_to_test>
+{file_path}: {brief description from SUMMARY}
+</files_to_test>
+
+<test_framework>
+{detected framework name and version}
+Existing test directory: {path}
+Test file naming: {pattern, e.g., *.test.js}
+</test_framework>
+
+<test_plan>
+{test plan from Step 4}
+</test_plan>
+
+Instructions:
+1. Read each source file to understand the implementation
+2. Write test files following the project's existing test patterns
+3. Each test file should cover: happy path, error cases, edge cases
+4. Use the project's existing mocking patterns if any exist
+5. Run the tests to verify they pass: {test command}
+6. Commit with format: test({phase}-tests): add tests for {file}
+```
+
+Spawn up to `parallelization.max_concurrent_agents` agents in parallel for independent files.
+
+## Step 6 — Verify and Report
+
+After all agents complete, check results:
+
+1. Glob for new test files created in this session
+2. Run the test suite to verify all new tests pass:
+   ```bash
+   {test_command}
+   ```
+3. Count: files tested, tests written, tests passing
+
+Display completion:
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║  PLAN-BUILD-RUN ► TESTS GENERATED ✓                          ║
+╚══════════════════════════════════════════════════════════════╝
+
+Phase {N}: {X} test files created, {Y} tests passing
+
+Files tested:
+  - src/auth/login.js → tests/auth/login.test.js (8 tests)
+  - src/api/users.js → tests/api/users.test.js (12 tests)
+
+
+
+╔══════════════════════════════════════════════════════════════╗
+║  ▶ NEXT UP                                                   ║
+╚══════════════════════════════════════════════════════════════╝
+
+**Run quality gate** to check for requirement-to-test gaps
+
+`/pbr:validate-phase {N}`
+
+**Run coverage check** to see how much is covered
+
+`npm test -- --coverage`
+
+<sub>`/clear` first → fresh context window</sub>
+
+
+
+**Also available:**
+- `/pbr:verify-work {N}` — verify the full phase
+- `/pbr:continue` — execute next logical step
+
+
+```
+
+**Clear active skill:** Delete `.planning/.active-skill`.
+
+---
+
+## Step 7 — Update State
+
+Reference: `skills/shared/state-update.md` for state update patterns.
+
+Update STATE.md `last_activity`: "Tests generated for phase {N} ({X} files, {Y} tests)"
+
+---
+
+## Step 8 — Commit
+
+Reference: `skills/shared/commit-planning-docs.md` for the commit pattern.
+
+If `planning.commit_docs` is true in config.json, commit test files:
+
+```text
+test({N}-tests): add tests for phase {N} ({X} test files)
+```
+
+---
+
+## Anti-Patterns
+
+1. **DO NOT** write test code in the main orchestrator context — always delegate to executor agents
+2. **DO NOT** generate tests for files not listed in SUMMARY.md key_files — stay scoped to the phase
+3. **DO NOT** skip running the tests — always verify they pass before reporting success
+4. **DO NOT** generate trivial tests (testing getters/setters, testing constants) — focus on behavior
+5. **DO NOT** read full source files in the orchestrator — let the executor agents read them
+
+---
+
+## Error Handling
+
+Reference: `skills/shared/error-reporting.md` for error output patterns.
+
+If test framework detection fails or no `key_files` found, display branded error and clear `.planning/.active-skill`.

package/plugins/pbr/skills/thread/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: thread
+description: "Persistent context threads for cross-session work that spans phases. Lighter than pause/resume."
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
+argument-hint: "[name | list | resume <name>]"
+---
+
+**STOP — DO NOT READ THIS FILE. You are already reading it.**
+
+# /pbr:thread — Persistent Context Threads
+
+Lightweight cross-session knowledge stores for work spanning multiple sessions that doesn't belong to any specific phase. Lighter than `/pbr:pause` (no phase state), richer than `/pbr:note` (structured sections).
+
+## Step 0 — Banner
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║  PLAN-BUILD-RUN ► THREAD                                     ║
+╚══════════════════════════════════════════════════════════════╝
+```
+
+## Subcommands
+
+### `/pbr:thread <name>` — Create thread
+
+1. `mkdir -p .planning/threads`
+2. Generate slug from name
+3. Write `.planning/threads/{slug}.md`:
+
+```markdown
+---
+created: {ISO date}
+updated: {ISO date}
+status: active
+---
+
+# {Thread Name}
+
+## Goal
+{What this thread is tracking — ask user}
+
+## Context
+{Current state of the work — filled during creation}
+
+## References
+{Related files, phases, decisions — gathered from conversation}
+
+## Next Steps
+{What to do next — filled during creation}
+```
+
+4. Display: `Thread created: {name}`
+
+### `/pbr:thread list` — List threads
+
+Scan `.planning/threads/*.md`, display name + status + last updated.
+
+### `/pbr:thread resume <name>` — Resume thread
+
+1. Find `.planning/threads/{slug}.md`
+2. Read and display Goal, Context, References, Next Steps
+3. Thread context is now in the conversation — work can continue
+4. Update the `updated` field in frontmatter
+
+### `/pbr:thread close <name>` — Close thread
+
+Update status to `closed`. Optionally promote to phase or backlog.
+
+## Anti-Patterns
+
+1. DO NOT use threads for phase-specific work — use pause/resume instead
+2. DO NOT create threads for one-off notes — use /pbr:note instead
+3. DO NOT auto-close threads — always ask user

package/plugins/pbr/skills/todo/SKILL.md

@@ -31,37 +31,15 @@ Parse `$ARGUMENTS` to determine the subcommand:
 
 ### `add <description>`
 
-1. Ensure `.planning/todos/pending/` directory exists
-2. Generate NNN: scan **both** `.planning/todos/pending/` and `.planning/todos/done/` for the highest existing number, then increment by 1 (zero-padded to 3 digits)
-3. Generate slug: take the first ~4 meaningful words from the description, lowercase, hyphen-separated (e.g., "Add rate limiting to login" → `add-rate-limiting-login`)
-4. Infer theme from description (e.g., "auth" → security, "test" → testing, "UI" → frontend, "refactor" → quality)
-5. Check for duplicates — read existing pending todos, if a similar one exists, ask user via AskUserQuestion
-6. Create `.planning/todos/pending/{NNN}-{slug}.md`:
-
-```yaml
----
-title: "{description}"
-status: pending
-priority: P2
-source: conversation
-created: {YYYY-MM-DD}
-theme: {inferred-theme}
----
-
-## Goal
-
-{description expanded into a clear goal statement}
-
-## Scope
-
-{any relevant context from the current conversation, or bullet points of what's in/out of scope}
-
-## Acceptance Criteria
-
-- [ ] {primary acceptance criterion derived from description}
-```
+1. Run the CLI to create the todo:
+   ```bash
+   node ${CLAUDE_PLUGIN_ROOT}/scripts/pbr-tools.js todo add "{description}"
+   ```
+   This handles NNN generation, slug creation (via slug-generate internally), duplicate detection, and file creation.
+   If the CLI fails, display a branded ERROR box and stop.
+2. Parse the CLI JSON output to extract the created file path, NNN, and slug for the confirmation display.
 
-7. Update STATE.md Pending Todos section
+3. **CRITICAL -- DO NOT SKIP:** Update STATE.md Pending Todos section
 
    If the Write fails, display:
    ```
@@ -97,8 +75,8 @@ theme: {inferred-theme}
 
 
 **Also available:**
-- `/pbr:todo list` — see all pending todos
-- `/pbr:status` — see project status
+- `/pbr:check-todos` — see all pending todos
+- `/pbr:progress` — see project status
 
 
 ```
@@ -134,46 +112,22 @@ Pending Todos:
 
 
 **Also available:**
-- `/pbr:status` — see project status
+- `/pbr:progress` — see project status
 
 
 ```
 
 ### `done <NNN>`
 
-1. Find `.planning/todos/pending/{NNN}-*.md` (match by number prefix)
-2. If not found, display:
-```
-╔══════════════════════════════════════════════════════════════╗
-║  ERROR                                                       ║
-╚══════════════════════════════════════════════════════════════╝
-
-Todo {NNN} not found in pending todos.
-
-**To fix:** Run `/pbr:todo list` to see available numbers.
-```
-3. Ensure `.planning/todos/done/` directory exists (create if needed)
-4. Read the pending file content
-5. Update frontmatter in the content: set `status: done` and add `completed: {YYYY-MM-DD}`
-
-**CRITICAL: Write to done/ FIRST, verify it exists, THEN delete from pending/. Do NOT delete pending before confirming done/ write succeeded.**
-
-6. Write the updated content to `.planning/todos/done/{NNN}-{slug}.md`
-7. Verify the done/ file was written successfully: check that `.planning/todos/done/{NNN}-{slug}.md` exists and has content (use `ls` or Glob)
-   - If the done/ write failed, abort and display:
-     ```
-     ╔══════════════════════════════════════════════════════════════╗
-     ║  ERROR                                                       ║
-     ╚══════════════════════════════════════════════════════════════╝
-
-     Failed to write to done/. Pending file preserved.
-
-     **To fix:** Check that `.planning/todos/done/` exists and is writable.
-     ```
-     Do NOT proceed to delete the pending file.
-8. Only THEN delete the original file from `.planning/todos/pending/` (use `rm` via Bash)
-8. Update STATE.md
-9. Confirm with branded output:
+1. Run the CLI to complete the todo:
+   ```bash
+   node ${CLAUDE_PLUGIN_ROOT}/scripts/pbr-tools.js todo done {NNN}
+   ```
+   This handles finding the file, updating frontmatter, safe write-to-done-then-delete-pending, and verification.
+   If the CLI fails (e.g., NNN not found), display a branded ERROR box and stop.
+2. Parse the CLI JSON output to extract the title for the confirmation display.
+3. Update STATE.md
+4. Confirm with branded output:
 ```
 ╔══════════════════════════════════════════════════════════════╗
 ║  PLAN-BUILD-RUN ► TODO COMPLETED ✓                           ║
@@ -189,7 +143,7 @@ Todo {NNN} not found in pending todos.
 
 **See remaining tasks**
 
-`/pbr:todo list`
+`/pbr:check-todos`
 
 <sub>`/clear` first → fresh context window</sub>
 
@@ -197,7 +151,7 @@ Todo {NNN} not found in pending todos.
 
 **Also available:**
 - `/pbr:continue` — execute next logical step
-- `/pbr:status` — see project status
+- `/pbr:progress` — see project status
 
 
 ```
@@ -205,7 +159,7 @@ Todo {NNN} not found in pending todos.
 ### `work <NNN>`
 
 1. Find `.planning/todos/pending/{NNN}-*.md` (match by number prefix)
-2. If not found, display the same error block as `done` — suggest `/pbr:todo list`
+2. If not found, display the same error block as `done` — suggest `/pbr:check-todos`
 3. Read the todo file content (frontmatter + body)
 4. Extract the `title` from frontmatter and the full body (Goal, Scope, Acceptance Criteria sections)
 
@@ -214,7 +168,7 @@ Todo {NNN} not found in pending todos.
 | Signal | Route to |
 |--------|----------|
 | Single file change, small fix, simple addition | `/pbr:quick` |
-| Multiple acceptance criteria, multi-file scope, architectural decisions, needs research | `/pbr:plan` (requires an active phase) |
+| Multiple acceptance criteria, multi-file scope, architectural decisions, needs research | `/pbr:plan-phase` (requires an active phase) |
 | Investigation needed, unclear root cause | `/pbr:debug` |
 | Open-ended exploration, no clear deliverable | `/pbr:explore` |
 
@@ -224,7 +178,7 @@ Todo {NNN} could be handled as a quick task or may need full planning.
 
 Which approach?
 - Quick task (/pbr:quick) — single executor, atomic commit
-- Full planning (/pbr:plan) — research, plan, build cycle
+- Full planning (/pbr:plan-phase) — research, plan, build cycle
 - Debug (/pbr:debug) — systematic investigation
 - Explore (/pbr:explore) — open-ended investigation
 ```
@@ -248,7 +202,7 @@ Context from todo {NNN}:
 {body content — Goal, Scope, Acceptance Criteria sections}
 ```
 
-For `/pbr:plan`, if no phase exists for this work yet, suggest the user run `/pbr:plan add` first to create one, then re-run `/pbr:todo work {NNN}`.
+For `/pbr:plan-phase`, if no phase exists for this work yet, suggest the user run `/pbr:plan-phase add` first to create one, then re-run `/pbr:todo work {NNN}`.
 
 8. When the skill completes, remind the user:
 
@@ -274,6 +228,8 @@ Show a brief summary: count of pending todos, grouped by theme, plus usage hint.
 
 After any todo operation, update the "Pending Todos" section of STATE.md with the current count and list.
 
+Reference: `skills/shared/error-reporting.md` for branded error output patterns.
+
 ## Git Integration
 
 Reference: `skills/shared/commit-planning-docs.md` for the standard commit pattern.

package/plugins/pbr/skills/ui-phase/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: ui-phase
+description: "Generate UI-SPEC.md design contracts for frontend-heavy phases."
+allowed-tools: Read, Write, Bash, Glob, Grep, Task, AskUserQuestion
+argument-hint: "<phase-number> [--url <dev-server-url>]"
+---
+
+**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 tokens. Begin executing Step 0 immediately.**
+
+## Step 0 -- Banner
+
+**Before ANY tool calls**, display this banner:
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║  PLAN-BUILD-RUN ► UI PHASE DESIGN                           ║
+╚══════════════════════════════════════════════════════════════╝
+```
+
+Then proceed to Step 1.
+
+## Step 1 -- Load State
+
+Read the following files:
+
+```bash
+node ${CLAUDE_PLUGIN_ROOT}/scripts/pbr-tools.js state load
+```
+
+Also read `.planning/config.json` to check for `ui.enabled` setting.
+
+## Step 2 -- Check UI Eligibility
+
+Determine whether the UI pipeline should be active:
+
+**2a.** If `config.ui.enabled` is explicitly `true`, proceed to Step 3.
+
+**2b.** If `config.ui.enabled` is explicitly `false`, display:
+
+```
+UI pipeline is disabled. Enable with: /pbr:config set ui.enabled true
+```
+
+Then **STOP**. Do not proceed further.
+
+**2c.** If `ui.enabled` is not set (undefined), auto-detect frontend project:
+
+1. Check `package.json` for dependencies or devDependencies containing: `react`, `vue`, `angular`, `svelte`, `next`, `nuxt`, `solid-js`, `preact`, `lit`, `@angular/core`
+2. Check for `index.html` in the project root or `public/` or `src/`
+3. Check for `.css`, `.scss`, `.less`, `.sass` files in `src/` or `styles/`
+
+If frontend indicators are found, proceed to Step 3.
+
+If NO frontend indicators are found, ask the user:
+
+```
+This doesn't appear to be a frontend project. No frontend frameworks
+or UI files were detected.
+
+Options:
+1. Continue anyway (I know this project has UI components)
+2. Cancel (this project doesn't need UI design contracts)
+3. Enable permanently: /pbr:config set ui.enabled true
+```
+
+If the user chooses option 1, proceed. If option 2, **STOP**. If option 3, tell them to run the config command and then re-run `/pbr:ui-phase`.
+
+## Step 3 -- Parse Arguments
+
+Parse `$ARGUMENTS` for:
+
+- **Phase number** (required): The phase to generate design contracts for
+- **--url flag** (optional): Dev server URL for visual inspection (e.g., `http://localhost:3000`)
+
+If no phase number is provided, display usage and **STOP**:
+
+```
+Usage: /pbr:ui-phase <phase-number> [--url <dev-server-url>]
+
+Example: /pbr:ui-phase 3 --url http://localhost:3000
+```
+
+## Step 4 -- Load Phase Context
+
+Read the ROADMAP.md to find the phase directory matching the given phase number:
+
+```bash
+node ${CLAUDE_PLUGIN_ROOT}/scripts/pbr-tools.js state load
+```
+
+Read the phase directory at `.planning/phases/{NN}-{slug}/` to understand the phase goal and any existing plans. Extract the phase goal from ROADMAP.md for the given phase number.
+
+If the phase directory does not exist, display an error and **STOP**:
+
+```
+Phase {N} not found. Check /pbr:status for available phases.
+```
+
+## Step 5 -- Spawn UI Researcher Agent
+
+**CRITICAL: Agent type rule** -- ALWAYS use `subagent_type: "pbr:ui-researcher"`. NEVER use `general-purpose` or other non-PBR agent types. The PreToolUse hook will block non-PBR agents.
+
+Spawn a Task with:
+
+- `subagent_type: "pbr:ui-researcher"`
+- Spawn prompt containing:
+  - Project root path
+  - Phase number and phase goal
+  - Dev server URL (if provided via `--url`, otherwise state "not provided")
+  - Target output path: `.planning/phases/{NN}-{slug}/UI-SPEC.md`
+  - **Template reference:** `${CLAUDE_PLUGIN_ROOT}/templates/UI-SPEC.md.tmpl` — the agent should read this template for the standard UI-SPEC format (design system, spacing, typography, color, components)
+  - Instruction to analyze the frontend codebase and generate design contracts
+
+Display before spawning:
+
+```
+Spawning ui-researcher... (est. 2-5 min)
+```
+
+Wait for agent completion.
+
+## Step 6 -- Present Results
+
+Read the generated `UI-SPEC.md` from `.planning/phases/{NN}-{slug}/UI-SPEC.md`.
+
+If the file was not created, report the error and **STOP**.
+
+Present a summary to the user showing:
+
+- Number of dimensions covered
+- Key design decisions proposed
+- Any constraints or patterns identified
+
+## Step 7 -- Confirm Design Contracts
+
+Ask the user:
+
+```
+Review the design contracts above. Options:
+1. Confirm -- lock UI-SPEC.md and proceed to planning
+2. Request changes -- describe what to adjust
+3. Cancel -- discard UI-SPEC.md
+```
+
+If the user requests changes, describe what they want adjusted and re-spawn the ui-researcher agent with the feedback. Repeat until confirmed or cancelled.
+
+If cancelled, delete the UI-SPEC.md file and **STOP**.
+
+## Step 8 -- Success
+
+Display:
+
+```
+UI-SPEC.md locked for phase {N}.
+
+Next step: Run /pbr:plan-phase {N} to plan with these design contracts.
+The planner will reference UI-SPEC.md as a constraint alongside CONTEXT.md.
+```
+
+## Context Budget
+
+Reference: `skills/shared/context-budget.md` for the universal orchestrator rules.
+Reference: `skills/shared/agent-type-resolution.md` for agent type fallback when spawning Task() subagents.
+
+Additionally for this skill:
+
+- Delegate ALL analysis to the ui-researcher subagent -- do not analyze frontend code yourself
+- Read UI-SPEC.md output only for summary presentation, not deep inspection
+- If user requests multiple rounds of changes, warn about context budget after 3 iterations
+
+Reference: `skills/shared/commit-planning-docs.md` -- if `planning.commit_docs` is true, commit UI-SPEC.md.
+
+## Anti-Patterns
+
+1. DO NOT analyze the frontend codebase yourself -- the ui-researcher agent does this
+2. DO NOT read agent .md files -- auto-loaded via subagent_type
+3. DO NOT modify UI-SPEC.md directly -- the agent handles writes
+4. DO NOT skip the UI eligibility check (Step 2)
+5. DO NOT proceed without user confirmation of design contracts
+6. DO NOT use general-purpose agents -- always use `pbr:ui-researcher`