@sienklogic/plan-build-run 2.18.1 → 2.19.1

package/plugins/copilot-pbr/skills/statusline/SKILL.md

@@ -1,149 +0,0 @@
----
-name: statusline
-description: "Install or configure the PBR status line in Claude Code."
----
-
-**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 ~3,000 tokens. Begin executing Step 0 immediately.**
-
-## Step 0 — Immediate Output
-
-**Before ANY tool calls**, display this banner:
-
-```
-╔══════════════════════════════════════════════════════════════╗
-║  PLAN-BUILD-RUN ► STATUS LINE                                ║
-╚══════════════════════════════════════════════════════════════╝
-```
-
-Then proceed to Step 1.
-
-# /pbr:statusline — Status Line Setup
-
-The PBR status line displays live project state (phase, plan, status, git branch, context usage) in the Claude Code terminal status bar.
-
----
-
-## Subcommand Parsing
-
-Parse `$ARGUMENTS`:
-
-| Argument | Action |
-|----------|--------|
-| `install` or empty | Install/enable the status line |
-| `uninstall` or `remove` | Remove the status line configuration |
-| `preview` | Show what the status line looks like without installing |
-
----
-
-## Subcommand: install (default)
-
-### Step 1: Locate the status-line script
-
-**CRITICAL: You must resolve the correct absolute path to `status-line.js`. Do NOT hardcode paths.**
-
-1. The script lives at `${PLUGIN_ROOT}/scripts/status-line.js`
-2. Resolve `${PLUGIN_ROOT}` to its absolute path using `pwd` or by checking the plugin root
-3. If running from a local plugin dir (`claude --plugin-dir .`), the path is the local repo's `plugins/pbr/scripts/status-line.js`
-4. If running from the installed plugin cache (`~/.claude/plugins/cache/`), use that path
-5. **Verify the script exists** with `ls` before proceeding. If it doesn't exist, show an error and stop.
-
-Store the resolved absolute path as `SCRIPT_PATH`.
-
-### Step 2: Read current settings
-
-Read `~/.claude/settings.json` (or `$HOME/.claude/settings.json`).
-
-- If the file doesn't exist: start with an empty object `{}`
-- If it exists: parse the JSON content
-- Check if `statusLine` key already exists:
-  - If yes and points to the same script: inform user "PBR status line is already installed." and stop (unless they want to reconfigure)
-  - If yes but points to a different command: warn user and ask if they want to replace it
-
-### Step 3: Configure settings.json
-
-Use AskUserQuestion:
-  question: "Install the PBR status line? This adds a `statusLine` entry to ~/.claude/settings.json."
-  header: "Install?"
-  options:
-    - label: "Install"  description: "Enable the PBR status line in Claude Code"
-    - label: "Preview first"  description: "Show a preview before installing"
-    - label: "Cancel"  description: "Don't install"
-  multiSelect: false
-
-If "Preview first": run the preview subcommand (show sample output), then ask again.
-If "Cancel": stop.
-If "Install":
-
-**CRITICAL: Use Read tool to read the file, then Write to update it. Do NOT use sed or other text manipulation on JSON files.**
-
-**CRITICAL: Back up settings.json NOW.** Write the original content to `~/.claude/settings.json.bak` before making any changes.
-
-1. Read `~/.claude/settings.json`
-2. Write the original content to `~/.claude/settings.json.bak`
-3. Parse the JSON
-4. Set `statusLine` to:
-   ```json
-   {
-     "type": "command",
-     "command": "node \"SCRIPT_PATH\""
-   }
-   ```
-   Where `SCRIPT_PATH` is the resolved absolute path from Step 1. Use forward slashes even on Windows.
-5. Write the updated JSON back (preserve all other settings, use 2-space indentation)
-
-### Step 4: Verify and confirm
-
-Display:
-```
-✓ PBR status line installed
-
-  Script: {SCRIPT_PATH}
-  Config: ~/.claude/settings.json
-
-The status line will appear on your next Claude Code session.
-Restart Claude Code or run `/clear` to activate it now.
-
-Customize per-project via .planning/config.json:
-  "status_line": {
-    "sections": ["phase", "plan", "status", "git", "context"],
-    "brand_text": "PBR"
-  }
-```
-
----
-
-## Subcommand: uninstall
-
-1. Read `~/.claude/settings.json`
-2. If no `statusLine` key: inform user "No status line configured." and stop
-3. **CRITICAL: Back up settings.json NOW.** Write the original content to `~/.claude/settings.json.bak` before making any changes.
-4. Remove the `statusLine` key from the JSON
-5. Write the updated file
-5. Display: `✓ PBR status line removed. Restart Claude Code to take effect.`
-
----
-
-## Subcommand: preview
-
-1. Locate and run the status-line script: `node {SCRIPT_PATH}`
-   - Pass sample stdin JSON: `{"context_window": {"used_percentage": 35}, "model": {"display_name": "Claude Opus 4.6"}, "cost": {"total_cost_usd": 0.42}}`
-2. Display the raw output to the user
-3. Also show a description of each section:
-   - **Phase**: Current phase number and name from STATE.md
-   - **Plan**: Plan progress (N of M)
-   - **Status**: Phase status keyword (planning, building, built, etc.)
-   - **Git**: Current branch + dirty indicator
-   - **Context**: Unicode bar showing context window usage (green/yellow/red)
-
----
-
-## Edge Cases
-
-### No .planning/ directory
-The status line works even without `.planning/` — it will show only git and context sections. Installation doesn't require a PBR project.
-
-### Plugin installed from npm vs local
-The script path differs between `~/.claude/plugins/cache/plan-build-run/pbr/{version}/scripts/status-line.js` and a local `plugins/pbr/scripts/status-line.js`. The install command must resolve the actual path at install time.
-
-### Existing non-PBR status line
-If `statusLine` already exists with a different command, warn the user and confirm before replacing.

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

