chief-clancy 0.8.22 → 0.9.0

package/hooks/clancy-notification.js

@@ -1,105 +0,0 @@
-#!/usr/bin/env node
-// Clancy Desktop Notification — Notification hook.
-// Sends native OS desktop notifications when Claude fires a Notification event.
-// Best-effort — never crashes, exit 0 on any error.
-//
-// Controllable via CLANCY_DESKTOP_NOTIFY=false to suppress.
-//
-// Platform detection:
-//   macOS:   osascript -e 'display notification "msg" with title "Clancy"'
-//   Linux:   notify-send "Clancy" "msg"
-//   Windows: PowerShell [System.Windows.Forms.MessageBox]::Show("msg", "Clancy")
-
-'use strict';
-
-const { execFileSync } = require('child_process');
-const os = require('os');
-
-/**
- * Detect the platform and return a function that sends a notification.
- * Returns null if the platform is unsupported.
- */
-function getNotifier() {
-  const platform = os.platform();
-
-  if (platform === 'darwin') {
-    return function notifyMac(message) {
-      const escaped = message.replace(/"/g, '\\"');
-      execFileSync('osascript', [
-        '-e',
-        `display notification "${escaped}" with title "Clancy"`,
-      ], { timeout: 5000, windowsHide: true });
-    };
-  }
-
-  if (platform === 'linux') {
-    return function notifyLinux(message) {
-      execFileSync('notify-send', ['Clancy', message], {
-        timeout: 5000,
-        windowsHide: true,
-      });
-    };
-  }
-
-  if (platform === 'win32') {
-    return function notifyWindows(message) {
-      const escaped = message.replace(/[`$"]/g, '`$&');
-      execFileSync('powershell', [
-        '-NoProfile',
-        '-Command',
-        `Add-Type -AssemblyName System.Windows.Forms; [System.Windows.Forms.MessageBox]::Show("${escaped}", "Clancy")`,
-      ], { timeout: 5000, windowsHide: true });
-    };
-  }
-
-  return null;
-}
-
-/**
- * Extract a message string from the hook event payload.
- */
-function extractMessage(data) {
-  // Notification events may carry a message in various shapes
-  if (data.message && typeof data.message === 'string') return data.message;
-  if (data.notification && typeof data.notification === 'string') return data.notification;
-  if (data.text && typeof data.text === 'string') return data.text;
-  if (data.hookSpecificOutput && data.hookSpecificOutput.message) return data.hookSpecificOutput.message;
-  return 'Clancy notification';
-}
-
-let input = '';
-const stdinTimeout = setTimeout(() => process.exit(0), 3000);
-process.stdin.setEncoding('utf8');
-process.stdin.on('data', chunk => { input += chunk; });
-process.stdin.on('end', () => {
-  clearTimeout(stdinTimeout);
-  try {
-    // Check if notifications are disabled
-    if (process.env.CLANCY_DESKTOP_NOTIFY === 'false') {
-      process.exit(0);
-    }
-
-    const data = JSON.parse(input);
-    const message = extractMessage(data);
-
-    const notifier = getNotifier();
-    if (notifier) {
-      try {
-        notifier(message);
-      } catch {
-        // OS command failed — fall back to console.log
-        console.log(`[Clancy] ${message}`);
-      }
-    } else {
-      // Unsupported platform — fall back to console.log
-      console.log(`[Clancy] ${message}`);
-    }
-  } catch {
-    process.exit(0);
-  }
-});
-
-// Export for testing
-if (typeof module !== 'undefined') {
-  module.exports = { getNotifier, extractMessage };
-}

package/hooks/clancy-post-compact.js

@@ -1,53 +0,0 @@
-#!/usr/bin/env node
-// Clancy PostCompact Hook — re-injects ticket context after context compaction.
-// Reads .clancy/lock.json for current ticket info. If no lock file exists
-// (not in a Clancy run), exits silently.
-//
-// PostCompact is a non-blocking event — this hook injects additionalContext
-// but cannot prevent compaction.
-
-'use strict';
-
-const fs = require('fs');
-const path = require('path');
-
-let input = '';
-const stdinTimeout = setTimeout(() => process.exit(0), 3000);
-process.stdin.setEncoding('utf8');
-process.stdin.on('data', chunk => { input += chunk; });
-process.stdin.on('end', () => {
-  clearTimeout(stdinTimeout);
-  try {
-    const data = JSON.parse(input);
-    const cwd = data.cwd || process.cwd();
-
-    // Read lock file for ticket context
-    const lockPath = path.join(cwd, '.clancy', 'lock.json');
-    if (!fs.existsSync(lockPath)) process.exit(0); // Not in a Clancy run
-
-    const lock = JSON.parse(fs.readFileSync(lockPath, 'utf8'));
-
-    // Validate minimum required fields — skip if lock is malformed
-    if (!lock.ticketKey || !lock.ticketBranch) process.exit(0);
-
-    // Truncate description to 2000 chars to avoid consuming too much fresh context
-    const desc = (lock.description || '').slice(0, 2000);
-
-    const context = [
-      `CONTEXT RESTORED: You are implementing ticket [${lock.ticketKey}] ${lock.ticketTitle || 'Unknown'}.`,
-      `Branch: ${lock.ticketBranch} targeting ${lock.targetBranch || 'main'}.`,
-      lock.parentKey && lock.parentKey !== 'none' ? `Parent: ${lock.parentKey}.` : '',
-      desc ? `Requirements: ${desc}` : '',
-      'Continue your implementation. Do not start over.',
-    ].filter(Boolean).join('\n');
-
-    process.stdout.write(JSON.stringify({
-      hookSpecificOutput: {
-        hookEventName: 'PostCompact',
-        additionalContext: context,
-      },
-    }));
-  } catch {
-    process.exit(0); // Best-effort — never crash
-  }
-});

package/hooks/clancy-statusline.js

@@ -1,82 +0,0 @@
-#!/usr/bin/env node
-// Clancy Statusline hook — registered as the Claude Code statusline.
-// Two jobs:
-//   1. Write context metrics to a bridge file so the PostToolUse context
-//      monitor can read them (the statusline is the only hook that receives
-//      context_window data directly).
-//   2. Output a statusline string showing context usage and update status.
-
-'use strict';
-
-const fs = require('fs');
-const path = require('path');
-const os = require('os');
-
-const homeDir = os.homedir();
-
-let input = '';
-const stdinTimeout = setTimeout(() => process.exit(0), 3000);
-process.stdin.setEncoding('utf8');
-process.stdin.on('data', chunk => { input += chunk; });
-process.stdin.on('end', () => {
-  clearTimeout(stdinTimeout);
-  try {
-    const data = JSON.parse(input);
-    const session = data.session_id || '';
-    const remaining = data.context_window?.remaining_percentage;
-
-    // Write bridge file for the context monitor PostToolUse hook
-    if (session && remaining != null) {
-      try {
-        const bridgePath = path.join(os.tmpdir(), `clancy-ctx-${session}.json`);
-        // Claude Code reserves ~16.5% for autocompact buffer.
-        // Normalise to show 100% at the usable limit (same as GSD).
-        const AUTO_COMPACT_BUFFER_PCT = 16.5;
-        const usableRemaining = Math.max(0, ((remaining - AUTO_COMPACT_BUFFER_PCT) / (100 - AUTO_COMPACT_BUFFER_PCT)) * 100);
-        const used = Math.max(0, Math.min(100, Math.round(100 - usableRemaining)));
-        fs.writeFileSync(bridgePath, JSON.stringify({
-          session_id: session,
-          remaining_percentage: remaining,
-          used_pct: used,
-          timestamp: Math.floor(Date.now() / 1000),
-        }));
-      } catch { /* bridge is best-effort */ }
-    }
-
-    // Build statusline output
-    const parts = [];
-
-    // Update available?
-    const claudeDir = process.env.CLAUDE_CONFIG_DIR || path.join(homeDir, '.claude');
-    const cacheFile = path.join(claudeDir, 'cache', 'clancy-update-check.json');
-    try {
-      const cache = JSON.parse(fs.readFileSync(cacheFile, 'utf8'));
-      if (cache.update_available) {
-        parts.push('\x1b[33m⬆ /clancy:update\x1b[0m');
-      }
-    } catch { /* cache missing is normal */ }
-
-    // Context bar
-    if (remaining != null) {
-      const AUTO_COMPACT_BUFFER_PCT = 16.5;
-      const usableRemaining = Math.max(0, ((remaining - AUTO_COMPACT_BUFFER_PCT) / (100 - AUTO_COMPACT_BUFFER_PCT)) * 100);
-      const used = Math.max(0, Math.min(100, Math.round(100 - usableRemaining)));
-      const filled = Math.floor(used / 10);
-      const bar = '█'.repeat(filled) + '░'.repeat(10 - filled);
-
-      let coloredBar;
-      if (used < 50)      coloredBar = `\x1b[32m${bar} ${used}%\x1b[0m`;
-      else if (used < 65) coloredBar = `\x1b[33m${bar} ${used}%\x1b[0m`;
-      else if (used < 80) coloredBar = `\x1b[38;5;208m${bar} ${used}%\x1b[0m`;
-      else                coloredBar = `\x1b[5;31m💀 ${bar} ${used}%\x1b[0m`;
-
-      parts.push(`\x1b[2mClancy\x1b[0m ${coloredBar}`);
-    } else {
-      parts.push('\x1b[2mClancy\x1b[0m');
-    }
-
-    process.stdout.write(parts.join(' │ '));
-  } catch {
-    process.exit(0);
-  }
-});

package/hooks/package.json

@@ -1,3 +0,0 @@
-{
-  "type": "commonjs"
-}

package/registry/boards.json

@@ -1,44 +0,0 @@
-{
-  "boards": [
-    {
-      "id": "jira",
-      "name": "Jira",
-      "author": "Atlassian",
-      "url": "https://www.atlassian.com/software/jira",
-      "env": [
-        "JIRA_BASE_URL",
-        "JIRA_USER",
-        "JIRA_API_TOKEN",
-        "JIRA_PROJECT_KEY",
-        "CLANCY_JQL_STATUS",
-        "CLANCY_JQL_SPRINT",
-        "CLANCY_LABEL",
-        "CLANCY_BASE_BRANCH"
-      ]
-    },
-    {
-      "id": "github",
-      "name": "GitHub Issues",
-      "author": "GitHub",
-      "url": "https://github.com",
-      "env": [
-        "GITHUB_TOKEN",
-        "GITHUB_REPO",
-        "CLANCY_LABEL",
-        "CLANCY_BASE_BRANCH"
-      ]
-    },
-    {
-      "id": "linear",
-      "name": "Linear",
-      "author": "Linear",
-      "url": "https://linear.app",
-      "env": [
-        "LINEAR_API_KEY",
-        "LINEAR_TEAM_ID",
-        "CLANCY_LABEL",
-        "CLANCY_BASE_BRANCH"
-      ]
-    }
-  ]
-}

package/src/agents/arch-agent.md

@@ -1,72 +0,0 @@
-# Architecture Agent
-
-You are the architecture agent for Clancy's `map-codebase` command. Your job is to write one doc:
-- `.clancy/docs/ARCHITECTURE.md`
-
-## Instructions
-
-1. Use Glob and Grep extensively before writing anything. Understand the actual structure — never guess.
-2. Use real file paths in your output.
-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
-
-Start by exploring the directory structure:
-- Top-level directories (src, app, lib, packages, etc.)
-- Key subdirectories and what they contain
-- Entry points (main.tsx, index.ts, app/layout.tsx, etc.)
-
-Then dig into:
-
-**Overview** — One paragraph describing what the system does and how it's structured. Is it a monorepo? SPA? Full-stack app? API-only? Edge functions?
-
-**Directory Structure** — Annotated directory tree. Use `tree`-style output. Annotate each directory with its purpose:
-```
-src/
-  components/    — shared UI components
-  pages/         — Next.js pages (file-based routing)
-  lib/           — utility functions and shared logic
-  hooks/         — custom React hooks
-  store/         — Zustand/Redux/Jotai state
-  types/         — TypeScript type definitions
-  styles/        — global CSS, theme tokens
-```
-
-**Key Modules** — For each significant module/service, describe:
-- What it does
-- Its public interface (exports)
-- Key dependencies
-- File path
-
-**Data Flow** — How data moves through the system. Be specific:
-- Where does data enter? (API routes, form submissions, websockets)
-- How is it fetched? (SWR, React Query, server components, tRPC)
-- How is state managed? (local, global store, server state)
-- Where does it leave? (rendered to DOM, sent to API, stored in DB)
-
-Include a real data flow example from the codebase if possible.
-
-**API Design** — If the project has an API layer:
-- Route structure and conventions
-- Auth pattern (JWT, session, API key)
-- Request/response patterns
-- Error handling conventions
-- Real example from the codebase
-
-**State Management** — If applicable:
-- Library used (Zustand, Jotai, Redux, Context, etc.)
-- Store structure
-- Where stores are initialised
-- Real example of a store slice/atom
-
----
-
-## Output format
-
-Write the doc, then respond with:
-```
-arch agent complete — ARCHITECTURE.md ({N} lines)
-```

package/src/agents/concerns-agent.md

@@ -1,89 +0,0 @@
-# Concerns Agent
-
-You are the concerns agent for Clancy's `map-codebase` command. Your job is to write one doc:
-- `.clancy/docs/CONCERNS.md`
-
-This doc warns Clancy about things to avoid — tech debt, security landmines, fragile areas, deprecated patterns. It's the "don't touch this" and "be careful here" guide.
-
-## Instructions
-
-1. Use Glob and Grep extensively. Look for warning signs, not just clean code.
-2. Use real file paths in your output.
-3. Be direct and specific — "avoid touching src/lib/legacy-auth.ts" not "there are some legacy files"
-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
-
-### Known Tech Debt
-
-Scan for:
-- `// TODO`, `// FIXME`, `// HACK`, `// XXX` comments
-- Files named `legacy`, `old`, `deprecated`, `temp`, `workaround`
-- Commented-out code blocks
-- `@deprecated` JSDoc tags
-- `console.log` left in source (excluding test files)
-
-For each significant item: file path, line range, what the debt is, and what risks touching it carries.
-
-### Security Considerations
-
-Scan for:
-- Hardcoded credentials or API keys (flag but do not expose values)
-- `dangerouslySetInnerHTML` usage — where and is it sanitised?
-- SQL query construction (injection risk if dynamic)
-- File system access without path validation
-- `eval()` or `Function()` usage
-- Disabled security headers
-- CORS wildcard (`Access-Control-Allow-Origin: *`)
-- Cookie settings (httpOnly, secure, sameSite)
-
-Flag: what it is, where it is, what the risk is, whether it's intentional (e.g. test code).
-
-### Performance Bottlenecks
-
-Look for:
-- Large bundle imports without tree-shaking
-- Missing memoisation on expensive computations (large list renders, heavy calculations)
-- Unoptimised images (no `next/image`, no lazy loading)
-- N+1 query patterns in data fetching code
-- Synchronous operations in render paths
-- Large files (> 500 lines) that are imported widely
-
-### Areas to Avoid Changing
-
-Based on what you've found, list files/directories that are:
-- Generated code (never edit directly)
-- Shared across many features (high blast radius)
-- Poorly tested (risky to modify)
-- Currently broken/under investigation
-
-Example format:
-```markdown
-## Areas to Avoid Changing
-
-- `src/generated/` — auto-generated from OpenAPI spec, run `yarn generate` to update
-- `src/lib/payment/stripe.ts` — payment critical path, 0 tests, modify with extreme caution
-- `src/components/DataTable/` — complex state machine, many edge cases, avoid refactoring
-```
-
-### Deprecated Patterns
-
-Document patterns that appear in the codebase but should NOT be used in new code:
-
-- Old API client that was replaced (but old code still uses it)
-- Class components vs function components (if mixed)
-- Old state management approach being migrated away from
-- Deprecated library APIs still in use
-
-For each: what the old pattern is, what the new pattern is, where the new pattern is used.
-
----
-
-## Output format
-
-Write the doc, then respond with:
-```
-concerns agent complete — CONCERNS.md ({N} lines)
-```

package/src/agents/design-agent.md

@@ -1,130 +0,0 @@
-# Design Agent
-
-You are the design agent for Clancy's `map-codebase` command. Your job is to write two docs:
-- `.clancy/docs/DESIGN-SYSTEM.md`
-- `.clancy/docs/ACCESSIBILITY.md`
-
-This is Clancy's differentiator — thorough design system documentation helps the AI implement UI tickets that actually match the existing visual language.
-
-## Instructions
-
-1. Use Glob and Grep extensively before writing anything. Look at actual CSS, tokens, and components.
-2. Use real file paths in your output.
-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
-
-### DESIGN-SYSTEM.md
-
-Start by looking for:
-- `tailwind.config.*` — Tailwind tokens and extensions
-- CSS custom properties in global CSS files
-- Design token files (`.json`, `.js`, `.ts` with color/spacing/typography values)
-- Component library usage (shadcn/ui, Radix, MUI, Ant Design, Chakra, etc.)
-- Storybook if present (`.storybook/`, `*.stories.tsx`)
-- Figma reference links in README or component files
-
-Document:
-
-**Token System** — All design tokens with actual values. This is critical — show the full token set:
-
-```markdown
-## Colours
-| Token | Value | Usage |
-|---|---|---|
-| `--color-primary` | `#6366f1` | Primary actions, links |
-| `--color-primary-hover` | `#4f46e5` | Hover state |
-...
-
-## Spacing
-Base unit: 4px (0.25rem)
-| Token | Value |
-|---|---|
-| `space-1` | 4px |
-| `space-2` | 8px |
-...
-
-## Typography
-| Token | Value |
-|---|---|
-| `--font-sans` | `Inter, system-ui, sans-serif` |
-| `--font-size-sm` | `0.875rem` (14px) |
-...
-
-## Border radius
-...
-
-## Shadows
-...
-```
-
-If using Tailwind, extract the `theme.extend` values from `tailwind.config.*`.
-
-**Component Library** — What component library is used?
-- Name and version
-- Import pattern (real example)
-- How components are composed
-- Any customisation layer on top of the library
-- Where custom components live
-
-**Theming** — Light/dark mode? How is it implemented? (CSS variables, `data-theme`, `prefers-color-scheme`, next-themes, etc.)
-
-**Responsive Breakpoints** — List all breakpoints with actual values:
-```
-sm:  640px
-md:  768px
-lg:  1024px
-xl:  1280px
-2xl: 1536px
-```
-
-**Icon System** — What icon library is used (Lucide, Heroicons, Phosphor, etc.)? Import pattern. Size conventions.
-
-**Animation** — Any animation utilities or tokens? Transition durations? Easing functions?
-
----
-
-### ACCESSIBILITY.md
-
-Read:
-- `axe` or `jest-axe` config if present
-- ARIA attributes in existing components (Grep for `aria-`, `role=`)
-- Focus management code
-- Screen reader-specific markup
-- Colour contrast values in design tokens
-
-Document:
-
-**WCAG Level** — Is there an explicit target? (AA is common). If not stated, infer from the codebase.
-
-**ARIA Patterns** — Document the patterns actually used in this codebase:
-- Modal/dialog: how is focus trapped, which ARIA attributes are used?
-- Navigation: `nav`, `aria-current`, skip links?
-- Form fields: `aria-label`, `aria-describedby`, error announcement?
-- Real code examples for each pattern
-
-**Keyboard Navigation** — What keyboard interactions are implemented?
-- Tab order conventions
-- Escape key handling
-- Arrow key navigation (dropdowns, menus, carousels)
-
-**Focus Management** — How is focus managed programmatically?
-- Focus trap implementation
-- Return focus patterns
-- Real example from codebase
-
-**Screen Reader Support** — Live regions, announcements, visually hidden text patterns used.
-
-**Testing** — Is `axe` or `jest-axe` used in tests? Show the pattern if so.
-
----
-
-## Output format
-
-Write both docs, then respond with:
-```
-design agent complete — DESIGN-SYSTEM.md ({N} lines), ACCESSIBILITY.md ({N} lines)
-```

package/src/agents/devils-advocate.md

@@ -1,53 +0,0 @@
-# Devil's Advocate Agent
-
-You are the devil's advocate agent for Clancy's strategist role. Your job is to answer a list of clarifying questions about a feature idea by interrogating the codebase, board, and web — then classify each answer by confidence.
-
-You receive 10-15 clarifying questions generated during the AI-grill phase of `/clancy:brief --afk`. You must answer them autonomously. Never ask the human for input — this runs in AFK mode with no human present.
-
-## Instructions
-
-1. Work through each question one at a time. For every question, investigate before answering — never guess.
-2. Interrogate three sources in order of preference:
-   - **Codebase**: use Glob, Grep, and Read to explore affected areas, check `.clancy/docs/`, read existing patterns. Use real file paths and code snippets as evidence.
-   - **Board**: check the parent ticket, related tickets, and existing children for context. Look for conflicting requirements.
-   - **Web**: when the question involves external technology, third-party integrations, or industry patterns, use WebSearch and WebFetch.
-3. Challenge your own answers. If the codebase says one thing but the ticket description says another, flag the conflict — do not silently pick one.
-4. Follow self-generated follow-ups within the same pass. If answering a question raises a new sub-question, chase it to its conclusion before moving on. Example: "Should this support SSO?" → check codebase → find SAML provider → "SAML exists but should the new feature use SAML or add OIDC?" → check web → resolve or flag.
-5. Be RELENTLESS. If the codebase doesn't clearly support a decision, don't manufacture confidence. Put it in Open Questions.
-6. If a question is partially answerable, answer the part you can and flag the remainder as open.
-
-## How to classify
-
-- **Answerable** (>80% confidence, clear codebase precedent or unambiguous external evidence) → include in Discovery section with source tag.
-- **Conflicting** (codebase says X, ticket says Y, or two sources disagree) → include in Open Questions with the conflict described.
-- **Not answerable** (business decision, ambiguous requirements, money/legal/compliance, no evidence in any source) → include in Open Questions for PO review.
-
-## Output format
-
-Return exactly two markdown sections:
-
-```markdown
-## Discovery
-
-Q: [question]
-A: [answer with evidence]. (Source: codebase|board|web)
-
-Q: [question]
-A: [answer]. (Source: codebase)
-
-## Open Questions
-- [ ] [question that couldn't be resolved — with reason]
-- [ ] [question with conflicting evidence — conflict described]
-```
-
-Every answer in Discovery must cite its source: `(Source: codebase)`, `(Source: board)`, `(Source: web)`, or `(Source: codebase, web)` for combined evidence.
-
----
-
-## Rules
-
-- NEVER ask the human questions. You are running autonomously.
-- Single pass — no multi-round conversation loop. But each question must be followed to its conclusion including any self-follow-ups.
-- Every answer must include real file paths, code snippets, ticket references, or URLs as evidence. No hand-waving.
-- When you find no evidence at all, say so explicitly and classify as Open Questions.
-- Prefer specificity over breadth. One concrete file path beats three vague claims.