@tyroneross/build-loop 0.34.0 → 0.36.0

package/commands/compose-handoff.md

@@ -1,113 +0,0 @@
----
-description: "Compose a complete build-loop handoff from current run state. Optional --launch starts a fresh session in the stable checkout with the handoff injected."
-argument-hint: "[--launch] [--workdir DIR]"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-{{#if ARGUMENTS}}
-{{#contains ARGUMENTS "--launch"}}
-
-## Step 1 — Compose the handoff doc
-
-Run from the STABLE checkout (not a worktree):
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/handoff --workdir "$PWD" --output .build-loop/handoff-latest.md
-```
-
-Report the sources used and any warnings from stderr.
-
-## Step 2 — Identify the stable checkout path
-
-Run:
-```bash
-git worktree list --porcelain | grep "^worktree" | head -1 | awk '{print $2}'
-```
-
-This is the canonical repo root. The new session MUST open there, not in any `.build-loop/worktrees/` sub-path (those may be GC'd).
-
-## Step 3 — Launch a fresh session with handoff injected
-
-Determine the host. Then:
-
-**Claude Code host** — use `claude --print` in a new terminal:
-```bash
-HANDOFF=$(cat .build-loop/handoff-latest.md)
-echo "RESUME_FROM_HANDOFF: The following handoff document captures the current build-loop run state. Use it to resume work.\n\n${HANDOFF}" | claude --print
-```
-If the trust prompt fires on the new session, type `y` and press Enter.
-
-**Codex host** — pass the doc as context:
-```bash
-codex --context "$(cat .build-loop/handoff-latest.md)" "Resume from the attached handoff document."
-```
-
-**Unknown / unsupported host** — print the path and instructions:
-```
-Handoff doc written to: .build-loop/handoff-latest.md
-To resume: open a fresh session at <stable-checkout-path>, share the handoff doc as your opening message, and load the build-loop:build-loop skill.
-```
-
-In all cases: exit 0 (degrade gracefully — the doc is the deliverable, launch is a convenience).
-
-{{else}}
-
-## Compose the handoff document
-
-Run:
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/handoff --workdir "$PWD"
-```
-
-Present the full output as your response. Also report:
-- Sources used (from the `sources` field if `--json` was used)
-- Any warnings
-
-{{/contains}}
-{{else}}
-
-## Compose the handoff document
-
-Run:
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/handoff --workdir "$PWD"
-```
-
-Present the full output. Also note:
-- What sources were found vs missing
-- Any errors/warnings
-
-To launch a fresh session after handoff, re-run with `--launch`:
-```
-/build-loop:compose-handoff --launch
-```
-
-{{/if}}
-
----
-
-## Reference
-
-**Emit to stdout (default)**
-```
-/build-loop:compose-handoff
-```
-
-**Write to file**
-```
-/build-loop:compose-handoff --workdir /path/to/repo
-```
-(Use `--output` flag in the script directly for file output.)
-
-**Emit + launch fresh session**
-```
-/build-loop:compose-handoff --launch
-```
-
-**JSON envelope (for programmatic use)**
-```bash
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/handoff --workdir "$PWD" --json
-```
-Returns `{document, sources, errors, ts}`.
-
-See `skills/handoff/SKILL.md` for the full 8-section template, source table, and host-agnostic design notes.

package/commands/debug.md

@@ -1,20 +0,0 @@
----
-description: "(Advanced override — `/build-loop:run` auto-routes here on symptom language; use this to force debug mode.) Deep iterative debugging — causal-tree investigation, fix, verify, critique. Up to 5 iterations."
-argument-hint: "<symptom>"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-{{#if ARGUMENTS}}
-Load the `build-loop:debug-loop` skill. Symptom: `{{ARGUMENTS}}`
-{{else}}
-Load the `build-loop:debug-loop` skill. Ask the user what failure to investigate.
-
-Examples:
-- `/build-loop:debug tests pass locally but fail in CI`
-- `/build-loop:debug login works once then breaks on refresh`
-- `/build-loop:debug API returns wrong data intermittently`
-
-For quick memory lookup, use `/build-loop:debugger` instead.
-For multi-domain assessment, use `/build-loop:assess` instead.
-{{/if}}

package/commands/debugger-detail.md

@@ -1,34 +0,0 @@
----
-description: "Load full build-loop incident or pattern details from native debugging memory"
-allowed-tools: Read, Grep
-argument-hint: "<INC_* or PTN_* id>"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-# Debugger Detail
-
-Load full details for a specific incident or pattern from debugging memory.
-
-## Usage
-
-```
-/debugger-detail <ID>
-```
-
-Where `<ID>` is an incident ID (INC_*) or pattern ID (PTN_*).
-
-## What to do
-
-1. Search `.build-loop/issues/` for the requested incident or pattern ID.
-
-2. Present the result to the user in a readable format:
-   - For incidents: show symptom, root cause, fix approach, file changes, verification status
-   - For patterns: show detection signature, solution template, success rate, usage history
-
-3. If the ID is from a progressive search result, explain how this detail relates to the user's current issue.
-
-## Examples
-
-- `/debugger-detail INC_API_20260215_143022_a1b2` — loads full incident
-- `/debugger-detail PTN_REACT_HOOKS` — loads full pattern

package/commands/debugger-scan.md

@@ -1,15 +0,0 @@
----
-description: "Capture recent debugging incidents into build-loop native memory"
-allowed-tools: Read, Grep, Bash
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-Review recent build-loop run notes, reports, and validation failures for debugging work from the past 7 days. Store confirmed incidents as Markdown files under `.build-loop/issues/`.
-
-Prioritize:
-- Root cause analysis documents
-- Error tracking logs
-- Fix reports
-
-Do not call external debugger packages by default. Use standalone Coding Debugger only when the user explicitly asks for cross-project memory.

package/commands/debugger-status.md

@@ -1,20 +0,0 @@
----
-description: "Show build-loop native debugging memory statistics"
-allowed-tools: Bash, Read
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-Display the current state of build-loop's native debugging memory:
-
-```bash
-find .build-loop/issues -type f -name '*.md' 2>/dev/null | wc -l
-```
-
-This shows:
-- Number of stored incidents
-- Number of extracted patterns
-- Storage size
-- Recent activity
-
-Use this to understand what debugging knowledge has been accumulated and whether the memory system is working correctly.

package/commands/debugger.md

@@ -1,32 +0,0 @@
----
-description: "Search build-loop native debugging memory before debugging"
-allowed-tools: Read, Grep
-argument-hint: "<symptom>"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-Search build-loop's native debugging memory for similar past incidents before investigating a new bug.
-
-{{#if ARGUMENTS}}
-
-Run the native memory-first workflow with the provided symptom:
-
-```
-Skill("build-loop:debugging-memory-search") with input { symptom: "{{ARGUMENTS}}" }
-```
-
-After running the search:
-1. If a match is found with >70% confidence, try that solution first
-2. Review the root cause and fix approach from past incidents
-3. Apply the documented fix, adapting as needed for the current context
-4. If the fix works, no need to store again (already in memory)
-5. If a different fix is needed, document it as a new incident
-
-{{else}}
-
-No symptom provided. Read recent local incidents from `.build-loop/issues/` if present, then ask the user to describe what they are debugging.
-
-Use standalone Coding Debugger only when the user explicitly asks for cross-project debugger memory.
-
-{{/if}}

package/commands/optimize-run.md

@@ -1,31 +0,0 @@
----
-name: optimize-run
-description: "(Advanced override — `/build-loop:run` auto-routes here; use this only to force the mode.) Run autonomous metric-driven optimization. Detects available targets or accepts a specific one."
-argument-hint: "[target]"
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-Load the `build-loop:optimize` skill.
-
-{{#if ARGUMENTS}}
-Target: `{{ARGUMENTS}}`
-
-Run all three phases:
-1. **Setup** — configure the optimization for the specified target
-2. **Loop** — iterate: hypothesize → edit → measure → keep or revert
-3. **Review** — check for overfitting, summarize results
-
-If the target matches a known profile (`simplify`, `optimize-build`, `optimize-tests`, `optimize-bundle`, `optimize-perf`, `semantic-search-latency`), use the pre-configured settings from `profiles.md`.
-
-For custom targets, run Phase 1 (Setup) interactively.
-For latency-sensitive targets, prefer repeated sampling with warmups and a stable aggregate such as `median` or `p95` instead of a single timing sample.
-{{else}}
-No target specified.
-
-1. Run `python3 ${CLAUDE_PLUGIN_ROOT}/scripts/optimize_loop.py --detect --workdir "$PWD"` to discover available targets
-2. Check for existing `.build-loop/optimize/experiment.json` — offer to resume if found
-3. Present available targets and let the user choose
-4. The `simplify` target is always available (reduces line count in changed files)
-5. For response-time work, initialize a custom target with `--metric-samples`, `--metric-warmups`, and `--metric-aggregate` so the loop compares stable latency numbers instead of one noisy run
-{{/if}}

package/commands/promote-experiment.md

@@ -1,129 +0,0 @@
----
-name: build-loop:promote-experiment
-description: Promote an auto-promoted experimental skill or agent from project-local `.build-loop/skills/active/` into the build-loop plugin repo, making it available across every project. Requires user confirmation and opens a PR on the plugin repo for review.
-argument-hint: <artifact-name>
----
-
-<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
-
-# /build-loop:promote-experiment <name>
-
-Promote a proven experimental artifact into the build-loop plugin itself. This is the manual, user-approved counterpart to Phase 6 Learn's auto-promote — which stays local to the project. Cross-project promotion modifies the plugin repo and affects every user, so it is never automatic.
-
-## Prerequisites
-
-1. The artifact must exist at `.build-loop/skills/active/<name>/SKILL.md` (already auto-promoted within the project), OR at `.build-loop/skills/experimental/<name>/SKILL.md` (user is fast-tracking without waiting for A/B completion — require explicit confirmation).
-
-2. The build-loop plugin repo must be writable. Check:
-   ```bash
-   BUILD_LOOP_REPO="${CLAUDE_PLUGIN_ROOT:-$HOME/Desktop/git-folder/build-loop}"
-   [ -d "$BUILD_LOOP_REPO/.git" ] && [ -w "$BUILD_LOOP_REPO/skills" ]
-   ```
-   If false, abort with "build-loop plugin repo not writable at $BUILD_LOOP_REPO".
-
-3. The user must supply `<name>` as an argument. If missing, list current candidates:
-   ```bash
-   ls .build-loop/skills/active/ 2>/dev/null
-   ls .build-loop/skills/experimental/ 2>/dev/null
-   ```
-
-## Steps
-
-### 1. Read the evidence
-
-Collect:
-- The artifact's SKILL.md content
-- Its experiments jsonl (`.build-loop/experiments/<name>.jsonl`)
-- All `applied` entries across this project (and, if a global index exists at `~/.build-loop/experiments/<name>.jsonl`, append those too)
-- Any `auto_promote` or `extend_sample` decisions from `.build-loop/experiments/decisions.jsonl`
-
-Compute:
-- Total applied runs (across projects)
-- Aggregate win rate vs baseline
-- Any regression signals (reversed auto-promotes, discard attempts)
-
-### 2. Synthesize a promotion dossier
-
-Build a markdown summary for the user:
-
-```markdown
-## Promotion dossier: <name>
-
-**Type**: skill | agent
-**Auto-promoted in this project**: <date>, after N runs
-**Cross-project evidence**: P projects, Q applied runs, R wins, S regressions
-**Aggregate metric delta**: +X% vs baseline (target was +Y%)
-**SKILL.md length**: N lines
-**Dependencies declared**: (none | list)
-**Last modified**: <date>
-
-**What the skill does** (from description frontmatter):
-<one line>
-
-**Recommended promotion target**:
-- Name on promote: build-loop:<name>  (or rename to: build-loop:<suggested-name>)
-- Target path: skills/<name>/SKILL.md in the plugin repo
-- Triggers on: <extracted trigger phrases>
-```
-
-### 3. Ask the user
-
-Use `AskUserQuestion`:
-
-```
-Question: "Promote '<name>' into the build-loop plugin repo?"
-Header: "Promote"
-Options:
-  - "Promote as drafted" — copy SKILL.md verbatim, open PR
-  - "Promote with rename" — user provides new name, then copy + PR
-  - "Review first" — output the dossier but do not copy (user decides after reading)
-  - Cancel (implicit via AskUserQuestion "Other")
-```
-
-### 4. Execute
-
-If user approved promotion:
-
-1. Determine target path: `$BUILD_LOOP_REPO/skills/<final-name>/SKILL.md` (plus any references/ subdirectory from source).
-2. If target already exists:
-   - Abort and ask user to choose a new name, OR confirm overwrite.
-3. Create a feature branch on the plugin repo: `feat/promote-<name>-from-<project-slug>`.
-4. Copy files. Edit frontmatter: remove `experimental: true`, `promoted_at`, `promoted_from_project`; add `promoted_at: <ISO>`, `promoted_from_project: <project-name>`, `original_baseline: <N>`, `aggregate_delta: <percent>`.
-5. Update the plugin's `skills/build-loop/SKILL.md` capability routing table to reference the new skill if it fits an existing row, OR add a new row (ask the user which).
-6. Commit:
-   ```
-   feat(skills): promote <name> from Phase 6 Learn
-
-   Originated as auto-drafted experimental skill in <project>.
-   Aggregate track record: P projects, Q runs, +X% vs baseline
-   (target was +Y%). SKILL.md copied verbatim with promotion
-   metadata added to frontmatter.
-
-   Evidence log: .build-loop/experiments/<name>.jsonl (N entries)
-   Signed off by Opus 4.7 on <auto-promote date>.
-   ```
-7. Push the branch and open a PR with the promotion dossier as the body.
-
-### 5. Record in project
-
-Append to `.build-loop/experiments/decisions.jsonl`:
-
-```jsonl
-{"event": "cross_project_promote", "date": "ISO", "name": "<name>", "plugin_pr_url": "<url>", "aggregate_evidence": { runs, projects, delta }}
-```
-
-Do not delete the local artifact — it stays in `.build-loop/skills/active/<name>/`. The plugin version will shadow it once installed; the local copy is retained as the historical source.
-
-## Safety rails
-
-- **Never auto-invoke**. Phase 6 Learn auto-promote stops at the project boundary. This command is the only path to the plugin repo.
-- **Require user confirmation**. AskUserQuestion is mandatory.
-- **Always open a PR**, never commit to main directly. Plugin maintainers review before merge.
-- **Preserve provenance**. Frontmatter records the source project, baseline, and delta. If the promoted skill regresses in a cross-project context, the track record makes rollback decisions clear.
-- **Never overwrite without confirmation**. If a skill with the same name exists, abort and let the user rename or approve overwrite.
-
-## Related
-
-- Phase 6 Learn auto-promote (project-local): `skills/self-improve/SKILL.md`
-- User removal override: `.build-loop/skills/.demoted` file or `rm -rf .build-loop/skills/active/<name>/`
-- Global cross-project evidence index: `~/.build-loop/experiments/<name>.jsonl` (appended on every applied run across projects)