arcane-cli 0.39.0 → 1.1.0

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

@@ -6,137 +6,4 @@ 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 [[.arcane/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](../../.arcane/governance/development-methodology.md) — Adversarial review requirements
-- [governance/testing-standards.md](../../.arcane/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.
-
-10. **Post the formal round state** (ARC-035 decision 3 — Arcane's own framework decision, cited as plain text, not linked, since this file ships; see `agent-output.instructions.md` → Doc-ID Link Format) — step 9's write-back is a human-readable summary; this is the separate, machine-readable signal the `Review round clear` required check actually reads. Only a confirmed blocker posts a formal review — an `APPROVE` or `DEFER` verdict posts nothing here, preserving the zero-friction path for PRs nobody formally blocks:
-    - **REQUEST CHANGES verdict:**
-      - GitHub: `gh pr review <n> --request-changes --body "<one-line blocker summary + pointer to the saved report>"`.
-      - Azure DevOps: `az repos pr set-vote --id <n> --vote reject` — the same primitive `spell-commit-work.prompt.md`'s author-side self-approval step already uses (`az repos pr set-vote --vote approve`), applied to the reviewer side.
-    - **Closing a round you previously blocked** (a later pass confirms the blocker is fixed) — do this explicitly; `dismiss_stale_reviews_on_push` is `false` on this repository's ruleset, so a later push never clears it automatically:
-      - GitHub: find the blocking review's ID (`gh api repos/{owner}/{repo}/pulls/<n>/reviews --jq '.[] | select(.state=="CHANGES_REQUESTED") | .id'`), then dismiss it — `gh api -X PUT repos/{owner}/{repo}/pulls/<n>/reviews/<review_id>/dismissals -f event=DISMISS -f message="<why this is now resolved, referencing the fix commit>"`.
-      - Azure DevOps: `az repos pr set-vote --id <n> --vote approve` (or reset to no-vote per team convention).
-    - Degrade silently if the CLI is unauthenticated or the PR can't be resolved (e.g. no PR exists yet for a local-only review) — never let this step abort a review that otherwise completed; the findings, report, and step 9 write-back still stand on their own.
-    - **GitHub refuses a REQUEST CHANGES verdict from the PR's own author** (`GraphQL: Review Can not request changes on your own pull request`, verified live 2026-08-31 — the same restriction as self-approval, just previously untested). When you are reviewing your own authored PR under the same GitHub identity, this call will fail with exactly that error: treat it as expected, not a bug, and fall back to the step 9 write-back as the only signal available — a formal blocking review needs a genuinely distinct reviewer identity (a second collaborator, or a separate bot/service account).
-
-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.
+This prompt is the Arcane `spell-review` spell. Read [`.arcane/spells/spell-review.md`](../../.arcane/spells/spell-review.md) and follow it as the complete workflow.

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

@@ -6,112 +6,4 @@ argument-hint: The idea itself — a sentence to a couple of paragraphs (e.g., "
 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`; in a hub, promote with `spell-manifest`.
-- This is the lightweight counterpart to `spell-document` (which formalizes a whole conversation into polished docs).
-- **In a hub repo:** "save this idea for <venture>" targets that venture's own `IDEAS.md` book instead of the hub root — private by default, including for ventures whose own repo is public.
-
----
-
-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 0 — Venture Targeting (Hub Only)
-
-Resolve `{BUSINESS_ROOT}` from `.arcane.json`'s `business_root` field (default `ventures/` if unset) before anything below.
-
-If the input names a venture ("save this idea for ordo", `--venture <slug>`), resolve it through `{BUSINESS_ROOT}/registry.json`'s aliases first (exact slug → alias → closest match offered — never guessed). Unknown slug:
-
-```
-No venture "<slug>" under {BUSINESS_ROOT}/ (closest: ordovica, tidewright).
-1) use <closest>  2) save to hub root IDEAS.md  3) cancel (create the venture first: spell-summon-venture)
-```
-
-Never silently create a venture folder.
-
-If `role` in `.arcane.json` is not `"hub"`, venture-targeting phrasing is refused:
-
-```
-Venture targeting works only in the hub repo (role: "hub" in .arcane.json). This repo has no venture books.
-1) save to this repo's IDEAS.md (venture reference removed)
-2) skip — capture it in the hub: spell-save-idea --venture <slug> "<idea>"
-Which? (1/2)
-```
-
-If option 1 is chosen and the named venture is a *different* venture than this repo's own, strip that name from the idea text before writing it — a sibling venture's name must never land in a consumer repo's `IDEAS.md`. If it's this repo's own venture, keep the text as given.
-
-An idea that only *mentions* a venture, without targeting phrasing, is not redirected — proceed with the hub root and append a non-blocking hint to the Step 3 confirmation instead (speed rule: don't block on a maybe):
-
-```
-(mentions ordovica — re-save with --venture ordovica, or route it later with spell-manifest)
-```
-
-When targeting a venture book that doesn't exist yet as a file, create it from the venture-template `IDEAS.md` stub (same header convention as the hub root, below) with the venture's name filled in. Tolerate operator YAML frontmatter above either book's header — always append after the final `---` divider, never before it.
-
-## 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` — the repo root, or the resolved venture's own book from Step 0.
-
-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). In a hub, `spell-manifest` promotes it downstream once ready.
-
-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.
+This prompt is the Arcane `spell-save-idea` spell. Read [`.arcane/spells/spell-save-idea.md`](../../.arcane/spells/spell-save-idea.md) and follow it as the complete workflow.

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

