@polderlabs/bizar 10.7.0 → 10.7.2

package/.claude/commands/audit.md

@@ -0,0 +1,48 @@
+---
+description: Run the Bizar harness audit — scores 12 dimensions 0-10, aggregates to 0-100.
+allowed-tools: Read, Write, Bash
+---
+
+# /audit — Harness Self-Audit
+
+Run the harness audit: `node scripts/audit.mjs --write`.
+The script scores 12 categories (each 0-10), aggregates to a 0-100 score,
+and writes `.harness/audit/latest.json`.
+
+## Categories scored
+
+| Category | Weight | What it checks |
+|---|---|---|
+| typecheck | 15% | `bunx tsc --noEmit` exits 0 |
+| tests | 12% | `make test` exits 0 |
+| e2e | 12% | `bun run scripts/bh-full-e2e.mjs` exits 0 |
+| arch-boundaries | 8% | `bash scripts/check-arch.sh .` passes |
+| security-patterns | 10% | No hardcoded keys, no overly broad allowed-tools |
+| doc-sync | 5% | AGENTS.md and CLAUDE.md are in sync |
+| feature-list-state | 10% | No `not_started` backlog, all passing features have evidence |
+| clean-state | 8% | No `console.log`, `debugger`, or `.only()` in production code |
+| perf-budget | 5% | No single file exceeds 2000 lines |
+| coverage | 5% | Coverage tooling configured (stub — add c8 to upgrade) |
+| observability | 5% | sessions.jsonl + arch-rules.json exist |
+| drift | 5% | Score differs from prior run |
+
+## Output
+
+```
+{version, startedAt, completedAt, total, scores, categories, weights}
+```
+
+- `categories[key].evidence` — human-readable explanation of the score
+- `categories[key].score` — 0-10 for that dimension
+- `total` — weighted sum, 0-100
+- `.harness/audit/latest.json` — persisted result (written with `--write`)
+
+## Usage
+
+```
+/audit              — print JSON score to stdout (no file written)
+/audit --write      — print JSON and write .harness/audit/latest.json
+make audit          — same as --write with a summary line
+```
+
+Run it, then read the evidence strings to understand which categories need attention.

package/.claude/commands/bizar.md

@@ -0,0 +1,22 @@
+---
+description: Bizar Plugin Menu — route to the right Bizar action based on the user's request.
+---
+
+# Bizar Dashboard
+
+The `/bizar` command launches the Bizar dashboard in your browser — a fully integrated workspace with Overview, Chat, Agents, Plans, Projects, Config, and Settings panels. The dashboard binds to `127.0.0.1` only and runs as a local Express + WebSocket server on a free port (preferred: 4321).
+
+If the user invoked `/bizar` with arguments, treat them as a request and route appropriately:
+
+- "explain X" → invoke `/explain X`
+- "plan Y" → invoke `/visual-plan on` and then `/plan new <slug>` with the user's intent as the slug
+- "review PR" → invoke `/pr-review`
+- "audit" → invoke `/audit`
+- "learn" → invoke `/learn`
+- "init" → invoke `/init`
+- "dashboard" or "open dashboard" → `/bizar` (no args, will launch the dashboard)
+- Otherwise: ask one clarifying question
+
+If the user invoked `/bizar` with no arguments, the dashboard is launching in the background. Visit `http://localhost:<port>/` to access it. The plugin's `chat.message` hook spawns `bizar dash start` as a detached child process and surfaces the live URL in its response.
+
+Common ports: 4321 is preferred; if it's taken, the launcher walks upward and picks the next free port. The PID and port are recorded under `~/.config/bizar/dashboard.{pid,port}` so `bizar dash stop` and `bizar dash status` can find the running instance.

package/.claude/commands/cron.md

