claude-craft

Resolve ambiguous user prompts by choosing whether to answer now, answer with assumptions, ask 1–2 high-value clarification questions, replan, or stop. Use when the best response depends on hidden intent, audience, scope, constraints, risk, output format, or desired depth.

Analyzes an approved plan and decomposes it into a dependency-ordered task graph via a two-phase TaskCreate and TaskUpdate pass. Detects linear DEPENDS ON chains (shared worktree), identifies independent work streams (parallelized), and executes the full worktree-isolated run. Also handles Branch B (learnings from session context). **AUTOMATICALLY INVOKE** only when: - The PostToolUse(ExitPlanMode) hook has injected its schedule-tasks nudge in this turn (i.e., the user just approved a plan), AND the user has not signaled they want to defer execution. - /schedule-plan-tasks is invoked explicitly. - The user explicitly says "schedule tasks", "execute the plan", "decompose plan into tasks" — only when a plan exists at ~/.claude/plans/*.md AND ExitPlanMode has already been approved in this session. **DO NOT auto-invoke** while plan mode is active, while review-plan is iterating, or before the user has approved ExitPlanMode. **References:** JIT-loaded from `${CLAUDE_SKILL_DIR}/references/`

Headless `claude -p` test harness V2 — runs a fixture's literal prompt through real Claude sessions (k replicas in parallel), grades each replica on five string views plus structured tool-call / tool-result / run-health / LLM-judge condition families, then quorum-aggregates row verdicts. Use when an LLM-driven prompt needs behavioral verification beyond contract-string parser tests.

Universal plan review: senior-engineer directive + deterministic count-based severity rule. AUTOMATICALLY INVOKE when: - MANDATORY_PRE_EXIT_PLAN directive applies (before ExitPlanMode) - User says "review plan", "check plan", "plan ready?" - Any plan file needs review NOT for: Code review of existing files (use /gas-suite:gas-review or /review-fix)

Compare an agent or skill prompt against its test harness skill for phase-model, skip-condition, and wiring consistency. Reports mismatches and identifies which file is authoritative.

TDD-based prompt migration — given a target agent/skill prompt and a remediation list from prompt-audit, writes failing tests first, then updates the prompt to make them pass, and commits both in a single atomic commit.

Full prompt-improvement workflow — runs prompt-audit to find inconsistencies, presents a remediation plan, then runs prompt-migrate to apply fixes and prompt-align to verify harness consistency. Use for any agent or skill prompt that needs structural repair.

Audit an agent or skill prompt file for internal inconsistencies (phase numbering, behavioral contracts, terminology, stale references). Produces a Q&A with info-gain scores, a learnings section, and a remediation list. Use before any prompt migration.

Test harness for the schedule-plan-tasks skill. Runs each plan fixture through the skill inline in the orchestrator session (where TaskCreate/TaskUpdate/TaskList are available), in two tracks: --plan-only validates the Dry-Run Report against expected chain/standalone topology and wiring rules (Asserts 3, 5, 6, 7, 8); --dry-run validates the Simulated Execution Trace against expected wave structure, cascade ordering, and validation predicates. Currently covers 8 fixtures (plan1–plan7 + plan8 cascade fan-in). **AUTOMATICALLY INVOKE** when: - User says "test schedule-plan-tasks", "validate the skill", "run fixture tests" - /test-schedule-plan-tasks is invoked

Unified GAS code review - runs BOTH gas-code-review AND gas-ui-review. **ALWAYS PREFER THIS** over gas-code-review or gas-ui-review individually. This agent provides cross-file analysis and parallel execution. **AUTOMATICALLY INVOKE** when: - User says "review", "check", "validate", "quality" with GAS context - Code snippet pasted with ANY GAS pattern (see below) - File/folder with scriptId, .gs files, or .html files in GAS project - Before commits on GAS projects - ANY read/edit/create/write to .gs or .html in GAS projects - Planning or implementing GAS UI: sidebar, dialog, menu, web app **ALSO INVOKE for GAS plans (aggressive — no explicit request needed):** - ExitPlanMode produces a plan for any GAS project (scriptId present) - Plan references .gs files, .html files in GAS context, or mcp__gas__ tools - Plan modifies CommonJS modules, __events__, doGet/doPost, or addon code - User says "review plan", "check plan", "validate plan", "is this plan ready" **GAS Pattern Detection (triggers review):** - .gs

Ablation test harness for the review-plan skill. Runs the structured question-based control (SKILL.md) and the directive-based ablated variant (SKILL-v-ablation-na.md, per-directive N/A semantics) against the same fixture set with k=3 repetition, then uses the review-plan-ablation-judge to compare outputs for logical equivalence and reports per-fixture stability. Answers: do the structured question IDs add meaningful signal, or does a directive prompt achieve equivalent issue detection? Spot-Check 1 Pass Criterion (input3b — clean-plan calibration anchor): - Majority winner = TIE (or SPLIT, treated as TIE) - Mode verdict_agreement = EQUIVALENT - Verdict stability = VERDICTS_STABLE (all 3 control runs same verdict AND all 3 ablated runs same verdict) - Winner stability = WINNER_STABLE OR WINNER_UNSTABLE (the latter is acceptable iff verdict-stability is VERDICTS_STABLE AND mode false_positives ∈ {EQUIVALENT, CONTROL}; surface in the false-positive summary as a signal, not a fail) - Mode fa

Symptom-based GAS UI debugging. Route by user's problem description. **AUTOMATICALLY INVOKE** when user describes: - "blank", "empty", "nothing shows" → CONSOLE_CHECK - "error", "red message" → CONSOLE_CHECK - "button doesn't work", "click does nothing" → HANDLER_TEST - "nothing happens" → CONNECTION_CHECK - "looks wrong", "layout broken" → SNAPSHOT_CHECK - "slow", "loading forever" → PERFORMANCE_CHECK **MCP REQUIRED:** chrome-devtools (with browserUrl for GAS auth)

Manage task persistence across /clear sessions — disable/enable auto-restore, list prior sessions, inspect tasks from a specific session

Dual-perspective GAS plan review (frontend + backend) with iterative convergence loop. 54 GAS-specific questions covering MCP workflow, CardService, V8 parsing, OAuth, concurrency. **AUTOMATICALLY INVOKE** when plan content signals GAS domain: - Plan references .gs files, .html files in GAS context, or mcp__gas__ tools - Plan modifies CommonJS modules, __events__, doGet/doPost, or addon code - Plan uses mcp-gas-deploy or references a scriptId **NOT for:** General plan review (use /review-suite:review-plan — it fires automatically before ExitPlanMode), code review (use /gas-review), non-GAS plans. **Explicit invocation:** `/gas-suite:gas-plan` — runs the full standalone 54-question GAS review without review-plan's general quality layer. Use when you want GAS-domain-only feedback, or before review-plan fires. **mode parameter:** - `standalone` (default): TeamCreate + parallel evaluators + convergence loop + ExitPlanMode - `evaluate`: Single-pass read-only evaluation — returns findings via SendMessage to a c

Generate professional presentations from material, notes, or topic descriptions. Produces reveal.js HTML (single file, no build step) or Google Slides (via GAS SlidesApp). AUTOMATICALLY INVOKE when: "create slides", "make a deck", "generate a presentation", "slides about", "deck on", "presentation from [material]" NOT for: editing existing PPTX, converting files, exporting Sheets charts Step 3B includes optional visual verification via Chrome DevTools.

Hook-driven proactive research pipeline. Runs automatically via UserPromptSubmit — there is no slash command to trigger it. This page documents how it works, how to disable it, and the env-var knobs.

Set up an LLM wiki for this repository. Creates directory structure and SCHEMA.md. The SessionStart hook auto-detects and injects the wiki from this point forward. AUTOMATICALLY INVOKE when: "set up wiki", "wiki this repo", "create wiki", "create knowledge base", "track what I read", "initialize wiki" NOT for: querying (use /wiki-query), ingesting sources (use /wiki-ingest)

Health check the project wiki. Finds orphans, broken links, contradictions, stale pages. Writes maintenance report. Suggests log rotation when log.md > 500 entries. AUTOMATICALLY INVOKE when: "wiki health check", "lint the wiki", "audit wiki", "find wiki issues", "check wiki quality", "wiki maintenance"

JIT wiki-context loader: searches project wiki + global wiki for topic. Loads raw pages — no synthesis. Unified retrieval interface for all knowledge tiers. AUTOMATICALLY INVOKE when: "what do we know about", "load context for", "pull in wiki context", "find in wiki", "look up in the wiki", "load the wiki page for", "what's in the wiki about", "load knowledge about" PROACTIVELY INVOKE when: wiki-notify injects WIKI_PARTIAL previews and current task involves planning/designing/debugging/answering those topics — full-page retrieval required before substantive work. Also invoke when entering plan-mode for features touching wiki-documented domains. NOT for: synthesized answers (/wiki-query), source ingestion (/wiki-ingest)

Synthesize an answer from the project wiki with citations. Optionally save the result as a new wiki page. AUTOMATICALLY INVOKE when: "query the wiki", "what does the wiki say about", "synthesize from wiki", "wiki answer for", "ask the wiki about" NOT for: loading raw context (use /wiki-load), ingesting sources (use /wiki-ingest)

Async workflow pipeline for use case preparation and implementation. Auto-invokes for feature planning and complex task preparation.

Dual-perspective Node.js/TypeScript plan review (TypeScript/API + Node runtime) with iterative convergence loop. 36 Node/TS-specific questions (N20/N21 naming+docs deferred to L1's Q-G6/Q-G7 which cover these universally). **AUTOMATICALLY INVOKE** when: - Any plan exists for Node.js or TypeScript changes - Plan references package.json, tsconfig.json, .ts files, npm/yarn/pnpm/bun - Plan targets Express, Fastify, NestJS, Next.js, or similar Node frameworks - Plan modifies async code, environment variables, or Node process lifecycle - User says "review plan", "check plan", "node-plan" **NOT for:** GAS plans (use /gas-plan), code review (use /review), non-Node plans

A/B benchmarking skill for code reviewer agent prompts. Runs two versions of a reviewer agent against fixture ground truth using an LLM judge for semantic evaluation, then compares precision/recall/F1 metrics side-by-side. Defaults to comparing current agent vs git HEAD~1. Reports IMPROVED / REGRESSED / NEUTRAL verdict on F1.

Ingest self-improvement feedback from the backlog and propose surgical prompt updates. Ensures high-quality prompt evolution without automated drift. AUTOMATICALLY INVOKE when: - "process feedback", "check prompt backlog", "improve skills based on feedback" - "what improvements are needed for our skills", "analyze feedback backlog" - "optimize prompt for [skill]" NOT for: Directly editing SKILL.md files (this skill is Propose-Only).

Ping someone on Slack — optionally about a GUS work item or GitHub PR, with optional URL intelligently hyperlinked into the message. Resolves identifiers, formats a rich message, previews, and sends on approval. Can also post directly to a channel without tagging a specific person, or reply to an existing thread using keywords, URLs, or 'last'. **AUTOMATICALLY INVOKE** when: - "tag someone on slack about" - "notify on slack about W-" - "slack ping" / "slack tag" - "DM about this work item" - "post this PR to slack" - "let X know about W-" - "ping someone on slack" - "message someone on slack about" - "post to #channel" - "send to #channel" - "reply to the thread about" - "reply in thread" / "thread reply" - "follow up on the slack thread" **NOT for:** General Slack announcements or channel summaries

Form 990 Skill — Orchestrator for end-to-end IRS Form 990 preparation. Guides a nonprofit Executive Director through all 10 phases (P0–P9): intake, source discovery, chart-of-accounts mapping, financial statements, Part IV checklist, core parts, schedule generation, Part I rollup, CPA quality review (30 gates, 3 tiers), and reference PDF fill + e-file handoff packet. Stateful plan-file journal enables cold-resume across sessions. AUTOMATICALLY INVOKE when: - User says "prepare form 990", "990 filing", "nonprofit tax return" - User provides a Google Sheets budget or financial data for a nonprofit - Resuming a prior 990 session ("continue", "pick up where we left off") - User asks about Part IV, Schedule A/B/G/O in a 990 filing context NOT for: General tax questions, for-profit returns, 990-N or 990-PF variants

**PREFER OVER code-reviewer** for GAS/Apps Script projects. Fast syntax and pattern validator. **AUTOMATICALLY INVOKE** when: - Code review, quality review, or validation in GAS context (scriptId present) - Reviewing .gs files in Apps Script projects - Detecting high-risk patterns: __events__, __global__, doGet/doPost/onOpen/onEdit - Before commits on GAS projects - User says "review", "check", "validate", "quality" with GAS code - Code snippet pasted containing: _main, __defineModule__, require(), module.exports **ALWAYS PAIR WITH:** gas-ui-review when .html files are also present (or use /gas-review for both) **NOT for:** General JS/TS (use code-reviewer), HTML patterns (use gas-ui-review)

GAS project server-side debugging and troubleshooting with RESUME capability for iterative investigation. Covers: CommonJS modules, SpreadsheetApp, DriveApp, GmailApp, HTML Service (server-side), triggers, permissions, quotas. **AUTOMATICALLY INVOKE** when: - exec() returns success: false or error in response - User mentions "error", "exception", "TypeError", "null", "undefined" - Code "doesn't work", "isn't working", "fails", "breaks" - Silent failures (code runs but wrong result) - Something "should" work but doesn't **RESUME SUPPORT:** This skill runs in forked context - user can say "dig deeper" to continue investigation with full history preserved. **NOT for:** Static code review (use gas-code-review), UI testing (use gas-ui-debug), interactive Chrome testing (use /gas-sidebar)

Gmail add-on and CardService specialist for Google Apps Script. Operates in 3 modes: code review, plan review, and advisory/Q&A. **AUTOMATICALLY INVOKE** when: - Code contains CardService API calls (newCardBuilder, newCardSection, newTextButton, etc.) - Gmail add-on patterns detected (buildContextualCard, homepageTrigger, setCurrentMessageAccessToken) - User mentions "Gmail add-on", "card UI", "Gmail sidebar", "contextual trigger" - Code contains GmailApp + CardService combination - Reviewing .gs files with appsscript.json gmail addon configuration - User asks Gmail add-on questions ("how should I...", "what's the best way...") - Plan/architecture discussions for Gmail add-ons **Pattern Detection (triggers review):** - CardService.newCardBuilder(), .addCard(), .buildHomepageCard() - GmailApp.setCurrentMessageAccessToken(), .getMessageById(), .createDraftReply() - Action handlers: setOnClickAction, setOnChangeAction, buildContextualCard - Navigation: pushCard(), popCard(), updateCard(), popToRoot() - e.gmail

Interactive GAS sidebar testing via Chrome DevTools. Launch sidebar, send prompts, read responses, manage config, and take screenshots -- all through MCP automation. **AUTOMATICALLY INVOKE** when: - User says "open sidebar", "launch sidebar", "test sidebar" - User says "send prompt", "send message", "chat with sidebar" - User says "check sidebar", "sidebar not working", "sidebar blank" - User wants to interact with Sheet Chat sidebar in any environment (Dev/Staging/Prod) - User says "gas-sidebar" or "/gas-sidebar" - User mentions "Sheet Chat" + any action verb (open, test, send, check) - User wants to verify sidebar deployment is working end-to-end **MCP REQUIRED:** chrome-devtools (with browserUrl for GAS auth), gas **NOT for:** Static code review (use /gas), server-side debugging (use /gas), symptom-based UI debugging without Chrome (use /gas)

GAS HTML/UI pattern reviewer for correctness and layout. **AUTOMATICALLY INVOKE** when: - Code snippet pasted containing: HtmlService, <?=, <?!=, google.script.run, createGasServer ## HTML File Operations (Highest Priority) - ANY edit/create/write to .html files in GAS projects - Reading .html files for review or understanding - Planning changes to HTML files **ALWAYS PAIR WITH:** gas-code-review when .gs files are also present (or use /gas-review for both) ## IFRAME & Embedding - IFRAME, embedding, X-Frame-Options, setXFrameOptionsMode - Web app deployment, doGet(), doPost() - External embedding, cross-origin, CORS ## UI Components & Layout - sidebar, dialog, modal, toast, menu, form, button - Layout, positioning, sizing, dimensions, width, height - CSS, styling, responsive, mobile - Template, HtmlService, HtmlOutput, HtmlTemplate ## GAS HTML Patterns - Scriptlets: <?= ?>, <?!= ?>, <? ?>, include() - createTemplateFromFile, createHtmlOutputFromFile, evaluate() - google.script.run, createGasServer(), se

Design system architecture and make technology decisions. Dispatches to system-architect agent for comprehensive design work. AUTOMATICALLY INVOKE when: - "design architecture", "what tech stack", "system design" - "how should I structure", "architecture for", "design system" - "technology recommendation", "compare frameworks" NOT for: Implementation (use superpowers:executing-plans), task breakdown (use superpowers:writing-plans)

Execute a delivery-agent fixture through an actual agent dispatch and print the full response. Supports --dry-run for safe simulation.

Generate comprehensive tests for code. Dispatches to qa-analyst agent for complex components requiring test architecture decisions. AUTOMATICALLY INVOKE when: - "write tests", "test this", "generate tests", "add test coverage" - "test plan", "what should I test" - After feature implementation is complete NOT for: Running existing tests (use `npm test`)

Compare two prompt versions (A vs B) by running both against a directory of test input files, then evaluating results on three dimensions in priority order: quality > tokens > time. **AUTOMATICALLY INVOKE** when user mentions: - "compare prompts", "which prompt is better", "prompt efficiency" - "A/B test prompts", "evaluate prompts", "test these prompts" - Multiple prompt variations to choose between **STRONGLY RECOMMENDED** for: - Optimizing prompt quality - Reducing token usage - Comparing alternative approaches - Before finalizing agent/skill prompts Position bias mitigated via randomized ordering per test case — judge sees A/B in random order, results remapped before aggregation.

A/B test two planning questions by applying each to one or more plans, judging which question produces a better plan revision. Priority chain: quality > input tokens (question size) > time. AUTOMATICALLY INVOKE when user mentions: - "compare questions", "which question is better", "A/B test questions" - "evaluate questions", "test these questions against plans" - "question efficiency", "question comparison" - Two planning questions to compare against plan(s) STRONGLY RECOMMENDED for: - Optimizing review-plan question quality - Reducing question token cost while maintaining effectiveness - Choosing between alternative question phrasings - Validating new questions against existing ones Position bias mitigated via randomized ordering per test case — judge sees A/B in random order, results remapped before aggregation.

Iteratively researches real software project failures and wins, extracts key planning questions via 5-whys analysis, validates them against synthetic test plans, judges their effectiveness via a parallel judge agent, refines them, and persists to a growing questions library. Builds a curated, language/system-agnostic question library that prevents known failure modes when applied during software planning. Supports multiple resumable runs: reads existing question inventory on startup, tracks researched failure domains, avoids near-duplicating existing questions. AUTOMATICALLY INVOKE when user mentions: - "derive questions", "derive planning questions", "research failure questions" - "build question library", "question library from failures" - "mine post-mortems", "extract planning questions"

Research-backed prompt improvement workflow. Analyzes with Q1-Q13 structural diagnostics, researches domain + prompt engineering best practices, generates fixed+dynamic evaluation questions, validates improvement plan (quality gate), runs E parallel experiment variants, scope-preservation gate (12-question check against baseline for unintended regression), evaluates via questions-based judge (not holistic), reconciles all learnings into a single ideas file, and commits only if improved. Three loop modes: default (stall detection stops after max_stalls consecutive failures), fixed (explicit --iterations N always completes all N), and duration (--duration 2h or "until 5pm" loops until time expires). Strategy escalation guides bolder changes after stalls. Position bias mitigated via randomized judge ordering. Supports --iterations N, --experiments N, --max-stalls N, and --duration. AUTOMATICALLY INVOKE when user mentions: - "improve this prompt", "make this prompt better", "optimize this prompt" - "prompt impro

Benchmark and compare system prompt variants (V2/V2a/V2b/V2c) for Sheets Chat by running test scenarios through the real GAS-side ClaudeConversation pipeline. Tests both system-placement and user-placement, then evaluates with heuristic scoring (ABTestHarness) and LLM-as-judge. **AUTOMATICALLY INVOKE** when: - User says "benchmark system prompts", "compare prompt variants" - User wants to evaluate placement (system vs user message) - User says "which prompt variant is best", "run prompt benchmark" **NOT for:** General prompt engineering, non-GAS prompts, one-off prompt writing. Use /optimize-system-prompt for editing/refining the active prompt.

Systematically optimize review-plan evaluator questions for token efficiency while maintaining quality. For each target question: generates 3 token-optimized variants (STRUCTURAL, SEMANTIC, RADICAL) in parallel, selects the best one (optionally synthesizing strengths from others), A/B tests it against the original via compare-questions using a dedicated test plan, and updates QUESTIONS.md if the variant wins. Retries up to N times with judge feedback. AUTOMATICALLY INVOKE when user mentions: - "optimize questions", "compress questions", "reduce question tokens" - "token-optimize review-plan", "make questions more concise" - "question efficiency", "shrink evaluator prompts" STRONGLY RECOMMENDED for: - Reducing review-plan token consumption - Iterative question quality improvement - Validating question rewrites against calibration plans