@@ -1,279 +0,0 @@
----
-name: todo
-description: "File-based persistent todos. Add, list, complete — survives sessions."
----
-
-## Step 0 — Immediate Output
-
-**Before ANY tool calls**, display this banner:
-
-```
-╔══════════════════════════════════════════════════════════════╗
-║  PLAN-BUILD-RUN ► TODO                                       ║
-╚══════════════════════════════════════════════════════════════╝
-```
-
-Then proceed to Step 1.
-
-# /pbr:todo — Persistent File-Based Todos
-
-## Why File-Based
-
-Native Claude Code Tasks are session-scoped — they vanish when the conversation ends. Plan-Build-Run todos are individual `.md` files in `.planning/todos/` that persist across sessions, context resets, and compactions.
-
-## Subcommands
-
-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}
-```
-
-7. Update STATE.md Pending Todos section
-
-   If the Write fails, display:
-   ```
-   ╔══════════════════════════════════════════════════════════════╗
-   ║  ERROR                                                       ║
-   ╚══════════════════════════════════════════════════════════════╝
-
-   Failed to write todo file.
-
-   **To fix:** Check that `.planning/todos/pending/` exists and is writable.
-   ```
-
-8. Confirm with branded output:
-```
-╔══════════════════════════════════════════════════════════════╗
-║  PLAN-BUILD-RUN ► TODO ADDED ✓                               ║
-╚══════════════════════════════════════════════════════════════╝
-
-**Todo {NNN}:** {description}
-
-
-
-╔══════════════════════════════════════════════════════════════╗
-║  ▶ NEXT UP                                                   ║
-╚══════════════════════════════════════════════════════════════╝
-
-**Work on it now** or see your task list
-
-`/pbr:quick`
-
-<sub>`/clear` first → fresh context window</sub>
-
-
-
-**Also available:**
-- `/pbr:todo list` — see all pending todos
-- `/pbr:status` — see project status
-
-
-```
-
-### `list [theme]`
-
-1. Read all files in `.planning/todos/pending/`
-2. Parse frontmatter from each
-3. If theme filter provided, filter by theme
-4. Display as table:
-
-```
-Pending Todos:
-| # | Title | Priority | Theme | Created |
-|---|-------|----------|-------|---------|
-| 074 | Status-line customization options | P2 | capability | 2026-02-10 |
-| 075 | Add WebSearch/WebFetch/Context7 to researcher | P2 | capability | 2026-02-10 |
-```
-
-5. Offer actions with branded routing:
-```
-
-
-╔══════════════════════════════════════════════════════════════╗
-║  ▶ NEXT UP                                                   ║
-╚══════════════════════════════════════════════════════════════╝
-
-**Pick a todo** — mark one done or start working
-
-`/pbr:todo work <NNN>` — start working on a todo
-`/pbr:todo done <NNN>` — mark a todo as complete
-
-
-
-**Also available:**
-- `/pbr:status` — 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:
-```
-╔══════════════════════════════════════════════════════════════╗
-║  PLAN-BUILD-RUN ► TODO COMPLETED ✓                           ║
-╚══════════════════════════════════════════════════════════════╝
-
-**Todo {NNN}:** {title}
-
-
-
-╔══════════════════════════════════════════════════════════════╗
-║  ▶ NEXT UP                                                   ║
-╚══════════════════════════════════════════════════════════════╝
-
-**See remaining tasks**
-
-`/pbr:todo list`
-
-<sub>`/clear` first → fresh context window</sub>
-
-
-
-**Also available:**
-- `/pbr:continue` — execute next logical step
-- `/pbr:status` — see project status
-
-
-```
-
-### `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`
-3. Read the todo file content (frontmatter + body)
-4. Extract the `title` from frontmatter and the full body (Goal, Scope, Acceptance Criteria sections)
-
-5. **Assess complexity** to choose the right skill. Evaluate the todo content against these criteria:
-
-| 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) |
-| Investigation needed, unclear root cause | `/pbr:debug` |
-| Open-ended exploration, no clear deliverable | `/pbr:explore` |
-
-If unsure, ask the user via AskUserQuestion:
-```
-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
-- Debug (/pbr:debug) — systematic investigation
-- Explore (/pbr:explore) — open-ended investigation
-```
-
-6. Display branded output:
-```
-╔══════════════════════════════════════════════════════════════╗
-║  PLAN-BUILD-RUN ► WORKING ON TODO {NNN}                      ║
-╚══════════════════════════════════════════════════════════════╝
-
-**Todo {NNN}:** {title}
-**Routing to:** /pbr:{chosen-skill}
-```
-
-7. Invoke the chosen skill via the Skill tool, passing the todo title and body as args:
-
-```
-{title}
-
-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}`.
-
-8. When the skill completes, remind the user:
-
-```
-
-
-╔══════════════════════════════════════════════════════════════╗
-║  ▶ NEXT UP                                                   ║
-╚══════════════════════════════════════════════════════════════╝
-
-**Mark this todo as done if the work is complete**
-
-`/pbr:todo done {NNN}`
-
-
-```
-
-### No arguments
-
-Show a brief summary: count of pending todos, grouped by theme, plus usage hint.
-
-## State Integration
-
-After any todo operation, update the "Pending Todos" section of STATE.md with the current count and list.
-
-## Git Integration
-
-Reference: `skills/shared/commit-planning-docs.md` for the standard commit pattern.
-
-If `planning.commit_docs: true` in config, commit todo changes:
-- `docs(planning): add todo {NNN}`
-- `docs(planning): complete todo {NNN}`