@@ -0,0 +1,36 @@
+---
+description: Manage scheduled cron tasks for autonomous agent runs.
+allowed-tools: Read, Write, Bash, WebFetch
+---
+
+# /cron — Scheduled Autonomous Tasks
+
+Manage cron tasks that run on a schedule using the Bizar SDK cron API.
+
+## Usage
+
+```
+/cron add <cron-expression> <prompt>  — Schedule a recurring task (e.g. "/cron add 0 * * * * Check email")
+/cron add-once <cron-expression> <prompt>  — Schedule a one-time task
+/cron list                            — List all scheduled tasks
+/cron remove <id>                     — Remove a task by its ID
+```
+
+## Routing
+
+- If the user wants to add a task → `/cron add <cron> <prompt>` or `/cron add-once <cron> <prompt>`
+- If the user wants to list tasks → `/cron list`
+- If the user wants to remove a task → `/cron remove <id>`
+
+## Implementation Notes
+
+Use the SDK cron API:
+```
+import { addCronTask, listCronTasks, removeCronTask } from "@polderlabs/bizar-sdk/agent/cron";
+```
+
+- `addCronTask({ cron, prompt, recurring })` — add a task
+- `listCronTasks()` — returns all tasks
+- `removeCronTask(id)` — removes by id, returns true if found
+
+Tasks are persisted to `.bizar/cron.json` in the project root.

package/.claude/commands/explain.md

@@ -0,0 +1,17 @@
+---
+description: Route to @susan for read-only codebase Q&A. She will explore the code and answer without making any changes.
+---
+
+# /explain — Read-Only Codebase Q&A
+
+The user is asking a question about the codebase. Use the **Agent tool** to dispatch to a read-only research subagent — name it `susan` if that agent exists, otherwise use the `general-purpose` or `Explore` subagent type with explicit read-only instructions.
+
+The subagent must:
+1. Use only read tools (`Read`, `Grep`, `Glob`, `Bash` with read-only commands)
+2. Never edit, write, or modify any file
+3. Explore the codebase to find the answer
+4. Return a concise, cited answer with file:line references
+
+If the user supplied an argument via `$ARGUMENTS`, treat that as the question. If `$ARGUMENTS` is empty, ask one clarifying question before dispatching.
+
+Pass `$ARGUMENTS` (or the refined question) to the subagent's prompt verbatim. Do not include any write or destructive tool in the subagent's allowed list.

package/.claude/commands/goal.md

