mirror of
https://github.com/JuliusBrussee/cavekit.git
synced 2026-09-14 16:32:40 +08:00
Rename 'blueprint' commands and plugin to 'bp'
Replace the long 'blueprint' namespace with the shorter 'bp' across docs, command specs, agent descriptions, scripts, and skills. Updated README, command/agent metadata, install/setup scripts, launcher/picker scripts, plugin.json (name -> "bp"), and many SKILL.md cross-references so slash commands (e.g. /blueprint:build) and plugin identifiers consistently use /bp:... and bp@... to avoid mismatches.
This commit is contained in:
Julius Brussee
@@ -34,7 +34,7 @@ Interactive multi-select picker shows all build sites:
|
||||
|
||||
Selected sites each get:
|
||||
- Their own **git worktree** (branch: `blueprint/<site-name>`)
|
||||
- A **tmux pane** running Claude Code with `/blueprint:build`
|
||||
- A **tmux pane** running Claude Code with `/bp:build`
|
||||
- Auto-layout: horizontal for 2-3 agents, tiled for 4+
|
||||
- Live status bar showing per-site progress
|
||||
|
||||
@@ -43,7 +43,7 @@ Staggered launch (5s between agents) to avoid API rate limits.
|
||||
### Expanded mode (`--monitor --expanded`)
|
||||
|
||||
One tmux window per site with the full 3-pane layout:
|
||||
- **Left (70%)** — Claude Code running `/blueprint:build`
|
||||
- **Left (70%)** — Claude Code running `/bp:build`
|
||||
- **Top-right** — live progress: tasks done, tiers, progress bar
|
||||
- **Bottom-right** — live activity: iteration log, git commits
|
||||
|
||||
@@ -61,19 +61,19 @@ Parses loop logs across all cycles and worktrees:
|
||||
## Claude: slash commands
|
||||
|
||||
```
|
||||
/blueprint:draft → draft blueprints (the WHAT)
|
||||
/blueprint:architect → generate build site (the ORDER)
|
||||
/blueprint:build → ralph loop (the BUILD)
|
||||
/blueprint:inspect → gap analysis + peer review (the CHECK)
|
||||
/blueprint:merge → blueprint-aware branch integration (the SHIP)
|
||||
/bp:draft → draft blueprints (the WHAT)
|
||||
/bp:architect → generate build site (the ORDER)
|
||||
/bp:build → ralph loop (the BUILD)
|
||||
/bp:inspect → gap analysis + peer review (the CHECK)
|
||||
/bp:merge → blueprint-aware branch integration (the SHIP)
|
||||
```
|
||||
|
||||
### 1. Draft — write blueprints
|
||||
|
||||
```bash
|
||||
/blueprint:draft # interactive — asks what to build
|
||||
/blueprint:draft context/refs/ # from PRDs, API docs, research
|
||||
/blueprint:draft --from-code # from existing codebase
|
||||
/bp:draft # interactive — asks what to build
|
||||
/bp:draft context/refs/ # from PRDs, API docs, research
|
||||
/bp:draft --from-code # from existing codebase
|
||||
```
|
||||
|
||||
Decomposes your project into domains. Each domain gets a blueprint with R-numbered requirements and testable acceptance criteria.
|
||||
@@ -81,8 +81,8 @@ Decomposes your project into domains. Each domain gets a blueprint with R-number
|
||||
### 2. Architect — generate build site
|
||||
|
||||
```bash
|
||||
/blueprint:architect # all blueprints
|
||||
/blueprint:architect --filter v2 # only v2 blueprints
|
||||
/bp:architect # all blueprints
|
||||
/bp:architect --filter v2 # only v2 blueprints
|
||||
```
|
||||
|
||||
Reads blueprints, breaks requirements into tasks, maps dependencies, organizes into tiers.
|
||||
@@ -90,9 +90,9 @@ Reads blueprints, breaks requirements into tasks, maps dependencies, organizes i
|
||||
### 3. Build — run the loop
|
||||
|
||||
```bash
|
||||
/blueprint:build # implement everything
|
||||
/blueprint:build --peer-review # add Codex (GPT-5.4) review
|
||||
/blueprint:build --max-iterations 30
|
||||
/bp:build # implement everything
|
||||
/bp:build --peer-review # add Codex (GPT-5.4) review
|
||||
/bp:build --max-iterations 30
|
||||
```
|
||||
|
||||
Each iteration: read site → find next unblocked task → read blueprint → implement → validate → commit → loop.
|
||||
@@ -100,16 +100,16 @@ Each iteration: read site → find next unblocked task → read blueprint → im
|
||||
### 4. Inspect — post-loop check
|
||||
|
||||
```bash
|
||||
/blueprint:inspect # gap analysis + peer review
|
||||
/bp:inspect # gap analysis + peer review
|
||||
```
|
||||
|
||||
### 5. Merge — blueprint-aware branch integration
|
||||
|
||||
```bash
|
||||
/blueprint:merge # merge all blueprint/* branches into main
|
||||
/bp:merge # merge all blueprint/* branches into main
|
||||
```
|
||||
|
||||
After parallel execution, each site lives on its own `blueprint/<name>` branch. `/blueprint:merge` integrates them back into main:
|
||||
After parallel execution, each site lives on its own `blueprint/<name>` branch. `/bp:merge` integrates them back into main:
|
||||
|
||||
1. Surveys all branches — commits, file overlaps, dependency order
|
||||
2. Reads the **blueprints and impl tracking** for each branch
|
||||
@@ -139,15 +139,15 @@ context/
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| **`/blueprint:draft`** | Draft blueprints |
|
||||
| **`/blueprint:architect`** | Generate build site |
|
||||
| **`/blueprint:build`** | Ralph Loop implementation |
|
||||
| **`/blueprint:inspect`** | Gap analysis + peer review |
|
||||
| **`/blueprint:merge`** | Blueprint-aware branch integration |
|
||||
| `/blueprint:progress` | Check site progress |
|
||||
| `/blueprint:gap-analysis` | Compare built vs intended |
|
||||
| `/blueprint:revise` | Trace manual fixes to blueprints |
|
||||
| `/blueprint:help` | Show usage |
|
||||
| **`/bp:draft`** | Draft blueprints |
|
||||
| **`/bp:architect`** | Generate build site |
|
||||
| **`/bp:build`** | Ralph Loop implementation |
|
||||
| **`/bp:inspect`** | Gap analysis + peer review |
|
||||
| **`/bp:merge`** | Blueprint-aware branch integration |
|
||||
| `/bp:progress` | Check site progress |
|
||||
| `/bp:gap-analysis` | Compare built vs intended |
|
||||
| `/bp:revise` | Trace manual fixes to blueprints |
|
||||
| `/bp:help` | Show usage |
|
||||
|
||||
| CLI | Description |
|
||||
|-----|-------------|
|
||||
@@ -155,7 +155,7 @@ context/
|
||||
| `blueprint --monitor --expanded` | One window per agent with dashboards |
|
||||
| `blueprint --status` | Check site progress |
|
||||
| `blueprint --analytics` | Trends across cycles |
|
||||
| `blueprint --merge` | Shows branches ready to merge (use `/blueprint:merge` in Claude) |
|
||||
| `blueprint --merge` | Shows branches ready to merge (use `/bp:merge` in Claude) |
|
||||
| `blueprint --kill` | Stop all agents, clean worktrees |
|
||||
|
||||
## Example
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: architect
|
||||
description: Generates framework-specific implementation plans from blueprints. Use when running /blueprint:architect-from-blueprints command.
|
||||
description: Generates framework-specific implementation plans from blueprints. Use when running /bp:architect-from-blueprints command.
|
||||
model: opus
|
||||
tools: [Read, Write, Edit, Grep, Glob, Bash, WebSearch, WebFetch]
|
||||
---
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: builder
|
||||
description: Implements the highest-priority unblocked work from plans. Use when running /blueprint:build command.
|
||||
description: Implements the highest-priority unblocked work from plans. Use when running /bp:build command.
|
||||
model: opus
|
||||
tools: [All tools]
|
||||
---
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: drafter
|
||||
description: Generates implementation-agnostic blueprints from reference materials or existing code. Use when running /blueprint:draft-from-code or /blueprint:draft-from-refs commands.
|
||||
description: Generates implementation-agnostic blueprints from reference materials or existing code. Use when running /bp:draft-from-code or /bp:draft-from-refs commands.
|
||||
model: opus
|
||||
tools: [Read, Write, Edit, Grep, Glob, Bash]
|
||||
---
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: blueprint-architect
|
||||
name: bp-architect
|
||||
description: "Generate a build site from blueprints — the task dependency graph that drives building"
|
||||
argument-hint: "[--filter PATTERN]"
|
||||
---
|
||||
@@ -13,7 +13,7 @@ No domain plans. No file ownership. No time budgets. Just: tasks, what blueprint
|
||||
## Step 1: Validate Blueprints Exist
|
||||
|
||||
Check `context/blueprints/` for blueprint files. If none found, tell the user:
|
||||
> No blueprints found. Run `/blueprint:draft` first.
|
||||
> No blueprints found. Run `/bp:draft` first.
|
||||
|
||||
If `--filter` is set, only include blueprints matching the filter pattern.
|
||||
|
||||
@@ -109,8 +109,8 @@ If a site already exists, ask the user whether to overwrite or keep the existing
|
||||
### Tier 0 Tasks: {count} (can start immediately)
|
||||
|
||||
### Next Step
|
||||
Run `/blueprint:build` to start the implementation loop.
|
||||
Run `/blueprint:build --peer review` to add Codex review.
|
||||
Run `/bp:build` to start the implementation loop.
|
||||
Run `/bp:build --peer review` to add Codex review.
|
||||
```
|
||||
|
||||
### Rules
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: blueprint-build
|
||||
name: bp-build
|
||||
description: "Start a Ralph Loop that implements the build site — builds, validates, commits, repeats"
|
||||
argument-hint: "[--filter PATTERN] [--peer-review] [--max-iterations N] [--completion-promise TEXT]"
|
||||
allowed-tools: ["Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-build.sh:*)", "Bash(cd *)"]
|
||||
|
||||
+2
-2
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: blueprint-draft
|
||||
name: bp-draft
|
||||
description: "Write blueprints: decompose what you're building into domains with testable requirements"
|
||||
argument-hint: "[REFS_PATH | --from-code] [--filter PATTERN]"
|
||||
---
|
||||
@@ -158,7 +158,7 @@ last_edited: "{CURRENT_DATE_UTC}"
|
||||
- {anything that couldn't be fully specified}
|
||||
|
||||
### Next Step
|
||||
Run `/blueprint:architect` to generate the build site.
|
||||
Run `/bp:architect` to generate the build site.
|
||||
```
|
||||
|
||||
Present the report to the user.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: blueprint-gap-analysis
|
||||
name: bp-gap-analysis
|
||||
description: Compare what was built against what was intended
|
||||
---
|
||||
|
||||
@@ -102,7 +102,7 @@ For each gap (PARTIAL, MISSING, OVER-BUILT, UNTESTABLE), determine the root caus
|
||||
| P1 | plan-{domain}.md | {what to update} | R{n} |
|
||||
|
||||
### Recommended Next Steps
|
||||
1. Run `/blueprint:revise` to trace gaps into context files
|
||||
1. Run `/bp:revise` to trace gaps into context files
|
||||
2. {Specific blueprint updates needed}
|
||||
3. {Specific plan updates needed}
|
||||
4. {Implementation work remaining}
|
||||
|
||||
+48
-48
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: blueprint-help
|
||||
name: bp-help
|
||||
description: Show Blueprint commands and usage
|
||||
---
|
||||
|
||||
@@ -8,53 +8,53 @@ description: Show Blueprint commands and usage
|
||||
## The Workflow
|
||||
|
||||
```
|
||||
/blueprint:draft → write blueprints (the WHAT)
|
||||
/blueprint:architect → generate site (the ORDER)
|
||||
/blueprint:build → ralph loop (the BUILD)
|
||||
/blueprint:inspect → gap analysis + peer review (the CHECK)
|
||||
/bp:draft → write blueprints (the WHAT)
|
||||
/bp:architect → generate site (the ORDER)
|
||||
/bp:build → ralph loop (the BUILD)
|
||||
/bp:inspect → gap analysis + peer review (the CHECK)
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
### `/blueprint:draft` — Write Blueprints
|
||||
### `/bp:draft` — Write Blueprints
|
||||
|
||||
```bash
|
||||
/blueprint:draft # interactive — asks what to build
|
||||
/blueprint:draft context/refs/ # from reference materials (PRDs, docs)
|
||||
/blueprint:draft --from-code # from existing codebase (brownfield)
|
||||
/blueprint:draft --filter v2 # only generate v2 blueprints
|
||||
/bp:draft # interactive — asks what to build
|
||||
/bp:draft context/refs/ # from reference materials (PRDs, docs)
|
||||
/bp:draft --from-code # from existing codebase (brownfield)
|
||||
/bp:draft --filter v2 # only generate v2 blueprints
|
||||
```
|
||||
|
||||
Decomposes your project into domains, writes `context/blueprints/blueprint-{domain}.md` files with R-numbered requirements and testable acceptance criteria.
|
||||
|
||||
### `/blueprint:architect` — Generate Site
|
||||
### `/bp:architect` — Generate Site
|
||||
|
||||
```bash
|
||||
/blueprint:architect # generates site from all blueprints
|
||||
/blueprint:architect --filter v2 # only v2 blueprints
|
||||
/bp:architect # generates site from all blueprints
|
||||
/bp:architect --filter v2 # only v2 blueprints
|
||||
```
|
||||
|
||||
Reads blueprints, decomposes requirements into tasks, organizes into dependency tiers. Writes `context/frontiers/build-site.md`. No domain plans — just tasks and dependencies.
|
||||
|
||||
### `/blueprint:build` — Run the Loop
|
||||
### `/bp:build` — Run the Loop
|
||||
|
||||
```bash
|
||||
/blueprint:build # ralph loop from site
|
||||
/blueprint:build --filter v2 # scope to v2
|
||||
/blueprint:build --peer-review # add Codex (GPT-5.4) review
|
||||
/blueprint:build --max-iterations 30 # iteration limit
|
||||
/blueprint:build --peer-review --codex-model gpt-5.4-mini
|
||||
/bp:build # ralph loop from site
|
||||
/bp:build --filter v2 # scope to v2
|
||||
/bp:build --peer-review # add Codex (GPT-5.4) review
|
||||
/bp:build --max-iterations 30 # iteration limit
|
||||
/bp:build --peer-review --codex-model gpt-5.4-mini
|
||||
```
|
||||
|
||||
Auto-archives any previous cycle, then starts a Ralph Loop. Each iteration: pick unblocked task → read blueprint → implement → validate → commit.
|
||||
|
||||
With `--peer-review`: alternates build and review iterations, calling Codex via MCP.
|
||||
|
||||
### `/blueprint:inspect` — Post-Loop Inspection
|
||||
### `/bp:inspect` — Post-Loop Inspection
|
||||
|
||||
```bash
|
||||
/blueprint:inspect # inspect everything from last loop
|
||||
/blueprint:inspect --filter v2 # only v2
|
||||
/bp:inspect # inspect everything from last loop
|
||||
/bp:inspect --filter v2 # only v2
|
||||
```
|
||||
|
||||
Runs after build completes. Does two things:
|
||||
@@ -63,11 +63,11 @@ Runs after build completes. Does two things:
|
||||
|
||||
Produces a verdict: APPROVE / REVISE / REJECT with prioritized findings.
|
||||
|
||||
### `/blueprint:progress` — Check Progress
|
||||
### `/bp:progress` — Check Progress
|
||||
|
||||
```bash
|
||||
/blueprint:progress # show site progress
|
||||
/blueprint:progress --filter v2
|
||||
/bp:progress # show site progress
|
||||
/bp:progress --filter v2
|
||||
```
|
||||
|
||||
Shows tasks done/ready/blocked, progress bar, current tier, and next tasks.
|
||||
@@ -76,11 +76,11 @@ Shows tasks done/ready/blocked, progress bar, current tier, and next tasks.
|
||||
|
||||
| Command | When |
|
||||
|---------|------|
|
||||
| `/blueprint:gap-analysis` | After a loop — compare built vs intended |
|
||||
| `/blueprint:revise` | After manual code fixes — trace back to blueprints |
|
||||
| `/blueprint:compact-specs` | When impl tracking files exceed ~500 lines |
|
||||
| `/blueprint:archive-loop` | Manually archive a loop cycle (build does this automatically) |
|
||||
| `/blueprint:next-session` | Generate a handoff document for next session |
|
||||
| `/bp:gap-analysis` | After a loop — compare built vs intended |
|
||||
| `/bp:revise` | After manual code fixes — trace back to blueprints |
|
||||
| `/bp:compact-specs` | When impl tracking files exceed ~500 lines |
|
||||
| `/bp:archive-loop` | Manually archive a loop cycle (build does this automatically) |
|
||||
| `/bp:next-session` | Generate a handoff document for next session |
|
||||
|
||||
### Legacy (advanced)
|
||||
|
||||
@@ -88,29 +88,29 @@ These still work but are superseded by the three main commands:
|
||||
|
||||
| Command | Replaced by |
|
||||
|---------|-------------|
|
||||
| `/blueprint init` | `/blueprint:draft` creates directories automatically |
|
||||
| `/blueprint spec-from-refs` | `/blueprint:draft context/refs/` |
|
||||
| `/blueprint spec-from-code` | `/blueprint:draft --from-code` |
|
||||
| `/blueprint plan-from-specs` | `/blueprint:architect` (generates site directly, no domain plans) |
|
||||
| `/blueprint implement` | `/blueprint:build` (one task at a time vs full loop) |
|
||||
| `/blueprint spec-loop` | `/blueprint:build` |
|
||||
| `/blueprint peer-review-loop` | `/blueprint:build --peer-review` |
|
||||
| `/blueprint quick` | `/blueprint:draft` + `/blueprint:architect` + `/blueprint:build` |
|
||||
| `/blueprint init` | `/bp:draft` creates directories automatically |
|
||||
| `/blueprint spec-from-refs` | `/bp:draft context/refs/` |
|
||||
| `/blueprint spec-from-code` | `/bp:draft --from-code` |
|
||||
| `/blueprint plan-from-specs` | `/bp:architect` (generates site directly, no domain plans) |
|
||||
| `/blueprint implement` | `/bp:build` (one task at a time vs full loop) |
|
||||
| `/blueprint spec-loop` | `/bp:build` |
|
||||
| `/blueprint peer-review-loop` | `/bp:build --peer-review` |
|
||||
| `/blueprint quick` | `/bp:draft` + `/bp:architect` + `/bp:build` |
|
||||
|
||||
## Skills (reference docs)
|
||||
|
||||
| Skill | Topic |
|
||||
|-------|-------|
|
||||
| `blueprint:methodology` | Core DABI lifecycle |
|
||||
| `blueprint:blueprint-writing` | How to write blueprints with testable criteria |
|
||||
| `blueprint:peer-review` | Cross-model review patterns |
|
||||
| `blueprint:peer-review-loop` | Ralph Loop + Codex architecture |
|
||||
| `blueprint:validation-first` | Every requirement must be auto-testable |
|
||||
| `blueprint:convergence-monitoring` | Detecting if loop is converging or stuck |
|
||||
| `blueprint:revision` | Tracing bugs back to blueprints |
|
||||
| `blueprint:context-architecture` | Organizing context/ for AI agents |
|
||||
| `blueprint:impl-tracking` | Progress tracking and dead ends |
|
||||
| `bp:methodology` | Core DABI lifecycle |
|
||||
| `bp:blueprint-writing` | How to write blueprints with testable criteria |
|
||||
| `bp:peer-review` | Cross-model review patterns |
|
||||
| `bp:peer-review-loop` | Ralph Loop + Codex architecture |
|
||||
| `bp:validation-first` | Every requirement must be auto-testable |
|
||||
| `bp:convergence-monitoring` | Detecting if loop is converging or stuck |
|
||||
| `bp:revision` | Tracing bugs back to blueprints |
|
||||
| `bp:context-architecture` | Organizing context/ for AI agents |
|
||||
| `bp:impl-tracking` | Progress tracking and dead ends |
|
||||
| `blueprint:brownfield-adoption` | Adopting Blueprint on existing codebases |
|
||||
| `blueprint:prompt-pipeline` | Designing prompt sequences |
|
||||
| `bp:prompt-pipeline` | Designing prompt sequences |
|
||||
| `blueprint:speculative-pipeline` | Staggered pipeline execution |
|
||||
| `blueprint:documentation-inversion` | Agent-first documentation |
|
||||
|
||||
+7
-7
@@ -1,12 +1,12 @@
|
||||
---
|
||||
name: blueprint-inspect
|
||||
name: bp-inspect
|
||||
description: "Inspect the last loop: gap analysis against blueprints + peer review code review for bugs, security, and quality"
|
||||
argument-hint: "[--filter PATTERN]"
|
||||
---
|
||||
|
||||
# Blueprint Inspect — Post-Loop Analysis
|
||||
|
||||
Run this after `/blueprint:build` completes (or is stopped). It does two things:
|
||||
Run this after `/bp:build` completes (or is stopped). It does two things:
|
||||
|
||||
1. **Gap analysis** — compares what was built against what the blueprints require
|
||||
2. **Peer review** — finds bugs, security issues, and quality problems in the code that was written
|
||||
@@ -23,7 +23,7 @@ Read these files to understand what happened:
|
||||
6. **Git diff** — run `git diff main...HEAD` (or appropriate base branch) to see all code changes
|
||||
|
||||
If no impl tracking or loop log exists, tell the user:
|
||||
> No loop artifacts found. Run `/blueprint:build` first, then `/blueprint:inspect` after it completes.
|
||||
> No loop artifacts found. Run `/bp:build` first, then `/bp:inspect` after it completes.
|
||||
|
||||
## Step 2: Gap Analysis
|
||||
|
||||
@@ -155,8 +155,8 @@ Present this to the user:
|
||||
## Recommended Next Steps
|
||||
1. {highest priority action}
|
||||
2. {next action}
|
||||
3. {if gaps exist: run `/blueprint:build` again to address remaining work}
|
||||
4. {if blueprint gaps found: blueprints will be updated below, then `/blueprint:architect` + `/blueprint:build`}
|
||||
3. {if gaps exist: run `/bp:build` again to address remaining work}
|
||||
4. {if blueprint gaps found: blueprints will be updated below, then `/bp:architect` + `/bp:build`}
|
||||
```
|
||||
|
||||
## Step 5: Revise
|
||||
@@ -215,7 +215,7 @@ last_edited: "{CURRENT_DATE_UTC}"
|
||||
| F-002: {title} | P1 | {path} | NEW |
|
||||
```
|
||||
|
||||
These findings will be picked up by the next `/blueprint:build` loop — the build prompt reads impl tracking and prioritizes P0 issues first.
|
||||
These findings will be picked up by the next `/bp:build` loop — the build prompt reads impl tracking and prioritizes P0 issues first.
|
||||
|
||||
### Report What Changed
|
||||
|
||||
@@ -237,5 +237,5 @@ After revision, tell the user:
|
||||
### Findings Logged
|
||||
{n} findings written to context/impl/impl-review-findings.md
|
||||
|
||||
Ready for next cycle: `/blueprint:build`
|
||||
Ready for next cycle: `/bp:build`
|
||||
```
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: blueprint-merge
|
||||
name: bp-merge
|
||||
description: "Merge completed Blueprint branches into main — resolves conflicts intelligently using blueprints and implementation context"
|
||||
allowed-tools: ["Bash", "Read", "Write", "Edit", "Glob", "Grep"]
|
||||
---
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: blueprint-progress
|
||||
name: bp-progress
|
||||
description: "Show progress against the build site — tasks done, in progress, blocked, remaining"
|
||||
argument-hint: "[--filter PATTERN]"
|
||||
---
|
||||
@@ -12,7 +12,7 @@ Show the user a progress report by comparing the build site against implementati
|
||||
|
||||
Look in `context/frontiers/` then `context/plans/` for `*site*` or `*frontier*` files. If `--filter` is set (parse from `$ARGUMENTS`), match against it.
|
||||
|
||||
If no site found: "No site found. Run `/blueprint:architect` first."
|
||||
If no site found: "No site found. Run `/bp:architect` first."
|
||||
|
||||
## Step 2: Read State
|
||||
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: blueprint-revise
|
||||
name: bp-revise
|
||||
description: Trace recent manual code fixes back into blueprints and context files
|
||||
---
|
||||
|
||||
|
||||
+13
-13
@@ -3,7 +3,7 @@
|
||||
## Greenfield: Task management API
|
||||
|
||||
```
|
||||
user: /blueprint:draft
|
||||
user: /bp:draft
|
||||
|
||||
claude: What are you building?
|
||||
|
||||
@@ -19,9 +19,9 @@ claude: Decomposing into domains...
|
||||
- blueprint-notifications.md (3 requirements, 8 acceptance criteria)
|
||||
|
||||
Dependency order: users → projects → tasks → notifications
|
||||
Next: /blueprint:architect
|
||||
Next: /bp:architect
|
||||
|
||||
user: /blueprint:architect
|
||||
user: /bp:architect
|
||||
|
||||
claude: Reading 4 blueprints, 22 requirements...
|
||||
|
||||
@@ -32,9 +32,9 @@ claude: Reading 4 blueprints, 22 requirements...
|
||||
- Tier 3: Task CRUD, assignments (10 tasks)
|
||||
- Tier 4: Notifications (8 tasks)
|
||||
|
||||
Next: /blueprint:build
|
||||
Next: /bp:build
|
||||
|
||||
user: /blueprint:build
|
||||
user: /bp:build
|
||||
|
||||
claude: Loop activated! 34 tasks, 20 max iterations.
|
||||
|
||||
@@ -57,7 +57,7 @@ claude: Loop activated! 34 tasks, 20 max iterations.
|
||||
## Brownfield: Adding collaboration to existing Next.js app
|
||||
|
||||
```
|
||||
user: /blueprint:draft --from-code
|
||||
user: /bp:draft --from-code
|
||||
|
||||
claude: Exploring codebase... Next.js 14, Prisma, NextAuth.
|
||||
|
||||
@@ -72,7 +72,7 @@ claude: Exploring codebase... Next.js 14, Prisma, NextAuth.
|
||||
4 requirements are gaps (not yet implemented).
|
||||
|
||||
user: I only want the collaboration features.
|
||||
/blueprint:architect --filter collaboration
|
||||
/bp:architect --filter collaboration
|
||||
|
||||
claude: Reading blueprint-collaboration.md (3 requirements)...
|
||||
|
||||
@@ -81,7 +81,7 @@ claude: Reading blueprint-collaboration.md (3 requirements)...
|
||||
- Tier 1: Cursor presence, CRDT integration
|
||||
- Tier 2: Conflict resolution, live sync
|
||||
|
||||
user: /blueprint:build --filter collaboration
|
||||
user: /bp:build --filter collaboration
|
||||
|
||||
claude: Loop activated! 8 tasks.
|
||||
|
||||
@@ -93,8 +93,8 @@ claude: Loop activated! 8 tasks.
|
||||
All done. <promise>BLUEPRINT COMPLETE</promise>
|
||||
|
||||
user: Now notifications with peer review.
|
||||
/blueprint:architect --filter notifications
|
||||
/blueprint:build --filter notifications --peer-review
|
||||
/bp:architect --filter notifications
|
||||
/bp:build --filter notifications --peer-review
|
||||
|
||||
claude: Archived previous cycle → context/impl/archive/20260314-201500/
|
||||
Configured Codex (gpt-5.4) as peer reviewer.
|
||||
@@ -116,7 +116,7 @@ claude: Archived previous cycle → context/impl/archive/20260314-201500/
|
||||
## The flow
|
||||
|
||||
```
|
||||
/blueprint:draft → blueprints
|
||||
/blueprint:architect → build site
|
||||
/blueprint:build → code
|
||||
/bp:draft → blueprints
|
||||
/bp:architect → build site
|
||||
/bp:build → code
|
||||
```
|
||||
|
||||
+9
-9
@@ -32,7 +32,7 @@ printf "${B}Installer${R}\n\n"
|
||||
# ─── Preflight ──────────────────────────────────────────────────────────────
|
||||
|
||||
command -v git &>/dev/null || fail "git not found."
|
||||
command -v claude &>/dev/null || warn "claude CLI not found. Install Claude Code to use /blueprint:... commands."
|
||||
command -v claude &>/dev/null || warn "claude CLI not found. Install Claude Code to use /bp:... commands."
|
||||
command -v tmux &>/dev/null || warn "tmux not found. Install for the parallel launcher: brew install tmux"
|
||||
|
||||
# ─── Register Claude Code plugin ───────────────────────────────────────────
|
||||
@@ -53,7 +53,7 @@ if [[ ! -f "$SETTINGS_FILE" ]]; then
|
||||
}
|
||||
},
|
||||
"enabledPlugins": {
|
||||
"blueprint@${MARKETPLACE_NAME}": true
|
||||
"bp@${MARKETPLACE_NAME}": true
|
||||
}
|
||||
}
|
||||
EOF
|
||||
@@ -69,7 +69,7 @@ path, name, mpath = sys.argv[1], sys.argv[2], sys.argv[3]
|
||||
with open(path) as f:
|
||||
d = json.load(f)
|
||||
d.setdefault("extraKnownMarketplaces", {})[name] = {"source": {"source": "directory", "path": mpath}}
|
||||
d.setdefault("enabledPlugins", {})[f"blueprint@{name}"] = True
|
||||
d.setdefault("enabledPlugins", {})[f"bp@{name}"] = True
|
||||
with open(path, "w") as f:
|
||||
json.dump(d, f, indent=2)
|
||||
PYEOF
|
||||
@@ -78,7 +78,7 @@ PYEOF
|
||||
warn "Could not auto-update settings. Add manually to $SETTINGS_FILE:"
|
||||
printf "\n"
|
||||
printf ' "extraKnownMarketplaces": { "%s": { "source": { "source": "directory", "path": "%s" } } }\n' "$MARKETPLACE_NAME" "$MARKETPLACE_PATH"
|
||||
printf ' "enabledPlugins": { "blueprint@%s": true }\n\n' "$MARKETPLACE_NAME"
|
||||
printf ' "enabledPlugins": { "bp@%s": true }\n\n' "$MARKETPLACE_NAME"
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
@@ -116,10 +116,10 @@ printf " blueprint --analytics Show loop trends\n"
|
||||
printf " blueprint --kill Stop sessions and clean worktrees\n"
|
||||
printf "\n"
|
||||
printf " ${B}Claude:${R}\n"
|
||||
printf " /blueprint:draft Draft blueprints\n"
|
||||
printf " /blueprint:architect Architect build sites\n"
|
||||
printf " /blueprint:build Build from blueprints\n"
|
||||
printf " /blueprint:inspect Inspect the build\n"
|
||||
printf " /blueprint:merge Merge completed Blueprint branches\n"
|
||||
printf " /bp:draft Draft blueprints\n"
|
||||
printf " /bp:architect Architect build sites\n"
|
||||
printf " /bp:build Build from blueprints\n"
|
||||
printf " /bp:inspect Inspect the build\n"
|
||||
printf " /bp:merge Merge completed Blueprint branches\n"
|
||||
printf "\n"
|
||||
printf " Restart Claude Code to load the plugin.\n\n"
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
{
|
||||
"name": "blueprint",
|
||||
"name": "bp",
|
||||
"description": "Blueprint Framework — a methodology for building software with AI coding agents where blueprints drive the development process — code is derived from them. Includes DABI lifecycle, prompt pipelines, validation gates, backpropagation, convergence monitoring, and agent team coordination patterns.",
|
||||
"version": "2.0.0"
|
||||
}
|
||||
|
||||
@@ -46,7 +46,7 @@ for wt in "${PROJECT_ROOT}/../${PROJECT_NAME}-blueprint-"*; do
|
||||
done
|
||||
|
||||
if [[ ${#LOGS[@]} -eq 0 ]]; then
|
||||
echo "No loop logs found. Run /blueprint:build first."
|
||||
echo "No loop logs found. Run /bp:build first."
|
||||
exit 0
|
||||
fi
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
#!/bin/bash
|
||||
|
||||
# blueprint-launch-session — Creates a tmux session with one pane per build site.
|
||||
# Each pane runs Claude in its own git worktree with /blueprint:build.
|
||||
# Each pane runs Claude in its own git worktree with /bp:build.
|
||||
#
|
||||
# Usage: blueprint-launch-session.sh [--expanded] <frontier-path> [<frontier-path> ...]
|
||||
#
|
||||
@@ -215,16 +215,16 @@ else
|
||||
tmux select-pane -t "$SESSION_NAME:0.0"
|
||||
fi
|
||||
|
||||
# ─── Staggered /blueprint:build launch ──────────────────────────────────────
|
||||
# ─── Staggered /bp:build launch ──────────────────────────────────────
|
||||
|
||||
# Background process that sends /blueprint:build to NEW panes (resumed ones already have context)
|
||||
# Background process that sends /bp:build to NEW panes (resumed ones already have context)
|
||||
(
|
||||
sleep 3 # Wait for Claude instances to start
|
||||
|
||||
for i in "${!NAMES[@]}"; do
|
||||
name="${NAMES[$i]}"
|
||||
|
||||
# Resumed sessions already have their loop — skip sending /blueprint:build
|
||||
# Resumed sessions already have their loop — skip sending /bp:build
|
||||
if [[ "${RESUMING[$i]}" == "true" ]]; then
|
||||
continue
|
||||
fi
|
||||
@@ -235,7 +235,7 @@ fi
|
||||
target="$SESSION_NAME:0.${i}"
|
||||
fi
|
||||
|
||||
tmux send-keys -t "$target" "/blueprint:build --filter ${name}" Enter
|
||||
tmux send-keys -t "$target" "/bp:build --filter ${name}" Enter
|
||||
|
||||
# Stagger between launches (skip delay after last one)
|
||||
sleep "$STAGGER_DELAY"
|
||||
|
||||
@@ -181,7 +181,7 @@ async function main() {
|
||||
|
||||
if (frontiers.length === 0) {
|
||||
console.error("No frontiers found in context/frontiers/");
|
||||
console.error("Run /blueprint:architect first to generate one.");
|
||||
console.error("Run /bp:architect first to generate one.");
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
|
||||
@@ -162,7 +162,7 @@ fi
|
||||
|
||||
if [[ ${#CANDIDATES[@]} -eq 0 ]]; then
|
||||
echo "❌ No build site found in context/frontiers/" >&2
|
||||
echo " Run /blueprint:architect first to generate one." >&2
|
||||
echo " Run /bp:architect first to generate one." >&2
|
||||
# Also check context/plans/ as a hint
|
||||
if [[ -d "context/plans" ]] && find "context/plans" -name "*frontier*" -type f 2>/dev/null | grep -q .; then
|
||||
echo " (Found frontier files in context/plans/ — move them to context/frontiers/)" >&2
|
||||
|
||||
@@ -313,7 +313,7 @@ Use brainstorming during the Draft phase to explore requirements you may not hav
|
||||
3. Formalize each requirement with acceptance criteria
|
||||
4. Add to the blueprint using the template
|
||||
|
||||
### With `blueprint:validation-first`
|
||||
### With `bp:validation-first`
|
||||
|
||||
Every acceptance criterion in a blueprint must map to at least one validation gate. When writing blueprints, think about which gate will verify each requirement:
|
||||
|
||||
@@ -326,11 +326,11 @@ Every acceptance criterion in a blueprint must map to at least one validation ga
|
||||
| "Application starts and displays main screen" | Gate 5: Launch Verification |
|
||||
| "UI matches design intent" | Gate 6: Human Review |
|
||||
|
||||
### With `blueprint:context-architecture`
|
||||
### With `bp:context-architecture`
|
||||
|
||||
Blueprints live in the `context/blueprints/` directory. See `blueprint:context-architecture` for the full context directory structure, CLAUDE.md conventions, and multi-repo strategies.
|
||||
Blueprints live in the `context/blueprints/` directory. See `bp:context-architecture` for the full context directory structure, CLAUDE.md conventions, and multi-repo strategies.
|
||||
|
||||
### With `blueprint:impl-tracking`
|
||||
### With `bp:impl-tracking`
|
||||
|
||||
As blueprints are implemented, progress is tracked in `context/impl/` documents. Dead ends discovered during implementation should be recorded to prevent future agents from retrying failed approaches.
|
||||
|
||||
|
||||
@@ -462,8 +462,8 @@ Track your brownfield adoption progress with these milestones:
|
||||
|
||||
## Cross-References
|
||||
|
||||
- **Context architecture:** See `blueprint:context-architecture` skill for the full context directory structure and progressive disclosure patterns.
|
||||
- **Prompt pipeline:** See `blueprint:prompt-pipeline` skill for designing the 001-003 prompts after bootstrap.
|
||||
- **Blueprint writing:** See `blueprint:blueprint-writing` skill for how to write high-quality blueprints with testable acceptance criteria.
|
||||
- **Revision:** See `blueprint:revision` skill for tracing bugs back to blueprints after brownfield adoption.
|
||||
- **Convergence monitoring:** See `blueprint:convergence-monitoring` skill for detecting when the bootstrap prompt has converged.
|
||||
- **Context architecture:** See `bp:context-architecture` skill for the full context directory structure and progressive disclosure patterns.
|
||||
- **Prompt pipeline:** See `bp:prompt-pipeline` skill for designing the 001-003 prompts after bootstrap.
|
||||
- **Blueprint writing:** See `bp:blueprint-writing` skill for how to write high-quality blueprints with testable acceptance criteria.
|
||||
- **Revision:** See `bp:revision` skill for tracing bugs back to blueprints after brownfield adoption.
|
||||
- **Convergence monitoring:** See `bp:convergence-monitoring` skill for detecting when the bootstrap prompt has converged.
|
||||
|
||||
@@ -70,7 +70,7 @@ This pattern prevents loading the entire documentation tree into the context win
|
||||
Two techniques keep documents focused and navigable:
|
||||
|
||||
- **Decomposition** — break large documents into domain-specific files
|
||||
- **Spec compaction** — compress implementation tracking when files exceed approximately 500 lines (see `blueprint:impl-tracking`)
|
||||
- **Spec compaction** — compress implementation tracking when files exceed approximately 500 lines (see `bp:impl-tracking`)
|
||||
|
||||
Together, these ensure that the context an agent loads is dense with relevant information rather than bloated with resolved history.
|
||||
|
||||
@@ -399,19 +399,19 @@ Completed or archived content should be moved to `impl/archive/`, not left in th
|
||||
|
||||
## Integration with Other Skills
|
||||
|
||||
### With `blueprint:blueprint-writing`
|
||||
### With `bp:blueprint-writing`
|
||||
|
||||
The context architecture defines WHERE blueprints live. The blueprint-writing skill defines HOW to write them. Blueprints go in `context/blueprints/` following the naming convention `blueprint-{domain}.md`.
|
||||
|
||||
### With `blueprint:impl-tracking`
|
||||
### With `bp:impl-tracking`
|
||||
|
||||
Implementation tracking documents live in `context/impl/`. When they exceed 500 lines, compact them and archive the old version to `context/impl/archive/`.
|
||||
|
||||
### With `blueprint:validation-first`
|
||||
### With `bp:validation-first`
|
||||
|
||||
Validation gate results are recorded in implementation tracking documents within the context structure. Phase gates reference specs by requirement ID.
|
||||
|
||||
### With `blueprint:methodology`
|
||||
### With `bp:methodology`
|
||||
|
||||
The context directory structure is established during the Spec phase of DABI and maintained throughout the entire lifecycle.
|
||||
|
||||
|
||||
@@ -407,7 +407,7 @@ With backpropagation:
|
||||
## Cross-References
|
||||
|
||||
- **Convergence patterns reference:** See `references/convergence-patterns.md` for the complete convergence pattern catalog with examples.
|
||||
- **Backpropagation:** See `blueprint:revision` skill for how tracing bugs to specs improves convergence.
|
||||
- **Prompt pipeline:** See `blueprint:prompt-pipeline` skill for designing prompts with proper exit criteria and completion signals.
|
||||
- **Validation-first design:** See `blueprint:validation-first` skill for building validation gates that provide convergence signals.
|
||||
- **Impl tracking:** See `blueprint:impl-tracking` skill for tracking progress and detecting ceiling conditions.
|
||||
- **Backpropagation:** See `bp:revision` skill for how tracing bugs to specs improves convergence.
|
||||
- **Prompt pipeline:** See `bp:prompt-pipeline` skill for designing prompts with proper exit criteria and completion signals.
|
||||
- **Validation-first design:** See `bp:validation-first` skill for building validation gates that provide convergence signals.
|
||||
- **Impl tracking:** See `bp:impl-tracking` skill for tracking progress and detecting ceiling conditions.
|
||||
|
||||
@@ -353,7 +353,7 @@ For structured handoffs between sessions (especially when different humans or au
|
||||
|
||||
- **Between human-managed sessions:** When a human starts each session and needs to know what happened
|
||||
- **Automation handoffs:** When an orchestration system decides what to work on next
|
||||
- **Work queue generation:** The `/blueprint:next-session` command consumes this feedback to generate prioritized work items
|
||||
- **Work queue generation:** The `/bp:next-session` command consumes this feedback to generate prioritized work items
|
||||
|
||||
> For the full session feedback protocol reference, see `references/session-feedback-protocol.md`.
|
||||
|
||||
@@ -407,19 +407,19 @@ This removes the orientation cost at the start of each session — agents begin
|
||||
|
||||
## Integration with Other Skills
|
||||
|
||||
### With `blueprint:blueprint-writing`
|
||||
### With `bp:blueprint-writing`
|
||||
|
||||
Implementation tracking references specs by requirement ID. When a task is completed, its acceptance criteria map back to spec requirements. When dead ends are found, they may reveal spec gaps that need backpropagation.
|
||||
|
||||
### With `blueprint:validation-first`
|
||||
### With `bp:validation-first`
|
||||
|
||||
Test health in the tracking document reflects validation gate results. Failing tests indicate which gates are not passing. The tracking document records which gates each task must clear.
|
||||
|
||||
### With `blueprint:context-architecture`
|
||||
### With `bp:context-architecture`
|
||||
|
||||
Implementation tracking documents live in `context/impl/`. When files grow too large, archive to `context/impl/archive/`. The CLAUDE.md in `context/impl/` instructs agents on tracking conventions.
|
||||
|
||||
### With `blueprint:methodology`
|
||||
### With `bp:methodology`
|
||||
|
||||
Implementation tracking is used primarily during the Implement and Iterate phases of DABI. The iteration loop reads and updates tracking documents every pass. The Monitor phase reviews tracking documents for progress signals.
|
||||
|
||||
|
||||
+13
-13
@@ -185,26 +185,26 @@ Blueprint is composed of techniques that work together. This methodology skill i
|
||||
|
||||
| Skill | Purpose | When to Use |
|
||||
|-------|---------|-------------|
|
||||
| `blueprint:blueprint-writing` | Write implementation-agnostic blueprints with testable acceptance criteria | Draft phase — always the first step |
|
||||
| `blueprint:context-architecture` | Organize context for progressive disclosure | Project setup and ongoing maintenance |
|
||||
| `blueprint:impl-tracking` | Track implementation progress, dead ends, test health | Build and Inspect phases |
|
||||
| `blueprint:validation-first` | Design validation gates agents can execute | All phases — validation is continuous |
|
||||
| `bp:blueprint-writing` | Write implementation-agnostic blueprints with testable acceptance criteria | Draft phase — always the first step |
|
||||
| `bp:context-architecture` | Organize context for progressive disclosure | Project setup and ongoing maintenance |
|
||||
| `bp:impl-tracking` | Track implementation progress, dead ends, test health | Build and Inspect phases |
|
||||
| `bp:validation-first` | Design validation gates agents can execute | All phases — validation is continuous |
|
||||
|
||||
### Pipeline Skills
|
||||
|
||||
| Skill | Purpose | When to Use |
|
||||
|-------|---------|-------------|
|
||||
| `blueprint:prompt-pipeline` | Design numbered prompt pipelines for DABI | Setting up automation |
|
||||
| `blueprint:revision` | Trace bugs back to blueprints and fix at the source | Inspect phase — after finding gaps |
|
||||
| `bp:prompt-pipeline` | Design numbered prompt pipelines for DABI | Setting up automation |
|
||||
| `bp:revision` | Trace bugs back to blueprints and fix at the source | Inspect phase — after finding gaps |
|
||||
| `blueprint:brownfield-adoption` | Adopt Blueprint on existing codebases | Starting Blueprint on legacy projects |
|
||||
|
||||
### Advanced Skills
|
||||
|
||||
| Skill | Purpose | When to Use |
|
||||
|-------|---------|-------------|
|
||||
| `blueprint:peer-review` | Use a second agent to challenge the first | Quality gates, architecture review |
|
||||
| `bp:peer-review` | Use a second agent to challenge the first | Quality gates, architecture review |
|
||||
| `blueprint:speculative-pipeline` | Stagger pipeline stages for parallelism | Optimizing long pipelines |
|
||||
| `blueprint:convergence-monitoring` | Detect convergence vs ceiling | Monitoring iteration loops |
|
||||
| `bp:convergence-monitoring` | Detect convergence vs ceiling | Monitoring iteration loops |
|
||||
| `blueprint:documentation-inversion` | Turn documentation into agent-consumable skills | Library/module documentation |
|
||||
|
||||
### Integration with Existing Skills
|
||||
@@ -236,11 +236,11 @@ Blueprint works **with** existing skills, not as a replacement:
|
||||
└── prompts/ # DABI pipeline prompts
|
||||
```
|
||||
|
||||
2. **Write blueprints** from your reference materials (see `blueprint:blueprint-writing`)
|
||||
3. **Generate plans** from blueprints (see `blueprint:prompt-pipeline`)
|
||||
4. **Implement** with validation gates (see `blueprint:validation-first`)
|
||||
5. **Track progress** in implementation documents (see `blueprint:impl-tracking`)
|
||||
6. **Iterate** — when gaps are found, revise blueprints (see `blueprint:revision`)
|
||||
2. **Write blueprints** from your reference materials (see `bp:blueprint-writing`)
|
||||
3. **Generate plans** from blueprints (see `bp:prompt-pipeline`)
|
||||
4. **Implement** with validation gates (see `bp:validation-first`)
|
||||
5. **Track progress** in implementation documents (see `bp:impl-tracking`)
|
||||
6. **Iterate** — when gaps are found, revise blueprints (see `bp:revision`)
|
||||
|
||||
### For an Existing Project (Brownfield)
|
||||
|
||||
|
||||
@@ -57,16 +57,16 @@ your implementation.
|
||||
|
||||
```bash
|
||||
# Basic: implement a blueprint with peer review
|
||||
/blueprint:peer-review-loop context/blueprints/blueprint-auth.md
|
||||
/bp:peer-review-loop context/blueprints/blueprint-auth.md
|
||||
|
||||
# With options
|
||||
/blueprint:peer-review-loop context/blueprints/blueprint-api.md --max-iterations 20 --codex-model gpt-5.4-mini
|
||||
/bp:peer-review-loop context/blueprints/blueprint-api.md --max-iterations 20 --codex-model gpt-5.4-mini
|
||||
|
||||
# Review-only mode (review existing code, don't build new)
|
||||
/blueprint:peer-review-loop context/blueprints/blueprint-api.md --review-only
|
||||
/bp:peer-review-loop context/blueprints/blueprint-api.md --review-only
|
||||
|
||||
# Review every iteration instead of every 2nd
|
||||
/blueprint:peer-review-loop context/blueprints/blueprint-auth.md --review-interval 1
|
||||
/bp:peer-review-loop context/blueprints/blueprint-auth.md --review-interval 1
|
||||
```
|
||||
|
||||
---
|
||||
@@ -108,8 +108,8 @@ code diff, Codex returns findings.
|
||||
Use `--codex-model` to specify which OpenAI model Codex should use:
|
||||
|
||||
```bash
|
||||
/blueprint:peer-review-loop blueprint.md --codex-model gpt-5.4-mini # faster, cheaper
|
||||
/blueprint:peer-review-loop blueprint.md --codex-model gpt-5.4 # default, most capable
|
||||
/bp:peer-review-loop blueprint.md --codex-model gpt-5.4-mini # faster, cheaper
|
||||
/bp:peer-review-loop blueprint.md --codex-model gpt-5.4 # default, most capable
|
||||
```
|
||||
|
||||
---
|
||||
@@ -202,7 +202,7 @@ The peer review loop has converged when:
|
||||
If the loop hits max iterations without converging:
|
||||
- Check `context/peer-review-findings.md` for persistent issues
|
||||
- Consider whether the blueprint needs clarification
|
||||
- Run `/blueprint:revise` to trace issues back to blueprints
|
||||
- Run `/bp:revise` to trace issues back to blueprints
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -446,6 +446,6 @@ The iteration loop handles: iteration counting, timeouts, nudging idle agents, d
|
||||
|
||||
- **Prompt engineering details:** See `references/prompt-engineering.md` for the complete reference on runtime inputs, spawn templates, task templates, time guards, and file ownership.
|
||||
- **Agent team patterns:** See `references/agent-team-patterns.md` for coordination patterns, batching, worktree isolation, and merge protocol.
|
||||
- **Convergence monitoring:** See `blueprint:convergence-monitoring` skill for detecting when the iteration loop should stop.
|
||||
- **Backpropagation:** See `blueprint:revision` skill for how prompt 006 traces bugs back to specs.
|
||||
- **Context architecture:** See `blueprint:context-architecture` skill for the directory structure that prompts read from and write to.
|
||||
- **Convergence monitoring:** See `bp:convergence-monitoring` skill for detecting when the iteration loop should stop.
|
||||
- **Backpropagation:** See `bp:revision` skill for how prompt 006 traces bugs back to specs.
|
||||
- **Context architecture:** See `bp:context-architecture` skill for the directory structure that prompts read from and write to.
|
||||
|
||||
@@ -326,16 +326,16 @@ Every revision cycle tightens the blueprints, so the iteration loop settles into
|
||||
|
||||
## 7. Integration with Other Blueprint Skills
|
||||
|
||||
- **Convergence monitoring:** Use `blueprint:convergence-monitoring` to detect when manual fixes are decreasing (good) or increasing (revision debt).
|
||||
- **Prompt pipeline:** Revision may trigger changes to prompts (Step 6), which affects the `blueprint:prompt-pipeline` design.
|
||||
- **Convergence monitoring:** Use `bp:convergence-monitoring` to detect when manual fixes are decreasing (good) or increasing (revision debt).
|
||||
- **Prompt pipeline:** Revision may trigger changes to prompts (Step 6), which affects the `bp:prompt-pipeline` design.
|
||||
- **Validation-first design:** Stronger validation gates catch issues earlier, reducing the need for revision.
|
||||
- **Gap analysis:** Systematic gap analysis (`/blueprint:gap-analysis`) identifies revision targets proactively, rather than waiting for bugs.
|
||||
- **Gap analysis:** Systematic gap analysis (`/bp:gap-analysis`) identifies revision targets proactively, rather than waiting for bugs.
|
||||
|
||||
---
|
||||
|
||||
## Cross-References
|
||||
|
||||
- **Convergence patterns:** See `references/convergence-patterns.md` for how revision drives convergence.
|
||||
- **Prompt pipeline:** See `blueprint:prompt-pipeline` skill for how prompt 006 (rewrite pattern) implements automated revision.
|
||||
- **Impl tracking:** See `blueprint:impl-tracking` skill for the revision log format in implementation tracking documents.
|
||||
- **Validation gates:** See `blueprint:validation-first` skill for validation layers that catch issues before they require revision.
|
||||
- **Prompt pipeline:** See `bp:prompt-pipeline` skill for how prompt 006 (rewrite pattern) implements automated revision.
|
||||
- **Impl tracking:** See `bp:impl-tracking` skill for the revision log format in implementation tracking documents.
|
||||
- **Validation gates:** See `bp:validation-first` skill for validation layers that catch issues before they require revision.
|
||||
|
||||
@@ -218,7 +218,7 @@ curl -f http://localhost:{PORT}/health
|
||||
|
||||
## Mapping Spec Requirements to Gates
|
||||
|
||||
Every spec requirement must map to at least one validation gate. When writing specs (see `blueprint:blueprint-writing`), each acceptance criterion should indicate which gate verifies it.
|
||||
Every spec requirement must map to at least one validation gate. When writing specs (see `bp:blueprint-writing`), each acceptance criterion should indicate which gate verifies it.
|
||||
|
||||
### Mapping Pattern
|
||||
|
||||
@@ -423,17 +423,17 @@ The existing `verification-before-completion` skill provides a general framework
|
||||
|
||||
**How they work together:**
|
||||
- `superpowers:verification-before-completion` ensures the agent checks its work
|
||||
- `blueprint:validation-first` defines exactly what checks to run and in what order
|
||||
- `bp:validation-first` defines exactly what checks to run and in what order
|
||||
|
||||
### With `blueprint:blueprint-writing`
|
||||
### With `bp:blueprint-writing`
|
||||
|
||||
Every spec requirement must have acceptance criteria that map to validation gates. The spec-writing skill defines how to write those criteria. Validation-first design defines how to verify them.
|
||||
|
||||
### With `blueprint:impl-tracking`
|
||||
### With `bp:impl-tracking`
|
||||
|
||||
Validation results are recorded in the implementation tracking document's Test Health table. Gate failures become Issues. Gate-related dead ends are documented in the Dead Ends section.
|
||||
|
||||
### With `blueprint:methodology`
|
||||
### With `bp:methodology`
|
||||
|
||||
Validation gates operate continuously across all DABI phases. Phase gates control transitions between phases. The iteration loop uses gate results as convergence signals.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user