package/plugins/copilot-pbr/templates/CONTEXT.md.tmpl

@@ -1,53 +0,0 @@
-<!-- canonical: ../../pbr/templates/CONTEXT.md.tmpl -->
-# CONTEXT.md Template
-
-> Referenced by: begin skill (Step 9c), discuss skill, plan skill
-> Created during /pbr:begin. Updated by /pbr:discuss and /pbr:plan --assumptions.
-
-## Structure
-
-```markdown
-# Project Context
-
-## Locked Decisions
-
-{Technology choices, architecture decisions, and constraints that are NON-NEGOTIABLE.
- These MUST be honored by every plan and executor — no exceptions.}
-
-| Decision | Rationale | Locked By |
-|----------|-----------|-----------|
-| {e.g., "Use TypeScript"} | {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 planning}
-
-- {e.g., "Solo developer, no team"}
-- {e.g., "Deploy to Hetzner VPS"}
-- {e.g., "Must work offline"}
-
-## Deferred Ideas
-
-{Features explicitly moved to v2 or out-of-scope. Plans MUST NOT include these.}
-
-| Idea | Reason Deferred |
-|------|----------------|
-| {feature} | {reason} |
-
-## Claude's Discretion Areas
-
-{Areas where the planner can make implementation choices without asking the user.
- Document the choice made and rationale when exercised.}
-
-| Area | Choice Made | Rationale |
-|------|------------|-----------|
-| {e.g., "State management library"} | {e.g., "Zustand"} | {e.g., "Lightweight, fits project size"} |
-```
-
-## Rules
-
-- Locked decisions are immutable once set — only the user can change them
-- Deferred ideas must NEVER appear in plans
-- Discretion areas are documented when the planner exercises choice
-- Phase-level CONTEXT.md files (in phase directories) override project-level for that phase