@@ -0,0 +1,99 @@
+---
+description: Add or update a long-horizon goal in .bizar/PROGRESS.md — same source-of-truth as the v8 dashboard Goals view.
+---
+
+# Goal — Track a Long-Horizon Commitment
+
+You are in `/goal` mode. The user has invoked this command to add or
+update a **goal** in `.bizar/PROGRESS.md`. This file is the single
+source of truth for goals — both the dashboard's Goals view and
+Claude Code's `/goal` slash command read from and write to it.
+
+## Contract
+
+- **Goals live in `.bizar/PROGRESS.md`** in the active project root.
+  Parse the current file first so you don't clobber existing goals.
+- **Round-trip via the dashboard API.** The dashboard server is the
+  canonical writer — it owns the parsing + serialization logic
+  (`bizar-dash/src/server/progress-parser.mjs`) and broadcasts a
+  `goals:change` WebSocket event so the dashboard updates live. **Do
+  not edit PROGRESS.md directly** unless the dashboard is down.
+- **Use the dashboard's HTTP API by default.** Resolve the dashboard
+  port from `${BIZAR_HOME}/dashboard.port` (default
+  `~/.config/bizar/dashboard.port` per `cli/install/paths.mjs:49`),
+  then POST/PATCH. This keeps goals in lock-step with whatever the
+  dashboard user is looking at.
+
+## API surface (S10/S12)
+
+```
+GET    /api/goals                        # list all parsed goals
+POST   /api/goals    { title, owner?, due? }   # create
+GET    /api/goals/:id                    # single goal
+PATCH  /api/goals/:id { title?, owner?, due? } # rename / reassign / re-due
+PATCH  /api/goals/:id/status  { status }       # on-track | at-risk | done | blocked | active
+POST   /api/goals/:id/key-results  { title }   # append KR
+PATCH  /api/goals/:id/key-results/:krId { title?, done? }  # toggle / rename
+DELETE /api/goals/:id/key-results/:krId         # remove KR
+```
+
+## Examples
+
+### Add a goal
+
+```bash
+PORT=$(jq -r .port ~/.cache/bizarharness/dash-auth.json)
+curl -s -X POST http://127.0.0.1:$PORT/api/goals \
+  -H "Content-Type: application/json" \
+  -d '{"title":"Ship current dashboard","owner":"sam","due":"2026-09-30"}'
+```
+
+### Change a goal's status to at-risk
+
+```bash
+curl -s -X PATCH http://127.0.0.1:$PORT/api/goals/G-abc123/status \
+  -H "Content-Type: application/json" \
+  -d '{"status":"at-risk"}'
+```
+
+### Add a key result
+
+```bash
+curl -s -X POST http://127.0.0.1:$PORT/api/goals/G-abc123/key-results \
+  -H "Content-Type: application/json" \
+  -d '{"title":"Cut S9 polish time in half"}'
+```
+
+### Mark a key result done
+
+```bash
+curl -s -X PATCH http://127.0.0.1:$PORT/api/goals/G-abc123/key-results/KR-xyz \
+  -H "Content-Type: application/json" \
+  -d '{"done":true}'
+```
+
+## When the dashboard is unreachable
+
+Fallback path: write directly to `<active-project>/.bizar/PROGRESS.md`
+using the format the parser understands:
+
+```markdown
+## G-<id> — <Title>
+Owner: <name> · Due: <YYYY-MM-DD>
+Goal is **<status>**.
+
+- [ ] <key-result title>
+- [x] <done key-result title>
+```
+
+Then when the dashboard comes back up, `GET /api/goals` re-parses the
+file and broadcasts a `goals:change` event to refresh the UI.
+
+## Background: why this exists
+
+`/goal` was added in S12 of the dashboard rewrite. Before this,
+goals lived only in the user's head and `FINAL_GOAL.md` (which is the
+user's own planning doc, not the harness's tracker). This command
+makes goals a **first-class dashboard entity** — they appear in the
+Goals view, the Overview stat tile, the Activity feed, and the
+command palette.

package/.claude/commands/init.md

@@ -0,0 +1,15 @@
+---
+description: Run bizar init to detect project stack, install relevant skills, and create .bizar/PROJECT.md.
+allowed-tools: Read, Bash, Write, Glob
+---
+
+# /init — Initialize `.bizar/` in the current project
+
+Run `bizar init` from the project root to:
+1. Detect the project stack (language, framework, database, tools)
+2. Install relevant skills from the skills registry
+3. Create `.bizar/PROJECT.md` with stack and conventions
+4. Create `.bizar/AGENTS_SELF_IMPROVEMENT.md` (only if missing)
+5. Build the per-project knowledge graph in `.bizar/graph/` (powered by graphify; skipped gracefully if graphify is not installed)
+
+After init, run `bizar doctor` to validate setup.

package/.claude/commands/learn.md