@@ -6,261 +6,4 @@ argument-hint: "Path to PRD or paste PRD content (e.g., 'Analyze PRD.md for {BUS
 agent: agent
 ---
 
-## Executive Summary
-
-- This spell takes a PRD of any size and produces an actionable execution plan.
-- It assesses scope, splits into sprint-sized epics, identifies architecture/security decisions needed, and maps agents to work.
-- Use this before `spell-architect` when the PRD is too large for a single Spell Loop cycle. (Formerly `spell-assess`.)
-- Output: `execution-plan.md` — ordered epics with dependency graph, risk flags, ADR candidates, and agent assignments.
-
----
-
-Analyze the provided PRD and produce a scoped execution plan.
-
-Use these files for context. Each is optional — if a file is missing, proceed with the stated fallback and note the gap in the output's Open Questions:
-
-- [governance/development-methodology.md](../../.arcane/governance/development-methodology.md) — Spell Loop methodology, story sizing rules, and the canonical **ADO Hierarchy Rules**. *Fallback: if missing, use the default sizing of 4–8 right-sized stories per cycle described below and skip external-tracker hierarchy mapping.*
-- [governance/testing-standards.md](../../.arcane/governance/testing-standards.md) — Testing frameworks per stack. *Fallback: if missing, flag test strategy as an open question.*
-- [governance/cicd-standards.md](../../.arcane/governance/cicd-standards.md) — Pipeline requirements. *Fallback: if missing, omit pipeline considerations.*
-- [DECISIONS.md](../../DECISIONS.md) — Existing ADRs to check against. *Fallback: if missing, treat all architecture decisions as new candidates.*
-- [security/threat-model.md](../../security/threat-model.md) — Active threat model. *Fallback: if missing, apply OWASP Top 10 as the baseline.*
-- [agents/agent-policies.md](../../.arcane/governance/agent-policies.md) — Agent roster, power levels, capabilities. *Fallback: if missing, assign work by role label (architecture, backend, frontend, mobile, QA, DevOps, research) instead of named personas.*
-- [naming-conventions.md](../../.arcane/governance/naming-conventions.md) — Agent roster and role-to-persona mapping. *Fallback: if missing, refer to roles by their generic label.*
-- [project.md](../../project.md) — Project goals and business context. *Fallback: if missing, derive context from the PRD itself.*
-- [governance/product-excellence-standards.md](../../.arcane/governance/product-excellence-standards.md) — PRD Quality Scorecard and scoring rubric. *Fallback: if missing, skip the Quality Quick-Check (section 1.5) and note that it was skipped.*
-
-> **Roster by reference.** This spell maps work to **roles** (architecture, backend, frontend, mobile, QA, DevOps, research, marketing). Resolve each role to a concrete agent persona via `agents/agent-policies.md` / `naming-conventions.md` at run time — do not assume a fixed set of persona names.
-
-> **Placeholder resolution.** `{ADO_ORG}`, `{ADO_PROJECT}`, `{BUSINESS_NAME}`, and any other `{UPPER_SNAKE}` token resolve from `.arcane.json` or the PRD frontmatter; if a value is unset, ask rather than assuming a default.
-
----
-
-## Workflow
-
-### 1. PRD Intake
-
-Accept the PRD from one of these input sources:
-
-| Source | Format | How to fetch |
-|--------|--------|--------------|
-| **File path** | `PRD.md` or any markdown file | Read the file directly |
-| **Pasted content** | Inline text in the prompt | Use as-is |
-| **External tracker work item ID** (external mode) | `#507` or `507` with org name | Detect the provider (see tracking settings below) and fetch the item's title, description, and acceptance criteria via that provider's CLI/API. For ADO: `az boards work-item show --id {id} --org https://dev.azure.com/{ADO_ORG} --output json` and extract `System.Description`, `Microsoft.VSTS.Common.AcceptanceCriteria`, and `System.Title` |
-
-If the input is an external work item ID:
-1. Confirm the org/account: `{ADO_ORG}` — resolve from `.arcane.json` / PRD frontmatter; ask if unset.
-2. Fetch the item via the detected provider (for ADO: `az boards work-item show`).
-3. If the work item has child items, fetch those too — they may contain additional requirements.
-4. Combine all content into a single PRD view before proceeding.
-
-Resolve tracking settings from PRD frontmatter (preferred) or ask:
-<!-- fragment:tracking-mode-declaration:start -->
-- `tracking_mode: internal | external`
-- `external_provider: ado | github | jira | other`
-<!-- fragment:tracking-mode-declaration:end -->
-
-If unset and ADO context already exists, default to `external` + `ado` for backward compatibility.
-
-If `tracking_mode=external` and `external_provider=ado`, resolve template/type availability before splitting epics (resolve `{ADO_ORG}` / `{ADO_PROJECT}` from `.arcane.json` / PRD frontmatter; ask if unset):
-```bash
-az devops project show --org https://dev.azure.com/{ADO_ORG} --project {ADO_PROJECT} --query "capabilities.processTemplate.templateName" --output tsv
-az boards work-item-type list --org https://dev.azure.com/{ADO_ORG} --project {ADO_PROJECT} --output json --query "[].name"
-```
-For non-ADO providers, detect the provider from `external_provider` and resolve its equivalent item types instead.
-
-Read the full PRD. Extract:
-- **Feature name** and business context
-- **Target repo** and tech stack
-- **Total requirement count** (Must Have / Should Have / Won't Have)
-- **Total acceptance criteria count**
-- **Dependencies** on external services, APIs, or decisions
-
-### 1.5. Quality Quick-Check
-
-Before proceeding to scope assessment, run a quick quality audit against the PRD Quality Scorecard in `governance/product-excellence-standards.md`. Score each dimension (Requirements, UX, Accessibility, Performance, Security, Responsive, Competitive) as Bronze / Silver / Gold.
-
-If any dimension scores **Bronze**, recommend:
-> 💡 **Quality recommendation:** This PRD scores Bronze on [dimensions]. Consider running `spell-enchant` to enhance the PRD before continuing with assessment and architecture. `spell-enchant` will conduct competitive research (research role) and marketing review (marketing role), and proactively add missing quality requirements.
-
-This is a recommendation, not a gate — the user decides whether to enchant first or proceed directly. Include the scorecard results in the execution plan output regardless.
-
-### 2. Scope Assessment
-
-Evaluate the PRD against Spell Loop sizing rules:
-- Each Spell Loop cycle = **1-2 weeks of agent work** = **4-8 right-sized stories**
-- A right-sized story: one file change, one endpoint, one component, one migration
-- Flag anything that violates story sizing: "Build the entire dashboard", "Add authentication", "Refactor the API layer"
-
-Classify the PRD:
-
-| Classification | Criteria | Action |
-|---------------|----------|--------|
-| **Single cycle** | ≤ 8 stories, no cross-cutting concerns | Proceed directly to `spell-architect` |
-| **Multi-cycle** | 9-30 stories, clear epic boundaries | Split into epics, each gets its own Spell Loop run |
-| **Program-scale** | 30+ stories, multiple subsystems, cross-team concerns | Split into phases with milestone gates between them |
-
-### 3. Epic Splitting (if multi-cycle or program-scale)
-
-Break the PRD into epics. Each epic must be:
-- **Self-contained** — shippable independently (no half-built features)
-- **Sprint-sized** — 4-8 stories per epic
-- **Dependency-ordered** — infrastructure before API before UI before polish
-
-For each epic, define:
-```markdown
-### Epic N: [Name]
-**Stories (estimated):** [count]
-**Dependencies:** [prior epics or external]
-**Tech stack:** [frameworks, platforms]
-**Primary role:** [backend / frontend / mobile / full-stack — resolve to a persona via `agent-policies` / `naming-conventions`]
-**Risk level:** Low / Medium / High
-**Sprint estimate:** [1 or 2 cycles]
-```
-
-### 3.5. External Tracker Mapping (external mode)
-
-Only applies when `tracking_mode=external`. Skip entirely for internal mode.
-
-Do **not** inline the work-item-type fallback order or the parent/child linkage rules here — they are the single source of truth in [governance/development-methodology.md](../../.arcane/governance/development-methodology.md), under **Process-Template-Aware ADO Hierarchy Rules** (`external_provider=ado`) or **GitHub Issues Conventions** (`external_provider=github`). Detect the provider from `external_provider`, then apply the matching section's rules. *Fallback: if that doc is missing, record the tracker mapping as an Open Question and proceed without item-type assignment.*
-
-Scope-specific delta (the only thing this spell adds on top of those rules): each split **epic** maps to the **Epic-level** logical level — use the `Epic` work item type whenever the resolved provider/template offers it, and record the selected type per epic in `execution-plan.md`. All lower-level and linkage decisions defer to the governance rules above.
-
-### 4. Architecture Decision Check
-
-Scan the PRD for decisions that need ADRs:
-- New frameworks or libraries not already in the stack
-- New external service integrations (APIs, databases, auth providers)
-- Data model changes that affect multiple subsystems
-- Deployment topology changes
-- New communication patterns (sync vs async, REST vs gRPC vs events)
-
-For each candidate:
-```markdown
-#### ADR Candidate: [Title]
-**Trigger:** [What in the PRD requires this decision]
-**Options:** [2-3 alternatives]
-**Recommendation:** [If obvious, state it; otherwise flag for the architecture role]
-**Blocking:** [Which epics are blocked until this is decided]
-```
-
-### 5. Security Review
-
-Check the PRD against the threat model:
-- Does this feature introduce new attack surface? (new endpoints, new auth flows, new data stores)
-- Does it handle PII, payment data, or secrets?
-- Does it change trust boundaries? (new external integrations, new user roles)
-- Are there OWASP Top 10 concerns? (injection points, auth gaps, data exposure)
-
-For each concern:
-```markdown
-#### Security Flag: [Title]
-**Threat:** [What could go wrong]
-**Mitigation required:** [What the implementation must include]
-**Blocking:** [yes/no — can the epic proceed without resolving this?]
-```
-
-### 6. Agent Assignment
-
-Map each epic to the right **role**, then resolve each role to a concrete agent persona via `agents/agent-policies.md` / `naming-conventions.md` (fallback: keep the generic role label if the roster files are absent):
-
-| Role | When |
-|------|------|
-| Architecture | ADR candidates, cross-epic design decisions |
-| Backend / Full-stack | APIs, databases, server-side logic |
-| Frontend / UI | Web UI, component frameworks |
-| Mobile | Native/cross-platform mobile apps |
-| QA | Test strategy, coverage validation |
-| DevOps | Pipeline creation, deployment config |
-| Research | Unknowns, technology evaluation, competitive analysis |
-| Marketing | User-facing copy, landing pages, SEO |
-
-Flag any epics that need **multiple roles** (e.g., a full-stack feature = backend + frontend + QA).
-
-### 7. Dependency Graph
-
-Produce a Mermaid diagram (per rule 8) showing epic execution order — an agent-authored planning diagram, not the generated-state-diagrams sub-convention ARC-036 covers, since the ordering is this spell's own design output rather than already-computed state:
-
-```mermaid
-flowchart LR
-    E1[Epic 1: Infrastructure] --> E2[Epic 2: API Layer]
-    E2 --> E3[Epic 3: Web UI]
-    E2 --> E4[Epic 4: Mobile App]
-    E3 --> E5[Epic 5: Integration Tests]
-    E4 --> E5
-```
-
-Identify:
-- **Critical path** — the longest dependency chain
-- **Parallelizable epics** — epics that can run simultaneously on different branches
-- **Milestone gates** — points where human review is needed before continuing
-
-### 8. Execution Plan Output
-
-Produce `execution-plan.md` with this structure:
-
-```markdown
-# Execution Plan: [Feature Name]
-
-## PRD Summary
-- **Source:** [PRD file or inline]
-- **Business:** [which business]
-- **Target repo:** [org/repo]
-- **Classification:** Single cycle / Multi-cycle / Program-scale
-- **Total epics:** [N]
-- **Total estimated stories:** [N]
-- **ADR candidates:** [N]
-- **Security flags:** [N]
-
-## Dependency Graph
-[Mermaid diagram]
-
-## Epics
-
-### Epic 1: [Name]
-- **Stories:** [estimated count]
-- **Agent:** [primary]
-- **Dependencies:** none
-- **Tracking item:** [internal-only OR external provider + type/id]
-- **Risk:** Low/Medium/High
-- **Notes:** [any special considerations]
-
-### Epic 2: [Name]
-...
-
-## Architecture Decisions Required
-[List of ADR candidates with recommendations]
-
-## Security Flags
-[List of security concerns with mitigations]
-
-## Recommended Execution Order
-1. Resolve ADR candidates (architecture role)
-2. Epic 1 — spell-full-cycle or spell-architect → spell-implement → spell-ship
-3. Run spell-commit-work to checkpoint major outputs before starting Epic 2
-4. Epic 2 — ...
-5. [milestone gate if needed]
-6. Epic N — ...
-
-## Open Questions
-[Anything that needs human decision before execution can start]
-```
-
-If `external_provider=jira` or `external_provider=other`, add explicit TODOs in Open Questions for provider-specific type mapping and linkage automation.
-
-### 9. Present and Confirm
-
-Present the execution plan to the user. Ask:
-1. Does the epic split make sense?
-2. Are the ADR candidates correct? Should any be decided now?
-3. Are there epics that should be deprioritized or cut?
-4. Ready to start with Epic 1?
-
----
-
-## Rules
-
-- **Never start implementation from this spell.** This spell produces a plan, not code. The output feeds into `spell-architect` or `spell-full-cycle`.
-- **Be honest about unknowns.** If the PRD references technology or services you don't have context on, flag it as a research item for the research role.
-- **Respect existing ADRs.** If the PRD proposes something that contradicts an existing ADR, flag the conflict — don't silently override.
-- **Conservative estimates.** When in doubt, split smaller. Two small epics are better than one that's too big.
-- **Security is non-negotiable.** If a security flag is blocking, it blocks. No "we'll add auth later."
+This prompt is the Arcane `spell-scope` spell. Read [`.arcane/spells/spell-scope.md`](../../.arcane/spells/spell-scope.md) and follow it as the complete workflow.

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

@@ -6,119 +6,4 @@ argument-hint: '<candidate name or term>'
 agent: agent
 ---
 
-## Executive Summary
-
-- This spell clears a candidate name before it ships, checking both the outside world and this
-  repository itself.
-- The inward pass runs first and is mandatory, not optional — a real naming decision (ARC-028's
-  `workspace`) was nearly settled on a clean external read alone, until a single `grep -ri` found the
-  word already load-bearing inside the repository in two other senses.
-- Both passes classify hits with the same taxonomy (same-space / adjacent / out-of-space) and combine
-  into one verdict: pass / pass-with-disclosure / kill.
-- `spell ward` is the opposite direction of this same concern — it finds what leaked **in**; this spell
-  clears what's about to go **out**. They do not call each other; ward's denylist scanning and scry's
-  single-candidate classification are different operations on the same underlying grep primitive.
-
----
-
-Clear the candidate name given in the prompt argument.
-
-## Step 1 — Resolve the candidate
-
-Take the term verbatim from the argument. If none was given, ask for it — do not guess a name to check.
-
-## Step 2 — Inward pass (mandatory, run first)
-
-Grep this repository for the candidate term before doing any outward research:
-
-- **Prose**: markdown, comments, documentation.
-- **Identifiers**: variable, function, type, and class names — weight these **above** prose, since
-  consumers already depend on code identifiers in a way they never depend on a sentence mentioning a
-  word.
-- **Config keys and schema fields**: `.arcane.json` fields, YAML/JSON config keys, any validated schema.
-
-Use word-boundary matching (the same principle `spell ward`'s denylist scan uses, expressed here as a
-`grep -w` / IDE-search equivalent over the codebase) — a bare substring match on a short candidate term
-will drown in false positives from unrelated words that merely contain it.
-
-**Classify each internal hit with the same taxonomy the outward checks use below:**
-
-- **Same-space**: the term is already load-bearing for a closely related concept (a config field, a
-  directory name, a class doing adjacent work) — a genuine internal collision.
-- **Adjacent**: the term appears near the concept but for something distinguishable enough that a
-  reader would not confuse the two once told them apart.
-- **Out-of-space**: incidental — a comment, an unrelated variable, coincidental substring overlap.
-
-**Why this runs first:** a same-space internal collision is often cheaper to find than the outward
-research below, and finding one early can save the effort of a full outward pass on a name that was
-already going to be killed. This is not a formality — the ARC-028 `workspace` incident is the concrete
-case: a clean external read had nearly settled the decision before a single `grep -ri` found the word
-already meaning something else in two other places inside this exact repository.
-
-## Step 3 — Outward pass: the four checks
-
-Research the candidate term against the outside world:
-
-1. **Who coined it** — search for the term's origin and earliest known usage in the relevant space
-   (software, apps, AI, games — whichever applies to this candidate).
-2. **Is an estate/trademark holder still trading** — distinguish an actively-used, enforced brand from
-   an abandoned or long-defunct one. A defunct mark carries much less collision risk than a live one.
-3. **Same-audience giants** — do major, well-known players who share this candidate's actual target
-   audience already use this name saliently? A collision with a giant outside the target audience
-   matters far less than one inside it.
-4. **First-association salience per market** — for someone in the target market, what does this term
-   bring to mind *first*? If the first association is something else entirely, that is a real cost even
-   without a formal trademark conflict.
-
-Classify each outward finding with the **same** same-space / adjacent / out-of-space taxonomy as the
-inward pass — never a separate scheme. Cite sources for every outward claim; do not assert a name's
-history or salience from unverified general knowledge alone.
-
-## Step 4 — Combine into one verdict
-
-A name that clears outward but collides inward is not a clean pass, and the reverse is equally true —
-combine both passes into a single verdict, not two separate reports:
-
-- **pass** — no same-space finding, inward or outward; adjacent/out-of-space findings, if any, are
-  noted but do not block.
-- **pass-with-disclosure** — a same-space finding exists but is distant, low-traffic, or otherwise minor
-  enough that proceeding is reasonable with the collision stated explicitly, not discovered later.
-- **kill** — a genuine, blocking same-space collision, inward or outward. Do not soften this to
-  pass-with-disclosure merely because the outward research took effort to produce.
-
-## Step 5 — Report
-
-```markdown
-## Scry verdict: <candidate> — PASS | PASS-WITH-DISCLOSURE | KILL
-
-### Inward pass
-| Hit | Location | Classification |
-|---|---|---|
-| <term usage> | <file:line> | same-space / adjacent / out-of-space |
-
-### Outward pass
-| Check | Finding | Classification | Source |
-|---|---|---|---|
-| Who coined it | ... | ... | <url or citation> |
-| Estate still trading | ... | ... | <url or citation> |
-| Same-audience giants | ... | ... | <url or citation> |
-| First-association salience | ... | ... | <url or citation> |
-
-### Verdict rationale
-<why this combination of inward + outward findings produced this verdict>
-```
-
-## Related Spells
-
-- `spell ward` — the opposite direction: finds third-party identifiers that already leaked into the
-  repo, rather than clearing a candidate before it ships out.
-
-## Rules
-
-- **Never skip the inward pass.** It is not optional, and it runs before the outward pass, not after.
-- **Never assert an outward finding without a source.** "Based on general knowledge" is not a citation.
-- **Never use a separate classification scheme for inward vs. outward findings.** Same-space / adjacent
-  / out-of-space applies to both, so a reader can compare them directly.
-- **Never round pass-with-disclosure up to pass, or down to kill, to avoid stating a nuanced verdict.**
-- This spell classifies and reports. It does not rename, alias, or otherwise resolve a collision it
-  finds — that decision belongs to whoever asked for the name cleared.
+This prompt is the Arcane `spell-scry` spell. Read [`.arcane/spells/spell-scry.md`](../../.arcane/spells/spell-scry.md) and follow it as the complete workflow.