@sienklogic/plan-build-run 2.11.0 → 2.12.1

package/plugins/copilot-pbr/templates/research/SUMMARY.md.tmpl

@@ -1,112 +0,0 @@
-<!-- Source: agents/researcher.md | Purpose: Output format for research project SUMMARY.md (executive overview with roadmap implications) -->
-# Project Research Summary
-
-**Project:** {project_name}
-**Domain:** {domain}
-**Researched:** {date}
-**Confidence:** {confidence}
-
-## Executive Summary
-
-{executive_summary}
-
-## Key Findings
-
-### Recommended Stack
-
-{stack_summary}
-
-**Core technologies:**
-- {technology}: {purpose} -- {rationale}
-
-### Expected Features
-
-{features_summary}
-
-**Must have (table stakes):**
-- {feature} -- users expect this
-
-**Should have (competitive):**
-- {feature} -- differentiator
-
-**Defer (v2+):**
-- {feature} -- not essential for launch
-
-### Architecture Approach
-
-{architecture_summary}
-
-**Major components:**
-1. {component} -- {responsibility}
-2. {component} -- {responsibility}
-3. {component} -- {responsibility}
-
-### Critical Pitfalls
-
-{pitfalls_summary}
-
-1. **{pitfall}** -- {avoidance}
-2. **{pitfall}** -- {avoidance}
-3. **{pitfall}** -- {avoidance}
-
-## Implications for Roadmap
-
-Based on research, suggested phase structure:
-
-### Phase 1: {phase_name}
-**Rationale:** {why_first}
-**Delivers:** {deliverables}
-**Addresses:** {features}
-**Avoids:** {pitfall}
-
-### Phase 2: {phase_name}
-**Rationale:** {why_this_order}
-**Delivers:** {deliverables}
-**Uses:** {stack_elements}
-**Implements:** {architecture_component}
-
-### Phase 3: {phase_name}
-**Rationale:** {why_this_order}
-**Delivers:** {deliverables}
-
-### Phase Ordering Rationale
-
-- {ordering_rationale}
-
-### Research Flags
-
-Phases likely needing deeper research during planning:
-- **Phase {x}:** {reason}
-
-Phases with standard patterns (skip research-phase):
-- **Phase {x}:** {reason}
-
-## Confidence Assessment
-
-| Area | Confidence | Notes |
-|------|------------|-------|
-| Stack | {confidence} | {notes} |
-| Features | {confidence} | {notes} |
-| Architecture | {confidence} | {notes} |
-| Pitfalls | {confidence} | {notes} |
-
-**Overall confidence:** {confidence}
-
-### Gaps to Address
-
-- {gap}: {handling}
-
-## Sources
-
-### Primary (HIGH confidence)
-- {source}
-
-### Secondary (MEDIUM confidence)
-- {source}
-
-### Tertiary (LOW confidence)
-- {source}
-
----
-*Research completed: {date}*
-*Ready for roadmap: yes*

package/plugins/copilot-pbr/templates/research-outputs/phase-research.md.tmpl

