arcane-cli 0.39.0 → 1.1.0

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

@@ -6,155 +6,4 @@ argument-hint: Feature or initiative to plan (e.g., "user authentication for a m
 agent: agent
 ---
 
-## Executive Summary
-
-- This prompt generates a PRD.md from a feature description or TODO item.
-- It follows a structured analysis pattern — requirements, acceptance criteria, and constraints.
-- Output feeds directly into `spell-architect` as the next phase of the Spell Loop.
-- See [[.arcane/governance/development-methodology|Development Methodology]] for full Spell Loop reference.
-
----
-
-Generate a Product Requirements Document for the described feature or initiative.
-
-Use these files for context:
-
-- [governance/development-methodology.md](../../.arcane/governance/development-methodology.md) — Spell Loop methodology
-- [project.md](../../project.md) — Project goals and priorities
-- [DECISIONS.md](../../DECISIONS.md) — Existing ADRs to respect
-
-Workflow:
-
-1. **Configure tracking mode first** — decide how this work will be tracked before requirement intake:
-
-   <!-- fragment:tracking-mode-declaration:start -->
-   - `tracking_mode: internal | external`
-   - `external_provider: ado | github | jira | other`
-   <!-- fragment:tracking-mode-declaration:end -->
-
-   Resolve in this order, matching spell-open-session's own resolution chain (EF-14): root
-   `.arcane.json` (if present) → the committed self-hosted source manifest (`src/assets/.arcane.json`,
-   read only when it declares `selfHosted: true`) → the current feature PRD frontmatter → ask.
-   Do not re-ask when any of the first three sources already sets it.
-
-   Rules:
-   - If not explicitly set and ADO context is already present (work item ID + org/project), default to `tracking_mode: external`, `external_provider: ado` for backward compatibility.
-   - If none of the three sources above set it and no ADO context exists, ask: "Track work in this repo (TODO.md / PRDs)" [internal] vs "Track work in an external tracker (Azure DevOps / GitHub / Jira / other)" [external].
-   - If `tracking_mode=internal`, do not require an external tracker ID.
-   - If `tracking_mode=external` and `external_provider=ado`, collect org/project and resolve process template + available work item types before planning:
-     ```bash
-     az devops project show --org https://dev.azure.com/{org} --project {project} --query "capabilities.processTemplate.templateName" --output tsv
-     az boards work-item-type list --org https://dev.azure.com/{org} --project {project} --output json --query "[].name"
-     ```
-     Then enforce level-to-type mapping using the first available type in order:
-     - Epic-level: `Epic → Feature → User Story → Issue`
-     - Feature-level: `Feature → User Story → Issue`
-     - Story-level: `User Story → Issue → Task`
-     - Task-level: `Task → Issue`
-     - Defect-level: `Bug → Issue → Task`
-   - If `tracking_mode=external` and `external_provider=github`, collect the repo (`{owner}/{repo}`, resolve from `git remote get-url origin`; ask if ambiguous) and, if the PRD's scope is known to need one, an existing issue number. GitHub Issues has no configurable work-item-type hierarchy the way ADO does — see [governance/development-methodology.md](../../.arcane/governance/development-methodology.md) → **GitHub Issues Conventions** for the labels-and-task-list substitute.
-   - If `external_provider=jira` or `other`, record as TODO and continue with internal artifacts unless the operator provides explicit provider workflow steps.
-
-2. **Gather requirements** — accept input from any of these sources:
-
-   | Source | Format | How to fetch |
-   |--------|--------|--------------|
-   | **Description in prompt** | Inline text | Use as-is |
-   | **ADO work item ID** (external/ado mode) | `#507` or `507` with org name | Run: `az boards work-item show --id {id} --org https://dev.azure.com/{org} --output json` and extract `System.Description`, `Microsoft.VSTS.Common.AcceptanceCriteria`, and `System.Title` |
-   | **GitHub issue number** (external/github mode) | `#42` or `42` | Run: `gh issue view {id} --json title,body,labels` and extract `title` and `body` as the feature description |
-   | **File path** | Path to existing doc | Read the file |
-
-   If the input is an ADO work item ID or a GitHub issue number, fetch its content first, then use it as the feature description. If it has child work items (ADO) or a task-list of related issues (GitHub — see governance's GitHub Issues Conventions), fetch those too for additional context.
-
-   Ask clarifying questions if the feature description is ambiguous. You need to understand:
-   - What problem does this solve?
-   - Who is the user/audience?
-   - What business does this belong to?
-   - Are there existing ADRs or constraints?
-   - **If `tracking_mode=external` and `external_provider=ado`: What is the ADO work item ID?** — required before proceeding in ADO mode. Store it as `adoWorkItemId` in PRD frontmatter so it flows to `spell-architect` and `stories.json`.
-   - **If `tracking_mode=external` and `external_provider=github`: What is the GitHub issue number, if one already exists?** — optional (unlike ADO, a PRD doesn't require a pre-existing issue); store it as `githubIssueId` in PRD frontmatter when known.
-
-3. **Research context** — check the relevant business docs under `{BUSINESS_ROOT}/` (resolve from `.arcane.json`'s `business_root` field, default `ventures/` if unset) and any existing code repos.
-
-4. **Generate PRD.md** with these sections:
-   ```markdown
-   # PRD: [Feature Name]
-
-   ---
-   tracking:
-     tracking_mode: [internal|external]
-     external_provider: [ado|github|jira|other|null]
-     adoWorkItemId: [number|null]
-     githubIssueId: [number|null]
-   ---
-
-   ## Problem Statement
-   [What problem are we solving? Why now?]
-
-   ## Target Users
-   [Who benefits? Which business?]
-
-   ## Requirements
-   ### Must Have
-   - [Requirement with acceptance criteria]
-
-   ### Should Have
-   - [Requirement with acceptance criteria]
-
-   ### Won't Have (this iteration)
-   - [Explicitly excluded scope]
-
-   ## Constraints
-   - [Technical: frameworks, platforms, existing architecture]
-   - [Business: budget, timeline, dependencies]
-   - [Security: per threat model]
-
-   ## Acceptance Criteria
-   - [ ] [Testable criterion 1]
-   - [ ] [Testable criterion 2]
-
-   ## Dependencies
-   - [Other features, services, or decisions needed]
-
-   ## Open Questions
-   - [Unresolved items that need human decision]
-   ```
-
-   Include an **example config snippet** when presenting the draft:
-   ```yaml
-   tracking:
-     tracking_mode: external
-     external_provider: ado
-     adoWorkItemId: 541
-   ```
-
-5. **Validate against existing ADRs** — ensure the PRD doesn't contradict established decisions.
-
-6. **Save to disk** — derive the feature folder from the tracking configuration and slugified feature name, then write the PRD:
-   ```bash
-   # external/ado example: adoWorkItemId=541, feature name="Phase 2A" → slug="phase-2a"
-   # FEATURE_DIR="features/{adoWorkItemId}-{slug}"
-
-   # external/github example: githubIssueId=42, feature name="Phase 2A" → slug="phase-2a"
-   # FEATURE_DIR="features/{githubIssueId}-{slug}"
-
-   # internal or a provider without a known issue ID:
-   # FEATURE_DIR="features/{slug}"
-   mkdir -p "$FEATURE_DIR"
-   # Write PRD.md to the feature folder
-   ```
-   Save the generated PRD.md using:
-   - `features/{adoWorkItemId}-{slug}/PRD.md` when `tracking_mode=external` and `external_provider=ado`
-   - `features/{githubIssueId}-{slug}/PRD.md` when `tracking_mode=external`, `external_provider=github`, and a `githubIssueId` is known
-   - `features/{slug}/PRD.md` otherwise (internal mode, or an external provider without a known issue ID)
-   Confirm the resolved path to the user.
-
-7. **Present for review** — show the PRD to the user for approval before proceeding to `spell-architect`.
-
-8. **Provider TODO handling** — if `external_provider=jira` or `external_provider=other`, add a TODO note in PRD open questions that provider-specific automation/linking is pending. `github` does not need this — it has a real, working flow (Step 1 above).
-
-Rules:
-- Every requirement must have at least one testable acceptance criterion.
-- Scope must be small enough for one sprint (1-2 weeks of agent work).
-- If the scope is too large, recommend splitting into multiple PRDs.
-- Flag any requirements that would need a new ADR decision.
+This prompt is the Arcane `spell-plan` spell. Read [`.arcane/spells/spell-plan.md`](../../.arcane/spells/spell-plan.md) and follow it as the complete workflow.

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

@@ -6,184 +6,4 @@ argument-hint: '[summary|deck] + optional audience/size — e.g., "for investors
 agent: agent
 ---
 
-See [[.arcane/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 |
-| `.github/agents/*.agent.md` | Agent lineup and capability tiers | Present the system generically if no generated agent files exist |
-| [agents/agent-policies.md](../../.arcane/governance/agent-policies.md) | Power levels, autonomy model | [[.arcane/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](../../.arcane/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 [[.arcane/governance/agent-policies]] / [[.arcane/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.
-
+This prompt is the Arcane `spell-present-arcane` spell. Read [`.arcane/spells/spell-present-arcane.md`](../../.arcane/spells/spell-present-arcane.md) and follow it as the complete workflow.

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

@@ -6,93 +6,4 @@ argument-hint: Feature or product area to review (e.g., "{BUSINESS_NAME} storefr
 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](../../.arcane/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.
+This prompt is the Arcane `spell-product-review` spell. Read [`.arcane/spells/spell-product-review.md`](../../.arcane/spells/spell-product-review.md) and follow it as the complete workflow.

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

@@ -6,108 +6,4 @@ argument-hint: '--prs <n,n,…> | --pr <n> | --file <path> | --query <q>  [--rep
 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.
-4. **Post the formal round state per PR** — apply `spell-review`'s step 10 (ARC-035 decision 3 — cited as plain text, not linked; see `agent-output.instructions.md` → Doc-ID Link Format) to *this* PR's number, not just this workflow's own single-run PR: a **request-changes** verdict posts `gh pr review <n> --request-changes` (or `az repos pr set-vote --id <n> --vote reject`); a re-review that clears a round this batch previously blocked dismisses/supersedes that prior review. An **approve** verdict posts nothing. Never let a posting failure (unauthenticated CLI, PR closed mid-batch) skip or abort the remaining PRs in the batch — record the result already computed and continue.
-
-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]({url}) | repo | …     | approve / request-changes | 0 | 1 | 2 |
-| [#n]({url}) | repo | …     | SKIPPED — {reason}        | —  | —  | —  |
-
-## Per-PR detail
-### [PR #n]({url}) — {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.
-
-**Gate flowchart** — per the generated state diagrams convention (rule 8, ARC-036), built only from
-the verdict already computed per PR above; skip entirely (the applicability guard) for a batch of one
-PR — there is nothing to aggregate:
-
-```mermaid
-flowchart LR
-   PR1["PR #n<br/>approve"] --> Gate{Gate}
-   PR2["PR #n<br/>request-changes"] --> Gate
-   Gate --> Verdict[GO]
-```
-
-One node per PR in the batch, labeled with its number and verdict exactly as computed in the table
-above (including `SKIPPED`); the gate node's outcome is the same GO/NO-GO already derived. Never use
-the bare lowercase word `end` as a node label — Mermaid's flowchart parser reserves it and will fail
-to render (verified against Mermaid's own flowchart syntax docs; none of this batch's real labels
-collide, but a PR title inserted verbatim as a label could).
-
-## 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.
+This prompt is the Arcane `spell-review-batch` spell. Read [`.arcane/spells/spell-review-batch.md`](../../.arcane/spells/spell-review-batch.md) and follow it as the complete workflow.