package/plugins/copilot-pbr/templates/INTEGRATION-REPORT.md.tmpl

@@ -1,152 +0,0 @@
-<!-- canonical: ../../pbr/templates/INTEGRATION-REPORT.md.tmpl -->
-<!-- Source: agents/integration-checker.md | Purpose: Output format for cross-phase integration verification reports -->
-
-```markdown
-# Integration Verification Report
-
-> Verified: {date}
-> Phases checked: {comma-separated list of phase IDs}
-> Status: **{INTEGRATED | GAPS_FOUND}**
-
-## Phase Dependency Graph
-
-```
-Phase 01 (Setup) ──provides──→ Phase 02 (Auth)
-Phase 01 (Setup) ──provides──→ Phase 03 (Core)
-Phase 02 (Auth)  ──provides──→ Phase 03 (Core)
-Phase 02 (Auth)  ──provides──→ Phase 04 (Frontend)
-Phase 03 (Core)  ──provides──→ Phase 04 (Frontend)
-```
-
-## 1. Export/Import Wiring
-
-### Export Status Summary
-
-| Phase | Total Exports | Consumed | Orphaned | Unused Imports | Mismatched |
-|-------|--------------|----------|----------|---------------|------------|
-| 01 | {n} | {n} | {n} | {n} | {n} |
-| 02 | {n} | {n} | {n} | {n} | {n} |
-
-### Detailed Export Map
-
-| Export | Source Phase | Source File:Line | Consumer(s) | Status |
-|--------|------------|-----------------|-------------|--------|
-| DatabaseConnection | 01 | src/db/conn.ts:5 | Phase 02, 03 | CONSUMED |
-| ConfigLoader | 01 | src/config/index.ts:12 | Phase 03 | CONSUMED |
-| ThemeProvider | 04 | src/theme/provider.tsx:8 | - | ORPHANED |
-
-### Orphaned Exports (created but never used)
-
-| Export | Phase | File | Line | Likely Intended Consumer |
-|--------|-------|------|------|------------------------|
-| {name} | {phase} | {file} | {line} | {best guess or "unknown"} |
-
-### Unused Imports (imported but symbol never called)
-
-| File | Imported Symbol | Source Module | Line |
-|------|----------------|--------------|------|
-| {file} | {symbol} | {module} | {line} |
-
-## 2. API Coverage
-
-### Route Coverage Matrix
-
-| Route | Method | Handler | Frontend Caller | Auth | Status |
-|-------|--------|---------|----------------|------|--------|
-| /api/users | GET | users.ts:12 | UserList.tsx:34 | YES | COVERED |
-| /api/users/:id | DELETE | users.ts:45 | - | YES | NO_CALLER |
-| /api/settings | PUT | - | Settings.tsx:22 | - | NO_HANDLER |
-
-### Uncovered Routes (backend exists, no frontend caller)
-
-| Route | Method | Handler | Possible Reason |
-|-------|--------|---------|----------------|
-| {route} | {method} | {file:line} | {guess: future feature, admin only, etc.} |
-
-### Missing Handlers (frontend calls, no backend route)
-
-| Frontend File | Calls | Expected Route | Expected Method |
-|--------------|-------|---------------|----------------|
-| {file} | fetch('/api/X') | /api/X | GET |
-
-## 3. Auth Protection
-
-### Route Protection Summary
-
-| Category | Total | Protected | Unprotected | Status |
-|----------|-------|-----------|-------------|--------|
-| API Routes | {n} | {n} | {n} | {OK/ISSUES} |
-| Pages | {n} | {n} | {n} | {OK/ISSUES} |
-| Public Routes | {n} | - | {n} | OK |
-
-### Unprotected Routes (SECURITY ISSUES)
-
-| Route | Method | Handler | Should Protect | Evidence |
-|-------|--------|---------|---------------|----------|
-| {route} | {method} | {file:line} | YES | No auth middleware in chain |
-
-### Auth Flow Completeness
-
-| Step | Status | Evidence |
-|------|--------|----------|
-| Login form exists | {YES/NO} | {file:line} |
-| Auth API called | {YES/NO} | {file:line} |
-| Token/session created | {YES/NO} | {file:line} |
-| Token sent with requests | {YES/NO} | {file:line} |
-| Auth middleware applied | {YES/NO} | {file:line} |
-| Unauthorized redirect | {YES/NO} | {file:line} |
-
-## 4. End-to-End Flows
-
-### Flow 1: {Flow Name} - {STATUS}
-
-| Step | Description | Component | Exists | Connected to Next | Evidence |
-|------|------------|-----------|--------|-------------------|----------|
-| 1 | {step desc} | {file} | YES | YES | import at L12, call at L45 |
-| 2 | {step desc} | {file} | YES | NO | handler exists but not called |
-| 3 | {step desc} | - | NO | - | File not found |
-
-**Break point**: {If BROKEN, where exactly the chain breaks}
-**Impact**: {What user action fails because of this break}
-
-### Flow 2: {Flow Name} - {STATUS}
-...
-
-## 5. Integration Issues Summary
-
-### Critical Issues (system cannot function)
-
-1. **{Issue}**: {description with evidence}
-   - Impact: {what breaks}
-   - Fix: {recommended action}
-
-### Warnings (partial functionality)
-
-1. **{Issue}**: {description with evidence}
-   - Impact: {what's degraded}
-   - Fix: {recommended action}
-
-### Info (cleanup opportunities)
-
-1. **{Issue}**: {description}
-   - Fix: {recommended action}
-
-## 6. Integration Score
-
-| Category | Items Checked | Passed | Failed | Score |
-|----------|--------------|--------|--------|-------|
-| Export wiring | {n} | {n} | {n} | {%} |
-| API coverage | {n} | {n} | {n} | {%} |
-| Auth protection | {n} | {n} | {n} | {%} |
-| E2E flows | {n} | {n} | {n} | {%} |
-| **Overall** | {n} | {n} | {n} | **{%}** |
-
-## Recommendations
-
-{Prioritized list of actions to fix integration issues}
-
-1. **[CRITICAL]** {Most important fix}
-2. **[CRITICAL]** {Second most important}
-3. **[WARNING]** {Important but not blocking}
-4. ...
-```