@@ -1,81 +0,0 @@
-# Phase Research: {Phase Name}
-
-> Research conducted: {date}
-> Research date: {ISO date}
-> Mode: phase-research
-> Phase: {NN}-{phase-name}
-> Confidence: {overall HIGH/MEDIUM/LOW}
-> Coverage: {COMPLETE/PARTIAL/INSUFFICIENT}
-> Retrieval cycles: {1-3}
-
-## User Constraints
-
-{Copied verbatim from CONTEXT.md}
-
-## Phase Goal
-
-{What this phase aims to achieve, extracted from the phase definition}
-
-## Implementation Approach
-
-### Recommended Approach
-
-{Detailed implementation strategy with source attribution}
-
-**Steps**:
-1. {Step with [S{n}] attribution}
-2. ...
-
-**Key decisions**:
-- {Decision with rationale and source}
-
-### Configuration Details
-
-{Specific configuration values, environment variables, file paths}
-
-```{language}
-// Source: [S{n}]
-{configuration example}
-```
-
-### API Patterns
-
-{Relevant API signatures, request/response formats, authentication patterns}
-
-### Data Models
-
-{Database schemas, type definitions, data flow}
-
-## Dependencies
-
-{What needs to be installed, configured, or available}
-
-| Dependency | Version | Purpose | Required By |
-|-----------|---------|---------|-------------|
-| ... | ... | ... | ... |
-
-## Pitfalls for This Phase
-
-{Phase-specific things that can go wrong}
-
-1. **{Pitfall}** [S{n}]: {Description}
-
-## Testing Strategy
-
-{How to verify this phase works correctly}
-
-## Coverage Assessment
-
-| Question | Status | Confidence | Cycle Resolved |
-|----------|--------|------------|----------------|
-| {Implementation question 1} | ANSWERED | HIGH | 1 |
-| {Implementation question 2} | GAP | — | — |
-
-**Overall coverage**: {COMPLETE/PARTIAL/INSUFFICIENT}
-**Gaps remaining**: {List any unresolved questions}
-
-## Sources
-
-| # | Type | URL/Description | Confidence |
-|---|------|----------------|------------|
-| ... | ... | ... | ... |

package/plugins/copilot-pbr/templates/research-outputs/project-research.md.tmpl

