arcane-cli 0.39.0 → 1.0.0

package/dist/assets/.github/prompts/spell-full-cycle.prompt.md

@@ -6,248 +6,4 @@ argument-hint: "Feature description, optional work item ID, target repo (e.g., '
 agent: agent
 ---
 
-## Executive Summary
-
-- This prompt chains all Spell Loop phases into a single autonomous pipeline.
-- Includes optional PRD enchantment (spell-enchant) between Plan and Architect for quality enhancement.
-- Only one human touchpoint: approving the PR at ship time.
-- Delegates each phase to the appropriate specialized agent role (research, architecture, build, QA, marketing review) — **in practice, a single agent switches hats per phase** unless a real per-tool subagent registry is configured (e.g. `.claude/agents/` for Claude Code); this framework ships no such registry by default, so "delegates" names the intended role model, not a literal handoff between separately running agents (2026-07-22 dogfooding finding). Resolve concrete personas from [agent-policies](../../.arcane/governance/agent-policies.md) / [naming-conventions](../../.arcane/governance/naming-conventions.md); if neither is present, proceed with role names directly.
-- If any phase fails, the pipeline halts and reports the blocker — no silent failures.
-
----
-
-Run the complete Spell Loop end-to-end for the described feature.
-
-Use these files for context:
-
-- [governance/development-methodology.md](../../.arcane/governance/development-methodology.md) — Spell Loop methodology and stories.json format
-- [governance/testing-standards.md](../../.arcane/governance/testing-standards.md) — Testing frameworks and coverage requirements
-- [governance/cicd-standards.md](../../.arcane/governance/cicd-standards.md) — CI/CD pipeline and deployment gates
-- [governance/git-conventions.md](../../.arcane/governance/git-conventions.md) — Branch discipline and commit format
-- [project.md](../../project.md) — Project goals and priorities
-- [DECISIONS.md](../../DECISIONS.md) — Existing ADRs to respect
-- [governance/product-excellence-standards.md](../../.arcane/governance/product-excellence-standards.md) — PRD Quality Scorecard for enchantment
-
----
-
-## Required Inputs
-
-Before proceeding, confirm you have all three:
-
-1. **Feature description** — what to build and why. Accepted formats:
-   - Inline text in the prompt
-   - Path to a PRD file (e.g., `PRD.md`)
-   - **Tracker work item ID** (e.g., `#507`) in `external` mode — fetch it using the detected provider's CLI/API. For an ADO provider, fetch via `az boards work-item show --id {id} --org https://dev.azure.com/{ADO_ORG} --output json` and extract `System.Title`, `System.Description`, and `Microsoft.VSTS.Common.AcceptanceCriteria`; for other providers, fetch the title, description, and acceptance criteria via that provider's equivalent. If the work item has child items, fetch those too. `{ADO_ORG}` resolves from `.arcane.json` or the PRD/feature frontmatter; ask if unset.
-2. **Tracking configuration** — required before execution:
-   <!-- fragment:tracking-mode-declaration:start -->
-   - `tracking_mode: internal | external`
-   - `external_provider: ado | github | jira | other`
-   <!-- fragment:tracking-mode-declaration:end -->
-   - (`external_provider` is required when `tracking_mode=external`)
-   - If omitted and an ADO context is already present, default to `external` + `ado` (backward compatibility).
-   - If `tracking_mode=external` and `external_provider=ado`, an `adoWorkItemId` is required for commit/PR linkage.
-   - If `tracking_mode=external` and `external_provider=github`, a `githubIssueId` is used for commit/PR linkage when one exists (optional, unlike ADO).
-   - In ADO mode, resolve available work item types and apply process-template-aware fallback mapping from `governance/development-methodology.md` before creating/linking hierarchy items. In GitHub mode, use that same doc's GitHub Issues Conventions (labels, not configurable types).
-3. **Target repo** — which repository and org (e.g., `{REPO_ORG}/{REPO_NAME}`). `{REPO_ORG}`/`{REPO_NAME}` resolve from `.arcane.json` or the PRD/feature frontmatter; if not provided, infer from context or ask.
-
-If `external_provider=jira` or `external_provider=other`, record TODO notes for provider-specific automation and continue with internal artifact flow unless explicit provider commands are supplied.
-
----
-
-## Pipeline Phases
-
-### Phase 1 — Plan
-
-Execute the `spell-plan` workflow:
-
-1. Gather requirements from the feature description.
-2. Check existing ADRs and business docs for constraints.
-3. **If the feature description hands in a pre-diagnosed root cause** (a specific file/line/mechanism already named as the cause of a bug), re-verify it against current source before accepting it — a handed-in diagnosis can be stale (2026-07-22 dogfooding finding: a filed root-cause lead was already fixed and the real causes were elsewhere). Do not carry a stale diagnosis into the PRD or stories unexamined.
-4. Produce `PRD.md` with requirements, acceptance criteria, constraints, and tracking configuration (`tracking_mode`, optional `external_provider`, optional `adoWorkItemId`/`githubIssueId`).
-5. **Gate:** Validate every requirement has at least one testable acceptance criterion. If scope is too large for one sprint, halt and recommend splitting.
-
-Store the PRD in the working directory. Proceed automatically to Phase 1.5.
-
-### Phase 1.5 — Enchant (Optional)
-
-Run a quick quality audit of the PRD against the scorecard in `governance/product-excellence-standards.md`. Score each dimension as Bronze / Silver / Gold.
-
-**Decision logic:**
-- If the user specified `--enchant` or explicitly requested enchantment: run `spell-enchant` workflow fully.
-- If any dimension scores Bronze: recommend enchantment, but proceed without it if the user hasn't requested it.
-- If all dimensions score Silver or above: skip enchantment and proceed to Phase 2.
-
-When running enchantment:
-1. Conduct the research role's analysis (competitive analysis, UX patterns, accessibility audit).
-2. Conduct the marketing-review role's pass (first impressions, brand alignment, onboarding).
-3. Generate enhancement suggestions (Must-Add / Should-Add / Could-Add / Won't-Add).
-4. Check scope budget — if enchanted scope exceeds 2× original, flag prominently.
-5. Produce the enhanced PRD, preserving all original requirements and tagging additions with `[ENCHANTED]`.
-6. Replace the working PRD with the enchanted version.
-
-**Gate:** If scope budget exceeds 2× and the user hasn't pre-approved, halt and ask for confirmation before proceeding.
-
-Proceed automatically to Phase 2.
-
-### Phase 2 — Architect
-
-Execute the `spell-architect` workflow:
-
-1. Read the PRD from Phase 1.
-2. Make architecture decisions (framework, patterns, component structure).
-3. Produce `architecture.md` with decisions, component diagram, and testing strategy.
-4. Produce `stories.json` with the full schema:
-   - Top-level: `feature`, `branchName`, `assignedAgent`, `trackingMode`, optional `externalProvider`, optional `adoWorkItemId`
-   - Per story: `id`, `title`, `description`, `acceptanceCriteria`, `priority`, `passes: false`, `assignedTo`, `testEvidence: null`
-5. **Gate:** Self-validate `stories.json` schema completeness. If any required field is missing, regenerate before proceeding. Every PRD requirement must map to at least one story. No story may depend on an unresolved Open Question.
-
-Proceed automatically to Phase 3.
-
-### Phase 3 — Implement (Autonomous Loop)
-
-Execute the `spell-implement` workflow:
-
-0. **Sync workspace** — before any code changes, ensure the workspace is current:
-   ```bash
-   git fetch --prune origin
-   git checkout main && git pull --ff-only
-   ```
-   If `pull --ff-only` fails, halt and report — manual rebase is needed.
-
-   **In a linked worktree, do not run the `checkout main` line** (ARC-028 R1/R8). It fails with `fatal: 'main' is already used by worktree at '<path>'` when another working tree holds `main`, and the halt instruction above only covers a `pull` failure — so an agent that runs it there has no branch to take. This matters especially here: the R4 rule below sends genuinely disjoint epics into parallel worktrees, so this pipeline reaches that state by design. Sync the remote-tracking ref instead:
-   ```bash
-   git fetch --prune origin        # origin/main is now current
-   ```
-   and branch from `origin/main` in step 1. Check which primitive you are in with `git rev-parse --path-format=absolute --git-common-dir` vs `--git-dir` — equal means primary checkout. `--path-format=absolute` is required, or every primary checkout looks like a worktree from any subdirectory.
-1. Create the topic branch from `stories.json.branchName` (format: `{agent}/type/description`).
-2. Loop:
-   a. Pick the next story where `passes: false`, ordered by priority.
-   b. Implement the story — minimum code to satisfy acceptance criteria.
-   b1. **DB migration guard.** If `architecture.md`/the PRD did not name a database migration as part of this feature's scope, but implementing this story is about to produce one anyway, **halt and flag it** — do not write the migration file silently (2026-07-22 dogfooding finding: this is a scoped hard guard, not a blanket ban). If a migration genuinely is in scope, **re-derive its sequence number from a fresh `git pull --ff-only` of the target branch immediately before writing the file** — not once at branch-creation time in step 0 — so a concurrent epic that landed a migration in the meantime is reflected. This is the concrete fix for a real incident: two epics run in parallel worktrees each independently claimed the same migration sequence number, invisible until human merge review.
-   c. Write tests per `governance/testing-standards.md`.
-   d. Run tests. If passing:
-      - In `external/ado` mode, commit with `#{adoWorkItemId} type(scope): description` and agent attribution trailers (`Agent`, `Model`, `Model-Source`, `Provider`).
-      - In `internal` mode, commit with standard Conventional Commits format (no ADO prefix) plus attribution trailers.
-   e. Update `stories.json`: set `passes: true`, fill `testEvidence`.
-   f. Append learnings to `progress.txt`.
-   g. Repeat until all stories pass or a story fails 3 consecutive attempts.
-3. **Gate:** If any story is stuck after 3 attempts, halt the pipeline and report the blocker with error details. Do not proceed to Phase 4 with failing stories.
-
-Proceed automatically to Phase 4.
-
-### Phase 4 — Test
-
-Execute the `spell-test` workflow:
-
-1. Run the full test suite (not just per-story — full regression).
-2. Validate coverage: 80% line minimum, 95% critical path.
-3. Map each acceptance criterion from the PRD to a specific passing test.
-4. **If this run produced a database migration:** a fresh/empty test database is not sufficient evidence by itself — this is a real incident's root cause (a unique index conflicted with legitimate duplicate rows the target app allows by design; every test passed against an empty DB, then broke the consumer's actual deploy). If the execution sandbox has access to a snapshot or copy of the target environment's real data, replay the migration against it and report the result. **If it does not** (the common case for an isolated sandbox), do not silently proceed as if this were validated — name the gap explicitly in the ship report's disclosure (see below) so a human reviews the migration against real data before it ships.
-5. Update `stories.json` with consolidated test evidence.
-6. **Gate:** If coverage is below threshold or any acceptance criterion lacks a test, loop back to Phase 3 to add missing tests. Maximum 2 coverage-fix loops before halting.
-
-Proceed automatically to Phase 5.
-
-### Phase 5 — Review (Adversarial)
-
-Execute the `spell-review` workflow:
-
-1. Review the full diff (`git diff main...HEAD`).
-2. Check architecture compliance against `architecture.md`.
-3. Check for OWASP Top 10 security issues.
-4. 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; never fabricate issues to hit one.
-5. Classify each real finding: HIGH / MEDIUM / LOW.
-6. **Gate:** If any HIGH severity finding exists, loop back to Phase 3 to fix it. MEDIUM and LOW findings are noted in the ship report but do not block. Maximum 2 review-fix loops before halting.
-
-Proceed automatically to Phase 6.
-
-### Phase 6 — Ship
-
-Execute the `spell-ship` workflow:
-
-1. Verify all prior phases passed (PRD, architecture, all stories, tests, review).
-1a. **PR strategy: one branch, one PR, per invocation.** This is the default and it is not optional to
-   restate per run — a 2026-07-22 dogfooding finding found this pattern had to be imposed by the
-   operator each time because the spell never stated it. If a later invocation would touch files an
-   earlier, still-open PR from a prior invocation already changed, do not open a second, conflicting PR
-   — rebase this branch onto the earlier PR's branch (or wait for it to merge, per this spell's own
-   multi-epic serialization default in the Rules section) before opening this one.
-2. Run pre-deploy checklist:
-   - No merge conflicts with target branch.
-   - No secrets or credentials in the diff.
-   - DECISIONS.md updated if new ADRs were created.
-   - Documentation updated for user-facing changes.
-3. Generate the ship report (phase status table, test evidence, review findings, recommendation).
-   **Mandatory disclosure section:** explicitly list anything this run could not verify in its own
-   execution sandbox — a real-data migration replay Phase 4 couldn't attempt, an external integration
-   it couldn't reach, a manual step it couldn't perform — never omit this section just because nothing
-   applies (state "Nothing withheld" in that case). Fold it into the consumer repo's own QA checklist
-   so a human reviewer sees exactly what still needs a human look, not just what passed (2026-07-22
-   dogfooding finding: honest disclosure of sandbox limits, not just of failures).
-4. Create the PR:
-   - `external/ado` mode: `az repos pr create --repository {repo} --source-branch {branch} --target-branch main --title "{feature}" --work-items {adoWorkItemId}`
-   - `internal` mode (or provider TODO mode): create PR without `--work-items`.
-5. **HUMAN GATE:** Present the ship report and PR link. Wait for explicit human approval bound to the exact PR ID and head SHA. This is separate from every earlier commit approval.
-6. **AUTHORITY GATE:** Resolve loader-validated effective power and `exec_allowed`. Below Magus or missing/invalid authority must visibly downgrade to human completion; do not invoke merge/auto-complete. Interactive Magus+ requires the separate approval from step 5; autonomous Magus+ may self-merge within approved scope.
-7. Only after both applicable gates pass: merge via the detected provider using the approved PR ID/head SHA and allowed merge strategy.
-8. Pull merge to local, delete the topic branch.
-
----
-
-## Error Handling
-
-- **Phase failure:** If any gate fails and exhausts its retry budget, halt immediately. Report which phase failed, what the error was, and what input is needed to unblock.
-- **Stuck story:** After 3 failed attempts on a single story, mark it in `stories.json` with the error and halt. Do not skip stories and continue — a failing story may indicate an architecture problem.
-- **Missing tooling:** If a required tool (test framework, SDK, CLI) is not installed, halt and report the prerequisite. Do not attempt to install system packages without confirmation.
-
----
-
-## Progress Reporting
-
-After each phase completes, output a brief status line:
-
-```
-[Phase 1/6 — Plan] COMPLETE — PRD.md generated (5 requirements, 8 acceptance criteria)
-[Phase 2/6 — Architect] COMPLETE — 4 stories in stories.json, branch: lafayette/feat/feature-name
-[Phase 3/6 — Implement] COMPLETE — 4/4 stories passing, 12 tests, 87% coverage
-[Phase 4/6 — Test] COMPLETE — full regression green, 87% line / 96% critical path
-[Phase 5/6 — Review] COMPLETE — 0 HIGH, 2 MEDIUM, 1 LOW findings
-[Phase 6/6 — Ship] AWAITING APPROVAL — PR #77 created, ship report below
-```
-
-**Pipeline state diagram** — per the generated state diagrams convention (rule 8, ARC-036), built only
-from the phase status this section already tracks; skip entirely (the applicability guard) after Phase
-1 alone, before any other phase has run — a single-state pipeline has nothing to show in relation to
-the rest. From Phase 2 onward, alongside the status line above:
-
-```mermaid
-stateDiagram-v2
-   [*] --> Plan
-   Plan --> Architect
-   Architect --> Implement
-   Implement --> Test
-   Test --> Review
-   Review --> Ship
-   Ship --> [*]
-   Implement : Implement (current)
-```
-
-Append ` (current)` to whichever phase's own name is the one that just completed or is in progress —
-exactly one phase carries it at a time, matching the status line's own `[Phase N/6 — Name]` value. Omit
-`Enchant` from the diagram entirely when Phase 1.5 was skipped (Decision logic above); insert it between
-`Plan` and `Architect` when it ran.
-
----
-
-## Rules
-
-- **One human gate only.** Everything before Phase 6 step 5 is autonomous. Do not ask for intermediate approvals unless a gate fails.
-- **No scope creep.** Only build what the feature description specifies.
-- **Fail fast.** If a phase cannot succeed, halt immediately rather than producing garbage for downstream phases.
-- **Attribution required.** Every commit must carry `Agent`, `Model`, `Model-Source`, and `Provider` trailers per ADR-028/ADR-029, plus `Persona`/`Role` when a roster exists and one was assigned.
-- **Branch discipline.** All work on topic branches, never on main — see `.arcane/governance/git-conventions.md`'s Trunk-based development rule. (Corrected 2026-08-31, BC-14: previously cited "ADR-048," which does exist in the shipped `framework-decisions.md` reference but is actually about the Code-Versus-Docs Branch Policy's local-only-repo fallback, unrelated to this general rule — a topical miscitation, the same class BC-06 found and fixed elsewhere. `git-conventions.md` states this rule directly with no ADR/ARC number attached, so there is nothing to cite beyond the file itself.)
-- **Fresh context per story.** Do not carry assumptions between stories during Phase 3.
-- **Epic checkpointing.** When this spell is run as one epic in a multi-epic plan, recommend running `spell-commit-work` before starting the next epic.
-- **Multi-epic runs serialize by default (ARC-028 R4).** Before running two or more epics concurrently in separate worktrees, compare their footprints: the file and directory globs each will touch, plus any **shared sequence** — database migration numbers, generated indexes and manifests, lockfiles, fixture IDs, anything where correctness depends on what another epic picked. If the footprints overlap on either axis, run the epics **sequentially in one workspace**, or re-scope them to disjoint footprints first. State the comparison and the resulting decision in the run's opening report; "they seemed unrelated" is not a footprint comparison.
-
-  This is a default derived from evidence, not caution for its own sake. A four-epic run with three executing in parallel isolated worktrees produced two epics independently claiming the same migration sequence number and two adding conflicting imports to the same file region — none of it visible until a human reached merge review. A three-epic re-run, strictly serialized in one workspace, produced zero collisions. Isolation prevents epics from *disturbing* each other; it does nothing to stop them *agreeing on the same answer* to a question neither knew the other was asking, and it delays the discovery until the most expensive moment. Serialization stays the default until re-derivation tooling exists (fresh-pull sequence re-derivation, shared numbering locks) — parallelism is available for genuinely disjoint footprints, and should be used there.
+This prompt is the Arcane `spell-full-cycle` spell. Read [`.arcane/spells/spell-full-cycle.md`](../../.arcane/spells/spell-full-cycle.md) and follow it as the complete workflow.