@@ -0,0 +1,46 @@
+---
+description: Pillar D — review instincts and decisions from the self-learning log, ask user what to save/promote/drop.
+allowed-tools: AskUserQuestion, Read, Write, Bash
+---
+
+# /learn — Self-Learning Review
+
+You are the `brenda` (self-improvement) agent. Review the instincts and
+decisions that have been recorded, then ask the user what to do.
+
+## Sources
+
+- Instinct log: `.bizar/learning/instincts.jsonl` (or via SDK: `listInstincts()`)
+- Decisions log: `.bizar/learning/decisions.jsonl` (or via SDK: `listDecisions()`)
+- Session traces: `.harness/traces/sessions.jsonl`
+
+## Process
+
+1. Read recent instincts (`listInstincts()` or read the JSONL directly).
+2. Read recent decisions (`listDecisions()` or read the JSONL directly).
+3. Read `.harness/traces/sessions.jsonl` for recent session outcomes.
+4. Ask the user one question per category via `AskUserQuestion`:
+
+   a) **New instinct?** — "You ran `make check` N times. Save a low-confidence
+      instinct for it?" → if yes, call `recordInstinct({ trigger, action, confidence: 0.3, evidence: [...], scope: 'project' })`
+
+   b) **Promote existing?** — "An instinct for `npm install` has confidence 0.3.
+      Promote it to 0.6?" → if yes, call `promoteInstinct(id, 0.6)`
+
+   c) **Drop stale?** — "An instinct for `git push` (confidence 0.1) hasn't
+      fired in N sessions. Drop it?" → if yes, call `dropInstinct(id)`
+
+5. Summarise what was saved, promoted, or dropped.
+
+## SDK Functions
+
+```ts
+import { recordInstinct, listInstincts, promoteInstinct, dropInstinct } from '@polderlabs/bizar-sdk/learning';
+// or monorepo path: packages/sdk/dist/learning/instincts.js
+```
+
+## Constraints
+
+- Use `AskUserQuestion` (one per category, not one per item).
+- Do NOT use `console.log` — write to the instincts/decisions log only.
+- Confidence is 0–1. Auto-recorded instincts use 0.3 (low confidence, user-promotable).

package/.claude/commands/plan.md

@@ -0,0 +1,35 @@
+---
+description: Open the Bizar visual plan canvas or manage existing plans.
+allowed-tools: Read, Write, Bash, WebFetch
+---
+
+# /plan — Visual Plan Canvas
+
+Open or manage a Bizar visual plan. Plans are collaborative canvases for structuring work across agents.
+
+## Usage
+
+```
+/plan new <slug> [template]  — Create a new plan with a unique slug
+/plan list                   — List all existing plans
+/plan open <slug>            — Open a plan (returns the canvas URL)
+/plan get <slug>             — Get full plan content as JSON
+/plan add <slug> --title "..." — Add a new element to a plan
+/plan update <slug> <id> ...  — Update an element's content/title/status
+/plan delete <slug> <id>    — Delete an element from a plan
+/plan comment <slug> [id] "..." — Add a comment to a plan or element
+/plan comments <slug> [id]   — List comments on a plan or element
+/plan status <slug> <status> — Set plan status (draft|approved|rejected|in-progress|done)
+/plan wait <slug>            — Block until the plan receives feedback
+```
+
+## Routing
+
+- If the user wants to create a new plan → `/plan new <slug>`
+- If the user wants to see existing plans → `/plan list`
+- If the user wants to open/view a plan → `/plan open <slug>`
+- If the user wants to add content to a plan → `/plan add <slug> --title "..."`
+- If the user wants to modify a plan element → `/plan update <slug> <id> ...`
+- If the user wants to discuss/approve/reject → `/plan status <slug> <status>`
+
+The full arguments are available as `$ARGUMENTS`. Parse them and route to the matching subcommand above.

package/.claude/commands/plow-through.md

