arcane-cli 0.14.0

package/dist/assets/.github/prompts/spell-present-arcane.prompt.md

@@ -0,0 +1,188 @@
+---
+name: Spell — Present Arcane
+description: Present Arcane in one of three modes — a full 1-hour talk (default), a live-state executive summary document, or a deck-builder meta-prompt sized to a slide count or duration.
+argument-hint: '[summary|deck] + optional audience/size — e.g., "for investors", "summary exec", "deck 10m", "deck 20 slides"'
+agent: agent
+---
+
+See [[governance/development-methodology|Development Methodology]] for full Spell Loop reference. Project context: [[project|Project Overview]].
+
+## Mode Selection
+
+Parse the first word of the argument before doing anything else. Match case-insensitively:
+
+- `summary` → run **Summary Mode** (produce a finished executive-summary document; skip the slide deck). See the Summary Mode section at the end of this file.
+- `deck` → run **Deck Mode** (emit a copy/paste prompt for an external AI to generate slides). See the Deck Mode section at the end of this file.
+- `present`, or no argument at all → run **Present Mode** (default): the full 1-hour talk outline defined immediately below (Purpose through Tone).
+- Any other leading word → treat the whole argument as an audience hint and run **Present Mode**. (If the word *looks* like an intended mode — e.g. `slides`, `doc`, `pdf`, `talk` — note in one line that it isn't a recognized mode and that you're defaulting to Present, then proceed.)
+
+After identifying the mode, treat every remaining word as an audience and/or size hint and carry it forward into the chosen mode. The mode keyword itself (`summary`/`deck`/`present`) is consumed by routing and is never a hint.
+
+---
+
+## Purpose
+
+Generate a complete, structured presentation for a **1-hour talk about the Arcane project** — including slide-by-slide outline, speaker notes, and a timed demo segment plan.
+
+The presentation should tell the story of *what was built*, *why it matters*, *how it works*, and *where it is going*.
+
+---
+
+## Context Files to Read First
+
+Read these files before generating the presentation. They are the ground truth **when present** — every row is **optional**. If a file is missing, use the listed fallback and continue; flag any gap in the output (see Output Instructions) rather than blocking.
+
+`{BUSINESS_ROOT}` is the directory holding per-business folders (e.g. `ventures/`, `businesses/`, or `projects/`); `{BUSINESS_NAME}` is a specific business. Resolve both from `.arcane.json` / project frontmatter; if unset, **detect** by scanning for a likely root, or ask the operator. There may be zero, one, or many businesses — enumerate whatever exists rather than assuming a fixed count.
+
+| File | What to extract | If missing, fall back to |
+|------|----------------|--------------------------|
+| [project.md](../../project.md) | Mission, vision, core principles, entities, goals | `README.md`, then ask the operator for the mission |
+| [ai-context/system-prompt-context.md](../../ai-context/system-prompt-context.md) | Environment, agent stack, current state | Infer environment from repo; omit slide detail if unknown |
+| [DECISIONS.md](../../DECISIONS.md) | Key ADRs — decisions that shaped the architecture | Skip ADR callouts; note that decision records are absent |
+| [agents/agent-capability-matrix.md](../../agents/agent-capability-matrix.md) | Agent lineup and capability tiers | `.github/agents/*.agent.md`; else present the system generically |
+| [agents/agent-policies.md](../../agents/agent-policies.md) | Power levels, autonomy model | [[governance/naming-conventions]]; else describe roles generically |
+| `{BUSINESS_ROOT}/<business>/overview.md` | Per-business status (repeat for each business found) | Enumerate `{BUSINESS_ROOT}/*`; if none, present Arcane without a ventures act |
+| [governance/development-methodology.md](../../governance/development-methodology.md) | The Spell Loop — development workflow | Describe the Spell Loop from the spell library filenames |
+| `{INFRA_DOC}` — hardware/infra inventory (e.g. `infrastructure/hardware-inventory.md`) | Hardware context for demo credibility | Detect any infra/hardware doc; else omit the infrastructure slide |
+| [README.md](../../README.md) | Repo structure overview | List top-level directories directly |
+
+---
+
+## Presentation Requirements
+
+### Format
+- **Total runtime:** 60 minutes
+- **Structure:** Slides + speaker notes + timed demo plan
+- **Output format:** Markdown outline suitable for pasting into Gamma.app, Google Slides, or PowerPoint
+  - Each slide = `## Slide N — Title` heading
+  - Bullet points = talking points (not wall-of-text)
+  - Speaker notes = italic block under each slide
+  - Max 6 bullets per slide
+
+### Timing Budget
+| Segment | Minutes |
+|---------|---------|
+| Opening hook + who I am | 5 |
+| What is Arcane / the vision | 8 |
+| The problem being solved | 5 |
+| Architecture & stack walkthrough | 12 |
+| Ventures — what's been built | 8 |
+| Live demo | 15 |
+| Lessons learned & what's next | 5 |
+| Q&A buffer | 2 |
+| **Total** | **60** |
+
+---
+
+## Slide Structure to Generate
+
+### Act 1 — Hook & Context (Slides 1–4, ~13 min)
+
+1. **Title slide** — Project name, presenter, date, one-line tagline
+2. **The dream** — "One person. Multiple businesses. AI does the work." The vision in human terms.
+3. **Who I am** — {OPERATOR_NAME}'s background, technical role, what motivated this project
+4. **The problem** — Running a business is brutal. AI tooling exists but isn't wired together. This project wires it together.
+
+### Act 2 — What Was Built (Slides 5–11, ~20 min)
+
+5. **Arcane — the operating system for AI-run businesses** — What the repo is, what it contains, how it's structured
+6. **Security model** — full-disk encryption, least privilege, no root, SecretRef, private network mesh — why security is non-negotiable for a production system
+7. **The AI agent stack** — the gateway plus the agent lineup, power levels, and tool profiles. Populate the roster from the agent-capability-matrix / `.github/agents/*.agent.md` (see [[governance/agent-policies]] / [[governance/naming-conventions]]); name each `{AGENT_NAME}` with its role rather than assuming a fixed cast. If no roster files exist, describe agent *roles* (e.g. research, marketing, ops, dev) generically.
+8. **The Spell Loop** — Arcane's development methodology: spell-plan → spell-architect → spell-implement → spell-ship
+9. **Multi-client AI governance** — Same rules enforced across every AI client the operator uses. Cite the relevant governance ADR if a decision record exists (resolve the ADR id from `DECISIONS.md`); otherwise state the principle without an id.
+10. **Ventures overview** — one line per business found under `{BUSINESS_ROOT}` (e.g. `{BUSINESS_NAME}` — launch-ready, `{BUSINESS_NAME}` — active dev), plus the idea pipeline. If none exist, replace with a roadmap slide.
+11. **Infrastructure** — `{PRIMARY_HOST}` (primary host; resolve from `{INFRA_DOC}` / `.arcane.json`, else ask or omit), the private network mesh, the configured tracker, and any dual-boot/host setup
+
+### Act 3 — Live Demo (Slides 12–13, ~15 min)
+
+12. **Demo plan slide** — What will be shown, in what order, what to look for
+13. **Demo backup slide** — Screenshots/recordings of key flows in case of live failure
+
+**Demo script to include (in speaker notes):**
+- Show Arcane repo structure in VS Code
+- Trigger a spell command (e.g., `spell-open-session` or `spell-sprint-status`) and show it in action
+- Show a Spell Loop output artifact (PRD or epics) that was AI-generated
+- Show the agent gateway running on `{PRIMARY_HOST}` (status, agent list, or a live agent message). Resolve `{PRIMARY_HOST}` from `{INFRA_DOC}` / `.arcane.json`; if unset, ask the operator or skip this beat.
+- Optional: show Gamma.app or SlidesAI generating a quick slide from a prompt (meta moment)
+
+### Act 4 — Reflection & Next (Slides 14–16, ~7 min)
+
+14. **What worked** — Top 3 things that validated the approach
+15. **What was hard** — Honest lessons: security overhead, LLM consistency, documentation discipline
+16. **What's next** — near-term milestones per business found (e.g. `{BUSINESS_NAME}` launch, `{BUSINESS_NAME}` Sprint 1) and scaling to the next business. Pull these from each `{BUSINESS_ROOT}/<business>/overview.md`; if none exist, present the framework roadmap instead.
+
+### Closing (Slide 17)
+
+17. **Close** — One-sentence takeaway, contact info, repo or demo link
+
+---
+
+## Output Instructions
+
+1. Generate the **full slide outline** with titles, bullet points (max 6 per slide), and speaker notes.
+2. Include a **demo timing breakdown** in the speaker notes for slides 12–13 (what to show at each minute mark).
+3. At the end, include a **"Gamma.app prompt"** block — a single text prompt the user can paste into Gamma.app to auto-generate the visual deck from this outline.
+4. Flag any slides where **content gaps exist** (e.g., a venture overview file that doesn't exist yet) so the user knows what to fill in before presenting.
+
+---
+
+## Tone
+
+- Confident and technical — this is not vaporware, this is a working production system.
+- Honest — show real numbers, real stack, real decisions. No marketing fluff.
+- Energetic — this is a unique project; present it with pride.
+- Audience-aware — if the user provided an audience hint (e.g., "for investors"), adjust language and emphasis accordingly. Default to technical/builder audience.
+
+---
+
+## Summary Mode
+
+Produce a finished, always-current executive summary **document** about Arcane — not a slide deck and not a prompt for another AI. The point is that it reflects live repository state at run time, so counts and versions are never stale.
+
+### Step 1 — Gather live state
+
+Read the repo to populate accurate values:
+
+- `package.json` / `.arcane.json` → Arcane version.
+- `.github/prompts/spell-*.prompt.md` → count of spells.
+- `.github/agents/*.agent.md` → count of agent personas.
+- `.arcane/governance/*.md` → governance/standards docs available.
+- `README.md` / `project.md` → scope and mission.
+
+### Step 2 — Tailor to audience
+
+If an audience hint followed `summary` (e.g., `exec`, `engineering`, `onboarding`), adjust emphasis:
+
+- **exec** — governance, auditability, delivery predictability.
+- **engineering** — the Spell Loop, quality gates, the spell + agent system.
+- **onboarding** — getting started, `spell init`, first session.
+- none — balanced general-stakeholder summary.
+
+### Step 3 — Output the document
+
+Output a complete Markdown document (no preamble), with current values filled in: what Arcane is, why it exists, what it includes (spell count, agent count, governance), how adopters use it (the Spell Loop), how quality/governance are enforced, and how to adopt it. End with a one-line generation note including the version. The document must be immediately usable as-is.
+
+---
+
+## Deck Mode
+
+Produce a single copy/paste **prompt** that the user can give to another AI tool to generate a full slide deck about Arcane, sized to the requested length.
+
+### Step 1 — Parse size
+
+From the words after `deck`:
+
+- `N slides` → target exactly N slides.
+- `Nm` (minutes) → ~1 slide/minute (10m → 8–12, 30m → 20–30).
+- `Nh` (hours) → convert to minutes, ~0.8–1.0 slides/minute (1h → 45–60).
+
+If no size is given (including when only an audience hint like `deck for investors` follows), stop and ask for one (`N slides`, `Nm`, or `Nh`) before emitting anything. Retain any audience hint already provided so the user need not repeat it.
+
+### Step 2 — Gather source material
+
+Use repo docs as ground truth (README, project, development-methodology, git-conventions, the spell library, agent roster). Cover: the Spell Loop lifecycle and quality gates; the spell + agent system; session continuity; governance; adoption path; risks and anti-patterns.
+
+### Step 3 — Emit the meta-prompt
+
+Output one fenced code block containing a prompt that instructs the external AI to produce: the target slide count (or range), a slide-by-slide outline, title + subtitle per slide, 3–5 bullets per slide, a visual suggestion per slide, and speaker notes — plus a final roadmap slide and a risks/limitations slide. Require plain language and claims grounded in the supplied context. After the block, add a one-line tip to paste it into the user's preferred slide generator and request export.
+

package/dist/assets/.github/prompts/spell-product-review.prompt.md

@@ -0,0 +1,97 @@
+---
+name: Spell — Product Review
+description: Build/Measure/Analyze/Decide cycle — evaluate feature performance and recommend next actions
+argument-hint: Feature or product area to review (e.g., "{BUSINESS_NAME} storefront performance", "{BUSINESS_NAME} beta feedback")
+agent: agent
+---
+
+## Executive Summary
+
+- This prompt runs a Build/Measure/Analyze/Decide product review cycle.
+- Used after a feature ships to evaluate its impact and decide what's next.
+- Combines analytics data, user feedback, and business metrics into an actionable recommendation.
+- Feeds back into `spell-plan` for the next iteration of the product.
+
+---
+
+Run a product review cycle for the specified feature or product area.
+
+**Placeholders** (resolve from `.arcane.json` or the feature/PRD frontmatter; if unset, **ask** rather than assuming a default):
+
+- `{BUSINESS_NAME}` — the business/venture under review.
+- `{BUSINESS_ROOT}` — the directory holding that business's product docs (KPIs, metrics, strategy). If no such root is configured or present, ask where these docs live; if there is none, treat the per-business metrics docs as absent and apply the fallback in step 2.
+
+Use these files for context:
+
+- [project.md](../../project.md) — Business goals and priorities
+- The relevant business docs under `{BUSINESS_ROOT}/` — KPIs, metrics, and product strategy. **If `{BUSINESS_ROOT}` or these docs are missing, proceed with what `project.md` provides and flag the gap; if even `project.md` is absent, report "insufficient context to review" and list what is missing rather than inventing goals.**
+- [governance/development-methodology.md](../../governance/development-methodology.md) — Spell Loop context
+
+Workflow:
+
+1. **Build — What was shipped?**
+   - Summarize the feature/change that was deployed.
+   - List the acceptance criteria and whether they were met.
+   - Note the timeline: when was it planned, built, and shipped?
+
+2. **Measure — What data do we have?**
+   - Gather available metrics:
+     - Usage data (if analytics are configured)
+     - Error rates / crash reports
+     - User feedback (support tickets, reviews, direct feedback)
+     - Business metrics (sales, conversions, engagement)
+   - If the KPI/metrics docs under `{BUSINESS_ROOT}` (or any analytics source) are missing or empty, **do not fabricate numbers.** Proceed with "insufficient data to review" and list exactly what is missing (which docs, which metrics, which instrumentation), then recommend adding it before the next review.
+
+3. **Analyze — What does the data tell us?**
+   - Is the feature achieving its goal?
+   - Are there unexpected behaviors or usage patterns?
+   - How does it compare to the hypothesis in the PRD?
+   - What's working well? What isn't?
+
+4. **Decide — What do we do next?**
+   - **Iterate:** feature needs improvement — generate follow-up PRD items.
+   - **Scale:** feature is working — invest in marketing/growth.
+   - **Pivot:** feature isn't solving the problem — reconsider approach.
+   - **Kill:** feature is net negative — plan removal.
+
+5. **Generate product review report**:
+   ```markdown
+   ## Product Review — [Feature/Product]
+
+   **Date:** [timestamp]
+   **Review Period:** [date range]
+   **Business:** {BUSINESS_NAME}
+
+   ### Build Summary
+   - Feature: [what was built]
+   - Shipped: [date]
+   - Stories completed: [N]
+
+   ### Metrics
+   | Metric   | Baseline | Current | Target | Status       |
+   | -------- | -------- | ------- | ------ | ------------ |
+   | [metric] | [before] | [after] | [goal] | ON/OFF TRACK |
+
+   ### Analysis
+   - [Key insights from the data]
+   - [Unexpected findings]
+
+   ### Decision
+   - **Recommendation:** [Iterate / Scale / Pivot / Kill]
+   - **Rationale:** [Why]
+   - **Next Actions:**
+     1. [Action item → owner]
+     2. [Action item → owner]
+
+   ### Missing Instrumentation
+   - [Metrics we should be tracking but aren't]
+   ```
+
+6. **Present for discussion** — this review drives human decision-making, not autonomous action.
+
+Rules:
+- **Data-driven, not opinion-driven.** Base recommendations on evidence, not assumptions.
+- **Acknowledge uncertainty.** If data is thin, say so — don't overfit to limited signals.
+- **Recommendation guardrails:** Flag any recommendation involving purchases or subscriptions for human approval (see your org's decision log / spending policy if one exists).
+- **Connect to business goals.** Every analysis must reference the relevant business's KPIs from `{BUSINESS_ROOT}` or `project.md`; if neither is available, say so explicitly instead of asserting goals.
+- **No vanity metrics.** Focus on metrics that drive decisions, not numbers that look good.

package/dist/assets/.github/prompts/spell-review-batch.prompt.md

@@ -0,0 +1,94 @@
+---
+name: Spell — Review Batch
+description: Adversarially review many pull requests in one run and emit per-PR verdicts plus a consolidated go/no-go readiness gate report. Provider-agnostic.
+argument-hint: '--prs <n,n,…> | --pr <n> | --file <path> | --query <q>  [--repos <r,…>] [--html] [--title <t>]'
+agent: agent
+---
+
+## Executive Summary
+
+- This spell runs the `spell-review` engine across a batch of pull requests and rolls the results into one report.
+- It produces a per-PR verdict (approve / request-changes) plus an overall **go / no-go** gate for the batch — useful for a release-readiness or UAT gate.
+- It is provider-agnostic: GitHub (`gh`) and Azure DevOps (`az repos`), detected from the git remote.
+- This is the reviewer-side, many-PR counterpart to `spell-review` (single diff). The author-side spell is `spell-address-review`; PRs are typically opened with `spell-create-pull-request`.
+
+---
+
+Review a batch of pull requests and produce a consolidated readiness report.
+
+Context to consult:
+
+- `.arcane/governance/git-conventions.md` — review severity and merge policy.
+- The `spell-review` spell — the single-PR review engine this spell reuses per PR (dimension-coverage lenses, severity, stable finding IDs `R1`, `R2`…).
+
+## Arguments
+
+- `--pr <n>` — a single PR.
+- `--prs <n,n,…>` — comma-separated PR numbers.
+- `--file <path>` — a file to extract PR numbers from (match `\b\d{2,}\b`).
+- `--query <q>` — a provider query to discover matching PRs.
+- `--repos <r,…>` — optional repo scoping for multi-repo orgs.
+- `--html` — also emit a self-contained HTML version of the consolidated report for easy sharing.
+- `--title <t>` — optional title for the consolidated report (e.g. "Sprint 42 UAT Gate").
+
+If no input mode is given, ask the user how they want to specify the PRs.
+
+## Step 1 — Resolve inputs
+
+1. Detect the provider first from `git remote get-url origin` (GitHub vs Azure DevOps). If the remote is ambiguous or unrecognized, stop and ask. Confirm the CLI is authenticated (`gh auth status` / `az account show`) before proceeding; on an auth failure, report the exact remediation command and stop — do not partially run.
+2. Parse the input mode and collect the PR list. For `--query`, discover PRs via the provider:
+   - **GitHub:** `gh pr list --search "<q>" --json number,title,headRefName`
+   - **Azure DevOps:** `az repos pr list --status active --query "<filter>"`
+   - If `--query` returns zero PRs, report "no PRs matched" and stop — there is nothing to gate.
+3. Deduplicate and validate every PR number (positive integers). Drop and note any malformed token rather than aborting. If the resulting list is empty, stop and ask for valid input.
+4. Resolve scope per PR. `--repos` scopes discovery and disambiguates PR numbers across a multi-repo org; carry the owning repo with each PR number so mixed-repo batches fetch from the right repo (`gh pr view <n> --repo <r>` / `az repos pr show --id <n>`). A bare number with no repo defaults to the origin repo.
+5. **Batch size.** Process PRs sequentially (each review is independent). If the batch exceeds **20 PRs**, warn the user, confirm intent, and proceed in order — do not silently truncate.
+
+## Step 2 — Review each PR
+
+For each PR in the batch, independently:
+
+1. Fetch the PR diff and metadata (`gh pr diff <n>` / `az repos pr show --id <n>` + diff). If a PR can't be fetched (deleted, no access, network error), **skip it, record it as `SKIPPED` with the reason, and continue** — never abort the whole batch for one bad PR.
+2. Run the `spell-review` workflow against that diff — the full dimension-coverage sweep (correctness, security, performance, tests, naming/clarity, architecture), severity-ranked findings (`HIGH` / `MEDIUM` / `LOW`, matching the `spell-review` ladder) with stable IDs, and the PASS/WARN/FAIL coverage table.
+3. Record a per-PR result: verdict (**approve** / **request-changes**), finding counts by severity, and the coverage table.
+
+Reviews are adversarial — actively look for problems, do not just confirm quality. Apply the same no-fabrication coverage mandate as `spell-review`: a clean lens is reported as "no issues," never padded.
+
+## Step 3 — Consolidate
+
+Build one report:
+
+```markdown
+# Batch Review — {title or "PR Readiness"}  ({date})
+
+## Gate: {GO / NO-GO}
+
+> GO only if every PR was reviewed and no PR carries an unresolved HIGH finding.
+
+| PR | Repo | Title | Verdict | High | Med | Low |
+| -- | ---- | ----- | ------- | ---- | --- | --- |
+| #n | repo | …     | approve / request-changes | 0 | 1 | 2 |
+| #n | repo | …     | SKIPPED — {reason}        | —  | —  | —  |
+
+## Per-PR detail
+### PR #n — {title}
+- Verdict: …
+- Coverage: {PASS/WARN/FAIL per lens}
+- Findings: {R1 …}
+```
+
+The overall gate is **NO-GO** if any reviewed PR has an unresolved HIGH finding, **or** if any requested PR was skipped (an un-reviewed PR can't be cleared) — otherwise **GO**. `HIGH` is the top severity in the `spell-review` ladder; do not invent a "Critical" tier the engine never emits.
+
+## Step 4 — Output
+
+1. Write the consolidated markdown report to a sensible path (e.g. `reviews/batch-review-{date}.md`).
+2. If `--html` was passed, also emit a self-contained HTML file (inline CSS, no external assets) at the same base path so it can be shared by email/chat.
+3. Print a summary to the user: total reviewed / skipped, verdict counts, total findings by severity, the GO/NO-GO gate, and the output path(s).
+
+## Rules
+
+- Reuse the `spell-review` engine per PR — do not invent a parallel, weaker rubric.
+- Reviews are adversarial but honest — no fabricated findings to inflate counts.
+- The HTML report must be fully self-contained (inline styles) so it works offline.
+- Do not commit or post anything to external systems — the report is a local file the user shares deliberately.
+- Never include secrets or tokens in the report.

package/dist/assets/.github/prompts/spell-review.prompt.md

@@ -0,0 +1,131 @@
+---
+name: Spell — Review
+description: Adversarial code review — must find issues, validate architecture compliance, and check security
+argument-hint: PR number, branch name, or file paths to review
+agent: agent
+---
+
+## Executive Summary
+
+- This prompt performs an adversarial code review — "looks good" is not acceptable.
+- The reviewer must explicitly cover every lens — correctness, security, performance, tests, naming/clarity, architecture — and state "no issues" for any lens that is clean. There is no finding quota: zero findings is a valid outcome on a clean or small diff.
+- Checks architecture compliance, test coverage, security, and coding standards.
+- See [[governance/development-methodology|Development Methodology]] for the adversarial review pattern.
+
+---
+
+Perform an adversarial review of the specified code changes.
+
+Use these files for context:
+
+- [governance/development-methodology.md](../../governance/development-methodology.md) — Adversarial review requirements
+- [governance/testing-standards.md](../../governance/testing-standards.md) — Coverage thresholds to validate
+- [DECISIONS.md](../../DECISIONS.md) — ADRs to check compliance against
+- [security/threat-model.md](../../security/threat-model.md) — Security controls to validate
+- The feature's `architecture.md` — tech decisions that code must follow
+
+Workflow:
+
+1. **Gather the diff** — get the full set of changes being reviewed:
+   - `git diff main...HEAD` for branch reviews.
+   - Specific file paths if provided.
+   - PR diff if a PR number is given.
+
+2. **Architecture compliance** — for each changed file:
+   - Does it follow the architecture decisions in architecture.md?
+   - Does it respect existing ADRs?
+   - Are there unauthorized framework or pattern deviations?
+
+3. **Code quality** — check for:
+   - Naming conventions (per project standards).
+   - Error handling (appropriate, not excessive).
+   - Code duplication (DRY violations).
+   - Complexity (functions too long, too many parameters).
+   - Dead code, commented-out code, debug statements.
+
+4. **Test coverage** — validate:
+   - New code has corresponding tests.
+   - Coverage meets thresholds per testing-standards.md.
+   - Edge cases are tested (nulls, empty collections, boundaries).
+   - No test stubs or skipped tests without justification.
+
+5. **Security review** — check for OWASP Top 10 issues:
+   - Injection vulnerabilities (SQL, XSS, command injection).
+   - Authentication/authorization gaps.
+   - Sensitive data exposure.
+   - Insecure dependencies.
+
+6. **Generate review report**:
+   ```markdown
+   ## Code Review — [Feature/Branch Name]
+
+   **Reviewer:** [Agent name]
+   **Date:** [timestamp]
+
+   ### Coverage Summary
+
+   One row per coverage lens. Verdict is `PASS` for a clean lens (note "no issues"),
+   `WARN` for non-blocking findings, `FAIL` for a blocker. Reference the relevant
+   finding IDs (`R1`, `R2`, …) in the Notes column.
+
+   | Lens            | Verdict (PASS/WARN/FAIL) | Notes                                |
+   | --------------- | ------------------------ | ------------------------------------ |
+   | Correctness     | [PASS/WARN/FAIL]         | [no issues / refs to R#]             |
+   | Security        | [PASS/WARN/FAIL]         | [no issues / refs to R#]             |
+   | Performance     | [PASS/WARN/FAIL]         | [no issues / refs to R#]             |
+   | Tests           | [PASS/WARN/FAIL]         | [no issues / refs to R#]             |
+   | Naming/Clarity  | [PASS/WARN/FAIL]         | [no issues / refs to R#]             |
+   | Architecture    | [PASS/WARN/FAIL]         | [no issues / refs to R#]             |
+
+   ### Findings
+
+   Give each finding a stable ID (`R1`, `R2`, …) so it can be referenced in follow-ups and in `spell-address-review`.
+
+   #### HIGH Severity
+   - **R1** — [Finding with file:line reference]
+
+   #### MEDIUM Severity
+   - **R2** — [Finding with file:line reference]
+
+   #### LOW Severity
+   - **R3** — [Finding with file:line reference]
+
+   ### Architecture Compliance
+   - [Compliant / Minor deviation / Major violation]
+
+   ### Test Coverage Assessment
+   - [Coverage % and gap analysis]
+
+   ### Security Assessment
+   - [OWASP checklist results]
+
+   ### Verdict
+   - [ ] APPROVE — no critical issues
+   - [ ] REQUEST CHANGES — critical issues found (list blockers)
+   - [ ] DEFER — needs human decision on [topic]
+
+   ### Backlog Items
+   - [Findings outside scope of this change — track separately]
+   ```
+
+7. **Save report to disk** — write the review report to the feature folder's `assessments/` directory:
+   ```bash
+   FEATURE_FOLDER="features/$(git symbolic-ref --short HEAD | sed 's|.*/feat/||')"
+   REPORT_PATH="$FEATURE_FOLDER/assessments/review-$(date +%Y-%m-%d).md"
+   mkdir -p "$FEATURE_FOLDER/assessments"
+   # Write the full review report to $REPORT_PATH
+   ```
+   If the branch doesn't follow `feat/{id}-{slug}`, ask the operator for the feature folder path.
+   Confirm the saved path to the user.
+
+8. **Present findings** — show the review to the user with a clear recommendation.
+
+9. **Write back to the pull request** — when a PR exists for these changes, sync a short verdict plus a findings summary (verdict + finding counts/IDs + a pointer to the saved report) into the PR body/description. Use provider-agnostic phrasing that works for either GitHub or Azure DevOps. Mark it clearly as a snapshot at review time, and fall back to a top-level PR comment if the description can't be updated.
+
+Rules:
+- **Cover every dimension, not a finding count.** You MUST explicitly address each lens — correctness, security, performance, tests, naming/clarity, architecture — and state "no issues" for any lens that is clean. There is no minimum number of findings: zero findings is a valid outcome on a clean or small diff. The mandate is coverage of effort, not a count of findings — never fabricate issues to hit a quota.
+- **Never rubber-stamp.** Every review must include substantive analysis across all dimensions.
+- **Classify severity honestly.** Don't inflate LOW findings to pad the report.
+- **Escalate architecture-level flaws.** If the review surfaces deep design or architecture problems (not line-level fixes), recommend routing them to `spell-architect` rather than trying to patch them inline.
+- **Separate concerns.** Don't block a PR for issues unrelated to the current change — add them to backlog.
+- **Check for bias.** If you wrote the code being reviewed, flag the conflict and recommend a different agent review.

package/dist/assets/.github/prompts/spell-save-idea.prompt.md

@@ -0,0 +1,83 @@
+---
+name: Spell — Save Idea
+description: Quickly capture a fleeting idea into the repo's idea inbox so it is not lost. Low ceremony, no approval gate, optimized for voice and speed.
+argument-hint: The idea itself — a sentence to a couple of paragraphs (e.g., "add a dark-mode toggle to the settings page")
+agent: agent
+---
+
+## Executive Summary
+
+- This spell saves a short idea into `IDEAS.md` at the repo root with a timestamp, so a good thought is not lost between sessions.
+- It is deliberately fast and low-friction: no approval gate, no multi-step proposal — capture and confirm.
+- Use it the moment an idea occurs to you. Triage later with `spell-todo` or `spell-suggest-feature`.
+- This is the lightweight counterpart to `spell-document` (which formalizes a whole conversation into polished docs).
+
+---
+
+Capture the user's idea into the idea inbox with minimal ceremony.
+
+The user's input IS the idea. If no idea text was provided, ask one short question: _"What's the idea?"_ and stop until they answer.
+
+## Step 1 — Normalize the Idea
+
+- Take the user's input verbatim as the core idea.
+- Strip a leading invocation phrase if the user dictated one (e.g., "save this idea —", "note that", "remind me to") — log the idea, not the command to log it.
+- Lightly clean it up: fix obvious typos and capitalization, but **do not** rewrite, expand, or editorialize. The user's phrasing is the record.
+- If the idea is clearly multiple distinct ideas, split them into separate entries (one appended line each).
+- Optionally infer a single short tag (1–2 words, kebab-case) from the content — e.g., `ui`, `infra`, `marketing`, `dx`. If nothing fits cleanly, omit the tag.
+- **If the idea contains a secret** (token, password, API key, connection string), redact it inline (e.g., `[redacted]`) before writing and warn the user in the confirmation. Never write the raw value to `IDEAS.md`.
+
+## Step 2 — Append to IDEAS.md
+
+Append (never overwrite) an entry to `IDEAS.md` at the repo root.
+
+Entry format:
+
+```markdown
+- **[YYYY-MM-DD HH:MM]** [#tag] <the idea, lightly cleaned> <!-- status: new -->
+```
+
+- Get the real local date and time from the system (e.g., run `date`) rather than guessing — a wrong timestamp silently corrupts the append-only log.
+- The `status: new` HTML comment lets later triage mark entries as `promoted` / `dropped` without deleting history.
+- Include `[#tag]` only if a tag was inferred; otherwise omit it.
+
+If `IDEAS.md` does not exist yet, create it with this header first, then append:
+
+```markdown
+# Idea Inbox
+
+Fast-capture log of ideas worth keeping. Add with `spell-save-idea`. Triage with `spell-todo`
+(actionable) or `spell-suggest-feature` (product ideas). Entries are append-only; mark status in the
+trailing comment rather than deleting.
+
+---
+```
+
+## Step 3 — Confirm (one line)
+
+Print a single concise confirmation, nothing more:
+
+```
+💡 Saved to IDEAS.md — [#tag] <short echo of the idea>
+```
+
+- If multiple entries were appended, confirm with one line per entry (or a count, e.g. `💡 Saved 3 ideas to IDEAS.md`).
+- If anything was redacted, append `(secret redacted)` to the confirmation so the user knows.
+
+## Step 4 — Offer Promotion (optional, non-blocking)
+
+After confirming, add at most one short line offering a next step **only if the idea is obviously
+actionable or product-shaped**:
+
+> Want to turn this into a tracked item? Run `spell-todo` (task) or `spell-suggest-feature` (product idea).
+
+Do not ask follow-up questions. Do not commit — leave that to `spell-commit-work`.
+
+## Rules
+
+- Speed over polish. This spell should feel instant.
+- Never overwrite existing entries — always append.
+- Never rewrite the user's idea beyond light cleanup. Preserve their words.
+- No approval gate — write immediately.
+- Never include secrets, tokens, or credentials in an entry.
+- Do not commit the change.