@chief-clancy/terminal 0.1.0

package/src/roles/reviewer/commands/logs.md

@@ -0,0 +1,7 @@
+# /clancy:logs
+
+Format and display .clancy/progress.txt — tickets completed, dates, epics, and progress bars by epic.
+
+@.claude/clancy/workflows/logs.md
+
+Display the progress log as documented in the workflow above.

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

@@ -0,0 +1,9 @@
+# /clancy:review
+
+Fetch the next ticket from the board and score it — returns a confidence score (0–100%) and actionable recommendations before you run.
+
+Does not implement anything. Read-only from Clancy's perspective, though it invokes Claude for analysis.
+
+@.claude/clancy/workflows/review.md
+
+Score the ticket as documented in the workflow above, including the full 7-criterion rubric and confidence bands.

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

@@ -0,0 +1,9 @@
+# /clancy:status
+
+Show the next tickets Clancy would pick up — read-only board check, no side effects.
+
+Fetches up to 3 tickets from the queue using the same query as /clancy:implement, so what you see here is exactly what Clancy would run next.
+
+@.claude/clancy/workflows/status.md
+
+Show status as documented in the workflow above. Strictly read-only — no git operations, no file writes, no ticket claiming.

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

@@ -0,0 +1,109 @@
+# Clancy Logs Workflow
+
+## Overview
+
+Read `.clancy/progress.txt` and present a formatted summary.
+
+---
+
+## Step 1 — Check file exists
+
+If `.clancy/progress.txt` does not exist:
+
+```
+🚨 Clancy — Logs
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+No progress logged yet.
+
+"The law is powerless to help you... but not for long." — Run /clancy:implement or /clancy:autopilot to get started.
+```
+
+Stop.
+
+---
+
+## Step 2 — Parse progress.txt
+
+Each line has one of these formats:
+
+- `YYYY-MM-DD HH:MM | TICKET-KEY | Summary | DONE` — completed implementation
+- `YYYY-MM-DD HH:MM | TICKET-KEY | REVIEW | {score}%` — ticket review
+- `YYYY-MM-DD HH:MM | TICKET-KEY | PLAN | {S/M/L}` — plan generated
+- `YYYY-MM-DD HH:MM | TICKET-KEY | REVISED | {S/M/L}` — plan revised after feedback
+- `YYYY-MM-DD HH:MM | TICKET-KEY | APPROVE_PLAN | —` — plan promoted to description
+- `YYYY-MM-DD HH:MM | TICKET-KEY | SKIPPED | {reason}` — ticket skipped
+- `YYYY-MM-DD HH:MM | TICKET-KEY | POST_FAILED | {reason}` — failed to post comment to board
+- `YYYY-MM-DD HH:MM | BRIEF | {slug} | {N} proposed tickets` — brief generated (slug-based format)
+- `YYYY-MM-DD HH:MM | APPROVE_BRIEF | {slug} | {N} tickets created` — brief approved (slug-based format)
+
+Parse each line:
+
+- Date (YYYY-MM-DD)
+- Time (HH:MM)
+- Key or status (BRIEF/APPROVE_BRIEF entries put the status here, standard entries put the ticket key)
+- Detail (status, score, size, reason, or slug for brief entries)
+
+Extract:
+
+- Total DONE tickets
+- First and latest run dates
+- All DONE tickets from the current calendar week (Mon–Sun)
+- Counts for each action type: PLAN, REVISED, APPROVE_PLAN, REVIEW, SKIPPED, POST_FAILED, BRIEF, APPROVE_BRIEF
+- Epic key from ticket key — e.g. PROJ-42 → epic likely PROJ-10 (use parent field if logged, otherwise group by project prefix)
+
+---
+
+## Step 3 — Display
+
+If only 1–3 DONE entries: show a flat list, skip grouping.
+
+If 4+ entries, show the full grouped display:
+
+```
+🚨 Clancy — Logs
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Total tickets completed: {count}
+First run: {YYYY-MM-DD}
+Latest run: {YYYY-MM-DD}
+
+This week ({Mon date}–{Sun date or today}):
+  ✅ {TICKET-KEY}  {Summary}
+  ✅ {TICKET-KEY}  {Summary}
+  ...
+
+By epic:
+  {EPIC-KEY} {Epic name or prefix}  {bar}  {count} tickets
+  {EPIC-KEY} {Epic name or prefix}  {bar}  {count} tickets
+  (other)                           {bar}  {count} tickets
+
+Plans generated: {N}      (only show if > 0)
+Plans revised: {N}        (only show if > 0)
+Plans approved: {N}       (only show if > 0)
+Briefs generated: {N}     (only show if > 0)
+Briefs approved: {N}      (only show if > 0)
+Reviews run: {N}          (only show if > 0)
+Tickets skipped: {N}      (only show if > 0)
+Post failures: {N}        (only show if > 0)
+Full log: .clancy/progress.txt
+
+"The law is powerless to help you, but here's what Clancy's done."
+```
+
+### Display rules
+
+- Show "this week" at the top — most recent activity is most relevant
+- Cap "this week" at 10 entries. If more: "...and {n} more this week"
+- Progress bars: ASCII, proportional to highest count, width 10 chars, `█` filled, `░` empty
+- Epic grouping: group by epic key in the ticket's parent field (from progress.txt if logged), or by project prefix if not available
+- Tickets without an epic: group under `(other)`
+- REVIEW, PLAN, REVISED, APPROVE_PLAN, BRIEF, APPROVE_BRIEF, SKIPPED, and POST_FAILED lines: shown separately at the end as counts — not included in ticket count
+
+---
+
+## Notes
+
+- No external dependencies — all ASCII, all bash-parseable
+- The full log is always available at `.clancy/progress.txt` for raw access
+- `--all` flag to remove the "this week" cap is a v2 addition — do not implement in v1

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