@@ -0,0 +1,50 @@
+---
+description: Autonomous mode — work fully independently, make all decisions, complete the task end-to-end without asking the user anything.
+---
+
+# Plow Through — Autonomous Mode
+
+You are in `/plow-through` mode. The user has invoked this command to tell you: **work autonomously, don't ask, decide things yourself, complete the task end-to-end.**
+
+## Contract
+
+- **No clarifying questions.** If the request is ambiguous, use the most reasonable interpretation based on project context. If you genuinely cannot proceed without user input (e.g., a destructive action requiring explicit authorization), log the blocker in your final report and continue with everything else.
+- **Decide things yourself.** Use your judgment. Read `.bizar/PROJECT.md`, `FINAL_GOAL.md`, `ROADMAP.md`, and search the memory vault (`bizar memory search "<topic>"`) for prior context before deciding.
+- **Split into parallel work streams.** Always dispatch 2+ subagents in parallel when the work is decomposable. Each stream must have a disjoint file scope. Use the **Agent tool** to spawn subagents — name them after the Bizar agent they represent (`todd`, `karen`, `greg`, `steve`, etc.) so the audit trail stays readable.
+- **Work to completion.** Don't stop at "I did X, should I continue?". The task is complete when: the deliverable exists, tests pass, changes are committed and pushed (where applicable).
+- **Report at the end.** Summarize what was done, what tests ran, any blockers encountered.
+
+## Background agents for long-running work
+
+Use the **Agent tool** with `run_in_background: true` (or the
+dashboard UI) to spawn background agents for tasks that span more
+than a few minutes. Check on them later via the dashboard's
+Background Agents panel or by sending a message to the teammate
+agent.
+
+## When to use
+
+- Multi-file refactors that don't require user approval
+- Bug-fix sweeps across a known surface area
+- Implementing a clearly-spec'd feature from the roadmap
+- Migration tasks (e.g., "migrate all CSS from @apply to vanilla")
+- Cleanup work (rename X, delete dead code Y, etc.)
+
+## When NOT to use
+
+- Anything that touches auth, billing, or destructive operations on user data
+- Architectural decisions with multiple valid approaches (use `/plan` first)
+- Tasks where you genuinely need user input on a key decision
+- Anything where being wrong has high consequences (merges to main, security patches)
+
+## Execution pattern
+
+1. Read project context (`.bizar/PROJECT.md`, `FINAL_GOAL.md`, `ROADMAP.md`)
+2. Search memory for prior context (`bizar memory search "<topic>"`)
+3. Decompose into independent work streams
+4. Dispatch streams via the **Agent tool** in parallel, naming them `todd` and `karen` (or whichever Bizar agents fit the scope)
+5. After streams return: run test gate (`bizar test-gate` or `/test`)
+6. Fix any test failures
+7. Update self-improvement log (`.bizar/AGENTS_SELF_IMPROVEMENT.md`)
+8. Commit + push (delegate to the `steve` subagent)
+9. Report final outcome

package/.claude/commands/pr-review.md

@@ -0,0 +1,49 @@
+---
+description: PR review mode. Launch @greg (research) and @linda (audit) in parallel, then post the combined review as a PR comment.
+allowed-tools: Read, Grep, Glob, Bash, WebFetch
+---
+
+# /pr-review — PR Review
+
+You are the `steve` agent running PR review mode. The full
+arguments are available as `$ARGUMENTS` — expect a PR number, URL,
+or branch name.
+
+## Protocol
+
+1. Resolve the PR. If `$ARGUMENTS` is empty, prompt for a PR
+   number. Use `gh pr view <ref>` to fetch the metadata.
+
+2. Dispatch two **parallel** subagents via the **Agent tool**:
+   - **`greg` (research)** — trace the diff's blast radius:
+     - Files changed and their blast radius
+     - Related call sites / consumers that might break
+     - Historical context (search `bizar memory search "<feature>"`)
+     - Tests that should have run
+   - **`linda` (audit)** — security and correctness review:
+     - Permission grants added or expanded
+     - Hardcoded secrets or PII
+     - Race conditions, TOCTOU, unbounded loops
+     - Missing input validation at trust boundaries
+
+   Spawn both in a **single message** with two Agent tool calls so
+   they run in parallel. Pass each agent a disjoint scope (the
+   research agent reads, the audit agent reads + flags).
+
+3. Synthesize. Wait for both subagents to finish, then combine:
+   - Verdict (`approve`, `request changes`, `comment`)
+   - Blocking issues (must-fix before merge)
+   - Non-blocking suggestions
+   - Test plan
+
+4. Post the review as a PR comment via `gh pr review <ref>
+   --comment --body-file -` (or `--approve` / `--request-changes`).
+
+5. Return the review summary to the user with the PR URL.
+
+## Constraints
+
+- Never merge on the user's behalf. Only post a review.
+- If the diff is huge (>1000 lines), narrow scope by file and
+  dispatch one subagent per logical chunk.
+- Always cite `file:line` for each finding.

