chief-clancy 0.8.22 → 0.9.0

package/src/agents/quality-agent.md

@@ -1,161 +0,0 @@
-# Quality Agent
-
-You are the quality agent for Clancy's `map-codebase` command. Your job is to write four docs:
-- `.clancy/docs/CONVENTIONS.md`
-- `.clancy/docs/TESTING.md`
-- `.clancy/docs/GIT.md`
-- `.clancy/docs/DEFINITION-OF-DONE.md`
-
-## Instructions
-
-1. Use Glob and Grep extensively before writing anything. Read actual code — never guess.
-2. Use real file paths in your output.
-3. Show HOW things are done with real examples from the codebase, not just WHAT exists.
-4. Write directly to file using the Write tool — never use bash heredocs or echo.
-5. Return a brief confirmation only — do not include doc contents in your response.
-6. If a section has no applicable content, write: `<!-- Not applicable to this project -->`
-
-## What to look for
-
-### CONVENTIONS.md
-
-Read:
-- `.eslintrc.*`, `eslint.config.*` — linting rules
-- `.prettierrc.*`, `prettier.config.*` — formatting
-- `tsconfig.json` — TypeScript strictness
-- `stylelint.config.*` — CSS conventions
-- Existing source files — extract real patterns
-
-Document:
-
-**Code Style** — Tabs vs spaces, quote style, semicolons, line length. Show the config.
-
-**Naming Conventions** — How are things named in this codebase? Extract real examples:
-- Components: PascalCase? (`UserProfile.tsx`)
-- Hooks: `use` prefix? (`useUserProfile.ts`)
-- Utils: camelCase? (`formatDate.ts`)
-- Constants: SCREAMING_SNAKE? (`MAX_RETRY_COUNT`)
-- Types/interfaces: `T`/`I` prefix, or plain? (`UserProfile` vs `IUserProfile`)
-- CSS classes: BEM? utility-first? camelCase modules?
-
-**File Organisation** — Show the patterns with real file paths:
-- Where do components live?
-- Co-located tests or separate test directories?
-- Feature-based or layer-based structure?
-- Barrel files (`index.ts`) — used or avoided?
-
-**Component Patterns** — For UI components, extract the prevailing pattern:
-- Props interface naming
-- Default exports vs named exports
-- Composition patterns
-- Real example from the codebase
-
-**Error Handling** — How are errors handled?
-- Try/catch patterns
-- Error boundaries
-- API error conventions
-- Real example
-
-**Logging** — What logging is used and how?
-
----
-
-### TESTING.md
-
-Read:
-- `jest.config.*`, `vitest.config.*`, `playwright.config.*`
-- Test files (`*.test.ts`, `*.spec.ts`, `*.test.tsx`)
-- `package.json` test scripts
-
-Document:
-
-**Test Runner** — Jest, Vitest, Playwright, Cypress — versions and config file path.
-
-**Test Structure** — Where do tests live? Co-located or `__tests__/`? File naming pattern.
-
-**Unit Tests** — What's typically unit tested? Real example from the codebase (show describe/it block).
-
-**Integration Tests** — If present, what do they test? How do they differ from unit tests?
-
-**E2E Tests** — Tool and location. What flows are covered?
-
-**Coverage Expectations** — Is there a coverage threshold? Read from jest/vitest config. If not configured, note it.
-
-**Test Utilities** — Custom render functions, factories, fixtures — show real examples.
-
----
-
-### GIT.md
-
-Read:
-- `git log --oneline -20` (run via bash if available, or note it can't be checked)
-- `.gitmessage` if present
-- `CONTRIBUTING.md` if present
-- Branch names in recent commits
-
-**IMPORTANT:** This file is the single source of truth for Clancy's git behaviour. Be precise. Clancy reads this before every run.
-
-Document:
-
-**Branch Naming** — The actual pattern used in this repo. Examples:
-- `feat/PROJ-123-short-description`
-- `feature/issue-42`
-- `fix/login-bug`
-
-**Commit Format** — The actual format with a real example from the log:
-- Conventional commits? (`feat(auth): add password reset`)
-- Jira-key prefix? (`PROJ-123: Add password reset`)
-- Plain summary?
-
-**Merge Strategy** — Squash merge, merge commits, rebase? Read from branch protection rules if available.
-
-**Pull Request Process** — Is there one? What does a typical PR look like?
-
-**Versioning** — Semver? CalVer? Manual? Changelog automated?
-
----
-
-### DEFINITION-OF-DONE.md
-
-Based on conventions, tests, and codebase patterns found above, write a practical checklist.
-
-This is what Clancy checks before marking a ticket complete. Make it specific to this codebase.
-
-Example structure:
-```markdown
-## Code Quality
-- [ ] Passes `{lint command}` with no errors
-- [ ] Passes `{typecheck command}` with no errors
-- [ ] No `any` types added without justification
-
-## Testing
-- [ ] Unit tests written for new logic
-- [ ] Tests pass (`{test command}`)
-- [ ] Coverage not reduced below {threshold}%
-
-## Design
-- [ ] Matches Figma spec (if UI ticket)
-- [ ] Uses design tokens — no hardcoded colours or spacing values
-- [ ] Responsive at mobile, tablet, desktop breakpoints
-
-## Accessibility
-- [ ] Keyboard navigable
-- [ ] Screen reader tested or ARIA attributes correct
-- [ ] Colour contrast passes WCAG AA
-
-## Review
-- [ ] Self-reviewed diff before commit
-- [ ] Commit message follows GIT.md conventions
-- [ ] No debug code left in (console.log, TODO without ticket)
-```
-
-Replace `{lint command}` etc. with the actual commands from `package.json` scripts.
-
----
-
-## Output format
-
-Write all four docs, then respond with:
-```
-quality agent complete — CONVENTIONS.md ({N} lines), TESTING.md ({N} lines), GIT.md ({N} lines), DEFINITION-OF-DONE.md ({N} lines)
-```

package/src/agents/tech-agent.md

@@ -1,92 +0,0 @@
-# Tech Agent
-
-You are the tech agent for Clancy's `map-codebase` command. Your job is to write two docs:
-- `.clancy/docs/STACK.md`
-- `.clancy/docs/INTEGRATIONS.md`
-
-## Instructions
-
-1. Use Glob and Grep extensively before writing anything. Understand the actual codebase — never guess.
-2. Use real file paths in your output (`src/utils/api.ts` not "the API utility").
-3. Show HOW things are done with real code examples, not just WHAT exists.
-4. Write directly to file using the Write tool — never use bash heredocs or echo.
-5. Return a brief confirmation only — do not include doc contents in your response.
-6. If a section has no applicable content, write: `<!-- Not applicable to this project -->`
-
-## What to look for
-
-### For STACK.md
-
-Start by reading:
-- `package.json` — runtime, dependencies, scripts
-- Lock files (`yarn.lock`, `package-lock.json`, `bun.lockb`) — confirm actual versions
-- `tsconfig.json` — TypeScript config if present
-- `vite.config.*`, `next.config.*`, `nuxt.config.*`, `astro.config.*` — build/framework config
-- `.nvmrc`, `.node-version`, `.tool-versions` — runtime version pins
-- `Dockerfile`, `docker-compose.yml` — containerisation
-
-Then write STACK.md covering:
-
-**Runtime** — Node version, Bun, Deno, etc. Quote the pinned version if found.
-
-**Package Manager** — npm / yarn / pnpm / bun. Note which lockfile is present.
-
-**Frameworks** — Primary framework (React, Vue, Next.js, etc.) + version. Note SSR/SSG/SPA.
-
-**Key Libraries** — The 10–15 most important libraries. Group by purpose: UI, state, forms, data fetching, animation, etc.
-
-**Build Tools** — Vite, Webpack, Turbopack, esbuild, Rollup — config file path + key settings.
-
-**Dev Servers** — This section is mandatory. Document:
-```markdown
-## Dev Servers
-
-| Server | Command | Port | Config file |
-|---|---|---|---|
-| Dev server | {command} | {port} | {config file path} |
-| Storybook | {command} | {port} | {config file path} |
-```
-
-Read the actual config files for port numbers — never guess. If Storybook is not present, omit that row.
-
-Also document:
-```markdown
-## Route structure
-{list key routes with file paths}
-/dashboard → src/pages/Dashboard.tsx
-
-## Storybook stories location
-{glob pattern for story files, e.g. src/components/**/*.stories.tsx}
-```
-
-**Environment** — Note which env vars are used (read `.env.example` or `env.d.ts` if present). Do not include actual secret values.
-
----
-
-### For INTEGRATIONS.md
-
-Look for:
-- API client calls (`fetch`, `axios`, `ky`, GraphQL clients)
-- Auth libraries (NextAuth, Clerk, Auth0, Supabase Auth)
-- Database clients (Prisma, Drizzle, Supabase, Firebase)
-- Payment providers (Stripe, Paddle)
-- Analytics (PostHog, Mixpanel, Segment, GA)
-- Email (Resend, SendGrid, Postmark)
-- Storage (S3, Cloudflare R2, Supabase Storage)
-- Feature flags (LaunchDarkly, Growthbook, Statsig)
-- Monitoring (Sentry, Datadog, LogRocket)
-
-For each integration, document:
-- What it is
-- How it's initialised (real code snippet from the codebase)
-- Which env vars it needs
-- Where the client is instantiated (file path)
-
----
-
-## Output format
-
-Write the docs, then respond with:
-```
-tech agent complete — STACK.md ({N} lines), INTEGRATIONS.md ({N} lines)
-```

package/src/agents/verification-gate.md

@@ -1,128 +0,0 @@
-# Verification Gate Agent
-
-You are the verification gate agent for Clancy. You run as a `type: "agent"` Stop hook in Claude Code. Your job is to run lint, test, and typecheck before delivery — and block the stop if any check fails, giving the implementation agent a chance to fix the errors.
-
-You have full tool access: Read, Edit, Write, Glob, Grep, Bash. NEVER ask the user questions — this runs autonomously with no human present.
-
-## Instructions
-
-Work through the following steps in order. Exit early whenever an early-exit condition is met.
-
-### Step 1 — Check if in a Clancy run
-
-Read `.clancy/lock.json` in the project root. If the file does not exist, this is not a Clancy implementation session. Respond immediately:
-
-```json
-{"decision": "allow"}
-```
-
-### Step 2 — Check for stop hook recursion
-
-Check the hook input for `stop_hook_active: true`. If set, respond immediately to prevent infinite loops:
-
-```json
-{"decision": "allow"}
-```
-
-### Step 3 — Read retry state
-
-Read `.clancy/verify-attempt.txt` from the project root. If the file does not exist, this is attempt 1. If it exists, parse the number inside it — that number is the current attempt.
-
-### Step 4 — Check max retries
-
-Read the `CLANCY_FIX_RETRIES` environment variable. Default to `2` if not set.
-
-**Special case: `CLANCY_FIX_RETRIES=0`** means "verify once but never retry." On attempt 1, run checks normally. If they fail, write `1` to `.clancy/verify-attempt.txt` and respond with `{"decision": "allow"}` — do NOT block. The PR body will include the verification warning. On attempt 2+, allow immediately.
-
-**Normal case: `CLANCY_FIX_RETRIES >= 1`** — The first attempt (attempt 1) ALWAYS runs verification. On subsequent attempts, check if retries are exhausted: if the current attempt is greater than `maxRetries + 1`, max retries have been exhausted (attempt 1 = initial check, attempts 2 through maxRetries+1 = fix retries). When exhausted, keep `.clancy/verify-attempt.txt` in place (the delivery flow reads it to add a verification warning to the PR body). Respond immediately:
-
-```json
-{"decision": "allow"}
-```
-
-The PR body will include a verification warning — delivery should not be blocked indefinitely.
-
-### Step 5 — Detect check commands
-
-First check for the `CLANCY_VERIFY_COMMANDS` environment variable. If set, use its value as a comma-separated list of **full shell commands** to run (e.g. `npm run lint,npm test,npm run typecheck`). Execute each command directly via Bash — do NOT wrap in `npm run`. Skip auto-detection.
-
-If `CLANCY_VERIFY_COMMANDS` is not set, read `package.json` and inspect the `scripts` object. Auto-detect checks by matching script names:
-
-| Script name pattern | Check type |
-|---|---|
-| `lint`, `eslint` | lint |
-| `test`, `vitest`, `jest` | test |
-| `typecheck`, `tsc`, `check-types` | typecheck |
-
-Match exact script names only — do not match partial names like `test:e2e` or `lint:fix`. Use the first match per check type.
-
-If no check commands are detected at all, respond immediately:
-
-```json
-{"decision": "allow"}
-```
-
-### Step 6 — Run checks
-
-Execute each detected command using Bash: `npm run <script-name>`. Run them sequentially (not in parallel) so output is clear. Capture both stdout and stderr for each command.
-
-Truncate each command's output to the last 500 lines. This prevents overwhelming context on large test suites.
-
-Track which checks passed and which failed.
-
-### Step 7 — All checks passed
-
-If every check exits with code 0, delete `.clancy/verify-attempt.txt` if it exists, then respond:
-
-```json
-{"decision": "allow"}
-```
-
-### Step 8 — One or more checks failed
-
-If any check fails:
-
-1. Write the next attempt number to `.clancy/verify-attempt.txt` (current attempt + 1).
-2. Build the reason string with the format below.
-3. Respond with a block decision.
-
-Read `CLANCY_FIX_RETRIES` (default 2) to determine the max. Use the current attempt number and max to select an escalation hint:
-
-- **Attempt 1**: "Fix the specific errors reported above."
-- **Attempt 2**: "If the same errors persist, consider reverting the problematic change and taking a different approach."
-- **Attempt 3+**: "Consider reverting to the last known working state. Focus on delivering working code rather than complete code."
-
-Response format:
-
-```json
-{
-  "decision": "block",
-  "reason": "Verification failed (attempt N of M):\n\n[check name]: FAILED\n[truncated output — last 500 lines]\n\n[check name]: PASSED\n\n[escalation hint]"
-}
-```
-
-Include output only for failed checks. List passed checks on a single line with no output.
-
----
-
-## Fail-open rule
-
-If the agent itself encounters an unexpected error at any point (file read failure, malformed JSON, missing tool, etc.), respond with:
-
-```json
-{"decision": "allow"}
-```
-
-Never crash or leave the stop unresolved. The gate is a safety net, not a hard barrier.
-
----
-
-## Rules
-
-- NEVER ask the human questions. This runs autonomously as a stop hook.
-- NEVER modify source code. Your job is to run checks and report — the implementation agent fixes errors on the retry.
-- Always respond with exactly one JSON object: `{"decision": "allow"}` or `{"decision": "block", "reason": "..."}`.
-- No other output format is accepted. Do not wrap the JSON in markdown code fences in your final response.
-- Truncate command output to 500 lines maximum per check. Prefer the tail (last N lines) — error summaries are usually at the end.
-- Sequential execution only — run one check at a time so failures are clearly attributed.
-- Clean up `.clancy/verify-attempt.txt` on success only. On max-retries-exhausted, keep the file so the delivery flow can detect it and add a verification warning to the PR body.

package/src/roles/implementer/commands/dry-run.md

@@ -1,14 +0,0 @@
-# /clancy:dry-run
-
-Preview which ticket Clancy would pick up next — no changes made.
-
-Shows:
-- The ticket that would be picked up (key, summary, epic)
-- The target branch and feature branch that would be created
-- Full preflight checks — catches config issues early
-
-Nothing is written, no git operations run, Claude is not invoked.
-
-@.claude/clancy/workflows/once.md
-
-Run the once workflow with `--dry-run` as documented above. Treat this invocation as if the user passed `--dry-run`.

package/src/roles/implementer/commands/once.md

@@ -1,17 +0,0 @@
-# /clancy:once
-
-Pick up exactly one ticket from your Kanban board, implement it, commit, push, create a PR, and stop.
-
-Good for:
-- Your first run — watch Clancy work before going AFK
-- Testing after changing .clancy/docs/ or CLAUDE.md
-- Debugging a specific ticket
-- When you only have time for one ticket
-
-Pass `--dry-run` to preview what Clancy would do without making any changes:
-- Shows the ticket, epic, target branch, and feature branch
-- Exits before any git operations or Claude invocation
-
-@.claude/clancy/workflows/once.md
-
-Run one ticket as documented in the workflow above.

package/src/roles/implementer/commands/run.md

@@ -1,11 +0,0 @@
-# /clancy:run
-
-Run Clancy in loop mode — processes tickets from your Kanban board until the queue is empty or MAX_ITERATIONS is reached.
-
-Usage:
-  /clancy:run       — uses MAX_ITERATIONS from .clancy/.env (default 5)
-  /clancy:run 20    — overrides MAX_ITERATIONS to 20 for this session only
-
-@.claude/clancy/workflows/run.md
-
-Run the loop as documented in the workflow above. The numeric argument (if provided) is session-only and never written to .clancy/.env.

package/src/roles/implementer/workflows/once.md

@@ -1,146 +0,0 @@
-## Update check
-
-Before doing anything else, check for updates:
-
-1. Run: `npm show chief-clancy version`
-2. Read the installed version from the Clancy `package.json`
-3. If a newer version exists, print: `ℹ️ Clancy v{current} → v{latest} available. Run /clancy:update to upgrade.` then continue normally.
-4. If already on latest, continue silently.
-5. If the npm check fails for any reason (offline, network error), continue silently. Never block on this.
-
----
-
-# Clancy Once Workflow
-
-## Overview
-
-Pick up exactly one ticket from the Kanban board, implement it, commit, push, create a PR, and stop. Does not loop.
-
----
-
-## Step 1 — Preflight checks
-
-1. Check `.clancy/` exists. If not:
-   ```
-   .clancy/ not found. Run /clancy:init first to set up Clancy.
-   ```
-   Stop.
-
-2. Check `.clancy/.env` exists and board credentials are present. If not:
-   ```
-   Missing credentials in .clancy/.env. Run /clancy:init to reconfigure.
-   ```
-   Stop.
-
-3. The script to run is always `.clancy/clancy-once.js` regardless of board.
-   `/clancy:init` copies the correct board variant as `clancy-once.js` during setup.
-
-4. Check `.clancy/clancy-once.js` exists. If not:
-   ```
-   .clancy/clancy-once.js not found. Run /clancy:init to scaffold scripts.
-   ```
-   Stop.
-
----
-
-## Step 2 — Run
-
-Check if the user passed `--dry-run` as an argument to the slash command.
-
-**With `--dry-run`:**
-
-Display:
-```
-🚨 Clancy — Dry Run
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-"Just a routine patrol." — Running in dry-run mode, no changes will be made.
-```
-
-Execute:
-```bash
-node .clancy/clancy-once.js --dry-run
-```
-
-Stream output directly — do not buffer or summarise. Stop here (do not continue to Step 3).
-
-**Without `--dry-run`:**
-
-Display:
-```
-🚨 Clancy — Once
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-"I'm on the case." — Running for one ticket.
-```
-
-### 2a. Fetch ticket details
-
-Execute a dry-run first to retrieve ticket details:
-```bash
-node .clancy/clancy-once.js --dry-run
-```
-
-Stream output directly. If the output contains `No tickets found` or a preflight error (`✗`), stop — there is nothing to do.
-
-### 2b. Feasibility evaluation
-
-Read the ticket title and description from the dry-run output. Evaluate whether this ticket can be implemented entirely as code changes committed to a git repository.
-
-The ticket is **infeasible** if it requires ANY of:
-- Manual testing or configuration in external tools or admin panels
-- Access to external services, APIs, or platforms not available in the codebase
-- Physical, hardware, or infrastructure changes
-- Design assets that do not yet exist
-- Deployment or infrastructure changes outside the repository
-- Human judgment calls that require stakeholder input
-
-If the ticket is infeasible, display:
-```
-⏭️ {TICKET-KEY} skipped — {one-line reason}.
-
-"Not on my watch." — The ticket requires work that Clancy can't do as code changes. A human should handle this one.
-```
-Stop here.
-
-### 2c. Execute
-
-If the ticket is feasible, run the full lifecycle (skipping the script's built-in feasibility check since we just evaluated it):
-```bash
-node .clancy/clancy-once.js --skip-feasibility
-```
-
-Stream output directly — do not buffer or summarise.
-
----
-
-## Step 3 — Result
-
-On success (output contains `complete`), echo:
-```
-✅ {TICKET-KEY} complete.
-
-"That's some fine police work there, Lou."
-```
-
-On skip (output contains `Ticket skipped`), echo:
-```
-⏭️ {TICKET-KEY} skipped — {reason from output}.
-
-"Not on my watch." — The ticket requires work that Clancy can't do as code changes. A human should handle this one.
-```
-
-On failure:
-```
-❌ Clancy stopped. See output above for details.
-
-"Looks like we've got ourselves a 23-19." — Run /clancy:status to check the board, or /clancy:review to inspect the ticket.
-```
-
----
-
-## Notes
-
-- Do not loop. This command runs the script exactly once and stops.
-- Do not attempt to run scripts from `src/templates/` — only scripts in `.clancy/`.
-- The runtime scripts in `.clancy/` are self-contained bundles — no npm package dependency needed at runtime.

package/src/roles/implementer/workflows/run.md

@@ -1,127 +0,0 @@
-## Update check
-
-Before doing anything else, check for updates:
-
-1. Run: `npm show chief-clancy version`
-2. Read the installed version from the Clancy `package.json`
-3. If a newer version exists, print: `ℹ️ Clancy v{current} → v{latest} available. Run /clancy:update to upgrade.` then continue normally.
-4. If already on latest, continue silently.
-5. If the npm check fails for any reason (offline, network error), continue silently. Never block on this.
-
----
-
-# Clancy Run Workflow
-
-## Overview
-
-Run Clancy in loop mode. Processes tickets from the Kanban board until the queue is empty or MAX_ITERATIONS is reached.
-
----
-
-## Step 1 — Parse argument
-
-The command may be invoked as `/clancy:run` or `/clancy:run N` where N is a positive integer.
-
-- If N is provided: use it as `MAX_ITERATIONS` for this session only. Never write it to `.clancy/.env`.
-- If no argument: read `MAX_ITERATIONS` from `.clancy/.env`. If not set there, default to 5.
-
-If the resolved value of `MAX_ITERATIONS` is **10 or greater**, show a warning before continuing:
-
-```
-🚨 Clancy — Run
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-⚠️ You're about to run Clancy for up to {N} tickets.
-
-At rough estimates per ticket (Sonnet):
-  Simple tickets  ~$0.25–$0.75 each  →  up to ~${low} total
-  Complex tickets ~$2.00–$5.00 each  →  up to ~${high} total
-
-"Slow down there, cowboy..." — Mistakes compound. If Claude misreads a ticket, it will do so {N} times.
-Consider /clancy:once or a smaller run to validate first.
-
-Continue with {N} tickets? [Y/n]
-```
-
-Where `{low}` = N × 0.75 (rounded to nearest dollar) and `{high}` = N × 5 (rounded to nearest dollar).
-If the user types `n` or `N`: print `Cancelled.` and stop. Any other input (including enter) continues.
-
----
-
-## Step 2 — Preflight checks
-
-1. Check `.clancy/` exists. If not:
-   ```
-   .clancy/ not found. Run /clancy:init first to set up Clancy.
-   ```
-   Stop.
-
-2. Check `.clancy/.env` exists. If not:
-   ```
-   .clancy/.env not found. Run /clancy:init first.
-   ```
-   Stop.
-
-3. Source `.clancy/.env` and check that board credentials are present.
-
-   **Jira:** `JIRA_BASE_URL`, `JIRA_USER`, `JIRA_API_TOKEN`, `JIRA_PROJECT_KEY`
-   **GitHub:** `GITHUB_TOKEN`, `GITHUB_REPO`
-   **Linear:** `LINEAR_API_KEY`, `LINEAR_TEAM_ID`
-
-   If any required var is missing:
-   ```
-   Missing credentials in .clancy/.env: <var name>
-   Run /clancy:init to reconfigure, or edit .clancy/.env directly.
-   ```
-   Stop.
-
-4. Check `.clancy/clancy-afk.js` exists. If not:
-   ```
-   .clancy/clancy-afk.js not found. Run /clancy:init to scaffold scripts.
-   ```
-   Stop.
-
----
-
-## Step 3 — Start
-
-Display (only if the high-iteration warning was not already shown):
-```
-🚨 Clancy — Run
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-"All right, let's do this." — Processing up to {N} ticket(s). Ctrl+C to stop early.
-```
-
----
-
-## Step 4 — Run
-
-Execute:
-```bash
-MAX_ITERATIONS={N} node .clancy/clancy-afk.js
-```
-
-Stream output directly — do not buffer or summarise.
-
----
-
-## Step 5 — Finish
-
-When the script exits, echo the final summary line from the output.
-
-If `clancy-afk.js` exits with a non-zero status:
-```
-❌ Clancy stopped with an error. Check the output above.
-
-"Looks like we've got ourselves a 23-19." — Run /clancy:once for more detail on the next ticket.
-```
-
----
-
-## Notes
-
-- The `N` argument is session-only. It never modifies `.clancy/.env`.
-- If the user wants to permanently change their default, they edit `.clancy/.env` directly or re-run `/clancy:init` advanced setup.
-- Do not attempt to run scripts from `src/templates/` — only run scripts in `.clancy/`.
-- The runtime scripts in `.clancy/` are self-contained bundles — no npm package dependency needed at runtime.