chief-clancy 0.8.22 → 0.9.0

package/src/roles/reviewer/workflows/review.md

@@ -1,186 +0,0 @@
-# Clancy Review Workflow
-
-## Overview
-
-Fetch the next ticket from the board and score how well-specified it is. Returns a confidence score (0–100%) and actionable recommendations. Does not implement anything.
-
----
-
-## Step 1 — Preflight checks
-
-1. Check `.clancy/` exists and `.clancy/.env` is present. If not:
-   ```
-   .clancy/ not found. Run /clancy:init to set up Clancy first.
-   ```
-   Stop.
-
-2. Source `.clancy/.env` and check board credentials are present (same vars checked by `/clancy:status`).
-
----
-
-## Step 2 — Fetch next ticket
-
-Detect board from `.clancy/.env` and fetch with `maxResults=1`. The query must match the once-runner exactly — what review shows is what run would pick up.
-
-**Jira:** Build JQL using the same clauses as the once-runner:
-- Sprint clause: include `AND sprint in openSprints()` if `CLANCY_JQL_SPRINT` is set
-- Label clause: include `AND labels = "$CLANCY_LABEL"` if `CLANCY_LABEL` is set
-- `CLANCY_JQL_STATUS` defaults to `To Do` if not set
-
-Full JQL: `project=$JIRA_PROJECT_KEY [AND sprint in openSprints()] [AND labels = "$CLANCY_LABEL"] AND assignee=currentUser() AND status="$CLANCY_JQL_STATUS" ORDER BY priority ASC`
-
-Use the POST `/rest/api/3/search/jql` endpoint (the old GET `/rest/api/3/search` was removed Aug 2025):
-
-```bash
-RESPONSE=$(curl -s \
-  -u "$JIRA_USER:$JIRA_API_TOKEN" \
-  -X POST \
-  -H "Content-Type: application/json" \
-  -H "Accept: application/json" \
-  "$JIRA_BASE_URL/rest/api/3/search/jql" \
-  -d '{"jql": "<jql as above>", "maxResults": 1, "fields": ["summary", "description", "issuelinks", "parent", "customfield_10014"]}')
-```
-
-**GitHub Issues:** First resolve the authenticated username (don't use `@me` — it breaks with fine-grained PATs):
-`GITHUB_USERNAME=$(curl -s -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/user | jq -r '.login')`
-Then: `GET /repos/$GITHUB_REPO/issues?state=open&assignee=$GITHUB_USERNAME&labels=clancy&per_page=1` — filter out PRs (entries with `pull_request` key).
-
-**Linear:** GraphQL `viewer.assignedIssues` with `filter: { state: { type: { eq: "unstarted" } }, team: { id: { eq: "$LINEAR_TEAM_ID" } }[, labels: { name: { eq: "$CLANCY_LABEL" } }] }` (label clause only if `CLANCY_LABEL` is set), `first: 1`, `orderBy: priority`
-
-Fetch full ticket content: summary, description (full text), acceptance criteria (if present), epic/parent info, blockers/issue links.
-
-If no tickets found:
-```
-🚨 Clancy — Review
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-No tickets in the queue. Nothing to review.
-
-"Quiet. Too quiet." — Check your board or run /clancy:status.
-```
-Stop.
-
----
-
-## Step 3 — Score against 7 criteria
-
-Score each criterion as pass / warn / fail using the rubric below. Compute weighted confidence score.
-
-### Scoring rubric
-
-| # | Criterion | Weight | Pass | Warn | Fail |
-|---|---|---|---|---|---|
-| 1 | Summary clarity | 10% | Specific, scopeable | Vague but workable | Too broad or meaningless |
-| 2 | Description quality | 15% | Explains what + why | What only, no why | Missing or one-liner |
-| 3 | Acceptance criteria | 25% | Concrete + testable | Present but vague | Missing entirely |
-| 4 | Figma URL (UI tickets only) | 15% | URL present in description | — | UI ticket, no Figma URL |
-| 5 | Scope realism | 15% | Single focused deliverable | Multiple deliverables or borderline | Too large, "and also" tasks, or spans unrelated systems |
-| 6 | Dependencies stated | 5% | Blockers explicit | — | No mention of dependencies |
-| 7 | Clancy executability | 15% | Purely codebase work | Mostly codebase, minor external touch | Requires work outside the codebase |
-
-**Criterion 7 — Clancy executability:** Score as Fail if the ticket primarily requires any of the following — Clancy cannot do these from within the codebase:
-- **External system admin:** "in Google Analytics", "in Salesforce", "in HubSpot", "in the AWS console", "in Jira admin", "in the app store dashboard"
-- **Human process steps:** "get sign-off from", "send an email to customers", "coordinate with", "schedule a meeting", "announce to users"
-- **Production ops (non-repo):** "deploy to production", "rotate the API keys in prod", "scale the fleet", "restart the service" — unless the ticket is purely about CI/CD config files that live in the repo
-- **Non-code deliverables:** "write a runbook", "update the wiki", "create a presentation", "document in Confluence"
-
-Score as Warn if the ticket is mostly codebase work but has an incidental external touch (e.g. "add a new event to the existing analytics tracking" — the code change is in the repo, even if the event appears in a dashboard).
-
-**Tech stack coherence (part of criterion 7):** If `.clancy/docs/STACK.md` exists, read it and check the ticket against the documented stack. If the ticket mentions a technology or platform not in the documented stack that appears to be an external service (not a new dependency to install), score criterion 7 as Warn and note the mismatch explicitly.
-
-**Figma criterion:** Only applies if the ticket description mentions UI, components, screens, design, or visual elements. Backend/API/config tickets skip criterion 4 and redistribute its 15% weight proportionally across the remaining criteria.
-
-**Figma URL quality checks:**
-- URL present but points to file root (no `node-id`) → warn: recommend scoping to specific frame
-- `FIGMA_API_KEY` not configured but UI ticket has Figma URL → warn: link will be ignored at runtime
-
-**Scope realism — additional Fail signals:**
-- Ticket contains multiple distinct deliverables ("and also", "additionally", "while you're at it", "as well as")
-- Ticket implies setting up new infrastructure from scratch where none exists in the repo (new database, new service, new deployment pipeline)
-- Ticket references 4+ unrelated subsystems that would each require deep separate context
-
-**Score calculation:**
-- Pass = full weight
-- Warn = half weight
-- Fail = zero weight
-- Sum all weighted scores → overall percentage
-
-**Hard gate — executability override:** If criterion 7 scores Fail, cap the verdict at "Needs work" regardless of the calculated score. A ticket that requires work outside the codebase cannot be run reliably no matter how well it is specified.
-
----
-
-## Step 4 — Generate recommendations
-
-For each warn or fail criterion, generate a specific, actionable recommendation — specific to this ticket, not generic advice.
-
-Good: "Add a Figma URL to the ticket description — this ticket mentions updating the profile header component"
-Bad: "Ensure design specs are provided"
-
----
-
-## Step 5 — Display output
-
-```
-🚨 Clancy — Review
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-[{TICKET-KEY}] {Summary}
-
-Confidence: {score}% — {badge} {band label}
-
-{for each criterion:}
-✅ {criterion name} — {pass reason}
-⚠️ {criterion name} — {warn reason}
-   → {specific recommendation}
-❌ {criterion name} — {fail reason}
-   → {specific recommendation}
-
-{verdict line}
-
-{sign-off quote}
-```
-
-### Confidence bands
-
-| Score | Badge | Label | Verdict action |
-|---|---|---|---|
-| 85–100% | 🟢 | Ready | "Run with confidence." |
-| 65–84% | 🟡 | Good to go with caveats | "Review the warnings above, then run /clancy:once." |
-| 40–64% | 🟠 | Needs work | "Address the ❌ items in the ticket, then re-run /clancy:review." |
-| 0–39% | 🔴 | Not ready | "This ticket needs significant rework before Clancy can implement it reliably." |
-
-**Executability override:** If criterion 7 (Clancy executability) scores Fail, ignore the calculated band and show:
-```
-🔴 Verdict: Not ready for Clancy
-   This ticket requires work outside the codebase — Clancy can only implement code changes.
-   Update the ticket to focus on the codebase side, or remove it from the queue.
-
-   "This is Papa Bear. Put out an APB for a better ticket spec."
-```
-
-### Sign-off quotes per band
-
-Append a Wiggum-themed quote after the verdict to add personality. Never suggest bypassing the review on low-confidence tickets:
-
-- **🟢 Ready:** `"Bake 'em away, toys." — Run /clancy:once to pick it up.`
-- **🟡 Good to go:** `"I'd rather let Herman go. I don't think we've got enough to nail him." — Fix the warnings, then run /clancy:once.`
-- **🟠 Needs work:** `"Uh, no. You got the wrong number. This is 9-1... 2." — Update the ticket, then re-run /clancy:review.`
-- **🔴 Not ready:** `"This is Papa Bear. Put out an APB for a better ticket spec." — Rework the ticket first.`
-
----
-
-## Step 6 — Log the review
-
-Append to `.clancy/progress.txt`:
-```
-YYYY-MM-DD HH:MM | {TICKET-KEY} | REVIEW | {score}%
-```
-
----
-
-## Notes
-
-- Recommendations are specific to this ticket — never generic
-- The verdict always suggests a next step — never leaves the user without a clear action
-- Re-running `/clancy:review` multiple times is safe — the score may improve as the ticket is updated
-- Do not implement anything — Claude is invoked for analysis only

package/src/roles/reviewer/workflows/status.md

@@ -1,134 +0,0 @@
-# Clancy Status Workflow
-
-## Overview
-
-Read-only board check. Fetches the next 3 tickets Clancy would pick up and displays them. No side effects whatsoever — no git operations, no file writes, no ticket claiming.
-
----
-
-## Step 1 — Preflight checks
-
-1. Check `.clancy/` exists and `.clancy/.env` is present.
-2. Source `.clancy/.env` and check board credentials are present.
-3. On any missing config, show a specific error and stop:
-   ```
-   Missing config. Run /clancy:init to set up Clancy.
-   ```
-
----
-
-## Step 2 — Detect board and fetch tickets
-
-Detect board from `.clancy/.env`:
-
-**Jira:**
-
-Build the JQL string first using the same clauses as the once-runner:
-- Sprint clause: include `AND sprint in openSprints()` if `CLANCY_JQL_SPRINT` is set
-- Label clause: include `AND labels = "$CLANCY_LABEL"` if `CLANCY_LABEL` is set
-- `CLANCY_JQL_STATUS` defaults to `To Do` if not set
-
-Full JQL (with both optional clauses shown):
-`project=$JIRA_PROJECT_KEY [AND sprint in openSprints()] [AND labels = "$CLANCY_LABEL"] AND assignee=currentUser() AND status="$CLANCY_JQL_STATUS" ORDER BY priority ASC`
-
-```bash
-RESPONSE=$(curl -s \
-  -u "$JIRA_USER:$JIRA_API_TOKEN" \
-  -X POST \
-  -H "Content-Type: application/json" \
-  -H "Accept: application/json" \
-  "$JIRA_BASE_URL/rest/api/3/search/jql" \
-  -d '{"jql": "<jql as above>", "maxResults": 3, "fields": ["summary", "parent", "customfield_10014", "status"]}')
-```
-
-**GitHub Issues:**
-First resolve the authenticated username (don't use `@me` — it breaks with fine-grained PATs):
-```bash
-GITHUB_USERNAME=$(curl -s -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/user | jq -r '.login')
-```
-Then fetch issues:
-```bash
-RESPONSE=$(curl -s \
-  -H "Authorization: Bearer $GITHUB_TOKEN" \
-  -H "X-GitHub-Api-Version: 2022-11-28" \
-  "https://api.github.com/repos/$GITHUB_REPO/issues?state=open&assignee=$GITHUB_USERNAME&labels=clancy&per_page=3")
-# Filter out PRs (entries with pull_request key)
-```
-
-**Linear:**
-
-Build the filter — `CLANCY_LABEL` is optional:
-- Base filter: `state: { type: { eq: "unstarted" } }, team: { id: { eq: "$LINEAR_TEAM_ID" } }`
-- If `CLANCY_LABEL` is set: add `labels: { name: { eq: "$CLANCY_LABEL" } }` to the filter
-
-```graphql
-query {
-  viewer {
-    assignedIssues(
-      filter: { state: { type: { eq: "unstarted" } }, team: { id: { eq: "$LINEAR_TEAM_ID" } } [, labels: { name: { eq: "$CLANCY_LABEL" } }] }
-      first: 3
-      orderBy: priority
-    ) {
-      nodes { id identifier title parent { identifier title } }
-    }
-  }
-}
-```
-
----
-
-## Step 3 — Display
-
-If tickets found, display:
-```
-🚨 Clancy — Status
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Next up:
-
-1. [{TICKET-KEY}] {Summary}
-   Epic: {epic key} — {epic title}
-   Status: {status}
-
-2. [{TICKET-KEY}] {Summary}
-   Epic: {epic key} — {epic title}
-   Status: {status}
-
-3. [{TICKET-KEY}] {Summary}
-   Epic: {epic key} — {epic title}
-   Status: {status}
-
-"Let me check the dispatch..." — Run /clancy:once to pick up #1, or /clancy:run to process the queue.
-```
-
-If no tickets found:
-```
-🚨 Clancy — Status
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-No tickets found in the current queue.
-
-"Quiet. Too quiet." — Check your board or run /clancy:init to verify your config.
-```
-
-If API call fails, show the error clearly:
-```
-🚨 Clancy — Status
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-❌ Board API error: {error message}
-
-Tips:
-- Check your credentials in .clancy/.env
-- For Jira: ensure you have VPN access if required
-- Run /clancy:init to reconfigure
-```
-
----
-
-## Notes
-
-- Show up to 3 tickets. If only 1 or 2 are available, show those.
-- Omit "Epic:" line if no epic/parent data is present for that ticket.
-- This command is strictly read-only. No git ops, no file writes, no Claude invocation for analysis.
-- The query used here must be identical to the one used by the once-runner — what status shows is exactly what run would pick up.

package/src/roles/setup/commands/doctor.md

@@ -1,7 +0,0 @@
-# /clancy:doctor
-
-Diagnose your Clancy setup — test every configured integration and report what's working, what's broken, and how to fix it.
-
-@.claude/clancy/workflows/doctor.md
-
-Run the doctor workflow as documented above.

package/src/roles/setup/commands/help.md

@@ -1,80 +0,0 @@
-# /clancy:help
-
-List all Clancy commands with descriptions.
-
-Display the following:
-
----
-
-## Clancy — autonomous, board-driven development for Claude Code
-
-Named after Chief Clancy Wiggum (Ralph's dad, The Simpsons). Built on the Ralph technique
-coined by Geoffrey Huntley (ghuntley.com/ralph/). Clancy extends that foundation with board
-integration (6 boards), structured codebase docs, and a git workflow built for team development.
-
-**Supported boards:** Jira, GitHub Issues, Linear, Shortcut, Notion, Azure DevOps
-
-### Planner *(optional — enable via `CLANCY_ROLES=planner` in `.clancy/.env`)*
-
-| Command | Description |
-|---|---|
-| `/clancy:plan` | Refine backlog tickets into structured implementation plans |
-| `/clancy:plan 3` | Plan up to 3 tickets in batch mode |
-| `/clancy:plan PROJ-123` | Plan a specific ticket by key (also `#42`, `ENG-42`) |
-| `/clancy:plan --fresh` | Discard any existing plan and start from scratch |
-| `/clancy:approve-plan` | Promote an approved plan to the ticket description |
-
-### Strategist *(optional — enable via `CLANCY_ROLES=strategist` in `.clancy/.env`)*
-
-| Command | Description |
-|---|---|
-| `/clancy:brief` | Generate a strategic brief (research + grill + decomposition) |
-| `/clancy:approve-brief` | Convert a brief into tickets on the board |
-
-### Implementer
-
-| Command | Description |
-|---|---|
-| `/clancy:once` | Pick up one ticket and stop — good for first runs and debugging |
-| `/clancy:run` | Run in loop mode until queue is empty or MAX_ITERATIONS hit |
-| `/clancy:run 20` | Same, but override MAX_ITERATIONS to 20 for this session |
-| `/clancy:dry-run` | Preview next ticket without making any changes |
-
-### Reviewer
-
-| Command | Description |
-|---|---|
-| `/clancy:review` | Score next ticket (0–100%) with actionable recommendations |
-| `/clancy:status` | Show next tickets without running — read-only board check |
-| `/clancy:logs` | Format and display .clancy/progress.txt |
-
-### Setup & Maintenance
-
-| Command | Description |
-|---|---|
-| `/clancy:init` | Wizard — choose board, collect config, scaffold everything, offer map-codebase |
-| `/clancy:settings` | View and change configuration — model, iterations, board, and more |
-| `/clancy:doctor` | Diagnose your setup — test every integration and report what's broken |
-| `/clancy:map-codebase` | Full 5-agent parallel codebase scan, writes all 10 docs |
-| `/clancy:update-docs` | Incremental refresh — re-runs agents for changed areas only |
-| `/clancy:update` | Update Clancy to latest version via npx |
-| `/clancy:uninstall` | Remove Clancy commands — optionally remove `.clancy/` too |
-| `/clancy:help` | This screen |
-
-### How it works
-
-1. Run `/clancy:init` to connect your Kanban board and scaffold .clancy/
-2. Run `/clancy:map-codebase` to generate codebase docs (or say yes during init)
-3. Run `/clancy:dry-run` to preview the first ticket, then `/clancy:once` to run it — then go AFK with `/clancy:run`
-
-Clancy picks one ticket per loop, fresh context every iteration. No context rot.
-
-### Links
-
-- GitHub: github.com/Pushedskydiver/clancy
-- Issues: github.com/Pushedskydiver/clancy/issues
-- Lineage: ghuntley.com/ralph/
-
----
-
-Show this output exactly. Do not add, remove, or reformat any content.

package/src/roles/setup/commands/init.md

@@ -1,7 +0,0 @@
-# /clancy:init
-
-Set up Clancy in your project — choose your Kanban board, collect config, scaffold scripts and docs, and optionally scan your codebase.
-
-@.claude/clancy/workflows/init.md
-
-Run the full init wizard as documented in the workflow above. Follow every step exactly.

package/src/roles/setup/commands/map-codebase.md

@@ -1,16 +0,0 @@
-# /clancy:map-codebase
-
-Scan your codebase with 5 parallel specialist agents and write 10 structured docs to .clancy/docs/.
-
-Agents run simultaneously:
-- tech — STACK.md, INTEGRATIONS.md
-- arch — ARCHITECTURE.md
-- quality — CONVENTIONS.md, TESTING.md, GIT.md, DEFINITION-OF-DONE.md
-- design — DESIGN-SYSTEM.md, ACCESSIBILITY.md
-- concerns — CONCERNS.md
-
-Takes approximately 2 minutes for a typical codebase.
-
-@.claude/clancy/workflows/map-codebase.md
-
-Run the 5-agent scan as documented in the workflow above. Spawn all agents simultaneously.

package/src/roles/setup/commands/settings.md

@@ -1,7 +0,0 @@
-# /clancy:settings
-
-View and change Clancy configuration without re-running init.
-
-@.claude/clancy/workflows/settings.md
-
-Run the settings workflow as documented above.

package/src/roles/setup/commands/uninstall.md

@@ -1,5 +0,0 @@
-/clancy:uninstall
-
-Remove Clancy's slash commands from this project or your global Claude Code installation.
-
-@.claude/clancy/workflows/uninstall.md

package/src/roles/setup/commands/update-docs.md

@@ -1,9 +0,0 @@
-# /clancy:update-docs
-
-Incrementally refresh .clancy/docs/ — re-runs only the agents covering areas that have changed since the last scan.
-
-Faster than a full map-codebase when you've made targeted changes (new dependency, design system update, new test strategy, etc.).
-
-@.claude/clancy/workflows/update-docs.md
-
-Run the incremental update as documented in the workflow above.

package/src/roles/setup/commands/update.md

@@ -1,12 +0,0 @@
-# /clancy:update
-
-Update Clancy itself to the latest version via npx and show what changed.
-
-This re-runs the installer, which copies the latest command files from the npm package into your .claude/commands/clancy/ directory. Your .clancy/ project folder (scripts, docs, progress log) is never touched.
-
-**Supported flags:**
-- `--afk` — skip the confirmation prompt and auto-approve the update (for autonomous setups)
-
-@.claude/clancy/workflows/update.md
-
-Run the update as documented in the workflow above. If `--afk` is passed, skip all confirmation prompts.

package/src/roles/setup/workflows/doctor.md

@@ -1,124 +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 Doctor Workflow
-
-## Overview
-
-Diagnose your Clancy setup — test every configured integration and report what's working, what's broken, and how to fix it. Never modifies any files or state.
-
----
-
-## Step 1 — Check install
-
-- Verify Clancy commands are installed (`.claude/commands/clancy/` or `~/.claude/commands/clancy/`)
-- Read installed version from `package.json` in the commands directory
-- Print: `✅ Clancy v{version} installed ({location})`
-
----
-
-## Step 2 — Check prerequisites
-
-Test each required binary:
-
-| Binary | Check | Fix hint |
-|---|---|---|
-| `node` | `command -v node` | Install Node.js 22+ |
-| `git` | `command -v git` | Install git for your OS |
-
-Print `✅` or `❌` for each.
-
----
-
-## Step 3 — Check project setup
-
-- `.clancy/` exists → `✅ .clancy/ found`
-- `.clancy/clancy-once.js` exists → `✅ clancy-once.js`
-- `.clancy/clancy-afk.js` exists → `✅ clancy-afk.js`
-- `.clancy/.env` exists → `✅ .clancy/.env found`
-- `.clancy/docs/` has non-empty files → `✅ codebase docs present ({N} files)`
-
-If `.clancy/` is missing: `❌ .clancy/ not found — run /clancy:init`
-If `.clancy/.env` is missing: `❌ .clancy/.env not found — run /clancy:init`
-
----
-
-## Step 4 — Check board credentials
-
-Source `.clancy/.env` and detect which board is configured:
-
-**Jira** — if `JIRA_BASE_URL` is set:
-1. Check all required vars are non-empty: `JIRA_BASE_URL`, `JIRA_USER`, `JIRA_API_TOKEN`, `JIRA_PROJECT_KEY`
-2. Ping: `GET {JIRA_BASE_URL}/rest/api/3/project/{JIRA_PROJECT_KEY}` with basic auth
-3. Report HTTP status with specific guidance for each failure code
-
-**GitHub Issues** — if `GITHUB_TOKEN` is set:
-1. Check: `GITHUB_TOKEN`, `GITHUB_REPO`
-2. Ping: `GET https://api.github.com/repos/{GITHUB_REPO}` with bearer token
-3. Report status
-
-**Linear** — if `LINEAR_API_KEY` is set:
-1. Check: `LINEAR_API_KEY`, `LINEAR_TEAM_ID`
-2. Ping: `POST https://api.linear.app/graphql` with `{ viewer { id } }` — no Bearer prefix
-3. Report status
-
----
-
-## Step 5 — Check optional integrations
-
-**Figma** — if `FIGMA_API_KEY` is set:
-- Call `GET https://api.figma.com/v1/me` with `X-Figma-Token: $FIGMA_API_KEY`
-- On success: print `✅ Figma connected — {email}`
-- On 403: print `❌ Figma authentication failed. Check FIGMA_API_KEY in .clancy/.env.`
-- Note: Figma's API does not expose plan information — check your plan at figma.com/settings
-
-**Playwright** — if `PLAYWRIGHT_ENABLED=true`:
-- Check `.clancy/docs/PLAYWRIGHT.md` exists
-- Verify `PLAYWRIGHT_DEV_COMMAND` and `PLAYWRIGHT_DEV_PORT` are set
-- Check port is not currently in use (just a status, not a blocker)
-
-**Notifications** — if `CLANCY_NOTIFY_WEBHOOK` is set:
-- Detect platform from URL (Slack/Teams)
-- Send a test ping: `"Clancy doctor — webhook test from {project dir}"`
-- Report success or failure
-
----
-
-## Step 6 — Summary
-
-```
-🚨 Clancy — Doctor
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-{N} checks passed, {N} warnings, {N} failures
-
-✅ Clancy v0.1.0 installed (global)
-✅ node, git — all present
-✅ .clancy/ set up — 10 docs present
-✅ Jira connected — PROJ reachable
-✅ Figma connected — alex@example.com (check plan at figma.com/settings)
-❌ PLAYWRIGHT_STORYBOOK_PORT — not set in .clancy/.env
-
-Fix the ❌ items, then run /clancy:once to verify end-to-end.
-
-"We've got a 415 in progress — a config disturbance."
-```
-
-If all checks pass:
-```
-🚨 Clancy — Doctor
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-All {N} checks passed.
-
-"Nothing to see here, folks. Move along." — Run /clancy:once to pick up your first ticket.
-```