package/.claude/commands/setup-provider.md

@@ -0,0 +1,96 @@
+---
+description: Configure a provider in settings.json (apiKey, baseUrl, model catalog). The installer no longer touches provider config — use this command to set one up.
+allowed-tools: Read, Write, Bash, WebFetch
+---
+
+# /setup-provider — Configure a provider in settings.json
+
+The Bizar installer no longer configures a provider for you (since
+v6.2.2 — the user owns provider config). Use this command to add
+or update a provider in `~/.claude/settings.json`.
+
+## What It Does
+
+Interactively (or non-interactively with flags), the setup-provider
+command writes a `provider` block to `~/.claude/settings.json` with:
+
+- `baseUrl` — the API endpoint (e.g. `http://localhost:20128/v1` for
+  the local 9Router gateway)
+- `apiKey` — the provider's API key (read from `env:` reference or
+  direct value)
+- `models` — the model catalog (the IDs returned by
+  `GET /v1/models`)
+
+## Default: 9Router Gateway
+
+If the user invokes `/setup-provider` with no arguments, default to
+the local 9Router gateway at `http://localhost:20128/v1`. The
+catalog comes from `GET http://localhost:20128/v1/models`. As of
+v6.2.2, that catalog includes:
+
+- `minimax/MiniMax-M3` (reasoning)
+- `minimax/MiniMax-M2.7` (reasoning)
+- `nvidia/minimaxai/minimax-m3` (reasoning)
+- `nvidia/minimaxai/minimax-m2.7` (reasoning)
+- `nvidia/z-ai/glm-5.2`
+- `nvidia/deepseek-ai/deepseek-v4-pro`
+- `nvidia/deepseek-ai/deepseek-v4-flash`
+- `nvidia/moonshotai/kimi-k2.6`
+- `nvidia/nemotron-3-ultra-550b-a55b`
+- `openrouter/cohere/north-mini-code:free`
+- `openrouter/poolside/laguna-m.1:free`
+- `openrouter/nvidia/nemotron-3-super-120b-a12b:free`
+- (and several more `minimax/MiniMax-M2.x` variants)
+
+## Flags
+
+- `--gateway <url>` — override the 9Router URL (default
+  `http://localhost:20128/v1`)
+- `--key <key>` — provider API key (writes `${env:KEY_NAME}` if it
+  looks like an env var name, otherwise writes the literal)
+- `--provider <name>` — provider name in settings.json (default `9router`)
+- `--model <id>` — add a single model instead of fetching the catalog
+- `--list` — print the model catalog from `/v1/models` and exit
+- `--remove <name>` — remove a provider by name
+
+## Examples
+
+```
+# Use the default 9Router gateway with the live model catalog
+/setup-provider
+
+# Custom provider
+/setup-provider --provider my-anthropic --gateway https://api.anthropic.com/v1 --key sk-ant-...
+
+# Just list the available models
+/setup-provider --list
+```
+
+## Implementation
+
+1. If `--list`, GET `${gateway}/v1/models` and pretty-print the IDs.
+2. If `--remove`, edit `~/.claude/settings.json` and remove the
+   `provider.<name>` block.
+3. Otherwise, read `~/.claude/settings.json`. If the file doesn't
+   exist, error — the user should run `bizar install` first.
+4. Build the new `provider.<name>` block from the flags + fetched
+   catalog.
+5. Write the file back atomically (write to `settings.json.tmp`,
+   then `rename`).
+6. Run `bizar validate` to confirm everything is wired up.
+
+## Security
+
+Never echo or log the full API key. If the user supplies a key on
+the command line, write it as a literal value (or `${env:KEY}`
+reference if it matches a `KEY_NAME` pattern). Never commit
+`~/.claude/settings.json` to source control — it may contain real
+secrets.
+
+## Related
+
+- `bizar connect` — interactive TUI for provider setup (alternative)
+- `bizar install` — installs the Bizar scaffolding (NOT provider config
+  since v6.2.2)
+- `bizar validate` — confirms provider config is wired correctly
+- Claude Code provider config: see https://docs.claude.com/en/docs/claude-code/settings