@@ -0,0 +1,197 @@
+# 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_BUILD"` if `CLANCY_LABEL_BUILD` is set (falls back to `CLANCY_LABEL`)
+- `CLANCY_JQL_STATUS` defaults to `To Do` if not set
+
+Full JQL: `project=$JIRA_PROJECT_KEY [AND sprint in openSprints()] [AND labels = "$CLANCY_LABEL_BUILD"] 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_LABEL_BUILD&per_page=1` — filter out PRs (entries with `pull_request` key). Use `CLANCY_LABEL_BUILD` from `.clancy/.env` (falls back to `CLANCY_LABEL`, defaults to `clancy`).
+
+**Linear:** GraphQL `viewer.assignedIssues` with `filter: { state: { type: { eq: "unstarted" } }, team: { id: { eq: "$LINEAR_TEAM_ID" } }[, labels: { name: { eq: "$CLANCY_LABEL_BUILD" } }] }` (label clause only if `CLANCY_LABEL_BUILD` is set, falls back to `CLANCY_LABEL`), `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:implement."                        |
+| 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:implement 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:implement.`
+- **🟠 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

@@ -0,0 +1,142 @@
+# 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_BUILD"` if `CLANCY_LABEL_BUILD` is set (falls back to `CLANCY_LABEL`)
+- `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_BUILD"] 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_LABEL_BUILD&per_page=3")
+# Filter out PRs (entries with pull_request key)
+```
+
+**Linear:**
+
+Build the filter — `CLANCY_LABEL_BUILD` is optional (falls back to `CLANCY_LABEL`):
+
+- Base filter: `state: { type: { eq: "unstarted" } }, team: { id: { eq: "$LINEAR_TEAM_ID" } }`
+- If `CLANCY_LABEL_BUILD` is set (or `CLANCY_LABEL` fallback): add `labels: { name: { eq: "$CLANCY_LABEL_BUILD" } }` to the filter
+
+```graphql
+query {
+  viewer {
+    assignedIssues(
+      filter: { state: { type: { eq: "unstarted" } }, team: { id: { eq: "$LINEAR_TEAM_ID" } } [, labels: { name: { eq: "$CLANCY_LABEL_BUILD" } }] }
+      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:implement to pick up #1, or /clancy:autopilot 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/roles.test.ts

@@ -0,0 +1,87 @@
+/**
+ * Structural tests for role markdown files.
+ *
+ * Verifies the roles directory contains the expected roles and subdirectories
+ * that the installer's role-filter module depends on.
+ */
+import { readdirSync, readFileSync } from 'node:fs';
+import { join } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+import { describe, expect, it } from 'vitest';
+
+const ROLES_DIR = fileURLToPath(new URL('.', import.meta.url));
+
+const CORE_ROLES = ['implementer', 'reviewer', 'setup'];
+const OPTIONAL_ROLES = ['planner', 'strategist'];
+const ALL_ROLES = [...CORE_ROLES, ...OPTIONAL_ROLES].sort();
+
+const SUBDIRS = ['commands', 'workflows'];
+
+describe('roles directory structure', () => {
+  it('contains exactly the expected roles', () => {
+    const roles = readdirSync(ROLES_DIR, { withFileTypes: true })
+      .filter((d) => d.isDirectory())
+      .map((d) => d.name)
+      .sort();
+
+    expect(roles).toEqual(ALL_ROLES);
+  });
+
+  ALL_ROLES.forEach((role) => {
+    describe(role, () => {
+      SUBDIRS.forEach((subdir) => {
+        it(`has a ${subdir}/ subdirectory with .md files`, () => {
+          const dir = join(ROLES_DIR, role, subdir);
+          const files = readdirSync(dir).filter((f) => f.endsWith('.md'));
+
+          expect(files.length).toBeGreaterThan(0);
+        });
+      });
+    });
+  });
+
+  SUBDIRS.forEach((subdir) => {
+    it(`has no duplicate filenames across roles in ${subdir}/`, () => {
+      const seen = new Map<string, string>();
+      const duplicates: string[] = [];
+
+      ALL_ROLES.forEach((role) => {
+        const dir = join(ROLES_DIR, role, subdir);
+        const files = readdirSync(dir).filter((f) => f.endsWith('.md'));
+
+        files.forEach((file) => {
+          const existing = seen.get(file);
+
+          if (existing) {
+            duplicates.push(`${file} in both ${existing} and ${role}`);
+          } else {
+            seen.set(file, role);
+          }
+        });
+      });
+
+      expect(duplicates).toEqual([]);
+    });
+  });
+
+  it('all command files start with a heading', () => {
+    const issues: string[] = [];
+
+    ALL_ROLES.forEach((role) => {
+      const cmdDir = join(ROLES_DIR, role, 'commands');
+      const files = readdirSync(cmdDir).filter((f) => f.endsWith('.md'));
+
+      files.forEach((file) => {
+        const content = readFileSync(join(cmdDir, file), 'utf8');
+        const firstLine = content.split('\n')[0]?.trim() ?? '';
+
+        if (!firstLine.startsWith('#')) {
+          issues.push(`${role}/commands/${file}`);
+        }
+      });
+    });
+
+    expect(issues).toEqual([]);
+  });
+});

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

@@ -0,0 +1,7 @@
+# /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

@@ -0,0 +1,80 @@
+# /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:implement`    | Pick up one ticket and stop — good for first runs and debugging |
+| `/clancy:autopilot`    | Run in loop mode until queue is empty or MAX_ITERATIONS hit     |
+| `/clancy:autopilot 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:implement` to run it — then go AFK with `/clancy:autopilot`
+
+Clancy picks one ticket per loop, fresh context every iteration. No context rot.
+
+### Links
+
+- GitHub: github.com/Pushedskydiver/chief-clancy
+- Issues: github.com/Pushedskydiver/chief-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

@@ -0,0 +1,7 @@
+# /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.