@@ -1,99 +0,0 @@
-# Research: {Topic Title}
-
-> Research conducted: {date}
-> Research date: {ISO date}
-> Mode: project-research
-> Confidence: {overall HIGH/MEDIUM/LOW}
-> Coverage: {COMPLETE/PARTIAL/INSUFFICIENT}
-> Retrieval cycles: {1-3}
-> Sources consulted: {count}
-
-## User Constraints
-
-{Copied verbatim from CONTEXT.md if it exists. Otherwise: "No CONTEXT.md found."}
-
-## Executive Summary
-
-{2-3 paragraph overview of findings. What is this technology/domain? Why does it matter for this project? What is the recommended approach?}
-
-## Standard Stack
-
-{The conventional/recommended technology stack for this domain}
-
-| Layer | Technology | Version | Confidence | Source |
-|-------|-----------|---------|------------|--------|
-| Runtime | Node.js | 20.x LTS | HIGH | [S2] |
-| Framework | Next.js | 14.x | HIGH | [S2] |
-| ... | ... | ... | ... | ... |
-
-### Stack Rationale
-
-{Why this combination? What alternatives were considered and why they were rejected?}
-
-### Stack Risks
-
-{Known issues, upcoming deprecations, migration concerns}
-
-## Architecture Patterns
-
-### Recommended Pattern: {Name}
-
-{Description with source attribution}
-
-**When to use**: ...
-**When to avoid**: ...
-**Example structure**:
-```
-project/
-  src/
-    ...
-```
-
-### Alternative Pattern: {Name}
-
-{Only include if CONTEXT.md doesn't lock the architecture}
-
-## Common Pitfalls
-
-{Numbered list of things that commonly go wrong}
-
-1. **{Pitfall name}** [S{n}]: {Description and how to avoid}
-2. ...
-
-## Code Examples
-
-{Working code snippets for key patterns. Every snippet must include source attribution.}
-
-### {Pattern Name}
-
-```{language}
-// Source: [S{n}] {url or description}
-{code}
-```
-
-## Integration Points
-
-{How this technology connects with other systems. API patterns, data flow, authentication.}
-
-## Coverage Assessment
-
-| Question | Status | Confidence | Cycle Resolved |
-|----------|--------|------------|----------------|
-| {Core question 1} | ANSWERED | HIGH | 1 |
-| {Core question 2} | ANSWERED | MEDIUM | 2 |
-| {Core question 3} | GAP | — | — |
-
-**Overall coverage**: {COMPLETE/PARTIAL/INSUFFICIENT}
-**Gaps remaining**: {List any unresolved questions and why they couldn't be answered}
-
-## Open Questions
-
-{Things the research could not definitively answer. These need human input or further investigation.}
-
-## Sources
-
-| # | Type | URL/Description | Confidence |
-|---|------|----------------|------------|
-| S1 | Official Docs | {url} | HIGH |
-| S2 | GitHub | {url} | HIGH |
-| ... | ... | ... | ... |

package/plugins/copilot-pbr/templates/research-outputs/synthesis.md.tmpl

@@ -1,36 +0,0 @@
-# Research Synthesis: {Topic}
-
-> Synthesized: {date}
-> Mode: synthesis
-> Input documents: {count}
-> Confidence: {overall}
-
-## Executive Summary
-
-{Unified findings across all input documents}
-
-## Key Findings
-
-{Numbered list of the most important findings, with source document attribution}
-
-## Contradictions Resolved
-
-{Where input documents disagreed and how it was resolved}
-
-| Topic | Document A Says | Document B Says | Resolution | Basis |
-|-------|----------------|----------------|------------|-------|
-| ... | ... | ... | ... | ... |
-
-## Recommended Approach
-
-{The synthesized recommendation}
-
-## Risks and Mitigations
-
-| Risk | Likelihood | Impact | Mitigation |
-|------|-----------|--------|------------|
-| ... | ... | ... | ... |
-
-## Sources
-
-{Consolidated source list from all input documents}

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

@@ -1,32 +0,0 @@
-{
-  "name": "pbr",
-  "displayName": "Plan-Build-Run",
-  "version": "2.11.0",
-  "description": "Plan-Build-Run — Structured development workflow for Cursor. Solves context rot through disciplined subagent delegation, structured planning, atomic execution, and goal-backward verification.",
-  "author": {
-    "name": "SienkLogic",
-    "email": "dave@sienklogic.com"
-  },
-  "publisher": "SienkLogic",
-  "homepage": "https://github.com/SienkLogic/plan-build-run",
-  "repository": "https://github.com/SienkLogic/plan-build-run",
-  "license": "MIT",
-  "logo": "../assets/logo.svg",
-  "keywords": [
-    "cursor",
-    "context-engineering",
-    "development-workflow",
-    "subagent-delegation"
-  ],
-  "category": "developer-tools",
-  "tags": [
-    "planning",
-    "workflow",
-    "structured-development",
-    "context-management"
-  ],
-  "skills": "./skills/",
-  "agents": "./agents/",
-  "rules": "./rules/",
-  "hooks": "./hooks/hooks.json"
-}

package/plugins/cursor-pbr/CHANGELOG.md

@@ -1,15 +0,0 @@
-# Changelog
-
-## v2.0.0 (2026-02-19)
-
-Initial release of Plan-Build-Run for Cursor.
-
-### Features
-
-- 21 skills covering the full development lifecycle: begin, plan, build, review, debug, and more
-- 10 specialized agents with fresh context windows for delegation without context rot
-- Shared hook scripts with the Claude Code plugin for consistent behavior
-- Cross-plugin compatibility: shared `.planning/` state directory works with both Cursor and Claude Code
-- File-based state management with structured planning, execution, and verification phases
-- Atomic commits with deviation handling and self-verification
-- Goal-backward verification ensuring builds match plans

package/plugins/cursor-pbr/README.md

@@ -1,118 +0,0 @@
-# Plan-Build-Run for Cursor
-
-A structured development workflow plugin for Cursor that solves context rot through disciplined subagent delegation, file-based state, and goal-backward verification.
-
-## Installation
-
-### Automated Setup (Recommended)
-
-The setup script creates symlinks from your project's `.cursor/` directory to the PBR plugin, so rules and agents are discovered automatically by Cursor.
-
-**macOS / Linux:**
-```bash
-cd /path/to/your/project
-bash /path/to/plan-build-run/plugins/cursor-pbr/setup.sh
-```
-
-**Windows (PowerShell):**
-```powershell
-cd C:\path\to\your\project
-powershell -ExecutionPolicy Bypass -File C:\path\to\plan-build-run\plugins\cursor-pbr\setup.ps1
-```
-
-This installs:
-- `.cursor/rules/pbr-workflow.mdc` — Workflow rules (auto-loaded when `.planning/` exists)
-- `.cursor/agents/*.md` — 10 specialized agent definitions
-
-### Manual Setup
-
-If you prefer not to use the setup script:
-
-1. Copy or symlink `rules/pbr-workflow.mdc` into your project's `.cursor/rules/` directory
-2. Copy or symlink all files from `agents/` into your project's `.cursor/agents/` directory
-3. Skills (in `skills/`) are prompt templates — paste a skill's `SKILL.md` content into Cursor chat to invoke it, or reference the skill directory if Cursor supports skill discovery
-
-### Uninstall
-
-Remove the symlinks created by setup:
-
-```bash
-rm .cursor/rules/pbr-workflow.mdc
-rm .cursor/agents/*.md    # only PBR agent files
-```
-
-## Quick Start
-
-The core workflow follows four steps per phase:
-
-```
-/pbr:begin     — Define your project: requirements, research, roadmap
-/pbr:plan 1    — Create a detailed plan for phase 1
-/pbr:build 1   — Execute the plan with atomic commits
-/pbr:review 1  — Verify the build matched the plan
-```
-
-Repeat `plan` / `build` / `review` for each phase in your roadmap.
-
-## Skills (21)
-
-| Skill | Description |
-|-------|-------------|
-| begin | Start a new project. Deep questioning, research, requirements, and roadmap. |
-| build | Execute all plans in a phase. Spawns agents to build in parallel, commits atomically. |
-| config | Configure settings: depth, model profiles, features, git, and gates. |
-| continue | Execute the next logical step automatically. No prompts, no decisions. |
-| debug | Systematic debugging with hypothesis testing. Persistent across sessions. |
-| discuss | Talk through a phase before planning. Identifies gray areas and captures decisions. |
-| explore | Explore ideas, think through approaches, and route insights to the right artifacts. |
-| health | Check planning directory integrity. Find and fix corrupted state. |
-| help | Command reference and workflow guide. |
-| import | Import external plans. Validates context, detects conflicts, generates PLAN.md. |
-| milestone | Manage milestones: new, complete, audit, gaps. |
-| note | Zero-friction idea capture. Append, list, or promote notes to todos. |
-| pause | Save your current session state for later resumption. |
-| plan | Create a detailed plan for a phase. Research, plan, and verify before building. |
-| quick | Execute an ad-hoc task with atomic commits. Skips full plan/review. |
-| resume | Pick up where you left off. Restores context and suggests next action. |
-| review | Verify the build matched the plan. Automated checks plus walkthrough. |
-| scan | Analyze an existing codebase. Maps structure, architecture, conventions, and concerns. |
-| setup | Onboarding wizard. Initialize project, select models, verify setup. |
-| status | Show current project status and suggest what to do next. |
-| todo | File-based persistent todos. Add, list, complete — survives sessions. |
-
-Skills live in `skills/{name}/SKILL.md`. Each is a self-contained prompt that can be pasted into Cursor chat or invoked as a slash command if Cursor discovers the plugin manifest.
-
-## Agents (10)
-
-| Agent | Description |
-|-------|-------------|
-| codebase-mapper | Explores codebases and writes structured analysis across four focus areas. |
-| debugger | Systematic debugging using scientific method with hypothesis testing and evidence tracking. |
-| executor | Executes plan tasks with atomic commits, deviation handling, and self-verification. |
-| general | Lightweight agent for ad-hoc tasks that don't fit specialized roles. |
-| integration-checker | Cross-phase integration and E2E flow verification. |
-| plan-checker | Verifies plans will achieve phase goals before execution via goal-backward analysis. |
-| planner | Creates executable phase plans with task breakdown, dependency analysis, and wave assignment. |
-| researcher | Unified research agent for project domains and implementation approaches. |
-| synthesizer | Fast synthesis of multiple research outputs into coherent recommendations. |
-| verifier | Goal-backward phase verification against the real codebase. |
-
-## Configuration
-
-Plan-Build-Run stores all state in a `.planning/` directory at your project root:
-
-- `.planning/config.json` — Workflow settings (~62 properties across 12 keys)
-- `.planning/STATE.md` — Current position and status
-- `.planning/ROADMAP.md` — Phase structure, goals, and dependencies
-- `.planning/phases/NN-slug/` — Per-phase plans, summaries, and verification reports
-
-Run `/pbr:config` to interactively adjust settings like depth, model profiles, and gate behavior.
-
-## Cross-Plugin Compatibility
-
-This plugin works alongside the Claude Code version of Plan-Build-Run. Both plugins share the same `.planning/` directory and file formats, so you can switch between Cursor and Claude Code without losing state. Hook scripts under `plugins/pbr/scripts/` are shared between both plugins via relative paths.
-
-## Links
-
-- Repository: [https://github.com/SienkLogic/plan-build-run](https://github.com/SienkLogic/plan-build-run)
-- License: MIT

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

@@ -1,150 +0,0 @@
----
-name: codebase-mapper
-description: "Explores existing codebases and writes structured analysis documents. Four focus areas: tech, arch, quality, concerns."
-model: sonnet
-readonly: false
----
-
-# Plan-Build-Run Codebase Mapper
-
-You are **codebase-mapper**, the codebase analysis agent for the Plan-Build-Run development system. You explore existing codebases and produce structured documentation that helps other agents (and humans) understand the project's technology stack, architecture, conventions, and concerns.
-
-## Core Philosophy
-
-- **Document quality over brevity.** Be thorough. Other agents depend on your analysis for accurate planning and execution.
-- **Always include file paths.** Every claim must reference the actual code location. Never say "the config file" — say "`tsconfig.json` at project root" or "`src/config/database.ts`".
-- **Write current state only.** No temporal language ("recently added", "will be changed", "was refactored"). Document WHAT IS, not what was or will be.
-- **Be prescriptive, not descriptive.** When documenting conventions: "Use this pattern" not "This pattern exists."
-- **Evidence-based.** Read the actual files. Don't guess from file names or directory structures.
-
----
-
-### Forbidden Files
-
-When exploring, NEVER commit or recommend committing:
-- `.env` files (except `.env.example` or `.env.template`)
-- `*.key`, `*.pem`, `*.pfx`, `*.p12` — private keys and certificates
-- Files containing `credential` or `secret` in their name
-- `*.keystore`, `*.jks` — Java keystores
-- `id_rsa`, `id_ed25519` — SSH keys
-
-If encountered, note in CONCERNS.md under "Security Considerations" but do NOT include contents.
-
----
-
-## Focus Areas
-
-You receive ONE focus area per invocation. All output is written to `.planning/codebase/` (create if needed). **Do NOT commit** — the orchestrator handles commits.
-
-| Focus | Output Files | Templates |
-|-------|-------------|-----------|
-| `tech` | STACK.md, INTEGRATIONS.md | `templates/codebase/STACK.md.tmpl`, `templates/codebase/INTEGRATIONS.md.tmpl` |
-| `arch` | ARCHITECTURE.md, STRUCTURE.md | `templates/codebase/ARCHITECTURE.md.tmpl`, `templates/codebase/STRUCTURE.md.tmpl` |
-| `quality` | CONVENTIONS.md, TESTING.md | `templates/codebase/CONVENTIONS.md.tmpl`, `templates/codebase/TESTING.md.tmpl` |
-| `concerns` | CONCERNS.md | `templates/codebase/CONCERNS.md.tmpl` |
-
-Read the relevant `.tmpl` file(s) and fill in all placeholder fields with data from your analysis.
-
-### Fallback Format (if templates unreadable)
-
-If the template files cannot be read, use these minimum viable structures:
-
-**STACK.md:**
-```markdown
-## Tech Stack
-| Category | Technology | Version | Config File |
-|----------|-----------|---------|-------------|
-## Package Manager
-{name} — lock file: {path}
-```
-
-**ARCHITECTURE.md:**
-```markdown
-## Architecture Overview
-**Pattern:** {pattern name}
-## Key Components
-| Component | Path | Responsibility |
-|-----------|------|---------------|
-## Data Flow
-{entry point} -> {processing} -> {output}
-```
-
-**CONVENTIONS.md:**
-```markdown
-## Code Conventions
-| Convention | Pattern | Example File |
-|-----------|---------|-------------|
-## Naming Patterns
-{description with file path evidence}
-```
-
-**CONCERNS.md:**
-```markdown
-## Concerns
-| Severity | Area | Description | File |
-|----------|------|-------------|------|
-## Security Considerations
-{findings}
-```
-
----
-
-## Exploration Process
-
-> **Cross-platform**: Use Glob, Read, and Grep tools — not Bash `ls`, `find`, or `cat`. Bash file commands fail on Windows.
-
-1. **Orientation** — Glob for source files, config files, docs, Docker, CI/CD to understand project shape.
-2. **Deep Inspection** — Read 5-10+ key files per focus area (package.json, configs, entry points, core modules).
-3. **Pattern Recognition** — Identify repeated conventions across the codebase.
-4. **Write Documentation** — Write to `.planning/codebase/` using the templates. Write documents as you go to manage context.
-
----
-
-## Output Budget
-
-| Artifact | Target | Hard Limit |
-|----------|--------|------------|
-| STACK.md | ≤ 800 tokens | 1,200 tokens |
-| INTEGRATIONS.md | ≤ 600 tokens | 1,000 tokens |
-| ARCHITECTURE.md | ≤ 1,000 tokens | 1,500 tokens |
-| STRUCTURE.md | ≤ 600 tokens | 1,000 tokens |
-| CONVENTIONS.md | ≤ 800 tokens | 1,200 tokens |
-| TESTING.md | ≤ 600 tokens | 1,000 tokens |
-| CONCERNS.md | ≤ 600 tokens | 1,000 tokens |
-| Total per focus area (2 docs) | ≤ 1,400 tokens | 2,200 tokens |
-
-**Guidance**: Tables over prose. Version numbers and file paths are the high-value data — skip explanations of what well-known tools do. The planner reads these documents to make decisions; give it decision-relevant facts, not tutorials.
-
----
-
-## Quality Standards
-
-1. Every claim must reference actual file paths (with line numbers when possible)
-2. Verify versions from package.json/lock files, not from memory
-3. Read at least 5-10 key files per focus area — file names lie, check source
-4. Include actual code examples from the codebase, not generic examples
-5. Stop before 50% context usage — write documents incrementally
-
----
-
-## Universal Anti-Patterns
-
-1. DO NOT guess or assume — read actual files for evidence
-2. DO NOT trust SUMMARY.md or other agent claims without verifying codebase
-3. DO NOT use vague language — be specific and evidence-based
-4. DO NOT present training knowledge as verified fact
-5. DO NOT exceed your role — recommend the correct agent if task doesn't fit
-6. DO NOT modify files outside your designated scope
-7. DO NOT add features or scope not requested — log to deferred
-8. DO NOT skip steps in your protocol, even for "obvious" cases
-9. DO NOT contradict locked decisions in CONTEXT.md
-10. DO NOT implement deferred ideas from CONTEXT.md
-11. DO NOT consume more than 50% context before producing output
-12. DO NOT read agent .md files from agents/ — auto-loaded via subagent_type
-
-Additionally for this agent:
-
-1. DO NOT guess technology versions — read package.json or equivalent
-2. DO NOT use temporal language ("recently added", "old code")
-3. DO NOT produce generic documentation — every claim must reference this specific codebase
-4. DO NOT commit the output — the orchestrator handles commits