package/.claude/commands/spec.md

@@ -0,0 +1,47 @@
+---
+description: Write a 5-phase spec and file it as a GitHub issue (with dedup check).
+allowed-tools: Read, Write, Bash, WebFetch
+---
+
+# /spec — Write and File a GitHub Issue Spec
+
+Generate a structured 5-section spec document, check for duplicates
+against existing GitHub issues, and file it as a GitHub issue.
+
+## 5 Sections
+
+1. **Context** — Why this feature matters, current pain point
+2. **Goals** — What success looks like (3-5 bullet points)
+3. **Non-Goals** — Deliberately out of scope (2-4 bullet points)
+4. **Design** — Key API shapes, data structures, or UX flows
+5. **Open Questions** — Unresolved items with suggested resolution paths
+
+## Process
+
+1. Ask the user: "What is the spec topic?" (wait for reply)
+2. Fetch existing issues via `gh issue list --limit 100 --json number,title,body`
+3. Compute similarity against existing issue titles using keyword overlap:
+   - Tokenize title into lowercase words
+   - Compute overlap coefficient = |intersection| / min(len(a), len(b))
+   - Flag as potential dup if overlap > 0.5
+4. Present any dupes to the user for confirmation before creating
+5. Generate the spec body
+6. Create the issue via `gh issue create --title "spec: <topic>" --body-file -`
+7. Print the issue URL
+
+## Dedup threshold
+
+- **0.7+** — "Likely duplicate" — block and require user to confirm before creating
+- **0.5-0.7** — "Possible duplicate" — warn but proceed
+- **<0.5** — proceed without warning
+
+## Output
+
+Prints the created issue URL on success. On dup block, prints the
+matching issue numbers and waits for the user to confirm or cancel.
+
+## Constraints
+
+- Never create an issue without explicit user confirmation when dup is likely
+- The spec body is written to a temp file and passed via `--body-file -` to `gh issue create`
+- Always prefix the issue title with `spec: `

package/.claude/commands/sprint.md

@@ -0,0 +1,43 @@
+---
+description: Auto-fill a sprint contract from a goal ID in PROGRESS.md.
+allowed-tools: Read, Write, Bash
+---
+
+# /sprint — Auto-Fill Sprint Contract from Goal
+
+Reads a goal from `.bizar/PROGRESS.md` and pre-fills
+`templates/sprint-contract.md` with its title and key results.
+
+## Usage
+
+```
+/sprint <goal-id>
+```
+
+Example: `/sprint F-099`
+
+## What it does
+
+1. Parses `.bizar/PROGRESS.md` via `bizar-dash/src/server/progress-parser.mjs`
+2. Finds the goal with matching `id` (e.g. `F-099`)
+3. Reads `templates/sprint-contract.md` as the template
+4. Pre-fills:
+   - **Feature ID** → `goal-id`
+   - **Title** → goal title
+   - **Scope (in)** → key results (uncompleted first, completed below)
+   - **Scope (out)** → empty (explicitly excluded items are sprint-specific)
+   - **Definition of Done (DoD)** → all 7 standard DoD checkboxes pre-checked
+5. Writes to `.bizar/sprints/<goal-id>-YYYY-MM-DD.md`
+6. Prints the path so the agent can open/edit it
+
+## Error handling
+
+- Goal not found → `Error: goal '<id>' not found in .bizar/PROGRESS.md`
+- No key results → Scope (in) section left blank with a `<fill>` placeholder
+- File write failure → prints the pre-filled content to stdout as fallback
+
+## Constraints
+
+- Never overwrite an existing sprint file for the same goal+date
+- Always use today's date in the filename (ISO 8601: YYYY-MM-DD)
+- DoD checkboxes: all 7 standard items pre-checked; add more only if the sprint scope requires it