@tyroneross/build-loop 0.35.0 → 0.36.1

package/commands/rally-point.md

@@ -1,301 +0,0 @@
----
-description: "Inspect or invoke build-loop's multi-session coordination (Rally Point + per-run coord file). Subcommands: status (default), watch, heartbeat, ack-inbox, announce, init, lead, escalate, boundary, docs, help."
-allowed-tools: Bash, Read
-argument-hint: "[status|watch|heartbeat|announce|init|lead|escalate|boundary|docs|help] [args]"
-model: inherit
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-Parse `{{ARGUMENTS}}` as `<subcommand> [args...]`. **If `<subcommand>` is omitted or empty, default to `status`** (the no-args case — most common interactive use).
-
-## Subcommands
-
-### `status` (default — no-args runs this)
-
-Cheap (~100-token) sensor poll. Reports active peer sessions, unresolved verifier verdicts, dirty files, task-heartbeat health, and the active coord file path. Run this BEFORE any step-boundary decision (next-step recommendation, subagent dispatch, commit, version bump, archive/delete).
-
-Executes:
-
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/coordination_status.py \
-  --workdir "$PWD" \
-  --session-id "user-rally-$(date +%s)" \
-  --json
-```
-
-(If the user passed `--coordination-file=<path>`, `--task-ref=<id>`, or
-`--task-heartbeat-grace-seconds=<seconds>` in subcommand args, forward it.)
-
-Example output (clear):
-
-```json
-{
-  "status": "clear",
-  "active_peers": [],
-  "unresolved": [],
-  "coordination_file": null
-}
-```
-
-Example output (warn — peer overlap on owned files):
-
-```json
-{
-  "status": "warn",
-  "active_peers": [{"session_id": "codex-...", "tool": "codex", "phase": "review"}],
-  "overlaps": [{"peer": "codex-...", "files": ["scripts/foo.py"], "severity": "warning"}],
-  "required_action": "review_peer_overlap_or_dirty_files"
-}
-```
-
-### `watch`
-
-Continuous cheap sensor loop. Use this while waiting on another coding host,
-during active shared-file work, or whenever an inbox message is expected. The
-watcher prints only state transitions, revision changes, dirty-file risk, and
-inbox unread count. When `--task-ref` is set, it also wakes on task-heartbeat
-health changes.
-
-Executes:
-
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/coordination_watch.py \
-  --workdir "$PWD" \
-  --session-id "user-rally-$(date +%s)" \
-  --tool "claude_code" \
-  --interval 5 \
-  --jsonl \
-  --baseline-current
-```
-
-If the user passed `--tool=<name>`, `--files-in-flight=<csv>`,
-`--coordination-file=<path>`, `--task-ref=<id>`, or
-`--task-heartbeat-grace-seconds=<seconds>` in subcommand args, forward them. Claude Code uses
-`--tool claude_code`; Codex uses `--tool codex`; other hosts should choose a
-stable lowercase tool id.
-
-When the watcher emits an event with a higher `revision`,
-`direct_inbox_unread_count > 0`, or `broadcast_inbox_unread_count > 0`, run
-`status`, read the addressed inbox plus `inbox/all.jsonl`, and respond through
-the channel before continuing. Watch/status output also includes
-`inbox_latest_messages`: compact metadata and a short preview for the newest
-direct/broadcast inbox records. Treat it as a doorbell only; read the inbox
-file for full payloads before acting. After the message is handled, run
-`ack-inbox` so old direct notes do not keep appearing as unread.
-
-### `heartbeat`
-
-Write a structured task heartbeat for long-running work. This is separate from
-presence: presence answers "process can still write"; heartbeat answers "the
-agent is still on the claimed task and when the next check-in is due."
-
-Use it at the start of a long-running task, then at least every 10 minutes or
-after each meaningful phase boundary. Set `--task-ref` to the claim, issue,
-pillar, or run id that status/watch should expect.
-
-Executes:
-
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py heartbeat \
-  --workdir "$PWD" \
-  --session-id "user-rally-$(date +%s)" \
-  --tool "claude_code" \
-  --model "inherit" \
-  --run-id "<run-id>" \
-  --task-ref "<claim-or-issue-id>" \
-  --status running \
-  --progress "<short progress since last check-in>" \
-  --evidence "<csv refs: files/tests/commits/handoffs>" \
-  --json
-```
-
-Use `--status blocked --attention-reason "<why>"` or
-`--status needs_attention --attention-reason "<why>"` when a human or lead must
-act. Use `--not-on-task` only to make drift explicit.
-
-### `ack-inbox`
-
-Mark the current direct/broadcast inbox tail as seen for this tool/session.
-This writes an ack cursor under `inbox/.acks/`; it does not rewrite or delete
-the append-only inbox messages.
-
-Executes:
-
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py ack-inbox \
-  --workdir "$PWD" \
-  --session-id "user-rally-$(date +%s)" \
-  --tool "claude_code" \
-  --json
-```
-
-Run this only after reading and acting on the current inbox payloads. Pass
-`--no-broadcast` when a broadcast message should remain visible.
-
-### `announce [message]`
-
-Publish lightweight Rally Point presence + a `kind=handoff` rally record for the current app slug, without creating a durable coordination file. Use this when another host (Codex, Claude Code, CI verifier) needs to see that this agent is present before work ownership is split, or when dogfooding coordination from outside a full build-loop run.
-
-Executes:
-
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/coordination_rally.py \
-  --workdir "$PWD" \
-  --session-id "user-rally-$(date +%s)" \
-  --tool "claude_code" \
-  --model "inherit" \
-  --to "peer" \
-  --message "<message or 'Agent is present and ready to coordinate.'>" \
-  --json
-```
-
-If the user passed `--owns=<csv>` or `--does-not-own=<csv>` in subcommand args, forward those values as `--owns` / `--does-not-own`. If omitted, the rally is presence-only and owns no files.
-
-Example output:
-
-```json
-{
-  "action": "rally-point-posted",
-  "app_slug": "example-ios-app",
-  "channel_revision": 1,
-  "presence_written": true
-}
-```
-
-### `init <topic> <scope-one-liner>`
-
-Bootstrap a NEW coord file at `.build-loop/coordination/<topic>-YYYY-MM-DD.md` from `references/coordination-file-template.md`. Writes own presence, posts a `kind=handoff` record so peers see it. **Idempotent and atomic** (per v0.12.10): if the coord file already exists OR a concurrent peer creates it between our check and our write, joins (writes presence + posts `phase=joined-existing-coord`) instead of overwriting.
-
-Executes:
-
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/coordination_bootstrap.py \
-  --workdir "$PWD" \
-  --topic "<topic-slug>" \
-  --scope "<scope-one-liner>" \
-  --session-id "user-rally-$(date +%s)" \
-  --json
-```
-
-Example invocation: `/build-loop:rally-point init v0130-feature-x "Add new feature X across orchestrator + bootstrap + tests"`
-
-Example output:
-
-```json
-{
-  "coord_file": ".build-loop/coordination/v0130-feature-x-2026-05-21.md",
-  "action": "bootstrapped",
-  "channel_revision": 65,
-  "session_id": "user-rally-1779320000"
-}
-```
-
-### `lead <claim|renew|transfer|relinquish|status>`
-
-Operate the leadership lease (G1). A multi-agent run has exactly ONE lead
-with a liveness lease; "lead" used to be implicit in whoever opened the
-coord file. The orchestrator auto-claims at Phase 1, renews at each
-phase-start, and relinquishes at Phase D closeout — use this command for
-manual lead inspection, an out-of-band takeover, or dogfooding.
-
-All `lead` ops shell out to the host-neutral CLI:
-
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py lead <op> \
-  --workdir "$PWD" \
-  --session-id "user-rally-$(date +%s)" \
-  --tool "claude_code" \
-  --run-id "<run-id>"
-```
-
-- `claim` — become lead if the channel has no lead or the lease expired.
-  Returns `{"claimed": bool, "lead": {...}}`. A second claim while a valid
-  lease is held returns `claimed: false` with the incumbent.
-- `renew` — extend the current lease (lead only; `--renew-every-minutes`,
-  default 15). `renew_every_minutes` is the lease clock — distinct from the
-  `watch` poll cadence.
-- `transfer` — hand the lead to another session (`--to-session-id`,
-  `--to-tool`, `--to-model`); rejected from a non-lead.
-- `relinquish` — give up the lead so the next `claim` succeeds immediately.
-- `status` — read the current lead + `lease_valid`.
-
-Example: `/build-loop:rally-point lead status`
-
-### `escalate <reason>`
-
-Post a `kind=escalation` change record (G3) — "needs lead or user
-attention now", distinct from routine `phase`/`feedback`. An open
-escalation makes `status` report `blocked` until acknowledged.
-
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py escalate \
-  --workdir "$PWD" \
-  --session-id "user-rally-$(date +%s)" \
-  --tool "claude_code" \
-  --run-id "<run-id>" \
-  --reason "<why this needs attention>"
-```
-
-### `boundary`
-
-Validate the embedded mini-plugin boundary used to keep Rally Point and the
-watcher extractable while they still ship inside build-loop.
-
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py boundary \
-  --repo "${CLAUDE_PLUGIN_ROOT}" \
-  --check \
-  --json
-```
-
-This checks `scripts/rally_point/plugin_boundary.json` and reports the
-current `agent-rally-point` and `agent-rally-watcher` extraction surfaces.
-
-### `docs`
-
-Prints the binding coordination constitution at `references/coordination-rules.md`. Use this when onboarding a peer (Codex, second Claude session, CI verifier) so they read the same rules — the verdict-gating operating rule, the `post()` helper mandate, MECE packets for every write-handoff, release-surface verification, Phase D closeout.
-
-Executes:
-
-```bash
-cat ${CLAUDE_PLUGIN_ROOT}/references/coordination-rules.md
-```
-
-### `help`
-
-Shows the subcommand reference table (replaces what the no-args case used to do pre-v0.12.10).
-
-Outputs:
-
-```
-/build-loop:rally-point — inspect or invoke build-loop's multi-session coordination
-
-Subcommands:
-  status (default)        Sensor poll: active peers, unresolved verdicts, coord file
-  watch                   Continuous sensor loop for peer/inbox changes
-  heartbeat               Write a long-running task check-in
-  announce [message]      Publish Rally Point presence + handoff without coord file
-  init <topic> <scope>    Bootstrap a coord file from template; atomic + idempotent
-  lead <op>               Inspect or update the leadership lease
-  escalate <reason>       Post an urgent coordination escalation
-  boundary                Validate embedded agent-rally extraction boundaries
-  docs                    Print the binding coordination constitution
-  help                    This message
-
-No-args invocation runs `status` (the most common interactive use).
-
-When auto-invoke is enough:
-  The build-orchestrator agent auto-invokes coordination at three trigger
-  points (Phase 1 Assess preamble, Phase 3 chunk-close, Phase 4 Review-A).
-  See agents/build-orchestrator.md §"Auto-invoke coordination". Use `watch`
-  when waiting on an async peer response or targeted inbox message. Use
-  `status`, `heartbeat`, `announce`, or `init` for manual peer setup, debugging
-  coordination state, or onboarding a fresh verifier session.
-```
-
-## Dispatch
-
-Based on the parsed subcommand (or `status` when `{{ARGUMENTS}}` is empty), run the corresponding bash command above using the Bash tool. Quote the result and surface key fields (status / coord_file / unresolved) in the response.
-
-For `status`, if `unresolved: []` is non-empty, hold and resolve them before the user's intended step proceeds.

package/commands/research-run.md

@@ -1,22 +0,0 @@
----
-name: research-run
-description: "(Advanced override — `/build-loop:run` auto-routes here; use this only to force the mode.) Generate a repo-grounded research packet without committing to build. Pre-decision analysis."
-argument-hint: "[topic]"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-Load the `build-loop:research` skill.
-
-{{#if ARGUMENTS}}
-Topic: `{{ARGUMENTS}}`
-
-Run the research packet workflow:
-1. Scan the repo for context relevant to the topic
-2. Classify the task type
-3. Generate a structured research packet (Bottom line, What I found, Best path, Why, Risks, Confidence, Next action)
-4. Archive to `.build-loop/research/`
-5. Present the packet — user decides next step: build, optimize, or shelve
-{{else}}
-No topic specified. Ask the user what they want to research or evaluate.
-{{/if}}

package/commands/review-knowledge.md

@@ -1,16 +0,0 @@
----
-description: "Surface review-needing items across episodic memory: review queue, decision rot, open conflicts, stale procedures."
-argument-hint: "[--rot-threshold-days N] [--no-db]"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-Load the `build-loop:knowledge-review` skill.
-
-{{#if ARGUMENTS}}
-Run with arguments: `{{ARGUMENTS}}`
-{{else}}
-Run with defaults (`--rot-threshold-days 90`).
-{{/if}}
-
-Invoke `python3 scripts/knowledge_review.py --workdir "$PWD" {{ARGUMENTS}}` and present the markdown output to the user. Read-only; do not auto-resolve any item.

package/commands/self-review.md

@@ -1,51 +0,0 @@
----
-description: "Periodic self-review: mine recent build activity for issues and efficiency signals, optionally apply SAFE improvements. Use --install/--uninstall/--status to manage the launchd schedule."
-argument-hint: "[light|deep] [--install|--uninstall|--status]"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-{{#if ARGUMENTS}}
-{{#contains ARGUMENTS "--install"}}
-Run `python3 scripts/install_self_review.py install --json` in the current repo and report the result.
-{{else}}
-{{#contains ARGUMENTS "--uninstall"}}
-Run `python3 scripts/install_self_review.py uninstall --json` in the current repo and report the result.
-{{else}}
-{{#contains ARGUMENTS "--status"}}
-Run `python3 scripts/install_self_review.py status --json` in the current repo and report loaded/not-loaded state for both scheduled jobs.
-{{else}}
-Determine mode from ARGUMENTS: if it contains "deep" use `deep`, otherwise use `light`.
-Determine mode from ARGUMENTS: if it contains "deep" use `deep`, otherwise use `light`.
-Run `python3 scripts/self_review/__main__.py --mode <mode> --workdir . --json` and display the digest path and queued proposal count. If mode is deep, also describe the queued proposals and their classify_hint values.
-{{/contains}}
-{{/contains}}
-{{/contains}}
-{{else}}
-Run `python3 scripts/self_review/__main__.py --mode light --workdir . --json` and display the digest path and queued proposal count.
-{{/if}}
-
----
-
-## Reference
-
-**Manual trigger (light — daily digest, no apply)**
-```
-/build-loop:self-review light
-```
-
-**Manual trigger (deep — full review; routes SAFE proposals through /build-loop:run)**
-```
-/build-loop:self-review deep
-```
-
-**Launchd schedule management**
-```
-/build-loop:self-review --install    # install both launchd jobs (reads .build-loop/config.json)
-/build-loop:self-review --status     # check loaded/not-loaded
-/build-loop:self-review --uninstall  # remove jobs and plists
-```
-
-Scheduled runs are fully autonomous: the deep job (Sunday 03:00 by default) runs the gatherer, then calls `claude -p` with the apply prompt to route SAFE proposals through `/build-loop:run`, which applies + commits + collapses. Push behavior is governed by `selfReview.autonomy` in `.build-loop/config.json` (`apply_push` / `apply_local` / `propose`). RISKY and DECISION proposals are never applied autonomously — they stay queued for manual review.
-
-See `skills/build-loop/references/self-review.md` for the full config schema, graceful-degradation notes, and the APPLY PROMPT.

package/commands/setup-memory.md

@@ -1,32 +0,0 @@
----
-description: "Set up or verify the build-loop central memory store (build-loop-memory). Guided and idempotent — copies only the packaged public seed, never overwrites your content. Safe to re-run."
-argument-hint: "[--check]"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-{{#if ARGUMENTS}}
-{{#contains ARGUMENTS "--check"}}
-Run `python3 "${CLAUDE_PLUGIN_ROOT:-$PWD}/scripts/install_memory.py" --check` and report the memory store status: which template files and which lanes (`indexes/`, `projects/`) exist vs are missing. Do not write anything.
-{{else}}
-Run `python3 "${CLAUDE_PLUGIN_ROOT:-$PWD}/scripts/install_memory.py" --guided` and report what was seeded vs already present, then surface the installer's printed next steps to the user.
-{{/contains}}
-{{else}}
-Run `python3 "${CLAUDE_PLUGIN_ROOT:-$PWD}/scripts/install_memory.py" --guided` and report what was seeded vs already present, then surface the installer's printed next steps to the user.
-{{/if}}
-
----
-
-## Reference
-
-**Guided setup (idempotent — public seed only, no personal content):**
-```
-/build-loop:setup-memory
-```
-
-**Status check (no writes):**
-```
-/build-loop:setup-memory --check
-```
-
-The store lives at `memory_store_root()`. Resolution: an env override (`$BUILD_LOOP_MEMORY_STORE_ROOT` / `$BUILD_LOOP_MEMORY_ROOT` / `$AGENT_MEMORY_ROOT`), else a pre-existing legacy `~/dev/git-folder/build-loop-memory` if it is already on disk, else the neutral fresh-install default `~/.build-loop-memory`. On a fresh machine it is also bootstrapped automatically on session start by `hooks/session-start-memory.sh` when entirely absent; this command is the manual / repair path and the way to see what's present. Research packets, project lessons, decisions, and debugging memory all persist under this store.

package/commands/start-prd.md

@@ -1,57 +0,0 @@
----
-name: start-prd
-description: "Start a living PRD for the current project by answering 3-5 strategic questions. Loads the prd-builder skill if installed."
-argument-hint: "[appname]"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-Load the `prd-builder` skill from RossLabs-AI-Toolkit if available. If unavailable, fall back to the inline guidance below.
-
-{{#if ARGUMENTS}}
-App name: `{{ARGUMENTS}}`
-
-Run the prd-builder workflow for this app:
-1. Confirm the skill applies (check trigger conditions).
-2. Ask Q1-3 in a single message, formatted as draft inferences (not blank prompts) based on whatever you know about the project from the codebase + memory.
-3. Wait for the user to redirect or confirm.
-4. Optionally ask Q4-5 if Q1-3 leave specific gaps the user wants pinned down.
-5. Draft the PRD at `docs/prd-{{ARGUMENTS}}.md` per the prd-builder Output Specification.
-6. Run the Fidelity check; deepen any section that fails prediction.
-7. Add a project-level pointer in `CLAUDE.md` (or `.claude/CLAUDE.md`): *"For non-trivial changes, read `docs/prd-{{ARGUMENTS}}.md` and apply its LLM Navigation Map."*
-8. (If applicable) bidirectionally link to existing research packets, audit docs, or operationalization documents.
-{{else}}
-No app name provided. Either:
-- Provide an appname argument: `/build-loop:start-prd myapp` → drafts `docs/prd-myapp.md`
-- Or ask the user what app this PRD is for, then proceed with the workflow above.
-{{/if}}
-
-## Fallback when prd-builder skill is not installed
-
-If the `prd-builder` skill is unavailable in this session, walk the user through the 3 core questions inline:
-
-**Q1 — Who and when (persona + trigger):** Describe the primary user (role, life stage, what they already use that this competes with). List 1-3 trigger moments that make them open the app. List 3-7 explicit "is NOT" exclusions.
-
-**Q2 — Outcome (the measurable change):** Pick ONE measurable change after N weeks/months of usage. Number, behavior, or self-perception.
-
-**Q3 — Stance (the philosophy):** Three sentences:
-1. Privacy/Data: "We will/won't [send/store/share] X because Y."
-2. Complexity: "Regular users will/won't see [advanced feature class] because Y."
-3. Cost: "App is [free/freemium/paid/subscription/...] because Y."
-
-Then draft a markdown PRD at `docs/prd-{{ARGUMENTS}}.md` with:
-- Frontmatter (name, status, revision, last_updated, load_when, evolves_when, core_principles)
-- Body sections: How to use this PRD, LLM Navigation Map, Section Index, Fidelity check, Intent, North Star, Persona, Outcome, Methodology, Stance, Non-goals (illustrative), Roadmap stance, One-line summary, Open questions, Pivot log, Document maintenance.
-
-Cite `~/dev/git-folder/RossLabs-AI-Toolkit/skills/prd-builder/SKILL.md` for the full output spec.
-
-After drafting, run the Fidelity check by predicting answers to:
-- Should the next major release prioritize speed or accuracy?
-- Should new features add complexity or simplify existing ones?
-- Should the home screen show many metrics or one north-star indicator?
-- Should we accept a feature request from a vocal user who doesn't fit the persona?
-- When should the app degrade gracefully vs fail loudly?
-- When should we move work from on-device to cloud (or vice versa)?
-- Should onboarding be opinionated or open?
-
-If you can predict each cleanly with PRD section citations, the PRD passes. If not, deepen the failing section.

package/commands/test.md

@@ -1,34 +0,0 @@
----
-description: "(Advanced override — `/build-loop:run` auto-routes here on 'test plugin'/'validate plugin' language; use this to force the mode.) Run build-loop's plugin-tests static-analysis suite against the current repo (skill resolution, manifest, MCP, triggers, bridges, agent surfaces, cache pruning)"
-allowed-tools: Bash, Read
-argument-hint: "[--strict] [<test-name>]"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-Load the `build-loop:plugin-tests` skill.
-
-{{#if ARGUMENTS}}
-Args: `{{ARGUMENTS}}`
-
-If `<test-name>` is one of `skill-resolution`, `plugin-manifest`, `mcp-registration`, `trigger-phrases`, `bridge-preflight`, `agent-surface-policy`, `cache-prune`, run only that single script. Otherwise treat the args as flags for the runner.
-
-Example:
-- `/build-loop:test skill-resolution` — run only the namesake-collision test
-- `/build-loop:test --strict` — exit non-zero on any soft warning (CI gate)
-{{else}}
-Run the full plugin-test suite from the repo root:
-
-```bash
-for t in scripts/test_skill_resolution.py scripts/test_plugin_manifest.py \
-         scripts/test_mcp_registration.py scripts/test_trigger_phrases.py \
-         scripts/test_bridge_preflight.py scripts/test_agent_surface_policy.py \
-         scripts/test_prune_plugin_cache.py scripts/test_prune_codex_plugin_cache.py; do
-  echo "=== $(basename $t) ==="
-  python3 "$t" || EXIT=1
-done
-exit ${EXIT:-0}
-```
-
-Surface failures with the script name + test name + the assertion message. On any failure, suggest the fix path documented in the test's docstring.
-{{/if}}

package/commands/verify-plan.md

@@ -1,39 +0,0 @@
----
-name: verify-plan
-description: "Deterministic verifier for plan markdown — grep-checkable rules (delete-with-callers, numeric-drift, route-change-evidence, package-state, missing-evidence). Run before accepting a Phase 2 plan."
-argument-hint: "<plan.md>"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-Load the `plan-verify` skill from `${CLAUDE_PLUGIN_ROOT}/skills/plan-verify/SKILL.md` for context.
-
-{{#if ARGUMENTS}}
-Plan file: `{{ARGUMENTS}}`
-
-Run:
-
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/plan_verify.py {{ARGUMENTS}} --repo "$PWD" --json
-```
-
-Then:
-
-1. Report the summary (BLOCKER / WARN / INFO counts and per-rule breakdown).
-2. If exit code is 1, list each BLOCKER with claim_text + line + rule_id and stop — do NOT proceed to Phase 3.
-3. If exit code is 0, surface WARN findings as advisory and proceed.
-4. If exit code is 2, treat as verifier outage and surface to the user.
-
-For non-deterministic checks (alternatives considered, MECE scope, marker adequacy),
-follow up by dispatching the `plan-critic` agent with the same plan + this script's JSON output.
-{{else}}
-No plan file specified.
-
-Usage: `/plan-verify <path-to-plan.md>`
-
-Example: `/plan-verify .build-loop/plan.md`
-
-The verifier exits 0 if there are no BLOCKERs, 1 if BLOCKERs are present, 2 on verifier error.
-
-To inspect rules, read `${CLAUDE_PLUGIN_ROOT}/skills/plan-verify/SKILL.md`.
-{{/if}}