package/dist/assets/.github/prompts/spell-generate-bot-icons.prompt.md

@@ -6,80 +6,4 @@ argument-hint: Bot concept (e.g., "{AGENT_NAME} for ecommerce ops, powerful + mo
 agent: agent
 ---
 
-## Executive Summary
-
-- This spell standardizes bot icon creation for Teams deployments.
-- It separates creative generation (image-capable agent) from deterministic packaging (local script).
-- Output is always Teams-ready: `color.png` (192x192) + `outline.png` (32x32 transparent, white glyph).
-- Use this **after** agent setup (the agent's identity/role is defined) and **before** packaging `manifest.json` in the Teams setup flow.
-
----
-
-Create a high-quality avatar concept for the bot, then prepare Teams-compliant icon files.
-
-## Inputs
-
-- Bot role and personality (from user argument)
-- Brand direction (if none provided): clean, modern, readable at small sizes
-
-## Rules
-
-- **Validate before processing.** After the source image is saved, confirm it exists and is **square** (equal width and height) before running the build script. If the file is missing, regenerate it; if it is non-square, regenerate or crop to a 1:1 ratio. Do **not** run the build step on a missing or non-square source — fail with a clear message (e.g. `source.png is 1024x768; Teams icons require a square source`).
-- Quick check: `python3 -c "from PIL import Image; w,h=Image.open('{TEMP_DIR}/source.png').size; print(w,h); assert w==h, 'source must be square'"` (or `file {TEMP_DIR}/source.png` to read the dimensions).
-- The image must contain no copyrighted logos, mascots, or trademarked characters.
-
-> **Placeholders.** `{TEMP_DIR}` resolves to a writable working directory — your OS temp dir (`os.tmpdir()` / `$TMPDIR` / `%TEMP%`) plus a `teams-app` subfolder, or a repo-local `.tmp/teams-app/`. `{REPO_ROOT}` is the consuming repository's root. Resolve from `.arcane.json` / your shell; ask if unset.
-
-## Image Generation Requirements
-
-Generate one **source image** with these constraints:
-
-- Square PNG
-- Transparent background preferred
-- High resolution (1024x1024 recommended)
-- Single strong subject, centered
-- Minimal detail that survives downscaling
-- No copyrighted logos, mascots, or trademarked characters
-
-Save as:
-
-- `{TEMP_DIR}/source.png`
-
-## Post-Process (Required)
-
-Run (the script path resolves relative to the repo root):
-
-```bash
-python3 {REPO_ROOT}/playbooks/scripts/build-teams-icons.py \
-  --input {TEMP_DIR}/source.png \
-  --output {TEMP_DIR}
-```
-
-If `playbooks/scripts/build-teams-icons.py` is **missing** under the repo root, do not improvise silently — tell the user the script is expected at `{REPO_ROOT}/playbooks/scripts/build-teams-icons.py` and either restore it or fall back to producing the two sizes manually (e.g. an equivalent PIL/ImageMagick resize: 192x192 `color.png`, and a 32x32 transparent `outline.png` with a white glyph).
-
-This creates:
-
-- `{TEMP_DIR}/color.png` (192x192)
-- `{TEMP_DIR}/outline.png` (32x32, transparent background, white glyph)
-
-## Validation
-
-Run:
-
-```bash
-file {TEMP_DIR}/color.png
-file {TEMP_DIR}/outline.png
-```
-
-Expected:
-
-- `color.png`: PNG image data, 192 x 192
-- `outline.png`: PNG image data, 32 x 32
-
-## Final Output
-
-Report:
-
-- Visual style chosen
-- Paths to generated files
-- Any readability concerns at 32x32 size
+This prompt is the Arcane `spell-generate-bot-icons` spell. Read [`.arcane/spells/spell-generate-bot-icons.md`](../../.arcane/spells/spell-generate-bot-icons.md) and follow it as the complete workflow.

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

@@ -6,104 +6,4 @@ argument-hint: Path to stories.json or paste story context (optional - uses curr
 agent: agent
 ---
 
-## Executive Summary
-
-- This is the core autonomous loop of the Spell Loop methodology.
-- Each iteration: pick a story → implement → run tests → commit if passing → update stories.json → loop.
-- Uses fresh context per iteration — only stories.json, progress.txt, and git history carry forward.
-- See [[.arcane/governance/development-methodology|Development Methodology]] for full Spell Loop reference.
-
----
-
-Run the autonomous implementation loop for the current feature.
-
-Use these files for context:
-
-- [governance/development-methodology.md](../../.arcane/governance/development-methodology.md) — Spell Loop methodology
-- [governance/testing-standards.md](../../.arcane/governance/testing-standards.md) — Testing frameworks and coverage requirements
-- The feature's `architecture.md` — for tech decisions and patterns
-- The feature's `stories.json` — for the work breakdown
-- The feature's `progress.txt` (in `features/{slug}/`, if present) — accumulated learnings from prior iterations; read it before each iteration and append new learnings as the loop proceeds
-
-Workflow (loop until all stories pass):
-
-0. **Sync workspace** — before any code changes, ensure the workspace is current:
-   ```bash
-   git fetch --prune origin
-   git checkout main && git pull --ff-only
-   ```
-   If `pull --ff-only` fails, halt and report — manual rebase is needed.
-
-   **In a linked worktree, do not run the `checkout main` line** (ARC-028 R1/R8). It fails with `fatal: 'main' is already used by worktree at '<path>'` when another working tree holds `main`, and the halt instruction above only covers a `pull` failure — so an agent that runs it there has no branch to take. Sync the remote-tracking ref instead, which is all this step actually needs:
-   ```bash
-   git fetch --prune origin        # origin/main is now current
-   git rebase origin/main          # or branch from origin/main directly in step 1
-   ```
-   Check with `git rev-parse --path-format=absolute --git-common-dir` vs `--git-dir`: equal means primary checkout, different means linked worktree. `--path-format=absolute` is required — without it the two differ from any subdirectory and every primary checkout looks like a worktree.
-
-1. **Load stories.json** — locate the feature folder from the current branch:
-   ```bash
-   # Derive feature folder from branch name (works for lafayette/feat/541-phase-2a or lafayette/feat/phase-2a)
-   FEATURE_FOLDER="features/$(git symbolic-ref --short HEAD | sed 's|.*/feat/||')"
-   ```
-   Load `$FEATURE_FOLDER/stories.json` and `$FEATURE_FOLDER/architecture.md`. If the branch name doesn't follow the `feat/{slug}` or `feat/{id}-{slug}` pattern, look for the most recently modified `features/*/stories.json` or ask the operator for the path.
-
-   Find the next story where `"passes": false`, ordered by priority.
-
-2. **Read context** — load only what this story needs:
-   - The story's description and acceptance criteria from stories.json
-   - Relevant sections of architecture.md
-   - Latest entries in progress.txt (if exists) for learnings from previous iterations
-   - Files that will be modified (check git status)
-
-3. **Implement the story**:
-   - Follow the architecture decisions — do not deviate without flagging.
-   - Write the minimum code to satisfy acceptance criteria.
-   - Follow project coding conventions and patterns from existing code.
-   - Include tests per governance/testing-standards.md.
-
-4. **Run tests**:
-   - Run the test suite for the affected area.
-   - All existing tests must still pass (no regressions).
-   - New tests must pass.
-   - Check coverage against thresholds (80% line, 95% critical path).
-
-5. **Evaluate results**:
-   - **Tests pass:** proceed to commit.
-   - **Tests fail:** debug and fix. If stuck after 3 attempts, mark the story with the error in stories.json and move to the next story.
-
-6. **Commit the story**:
-   - Use Conventional Commits format (see spell-commit-work).
-   - One commit per story (squash if needed).
-   - Include the story ID in the commit body.
-
-7. **Update stories.json**:
-   - Set `"passes": true` for the completed story.
-   - Set `"testEvidence"` with coverage % and test count.
-
-8. **Append to `$FEATURE_FOLDER/progress.txt`**:
-   ```
-   ## Iteration N — [STORY-ID] — [timestamp]
-   ### What was done
-   - [summary of changes]
-   ### What was learned
-   - [patterns, gotchas, conventions discovered]
-   ### What to watch for
-   - [warnings for future iterations]
-   ```
-   File lives in the feature folder, not the repo root.
-
-9. **Loop** — go to step 1 and pick the next story.
-
-10. **Completion** — when all stories have `"passes": true`:
-    - Summarize what was built.
-    - Report total test count and coverage.
-    - Recommend running `spell-review` for adversarial review.
-
-Rules:
-- **Fresh context:** do not carry assumptions from previous stories. Re-read what you need.
-- **No scope creep:** only implement what the story specifies.
-- **Test first when possible:** write the test, see it fail, then implement.
-- **Commit atomically:** one story = one commit.
-- **Never skip tests:** if there's no test framework set up, set it up as the first story.
-- **Stuck threshold:** if a story fails 3 consecutive attempts, mark it and move on. Human intervention needed.
+This prompt is the Arcane `spell-implement` spell. Read [`.arcane/spells/spell-implement.md`](../../.arcane/spells/spell-implement.md) and follow it as the complete workflow.