From 2993da5c8290eec6bc256f15513d26b7c1f9e64c Mon Sep 17 00:00:00 2001 From: Bryce Date: Fri, 1 May 2026 11:34:48 -0700 Subject: [PATCH] add project configuration files (.env, .envrc, opencode.json, package-lock) --- .env | 1 + .envrc | 1 + .opencode/package-lock.json | 376 ++++++++++++++++++++++++++++++++++++ opencode.json | 246 +++++++++++++++++++++++ 4 files changed, 624 insertions(+) create mode 100644 .env create mode 100644 .envrc create mode 100644 .opencode/package-lock.json create mode 100644 opencode.json diff --git a/.env b/.env new file mode 100644 index 00000000..b67c4a54 --- /dev/null +++ b/.env @@ -0,0 +1 @@ +OPENROUTER_API_KEY=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 diff --git a/.envrc b/.envrc new file mode 100644 index 00000000..f64001f3 --- /dev/null +++ b/.envrc @@ -0,0 +1 @@ +export OPENROUTER_API_KEY=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 diff --git a/.opencode/package-lock.json b/.opencode/package-lock.json new file mode 100644 index 00000000..41ff2315 --- /dev/null +++ b/.opencode/package-lock.json @@ -0,0 +1,376 @@ +{ + "name": ".opencode", + "lockfileVersion": 3, + "requires": true, + "packages": { + "": { + "dependencies": { + "@opencode-ai/plugin": "1.14.31" + } + }, + "node_modules/@msgpackr-extract/msgpackr-extract-darwin-arm64": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/@msgpackr-extract/msgpackr-extract-darwin-arm64/-/msgpackr-extract-darwin-arm64-3.0.3.tgz", + "integrity": "sha512-QZHtlVgbAdy2zAqNA9Gu1UpIuI8Xvsd1v8ic6B2pZmeFnFcMWiPLfWXh7TVw4eGEZ/C9TH281KwhVoeQUKbyjw==", + "cpu": [ + "arm64" + ], + "license": "MIT", + "optional": true, + "os": [ + "darwin" + ] + }, + "node_modules/@msgpackr-extract/msgpackr-extract-darwin-x64": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/@msgpackr-extract/msgpackr-extract-darwin-x64/-/msgpackr-extract-darwin-x64-3.0.3.tgz", + "integrity": "sha512-mdzd3AVzYKuUmiWOQ8GNhl64/IoFGol569zNRdkLReh6LRLHOXxU4U8eq0JwaD8iFHdVGqSy4IjFL4reoWCDFw==", + "cpu": [ + "x64" + ], + "license": "MIT", + "optional": true, + "os": [ + "darwin" + ] + }, + "node_modules/@msgpackr-extract/msgpackr-extract-linux-arm": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/@msgpackr-extract/msgpackr-extract-linux-arm/-/msgpackr-extract-linux-arm-3.0.3.tgz", + "integrity": "sha512-fg0uy/dG/nZEXfYilKoRe7yALaNmHoYeIoJuJ7KJ+YyU2bvY8vPv27f7UKhGRpY6euFYqEVhxCFZgAUNQBM3nw==", + "cpu": [ + "arm" + ], + "license": "MIT", + "optional": true, + "os": [ + "linux" + ] + }, + "node_modules/@msgpackr-extract/msgpackr-extract-linux-arm64": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/@msgpackr-extract/msgpackr-extract-linux-arm64/-/msgpackr-extract-linux-arm64-3.0.3.tgz", + "integrity": "sha512-YxQL+ax0XqBJDZiKimS2XQaf+2wDGVa1enVRGzEvLLVFeqa5kx2bWbtcSXgsxjQB7nRqqIGFIcLteF/sHeVtQg==", + "cpu": [ + "arm64" + ], + "license": "MIT", + "optional": true, + "os": [ + "linux" + ] + }, + "node_modules/@msgpackr-extract/msgpackr-extract-linux-x64": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/@msgpackr-extract/msgpackr-extract-linux-x64/-/msgpackr-extract-linux-x64-3.0.3.tgz", + "integrity": "sha512-cvwNfbP07pKUfq1uH+S6KJ7dT9K8WOE4ZiAcsrSes+UY55E/0jLYc+vq+DO7jlmqRb5zAggExKm0H7O/CBaesg==", + "cpu": [ + "x64" + ], + "license": "MIT", + "optional": true, + "os": [ + "linux" + ] + }, + "node_modules/@msgpackr-extract/msgpackr-extract-win32-x64": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/@msgpackr-extract/msgpackr-extract-win32-x64/-/msgpackr-extract-win32-x64-3.0.3.tgz", + "integrity": "sha512-x0fWaQtYp4E6sktbsdAqnehxDgEc/VwM7uLsRCYWaiGu0ykYdZPiS8zCWdnjHwyiumousxfBm4SO31eXqwEZhQ==", + "cpu": [ + "x64" + ], + "license": "MIT", + "optional": true, + "os": [ + "win32" + ] + }, + "node_modules/@opencode-ai/plugin": { + "version": "1.14.31", + "resolved": "https://registry.npmjs.org/@opencode-ai/plugin/-/plugin-1.14.31.tgz", + "integrity": "sha512-ZF7UoNKtZDtgW/2KrcFw5I7R2HRj/NigBuRwKPonvSZS36LnghZ7PYcXYZFGCjEgBmLUMMrLVgxccKLyxsgB0g==", + "license": "MIT", + "dependencies": { + "@opencode-ai/sdk": "1.14.31", + "effect": "4.0.0-beta.57", + "zod": "4.1.8" + }, + "peerDependencies": { + "@opentui/core": ">=0.2.0", + "@opentui/solid": ">=0.2.0" + }, + "peerDependenciesMeta": { + "@opentui/core": { + "optional": true + }, + "@opentui/solid": { + "optional": true + } + } + }, + "node_modules/@opencode-ai/sdk": { + "version": "1.14.31", + "resolved": "https://registry.npmjs.org/@opencode-ai/sdk/-/sdk-1.14.31.tgz", + "integrity": "sha512-QaV+ti3NYUITmgIDqtNMqGIYBXJOx2zheN1g+7w4HC8QQsbaW1c7glxXExQHRbdUzcQPP2vUQhnXOcEsTw5CcQ==", + "license": "MIT", + "dependencies": { + "cross-spawn": "7.0.6" + } + }, + "node_modules/@standard-schema/spec": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/@standard-schema/spec/-/spec-1.1.0.tgz", + "integrity": "sha512-l2aFy5jALhniG5HgqrD6jXLi/rUWrKvqN/qJx6yoJsgKhblVd+iqqU4RCXavm/jPityDo5TCvKMnpjKnOriy0w==", + "license": "MIT" + }, + "node_modules/cross-spawn": { + "version": "7.0.6", + "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.6.tgz", + "integrity": "sha512-uV2QOWP2nWzsy2aMp8aRibhi9dlzF5Hgh5SHaB9OiTGEyDTiJJyx0uy51QXdyWbtAHNua4XJzUKca3OzKUd3vA==", + "license": "MIT", + "dependencies": { + "path-key": "^3.1.0", + "shebang-command": "^2.0.0", + "which": "^2.0.1" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/detect-libc": { + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/detect-libc/-/detect-libc-2.1.2.tgz", + "integrity": "sha512-Btj2BOOO83o3WyH59e8MgXsxEQVcarkUOpEYrubB0urwnN10yQ364rsiByU11nZlqWYZm05i/of7io4mzihBtQ==", + "license": "Apache-2.0", + "optional": true, + "engines": { + "node": ">=8" + } + }, + "node_modules/effect": { + "version": "4.0.0-beta.57", + "resolved": "https://registry.npmjs.org/effect/-/effect-4.0.0-beta.57.tgz", + "integrity": "sha512-rg32VgXnLKaPRs9tbRDaZ5jxmzNY7ojXt85gSHGUTwdlbWH5Ik+OCUY2q14TXliygPGoHwCAvNWS4bQJOqf00g==", + "license": "MIT", + "dependencies": { + "@standard-schema/spec": "^1.1.0", + "fast-check": "^4.6.0", + "find-my-way-ts": "^0.1.6", + "ini": "^6.0.0", + "kubernetes-types": "^1.30.0", + "msgpackr": "^1.11.9", + "multipasta": "^0.2.7", + "toml": "^4.1.1", + "uuid": "^13.0.0", + "yaml": "^2.8.3" + } + }, + "node_modules/fast-check": { + "version": "4.7.0", + "resolved": "https://registry.npmjs.org/fast-check/-/fast-check-4.7.0.tgz", + "integrity": "sha512-NsZRtqvSSoCP0HbNjUD+r1JH8zqZalyp6gLY9e7OYs7NK9b6AHOs2baBFeBG7bVNsuoukh89x2Yg3rPsul8ziQ==", + "funding": [ + { + "type": "individual", + "url": "https://github.com/sponsors/dubzzz" + }, + { + "type": "opencollective", + "url": "https://opencollective.com/fast-check" + } + ], + "license": "MIT", + "dependencies": { + "pure-rand": "^8.0.0" + }, + "engines": { + "node": ">=12.17.0" + } + }, + "node_modules/find-my-way-ts": { + "version": "0.1.6", + "resolved": "https://registry.npmjs.org/find-my-way-ts/-/find-my-way-ts-0.1.6.tgz", + "integrity": "sha512-a85L9ZoXtNAey3Y6Z+eBWW658kO/MwR7zIafkIUPUMf3isZG0NCs2pjW2wtjxAKuJPxMAsHUIP4ZPGv0o5gyTA==", + "license": "MIT" + }, + "node_modules/ini": { + "version": "6.0.0", + "resolved": "https://registry.npmjs.org/ini/-/ini-6.0.0.tgz", + "integrity": "sha512-IBTdIkzZNOpqm7q3dRqJvMaldXjDHWkEDfrwGEQTs5eaQMWV+djAhR+wahyNNMAa+qpbDUhBMVt4ZKNwpPm7xQ==", + "license": "ISC", + "engines": { + "node": "^20.17.0 || >=22.9.0" + } + }, + "node_modules/isexe": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz", + "integrity": "sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw==", + "license": "ISC" + }, + "node_modules/kubernetes-types": { + "version": "1.30.0", + "resolved": "https://registry.npmjs.org/kubernetes-types/-/kubernetes-types-1.30.0.tgz", + "integrity": "sha512-Dew1okvhM/SQcIa2rcgujNndZwU8VnSapDgdxlYoB84ZlpAD43U6KLAFqYo17ykSFGHNPrg0qry0bP+GJd9v7Q==", + "license": "Apache-2.0" + }, + "node_modules/msgpackr": { + "version": "1.11.10", + "resolved": "https://registry.npmjs.org/msgpackr/-/msgpackr-1.11.10.tgz", + "integrity": "sha512-iCZNq+HszvF+fC3anCm4nBmWEnbeIAfpDs6IStAEKhQ2YSgkjzVG2FF9XJqwwQh5bH3N9OUTUt4QwVN6MLMLtA==", + "license": "MIT", + "optionalDependencies": { + "msgpackr-extract": "^3.0.2" + } + }, + "node_modules/msgpackr-extract": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/msgpackr-extract/-/msgpackr-extract-3.0.3.tgz", + "integrity": "sha512-P0efT1C9jIdVRefqjzOQ9Xml57zpOXnIuS+csaB4MdZbTdmGDLo8XhzBG1N7aO11gKDDkJvBLULeFTo46wwreA==", + "hasInstallScript": true, + "license": "MIT", + "optional": true, + "dependencies": { + "node-gyp-build-optional-packages": "5.2.2" + }, + "bin": { + "download-msgpackr-prebuilds": "bin/download-prebuilds.js" + }, + "optionalDependencies": { + "@msgpackr-extract/msgpackr-extract-darwin-arm64": "3.0.3", + "@msgpackr-extract/msgpackr-extract-darwin-x64": "3.0.3", + "@msgpackr-extract/msgpackr-extract-linux-arm": "3.0.3", + "@msgpackr-extract/msgpackr-extract-linux-arm64": "3.0.3", + "@msgpackr-extract/msgpackr-extract-linux-x64": "3.0.3", + "@msgpackr-extract/msgpackr-extract-win32-x64": "3.0.3" + } + }, + "node_modules/multipasta": { + "version": "0.2.7", + "resolved": "https://registry.npmjs.org/multipasta/-/multipasta-0.2.7.tgz", + "integrity": "sha512-KPA58d68KgGil15oDqXjkUBEBYc00XvbPj5/X+dyzeo/lWm9Nc25pQRlf1D+gv4OpK7NM0J1odrbu9JNNGvynA==", + "license": "MIT" + }, + "node_modules/node-gyp-build-optional-packages": { + "version": "5.2.2", + "resolved": "https://registry.npmjs.org/node-gyp-build-optional-packages/-/node-gyp-build-optional-packages-5.2.2.tgz", + "integrity": "sha512-s+w+rBWnpTMwSFbaE0UXsRlg7hU4FjekKU4eyAih5T8nJuNZT1nNsskXpxmeqSK9UzkBl6UgRlnKc8hz8IEqOw==", + "license": "MIT", + "optional": true, + "dependencies": { + "detect-libc": "^2.0.1" + }, + "bin": { + "node-gyp-build-optional-packages": "bin.js", + "node-gyp-build-optional-packages-optional": "optional.js", + "node-gyp-build-optional-packages-test": "build-test.js" + } + }, + "node_modules/path-key": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/path-key/-/path-key-3.1.1.tgz", + "integrity": "sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==", + "license": "MIT", + "engines": { + "node": ">=8" + } + }, + "node_modules/pure-rand": { + "version": "8.4.0", + "resolved": "https://registry.npmjs.org/pure-rand/-/pure-rand-8.4.0.tgz", + "integrity": "sha512-IoM8YF/jY0hiugFo/wOWqfmarlE6J0wc6fDK1PhftMk7MGhVZl88sZimmqBBFomLOCSmcCCpsfj7wXASCpvK9A==", + "funding": [ + { + "type": "individual", + "url": "https://github.com/sponsors/dubzzz" + }, + { + "type": "opencollective", + "url": "https://opencollective.com/fast-check" + } + ], + "license": "MIT" + }, + "node_modules/shebang-command": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz", + "integrity": "sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==", + "license": "MIT", + "dependencies": { + "shebang-regex": "^3.0.0" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/shebang-regex": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/shebang-regex/-/shebang-regex-3.0.0.tgz", + "integrity": "sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==", + "license": "MIT", + "engines": { + "node": ">=8" + } + }, + "node_modules/toml": { + "version": "4.1.1", + "resolved": "https://registry.npmjs.org/toml/-/toml-4.1.1.tgz", + "integrity": "sha512-EBJnVBr3dTXdA89WVFoAIPUqkBjxPMwRqsfuo1r240tKFHXv3zgca4+NJib/h6TyvGF7vOawz0jGuryJCdNHrw==", + "license": "MIT", + "engines": { + "node": ">=20" + } + }, + "node_modules/uuid": { + "version": "13.0.1", + "resolved": "https://registry.npmjs.org/uuid/-/uuid-13.0.1.tgz", + "integrity": "sha512-9ezox2roIft6ExBVTVqibSd5dc5/47Sw/uY6b4SjQUT2TzQ0tltNquWA46y4xPQmdZYqvnio22SgWd41M86+jw==", + "funding": [ + "https://github.com/sponsors/broofa", + "https://github.com/sponsors/ctavan" + ], + "license": "MIT", + "bin": { + "uuid": "dist-node/bin/uuid" + } + }, + "node_modules/which": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz", + "integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==", + "license": "ISC", + "dependencies": { + "isexe": "^2.0.0" + }, + "bin": { + "node-which": "bin/node-which" + }, + "engines": { + "node": ">= 8" + } + }, + "node_modules/yaml": { + "version": "2.8.3", + "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.8.3.tgz", + "integrity": "sha512-AvbaCLOO2Otw/lW5bmh9d/WEdcDFdQp2Z2ZUH3pX9U2ihyUY0nvLv7J6TrWowklRGPYbB/IuIMfYgxaCPg5Bpg==", + "license": "ISC", + "bin": { + "yaml": "bin.mjs" + }, + "engines": { + "node": ">= 14.6" + }, + "funding": { + "url": "https://github.com/sponsors/eemeli" + } + }, + "node_modules/zod": { + "version": "4.1.8", + "license": "MIT", + "funding": { + "url": "https://github.com/sponsors/colinhacks" + } + } + } +} diff --git a/opencode.json b/opencode.json new file mode 100644 index 00000000..120ca721 --- /dev/null +++ b/opencode.json @@ -0,0 +1,246 @@ +{ + "$schema": "https://opencode.ai/config.json", + "command": { + "resolve_pr_parallel": { + "description": "Resolve all PR comments using parallel processing", + "template": "Resolve all PR comments using parallel processing.\n\nClaude Code automatically detects and understands your git context:\n\n- Current branch detection\n- Associated PR context\n- All PR comments and review threads\n- Can work with any PR by specifying the PR number, or ask it.\n\n## Workflow\n\n### 1. Analyze\n\nGet all unresolved comments for PR\n\n```bash\ngh pr status\nbin/get-pr-comments PR_NUMBER\n```\n\n### 2. Plan\n\nCreate a TodoWrite list of all unresolved items grouped by type.\n\n### 3. Implement (PARALLEL)\n\nSpawn a pr-comment-resolver agent for each unresolved item in parallel.\n\nSo if there are 3 comments, it will spawn 3 pr-comment-resolver agents in parallel. liek this\n\n1. Task pr-comment-resolver(comment1)\n2. Task pr-comment-resolver(comment2)\n3. Task pr-comment-resolver(comment3)\n\nAlways run all in parallel subagents/Tasks for each Todo item.\n\n### 4. Commit & Resolve\n\n- Commit changes\n- Run bin/resolve-pr-thread THREAD_ID_1\n- Push to remote\n\nLast, check bin/get-pr-comments PR_NUMBER again to see if all comments are resolved. They should be, if not, repeat the process from 1." + }, + "report-bug": { + "description": "Report a bug in the compound-engineering plugin", + "template": "# Report a Compounding Engineering Plugin Bug\n\nReport bugs encountered while using the compound-engineering plugin. This command gathers structured information and creates a GitHub issue for the maintainer.\n\n## Step 1: Gather Bug Information\n\nUse the AskUserQuestion tool to collect the following information:\n\n**Question 1: Bug Category**\n- What type of issue are you experiencing?\n- Options: Agent not working, Command not working, Skill not working, MCP server issue, Installation problem, Other\n\n**Question 2: Specific Component**\n- Which specific component is affected?\n- Ask for the name of the agent, command, skill, or MCP server\n\n**Question 3: What Happened (Actual Behavior)**\n- Ask: \"What happened when you used this component?\"\n- Get a clear description of the actual behavior\n\n**Question 4: What Should Have Happened (Expected Behavior)**\n- Ask: \"What did you expect to happen instead?\"\n- Get a clear description of expected behavior\n\n**Question 5: Steps to Reproduce**\n- Ask: \"What steps did you take before the bug occurred?\"\n- Get reproduction steps\n\n**Question 6: Error Messages**\n- Ask: \"Did you see any error messages? If so, please share them.\"\n- Capture any error output\n\n## Step 2: Collect Environment Information\n\nAutomatically gather:\n```bash\n# Get plugin version\ncat ~/.claude/plugins/installed_plugins.json 2>/dev/null | grep -A5 \"compound-engineering\" | head -10 || echo \"Plugin info not found\"\n\n# Get Claude Code version\nclaude --version 2>/dev/null || echo \"Claude CLI version unknown\"\n\n# Get OS info\nuname -a\n```\n\n## Step 3: Format the Bug Report\n\nCreate a well-structured bug report with:\n\n```markdown\n## Bug Description\n\n**Component:** [Type] - [Name]\n**Summary:** [Brief description from argument or collected info]\n\n## Environment\n\n- **Plugin Version:** [from installed_plugins.json]\n- **Claude Code Version:** [from claude --version]\n- **OS:** [from uname]\n\n## What Happened\n\n[Actual behavior description]\n\n## Expected Behavior\n\n[Expected behavior description]\n\n## Steps to Reproduce\n\n1. [Step 1]\n2. [Step 2]\n3. [Step 3]\n\n## Error Messages\n\n```\n[Any error output]\n```\n\n## Additional Context\n\n[Any other relevant information]\n\n---\n*Reported via `/report-bug` command*\n```\n\n## Step 4: Create GitHub Issue\n\nUse the GitHub CLI to create the issue:\n\n```bash\ngh issue create \\\n --repo EveryInc/compound-engineering-plugin \\\n --title \"[compound-engineering] Bug: [Brief description]\" \\\n --body \"[Formatted bug report from Step 3]\" \\\n --label \"bug,compound-engineering\"\n```\n\n**Note:** If labels don't exist, create without labels:\n```bash\ngh issue create \\\n --repo EveryInc/compound-engineering-plugin \\\n --title \"[compound-engineering] Bug: [Brief description]\" \\\n --body \"[Formatted bug report]\"\n```\n\n## Step 5: Confirm Submission\n\nAfter the issue is created:\n1. Display the issue URL to the user\n2. Thank them for reporting the bug\n3. Let them know the maintainer (Kieran Klaassen) will be notified\n\n## Output Format\n\n```\nβœ… Bug report submitted successfully!\n\nIssue: https://github.com/EveryInc/compound-engineering-plugin/issues/[NUMBER]\nTitle: [compound-engineering] Bug: [description]\n\nThank you for helping improve the compound-engineering plugin!\nThe maintainer will review your report and respond as soon as possible.\n```\n\n## Error Handling\n\n- If `gh` CLI is not authenticated: Prompt user to run `gh auth login` first\n- If issue creation fails: Display the formatted report so user can manually create the issue\n- If required information is missing: Re-prompt for that specific field\n\n## Privacy Notice\n\nThis command does NOT collect:\n- Personal information\n- API keys or credentials\n- Private code from your projects\n- File paths beyond basic OS info\n\nOnly technical information about the bug is included in the report." + }, + "generate_command": { + "description": "Create a new custom slash command following conventions and best practices", + "template": "# Create a Custom Claude Code Command\n\nCreate a new slash command in `.claude/commands/` for the requested task.\n\n## Goal\n\n#$ARGUMENTS\n\n## Key Capabilities to Leverage\n\n**File Operations:**\n- Read, Edit, Write - modify files precisely\n- Glob, Grep - search codebase\n- MultiEdit - atomic multi-part changes\n\n**Development:**\n- Bash - run commands (git, tests, linters)\n- Task - launch specialized agents for complex tasks\n- TodoWrite - track progress with todo lists\n\n**Web & APIs:**\n- WebFetch, WebSearch - research documentation\n- GitHub (gh cli) - PRs, issues, reviews\n- Playwright - browser automation, screenshots\n\n**Integrations:**\n- AppSignal - logs and monitoring\n- Context7 - framework docs\n- Stripe, Todoist, Featurebase (if relevant)\n\n## Best Practices\n\n1. **Be specific and clear** - detailed instructions yield better results\n2. **Break down complex tasks** - use step-by-step plans\n3. **Use examples** - reference existing code patterns\n4. **Include success criteria** - tests pass, linting clean, etc.\n5. **Think first** - use \"think hard\" or \"plan\" keywords for complex problems\n6. **Iterate** - guide the process step by step\n\n## Required: YAML Frontmatter\n\n**EVERY command MUST start with YAML frontmatter:**\n\n```yaml\n---\nname: command-name\ndescription: Brief description of what this command does (max 100 chars)\nargument-hint: \"[what arguments the command accepts]\"\n---\n```\n\n**Fields:**\n- `name`: Lowercase command identifier (used internally)\n- `description`: Clear, concise summary of command purpose\n- `argument-hint`: Shows user what arguments are expected (e.g., `[file path]`, `[PR number]`, `[optional: format]`)\n\n## Structure Your Command\n\n```markdown\n# [Command Name]\n\n[Brief description of what this command does]\n\n## Steps\n\n1. [First step with specific details]\n - Include file paths, patterns, or constraints\n - Reference existing code if applicable\n\n2. [Second step]\n - Use parallel tool calls when possible\n - Check/verify results\n\n3. [Final steps]\n - Run tests\n - Lint code\n - Commit changes (if appropriate)\n\n## Success Criteria\n\n- [ ] Tests pass\n- [ ] Code follows style guide\n- [ ] Documentation updated (if needed)\n```\n\n## Tips for Effective Commands\n\n- **Use $ARGUMENTS** placeholder for dynamic inputs\n- **Reference CLAUDE.md** patterns and conventions\n- **Include verification steps** - tests, linting, visual checks\n- **Be explicit about constraints** - don't modify X, use pattern Y\n- **Use XML tags** for structured prompts: ``, ``, ``\n\n## Example Pattern\n\n```markdown\nImplement #$ARGUMENTS following these steps:\n\n1. Research existing patterns\n - Search for similar code using Grep\n - Read relevant files to understand approach\n\n2. Plan the implementation\n - Think through edge cases and requirements\n - Consider test cases needed\n\n3. Implement\n - Follow existing code patterns (reference specific files)\n - Write tests first if doing TDD\n - Ensure code follows CLAUDE.md conventions\n\n4. Verify\n - Run tests: `bin/rails test`\n - Run linter: `bundle exec standardrb`\n - Check changes with git diff\n\n5. Commit (optional)\n - Stage changes\n - Write clear commit message\n```\n\n## Creating the Command File\n\n1. **Create the file** at `.claude/commands/[name].md` (subdirectories like `workflows/` supported)\n2. **Start with YAML frontmatter** (see section above)\n3. **Structure the command** using the template above\n4. **Test the command** by using it with appropriate arguments\n\n## Command File Template\n\n```markdown\n---\nname: command-name\ndescription: What this command does\nargument-hint: \"[expected arguments]\"\n---\n\n# Command Title\n\nBrief introduction of what the command does and when to use it.\n\n## Workflow\n\n### Step 1: [First Major Step]\n\nDetails about what to do.\n\n### Step 2: [Second Major Step]\n\nDetails about what to do.\n\n## Success Criteria\n\n- [ ] Expected outcome 1\n- [ ] Expected outcome 2\n```" + }, + "reproduce-bug": { + "description": "Reproduce and investigate a bug using logs, console inspection, and browser screenshots", + "template": "# Reproduce Bug Command\n\nLook at github issue #$ARGUMENTS and read the issue description and comments.\n\n## Phase 1: Log Investigation\n\nRun the following agents in parallel to investigate the bug:\n\n1. Task rails-console-explorer(issue_description)\n2. Task appsignal-log-investigator(issue_description)\n\nThink about the places it could go wrong looking at the codebase. Look for logging output we can look for.\n\nRun the agents again to find any logs that could help us reproduce the bug.\n\nKeep running these agents until you have a good idea of what is going on.\n\n## Phase 2: Visual Reproduction with Playwright\n\nIf the bug is UI-related or involves user flows, use Playwright to visually reproduce it:\n\n### Step 1: Verify Server is Running\n\n```\nmcp__plugin_compound-engineering_pw__browser_navigate({ url: \"http://localhost:3000\" })\nmcp__plugin_compound-engineering_pw__browser_snapshot({})\n```\n\nIf server not running, inform user to start `bin/dev`.\n\n### Step 2: Navigate to Affected Area\n\nBased on the issue description, navigate to the relevant page:\n\n```\nmcp__plugin_compound-engineering_pw__browser_navigate({ url: \"http://localhost:3000/[affected_route]\" })\nmcp__plugin_compound-engineering_pw__browser_snapshot({})\n```\n\n### Step 3: Capture Screenshots\n\nTake screenshots at each step of reproducing the bug:\n\n```\nmcp__plugin_compound-engineering_pw__browser_take_screenshot({ filename: \"bug-[issue]-step-1.png\" })\n```\n\n### Step 4: Follow User Flow\n\nReproduce the exact steps from the issue:\n\n1. **Read the issue's reproduction steps**\n2. **Execute each step using Playwright:**\n - `browser_click` for clicking elements\n - `browser_type` for filling forms\n - `browser_snapshot` to see the current state\n - `browser_take_screenshot` to capture evidence\n\n3. **Check for console errors:**\n ```\n mcp__plugin_compound-engineering_pw__browser_console_messages({ level: \"error\" })\n ```\n\n### Step 5: Capture Bug State\n\nWhen you reproduce the bug:\n\n1. Take a screenshot of the bug state\n2. Capture console errors\n3. Document the exact steps that triggered it\n\n```\nmcp__plugin_compound-engineering_pw__browser_take_screenshot({ filename: \"bug-[issue]-reproduced.png\" })\n```\n\n## Phase 3: Document Findings\n\n**Reference Collection:**\n\n- [ ] Document all research findings with specific file paths (e.g., `app/services/example_service.rb:42`)\n- [ ] Include screenshots showing the bug reproduction\n- [ ] List console errors if any\n- [ ] Document the exact reproduction steps\n\n## Phase 4: Report Back\n\nAdd a comment to the issue with:\n\n1. **Findings** - What you discovered about the cause\n2. **Reproduction Steps** - Exact steps to reproduce (verified)\n3. **Screenshots** - Visual evidence of the bug (upload captured screenshots)\n4. **Relevant Code** - File paths and line numbers\n5. **Suggested Fix** - If you have one" + }, + "feature-video": { + "description": "Record a video walkthrough of a feature and add it to the PR description", + "template": "# Feature Video Walkthrough\n\nRecord a video walkthrough demonstrating a feature, upload it, and add it to the PR description.\n\n## Introduction\n\nDeveloper Relations Engineer creating feature demo videos\n\nThis command creates professional video walkthroughs of features for PR documentation:\n- Records browser interactions using agent-browser CLI\n- Demonstrates the complete user flow\n- Uploads the video for easy sharing\n- Updates the PR description with an embedded video\n\n## Prerequisites\n\n\n- Local development server running (e.g., `bin/dev`, `rails server`)\n- agent-browser CLI installed\n- Git repository with a PR to document\n- `ffmpeg` installed (for video conversion)\n- `rclone` configured (optional, for cloud upload - see rclone skill)\n\n\n## Setup\n\n**Check installation:**\n```bash\ncommand -v agent-browser >/dev/null 2>&1 && echo \"Installed\" || echo \"NOT INSTALLED\"\n```\n\n**Install if needed:**\n```bash\nnpm install -g agent-browser && agent-browser install\n```\n\nSee the `agent-browser` skill for detailed usage.\n\n## Main Tasks\n\n### 1. Parse Arguments\n\n\n\n**Arguments:** $ARGUMENTS\n\nParse the input:\n- First argument: PR number or \"current\" (defaults to current branch's PR)\n- Second argument: Base URL (defaults to `http://localhost:3000`)\n\n```bash\n# Get PR number for current branch if needed\ngh pr view --json number -q '.number'\n```\n\n\n\n### 2. Gather Feature Context\n\n\n\n**Get PR details:**\n```bash\ngh pr view [number] --json title,body,files,headRefName -q '.'\n```\n\n**Get changed files:**\n```bash\ngh pr view [number] --json files -q '.files[].path'\n```\n\n**Map files to testable routes** (same as playwright-test):\n\n| File Pattern | Route(s) |\n|-------------|----------|\n| `app/views/users/*` | `/users`, `/users/:id`, `/users/new` |\n| `app/controllers/settings_controller.rb` | `/settings` |\n| `app/javascript/controllers/*_controller.js` | Pages using that Stimulus controller |\n| `app/components/*_component.rb` | Pages rendering that component |\n\n\n\n### 3. Plan the Video Flow\n\n\n\nBefore recording, create a shot list:\n\n1. **Opening shot**: Homepage or starting point (2-3 seconds)\n2. **Navigation**: How user gets to the feature\n3. **Feature demonstration**: Core functionality (main focus)\n4. **Edge cases**: Error states, validation, etc. (if applicable)\n5. **Success state**: Completed action/result\n\nAsk user to confirm or adjust the flow:\n\n```markdown\n**Proposed Video Flow**\n\nBased on PR #[number]: [title]\n\n1. Start at: /[starting-route]\n2. Navigate to: /[feature-route]\n3. Demonstrate:\n - [Action 1]\n - [Action 2]\n - [Action 3]\n4. Show result: [success state]\n\nEstimated duration: ~[X] seconds\n\nDoes this look right?\n1. Yes, start recording\n2. Modify the flow (describe changes)\n3. Add specific interactions to demonstrate\n```\n\n\n\n### 4. Setup Video Recording\n\n\n\n**Create videos directory:**\n```bash\nmkdir -p tmp/videos\n```\n\n**Recording approach: Use browser screenshots as frames**\n\nagent-browser captures screenshots at key moments, then combine into video using ffmpeg:\n\n```bash\nffmpeg -framerate 2 -pattern_type glob -i 'tmp/screenshots/*.png' -vf \"scale=1280:-1\" tmp/videos/feature-demo.gif\n```\n\n\n\n### 5. Record the Walkthrough\n\n\n\nExecute the planned flow, capturing each step:\n\n**Step 1: Navigate to starting point**\n```bash\nagent-browser open \"[base-url]/[start-route]\"\nagent-browser wait 2000\nagent-browser screenshot tmp/screenshots/01-start.png\n```\n\n**Step 2: Perform navigation/interactions**\n```bash\nagent-browser snapshot -i # Get refs\nagent-browser click @e1 # Click navigation element\nagent-browser wait 1000\nagent-browser screenshot tmp/screenshots/02-navigate.png\n```\n\n**Step 3: Demonstrate feature**\n```bash\nagent-browser snapshot -i # Get refs for feature elements\nagent-browser click @e2 # Click feature element\nagent-browser wait 1000\nagent-browser screenshot tmp/screenshots/03-feature.png\n```\n\n**Step 4: Capture result**\n```bash\nagent-browser wait 2000\nagent-browser screenshot tmp/screenshots/04-result.png\n```\n\n**Create video/GIF from screenshots:**\n\n```bash\n# Create directories\nmkdir -p tmp/videos tmp/screenshots\n\n# Create MP4 video (RECOMMENDED - better quality, smaller size)\n# -framerate 0.5 = 2 seconds per frame (slower playback)\n# -framerate 1 = 1 second per frame\nffmpeg -y -framerate 0.5 -pattern_type glob -i 'tmp/screenshots/*.png' \\\n -c:v libx264 -pix_fmt yuv420p -vf \"scale=1280:-2\" \\\n tmp/videos/feature-demo.mp4\n\n# Create low-quality GIF for preview (small file, for GitHub embed)\nffmpeg -y -framerate 0.5 -pattern_type glob -i 'tmp/screenshots/*.png' \\\n -vf \"scale=640:-1:flags=lanczos,split[s0][s1];[s0]palettegen=max_colors=128[p];[s1][p]paletteuse\" \\\n -loop 0 tmp/videos/feature-demo-preview.gif\n```\n\n**Note:**\n- The `-2` in MP4 scale ensures height is divisible by 2 (required for H.264)\n- Preview GIF uses 640px width and 128 colors to keep file size small (~100-200KB)\n\n\n\n### 6. Upload the Video\n\n\n\n**Upload with rclone:**\n\n```bash\n# Check rclone is configured\nrclone listremotes\n\n# Upload video, preview GIF, and screenshots to cloud storage\n# Use --s3-no-check-bucket to avoid permission errors\nrclone copy tmp/videos/ r2:kieran-claude/pr-videos/pr-[number]/ --s3-no-check-bucket --progress\nrclone copy tmp/screenshots/ r2:kieran-claude/pr-videos/pr-[number]/screenshots/ --s3-no-check-bucket --progress\n\n# List uploaded files\nrclone ls r2:kieran-claude/pr-videos/pr-[number]/\n```\n\nPublic URLs (R2 with public access):\n```\nVideo: https://pub-4047722ebb1b4b09853f24d3b61467f1.r2.dev/pr-videos/pr-[number]/feature-demo.mp4\nPreview: https://pub-4047722ebb1b4b09853f24d3b61467f1.r2.dev/pr-videos/pr-[number]/feature-demo-preview.gif\n```\n\n\n\n### 7. Update PR Description\n\n\n\n**Get current PR body:**\n```bash\ngh pr view [number] --json body -q '.body'\n```\n\n**Add video section to PR description:**\n\nIf the PR already has a video section, replace it. Otherwise, append:\n\n**IMPORTANT:** GitHub cannot embed external MP4s directly. Use a clickable GIF that links to the video:\n\n```markdown\n## Demo\n\n[![Feature Demo]([preview-gif-url])]([video-mp4-url])\n\n*Click to view full video*\n```\n\nExample:\n```markdown\n[![Feature Demo](https://pub-4047722ebb1b4b09853f24d3b61467f1.r2.dev/pr-videos/pr-137/feature-demo-preview.gif)](https://pub-4047722ebb1b4b09853f24d3b61467f1.r2.dev/pr-videos/pr-137/feature-demo.mp4)\n```\n\n**Update the PR:**\n```bash\ngh pr edit [number] --body \"[updated body with video section]\"\n```\n\n**Or add as a comment if preferred:**\n```bash\ngh pr comment [number] --body \"## Feature Demo\n\n![Demo]([video-url])\n\n_Automated walkthrough of the changes in this PR_\"\n```\n\n\n\n### 8. Cleanup\n\n\n\n```bash\n# Optional: Clean up screenshots\nrm -rf tmp/screenshots\n\n# Keep videos for reference\necho \"Video retained at: tmp/videos/feature-demo.gif\"\n```\n\n\n\n### 9. Summary\n\n\n\nPresent completion summary:\n\n```markdown\n## Feature Video Complete\n\n**PR:** #[number] - [title]\n**Video:** [url or local path]\n**Duration:** ~[X] seconds\n**Format:** [GIF/MP4]\n\n### Shots Captured\n1. [Starting point] - [description]\n2. [Navigation] - [description]\n3. [Feature demo] - [description]\n4. [Result] - [description]\n\n### PR Updated\n- [x] Video section added to PR description\n- [ ] Ready for review\n\n**Next steps:**\n- Review the video to ensure it accurately demonstrates the feature\n- Share with reviewers for context\n```\n\n\n\n## Quick Usage Examples\n\n```bash\n# Record video for current branch's PR\n/feature-video\n\n# Record video for specific PR\n/feature-video 847\n\n# Record with custom base URL\n/feature-video 847 http://localhost:5000\n\n# Record for staging environment\n/feature-video current https://staging.example.com\n```\n\n## Tips\n\n- **Keep it short**: 10-30 seconds is ideal for PR demos\n- **Focus on the change**: Don't include unrelated UI\n- **Show before/after**: If fixing a bug, show the broken state first (if possible)\n- **Annotate if needed**: Add text overlays for complex features" + }, + "xcode-test": { + "description": "Build and test iOS apps on simulator using XcodeBuildMCP", + "template": "# Xcode Test Command\n\nBuild, install, and test iOS apps on the simulator using XcodeBuildMCP. Captures screenshots, logs, and verifies app behavior.\n\n## Introduction\n\niOS QA Engineer specializing in simulator-based testing\n\nThis command tests iOS/macOS apps by:\n- Building for simulator\n- Installing and launching the app\n- Taking screenshots of key screens\n- Capturing console logs for errors\n- Supporting human verification for external flows\n\n## Prerequisites\n\n\n- Xcode installed with command-line tools\n- XcodeBuildMCP server connected\n- Valid Xcode project or workspace\n- At least one iOS Simulator available\n\n\n## Main Tasks\n\n### 0. Verify XcodeBuildMCP is Installed\n\n\n\n**First, check if XcodeBuildMCP tools are available.**\n\nTry calling:\n```\nmcp__xcodebuildmcp__list_simulators({})\n```\n\n**If the tool is not found or errors:**\n\nTell the user:\n```markdown\n**XcodeBuildMCP not installed**\n\nPlease install the XcodeBuildMCP server first:\n\n\\`\\`\\`bash\nclaude mcp add XcodeBuildMCP -- npx xcodebuildmcp@latest\n\\`\\`\\`\n\nThen restart Claude Code and run `/xcode-test` again.\n```\n\n**Do NOT proceed** until XcodeBuildMCP is confirmed working.\n\n\n\n### 1. Discover Project and Scheme\n\n\n\n**Find available projects:**\n```\nmcp__xcodebuildmcp__discover_projs({})\n```\n\n**List schemes for the project:**\n```\nmcp__xcodebuildmcp__list_schemes({ project_path: \"/path/to/Project.xcodeproj\" })\n```\n\n**If argument provided:**\n- Use the specified scheme name\n- Or \"current\" to use the default/last-used scheme\n\n\n\n### 2. Boot Simulator\n\n\n\n**List available simulators:**\n```\nmcp__xcodebuildmcp__list_simulators({})\n```\n\n**Boot preferred simulator (iPhone 15 Pro recommended):**\n```\nmcp__xcodebuildmcp__boot_simulator({ simulator_id: \"[uuid]\" })\n```\n\n**Wait for simulator to be ready:**\nCheck simulator state before proceeding with installation.\n\n\n\n### 3. Build the App\n\n\n\n**Build for iOS Simulator:**\n```\nmcp__xcodebuildmcp__build_ios_sim_app({\n project_path: \"/path/to/Project.xcodeproj\",\n scheme: \"[scheme_name]\"\n})\n```\n\n**Handle build failures:**\n- Capture build errors\n- Create P1 todo for each build error\n- Report to user with specific error details\n\n**On success:**\n- Note the built app path for installation\n- Proceed to installation step\n\n\n\n### 4. Install and Launch\n\n\n\n**Install app on simulator:**\n```\nmcp__xcodebuildmcp__install_app_on_simulator({\n app_path: \"/path/to/built/App.app\",\n simulator_id: \"[uuid]\"\n})\n```\n\n**Launch the app:**\n```\nmcp__xcodebuildmcp__launch_app_on_simulator({\n bundle_id: \"[app.bundle.id]\",\n simulator_id: \"[uuid]\"\n})\n```\n\n**Start capturing logs:**\n```\nmcp__xcodebuildmcp__capture_sim_logs({\n simulator_id: \"[uuid]\",\n bundle_id: \"[app.bundle.id]\"\n})\n```\n\n\n\n### 5. Test Key Screens\n\n\n\nFor each key screen in the app:\n\n**Take screenshot:**\n```\nmcp__xcodebuildmcp__take_screenshot({\n simulator_id: \"[uuid]\",\n filename: \"screen-[name].png\"\n})\n```\n\n**Review screenshot for:**\n- UI elements rendered correctly\n- No error messages visible\n- Expected content displayed\n- Layout looks correct\n\n**Check logs for errors:**\n```\nmcp__xcodebuildmcp__get_sim_logs({ simulator_id: \"[uuid]\" })\n```\n\nLook for:\n- Crashes\n- Exceptions\n- Error-level log messages\n- Failed network requests\n\n\n\n### 6. Human Verification (When Required)\n\n\n\nPause for human input when testing touches:\n\n| Flow Type | What to Ask |\n|-----------|-------------|\n| Sign in with Apple | \"Please complete Sign in with Apple on the simulator\" |\n| Push notifications | \"Send a test push and confirm it appears\" |\n| In-app purchases | \"Complete a sandbox purchase\" |\n| Camera/Photos | \"Grant permissions and verify camera works\" |\n| Location | \"Allow location access and verify map updates\" |\n\nUse AskUserQuestion:\n```markdown\n**Human Verification Needed**\n\nThis test requires [flow type]. Please:\n1. [Action to take on simulator]\n2. [What to verify]\n\nDid it work correctly?\n1. Yes - continue testing\n2. No - describe the issue\n```\n\n\n\n### 7. Handle Failures\n\n\n\nWhen a test fails:\n\n1. **Document the failure:**\n - Take screenshot of error state\n - Capture console logs\n - Note reproduction steps\n\n2. **Ask user how to proceed:**\n ```markdown\n **Test Failed: [screen/feature]**\n\n Issue: [description]\n Logs: [relevant error messages]\n\n How to proceed?\n 1. Fix now - I'll help debug and fix\n 2. Create todo - Add to todos/ for later\n 3. Skip - Continue testing other screens\n ```\n\n3. **If \"Fix now\":**\n - Investigate the issue in code\n - Propose a fix\n - Rebuild and retest\n\n4. **If \"Create todo\":**\n - Create `{id}-pending-p1-xcode-{description}.md`\n - Continue testing\n\n\n\n### 8. Test Summary\n\n\n\nAfter all tests complete, present summary:\n\n```markdown\n## πŸ“± Xcode Test Results\n\n**Project:** [project name]\n**Scheme:** [scheme name]\n**Simulator:** [simulator name]\n\n### Build: βœ… Success / ❌ Failed\n\n### Screens Tested: [count]\n\n| Screen | Status | Notes |\n|--------|--------|-------|\n| Launch | βœ… Pass | |\n| Home | βœ… Pass | |\n| Settings | ❌ Fail | Crash on tap |\n| Profile | ⏭️ Skip | Requires login |\n\n### Console Errors: [count]\n- [List any errors found]\n\n### Human Verifications: [count]\n- Sign in with Apple: βœ… Confirmed\n- Push notifications: βœ… Confirmed\n\n### Failures: [count]\n- Settings screen - crash on navigation\n\n### Created Todos: [count]\n- `006-pending-p1-xcode-settings-crash.md`\n\n### Result: [PASS / FAIL / PARTIAL]\n```\n\n\n\n### 9. Cleanup\n\n\n\nAfter testing:\n\n**Stop log capture:**\n```\nmcp__xcodebuildmcp__stop_log_capture({ simulator_id: \"[uuid]\" })\n```\n\n**Optionally shut down simulator:**\n```\nmcp__xcodebuildmcp__shutdown_simulator({ simulator_id: \"[uuid]\" })\n```\n\n\n\n## Quick Usage Examples\n\n```bash\n# Test with default scheme\n/xcode-test\n\n# Test specific scheme\n/xcode-test MyApp-Debug\n\n# Test after making changes\n/xcode-test current\n```\n\n## Integration with /workflows:review\n\nWhen reviewing PRs that touch iOS code, the `/workflows:review` command can spawn this as a subagent:\n\n```\nTask general-purpose(\"Run /xcode-test for scheme [name]. Build, install on simulator, test key screens, check for crashes.\")\n```" + }, + "plan_review": { + "description": "Have multiple specialized agents review a plan in parallel", + "template": "Have @agent-dhh-rails-reviewer @agent-kieran-rails-reviewer @agent-code-simplicity-reviewer review this plan in parallel." + }, + "test-browser": { + "description": "Run browser tests on pages affected by current PR or branch", + "template": "# Browser Test Command\n\nRun end-to-end browser tests on pages affected by a PR or branch changes using agent-browser CLI.\n\n## CRITICAL: Use agent-browser CLI Only\n\n**DO NOT use Chrome MCP tools (mcp__claude-in-chrome__*).**\n\nThis command uses the `agent-browser` CLI exclusively. The agent-browser CLI is a Bash-based tool from Vercel that runs headless Chromium. It is NOT the same as Chrome browser automation via MCP.\n\nIf you find yourself calling `mcp__claude-in-chrome__*` tools, STOP. Use `agent-browser` Bash commands instead.\n\n## Introduction\n\nQA Engineer specializing in browser-based end-to-end testing\n\nThis command tests affected pages in a real browser, catching issues that unit tests miss:\n- JavaScript integration bugs\n- CSS/layout regressions\n- User workflow breakages\n- Console errors\n\n## Prerequisites\n\n\n- Local development server running (e.g., `bin/dev`, `rails server`, `npm run dev`)\n- agent-browser CLI installed (see Setup below)\n- Git repository with changes to test\n\n\n## Setup\n\n**Check installation:**\n```bash\ncommand -v agent-browser >/dev/null 2>&1 && echo \"Installed\" || echo \"NOT INSTALLED\"\n```\n\n**Install if needed:**\n```bash\nnpm install -g agent-browser\nagent-browser install # Downloads Chromium (~160MB)\n```\n\nSee the `agent-browser` skill for detailed usage.\n\n## Main Tasks\n\n### 0. Verify agent-browser Installation\n\nBefore starting ANY browser testing, verify agent-browser is installed:\n\n```bash\ncommand -v agent-browser >/dev/null 2>&1 && echo \"Ready\" || (echo \"Installing...\" && npm install -g agent-browser && agent-browser install)\n```\n\nIf installation fails, inform the user and stop.\n\n### 1. Ask Browser Mode\n\n\n\nBefore starting tests, ask user if they want to watch the browser:\n\nUse AskUserQuestion with:\n- Question: \"Do you want to watch the browser tests run?\"\n- Options:\n 1. **Headed (watch)** - Opens visible browser window so you can see tests run\n 2. **Headless (faster)** - Runs in background, faster but invisible\n\nStore the choice and use `--headed` flag when user selects \"Headed\".\n\n\n\n### 2. Determine Test Scope\n\n $ARGUMENTS \n\n\n\n**If PR number provided:**\n```bash\ngh pr view [number] --json files -q '.files[].path'\n```\n\n**If 'current' or empty:**\n```bash\ngit diff --name-only main...HEAD\n```\n\n**If branch name provided:**\n```bash\ngit diff --name-only main...[branch]\n```\n\n\n\n### 3. Map Files to Routes\n\n\n\nMap changed files to testable routes:\n\n| File Pattern | Route(s) |\n|-------------|----------|\n| `app/views/users/*` | `/users`, `/users/:id`, `/users/new` |\n| `app/controllers/settings_controller.rb` | `/settings` |\n| `app/javascript/controllers/*_controller.js` | Pages using that Stimulus controller |\n| `app/components/*_component.rb` | Pages rendering that component |\n| `app/views/layouts/*` | All pages (test homepage at minimum) |\n| `app/assets/stylesheets/*` | Visual regression on key pages |\n| `app/helpers/*_helper.rb` | Pages using that helper |\n| `src/app/*` (Next.js) | Corresponding routes |\n| `src/components/*` | Pages using those components |\n\nBuild a list of URLs to test based on the mapping.\n\n\n\n### 4. Verify Server is Running\n\n\n\nBefore testing, verify the local server is accessible:\n\n```bash\nagent-browser open http://localhost:3000\nagent-browser snapshot -i\n```\n\nIf server is not running, inform user:\n```markdown\n**Server not running**\n\nPlease start your development server:\n- Rails: `bin/dev` or `rails server`\n- Node/Next.js: `npm run dev`\n\nThen run `/test-browser` again.\n```\n\n\n\n### 5. Test Each Affected Page\n\n\n\nFor each affected route, use agent-browser CLI commands (NOT Chrome MCP):\n\n**Step 1: Navigate and capture snapshot**\n```bash\nagent-browser open \"http://localhost:3000/[route]\"\nagent-browser snapshot -i\n```\n\n**Step 2: For headed mode (visual debugging)**\n```bash\nagent-browser --headed open \"http://localhost:3000/[route]\"\nagent-browser --headed snapshot -i\n```\n\n**Step 3: Verify key elements**\n- Use `agent-browser snapshot -i` to get interactive elements with refs\n- Page title/heading present\n- Primary content rendered\n- No error messages visible\n- Forms have expected fields\n\n**Step 4: Test critical interactions**\n```bash\nagent-browser click @e1 # Use ref from snapshot\nagent-browser snapshot -i\n```\n\n**Step 5: Take screenshots**\n```bash\nagent-browser screenshot page-name.png\nagent-browser screenshot --full page-name-full.png # Full page\n```\n\n\n\n### 6. Human Verification (When Required)\n\n\n\nPause for human input when testing touches:\n\n| Flow Type | What to Ask |\n|-----------|-------------|\n| OAuth | \"Please sign in with [provider] and confirm it works\" |\n| Email | \"Check your inbox for the test email and confirm receipt\" |\n| Payments | \"Complete a test purchase in sandbox mode\" |\n| SMS | \"Verify you received the SMS code\" |\n| External APIs | \"Confirm the [service] integration is working\" |\n\nUse AskUserQuestion:\n```markdown\n**Human Verification Needed**\n\nThis test touches the [flow type]. Please:\n1. [Action to take]\n2. [What to verify]\n\nDid it work correctly?\n1. Yes - continue testing\n2. No - describe the issue\n```\n\n\n\n### 7. Handle Failures\n\n\n\nWhen a test fails:\n\n1. **Document the failure:**\n - Screenshot the error state: `agent-browser screenshot error.png`\n - Note the exact reproduction steps\n\n2. **Ask user how to proceed:**\n ```markdown\n **Test Failed: [route]**\n\n Issue: [description]\n Console errors: [if any]\n\n How to proceed?\n 1. Fix now - I'll help debug and fix\n 2. Create todo - Add to todos/ for later\n 3. Skip - Continue testing other pages\n ```\n\n3. **If \"Fix now\":**\n - Investigate the issue\n - Propose a fix\n - Apply fix\n - Re-run the failing test\n\n4. **If \"Create todo\":**\n - Create `{id}-pending-p1-browser-test-{description}.md`\n - Continue testing\n\n5. **If \"Skip\":**\n - Log as skipped\n - Continue testing\n\n\n\n### 8. Test Summary\n\n\n\nAfter all tests complete, present summary:\n\n```markdown\n## Browser Test Results\n\n**Test Scope:** PR #[number] / [branch name]\n**Server:** http://localhost:3000\n\n### Pages Tested: [count]\n\n| Route | Status | Notes |\n|-------|--------|-------|\n| `/users` | Pass | |\n| `/settings` | Pass | |\n| `/dashboard` | Fail | Console error: [msg] |\n| `/checkout` | Skip | Requires payment credentials |\n\n### Console Errors: [count]\n- [List any errors found]\n\n### Human Verifications: [count]\n- OAuth flow: Confirmed\n- Email delivery: Confirmed\n\n### Failures: [count]\n- `/dashboard` - [issue description]\n\n### Created Todos: [count]\n- `005-pending-p1-browser-test-dashboard-error.md`\n\n### Result: [PASS / FAIL / PARTIAL]\n```\n\n\n\n## Quick Usage Examples\n\n```bash\n# Test current branch changes\n/test-browser\n\n# Test specific PR\n/test-browser 847\n\n# Test specific branch\n/test-browser feature/new-dashboard\n```\n\n## agent-browser CLI Reference\n\n**ALWAYS use these Bash commands. NEVER use mcp__claude-in-chrome__* tools.**\n\n```bash\n# Navigation\nagent-browser open # Navigate to URL\nagent-browser back # Go back\nagent-browser close # Close browser\n\n# Snapshots (get element refs)\nagent-browser snapshot -i # Interactive elements with refs (@e1, @e2, etc.)\nagent-browser snapshot -i --json # JSON output\n\n# Interactions (use refs from snapshot)\nagent-browser click @e1 # Click element\nagent-browser fill @e1 \"text\" # Fill input\nagent-browser type @e1 \"text\" # Type without clearing\nagent-browser press Enter # Press key\n\n# Screenshots\nagent-browser screenshot out.png # Viewport screenshot\nagent-browser screenshot --full out.png # Full page screenshot\n\n# Headed mode (visible browser)\nagent-browser --headed open # Open with visible browser\nagent-browser --headed click @e1 # Click in visible browser\n\n# Wait\nagent-browser wait @e1 # Wait for element\nagent-browser wait 2000 # Wait milliseconds\n```" + }, + "create-agent-skill": { + "description": "Create or edit Claude Code skills with expert guidance on structure and best practices", + "template": "Invoke the create-agent-skills skill for: $ARGUMENTS" + }, + "workflows:review": { + "description": "Perform exhaustive code reviews using multi-agent analysis, ultra-thinking, and worktrees", + "template": "# Review Command\n\n Perform exhaustive code reviews using multi-agent analysis, ultra-thinking, and Git worktrees for deep local inspection. \n\n## Introduction\n\nSenior Code Review Architect with expertise in security, performance, architecture, and quality assurance\n\n## Prerequisites\n\n\n- Git repository with GitHub CLI (`gh`) installed and authenticated\n- Clean main/master branch\n- Proper permissions to create worktrees and access the repository\n- For document reviews: Path to a markdown file or document\n\n\n## Main Tasks\n\n### 1. Determine Review Target & Setup (ALWAYS FIRST)\n\n #$ARGUMENTS \n\n\nFirst, I need to determine the review target type and set up the code for analysis.\n\n\n#### Immediate Actions:\n\n\n\n- [ ] Determine review type: PR number (numeric), GitHub URL, file path (.md), or empty (current branch)\n- [ ] Check current git branch\n- [ ] If ALREADY on the target branch (PR branch, requested branch name, or the branch already checked out for review) β†’ proceed with analysis on current branch\n- [ ] If DIFFERENT branch than the review target β†’ offer to use worktree: \"Use git-worktree skill for isolated Call `skill: git-worktree` with branch name\n- [ ] Fetch PR metadata using `gh pr view --json` for title, body, files, linked issues\n- [ ] Set up language-specific analysis tools\n- [ ] Prepare security scanning environment\n- [ ] Make sure we are on the branch we are reviewing. Use gh pr checkout to switch to the branch or manually checkout the branch.\n\nEnsure that the code is ready for analysis (either in worktree or on current branch). ONLY then proceed to the next step.\n\n\n\n#### Protected Artifacts\n\n\nThe following paths are compound-engineering pipeline artifacts and must never be flagged for deletion, removal, or gitignore by any review agent:\n\n- `docs/plans/*.md` β€” Plan files created by `/workflows:plan`. These are living documents that track implementation progress (checkboxes are checked off by `/workflows:work`).\n- `docs/solutions/*.md` β€” Solution documents created during the pipeline.\n\nIf a review agent flags any file in these directories for cleanup or removal, discard that finding during synthesis. Do not create a todo for it.\n\n\n#### Parallel Agents to review the PR:\n\n\n\nRun ALL or most of these agents at the same time:\n\n1. Task kieran-rails-reviewer(PR content)\n2. Task dhh-rails-reviewer(PR title)\n3. If turbo is used: Task rails-turbo-expert(PR content)\n4. Task git-history-analyzer(PR content)\n5. Task dependency-detective(PR content)\n6. Task pattern-recognition-specialist(PR content)\n7. Task architecture-strategist(PR content)\n8. Task code-philosopher(PR content)\n9. Task security-sentinel(PR content)\n10. Task performance-oracle(PR content)\n11. Task devops-harmony-analyst(PR content)\n12. Task data-integrity-guardian(PR content)\n13. Task agent-native-reviewer(PR content) - Verify new features are agent-accessible\n\n\n\n#### Conditional Agents (Run if applicable):\n\n\n\nThese agents are run ONLY when the PR matches specific criteria. Check the PR files list to determine if they apply:\n\n**If PR contains database migrations (db/migrate/*.rb files) or data backfills:**\n\n14. Task data-migration-expert(PR content) - Validates ID mappings match production, checks for swapped values, verifies rollback safety\n15. Task deployment-verification-agent(PR content) - Creates Go/No-Go deployment checklist with SQL verification queries\n\n**When to run migration agents:**\n- PR includes files matching `db/migrate/*.rb`\n- PR modifies columns that store IDs, enums, or mappings\n- PR includes data backfill scripts or rake tasks\n- PR changes how data is read/written (e.g., changing from FK to string column)\n- PR title/body mentions: migration, backfill, data transformation, ID mapping\n\n**What these agents check:**\n- `data-migration-expert`: Verifies hard-coded mappings match production reality (prevents swapped IDs), checks for orphaned associations, validates dual-write patterns\n- `deployment-verification-agent`: Produces executable pre/post-deploy checklists with SQL queries, rollback procedures, and monitoring plans\n\n\n\n### 4. Ultra-Thinking Deep Dive Phases\n\n For each phase below, spend maximum cognitive effort. Think step by step. Consider all angles. Question assumptions. And bring all reviews in a synthesis to the user.\n\n\nComplete system context map with component interactions\n\n\n#### Phase 3: Stakeholder Perspective Analysis\n\n ULTRA-THINK: Put yourself in each stakeholder's shoes. What matters to them? What are their pain points? \n\n\n\n1. **Developer Perspective** \n\n - How easy is this to understand and modify?\n - Are the APIs intuitive?\n - Is debugging straightforward?\n - Can I test this easily? \n\n2. **Operations Perspective** \n\n - How do I deploy this safely?\n - What metrics and logs are available?\n - How do I troubleshoot issues?\n - What are the resource requirements? \n\n3. **End User Perspective** \n\n - Is the feature intuitive?\n - Are error messages helpful?\n - Is performance acceptable?\n - Does it solve my problem? \n\n4. **Security Team Perspective** \n\n - What's the attack surface?\n - Are there compliance requirements?\n - How is data protected?\n - What are the audit capabilities? \n\n5. **Business Perspective** \n - What's the ROI?\n - Are there legal/compliance risks?\n - How does this affect time-to-market?\n - What's the total cost of ownership? \n\n#### Phase 4: Scenario Exploration\n\n ULTRA-THINK: Explore edge cases and failure scenarios. What could go wrong? How does the system behave under stress? \n\n\n\n- [ ] **Happy Path**: Normal operation with valid inputs\n- [ ] **Invalid Inputs**: Null, empty, malformed data\n- [ ] **Boundary Conditions**: Min/max values, empty collections\n- [ ] **Concurrent Access**: Race conditions, deadlocks\n- [ ] **Scale Testing**: 10x, 100x, 1000x normal load\n- [ ] **Network Issues**: Timeouts, partial failures\n- [ ] **Resource Exhaustion**: Memory, disk, connections\n- [ ] **Security Attacks**: Injection, overflow, DoS\n- [ ] **Data Corruption**: Partial writes, inconsistency\n- [ ] **Cascading Failures**: Downstream service issues \n\n### 6. Multi-Angle Review Perspectives\n\n#### Technical Excellence Angle\n\n- Code craftsmanship evaluation\n- Engineering best practices\n- Technical documentation quality\n- Tooling and automation assessment\n\n#### Business Value Angle\n\n- Feature completeness validation\n- Performance impact on users\n- Cost-benefit analysis\n- Time-to-market considerations\n\n#### Risk Management Angle\n\n- Security risk assessment\n- Operational risk evaluation\n- Compliance risk verification\n- Technical debt accumulation\n\n#### Team Dynamics Angle\n\n- Code review etiquette\n- Knowledge sharing effectiveness\n- Collaboration patterns\n- Mentoring opportunities\n\n### 4. Simplification and Minimalism Review\n\nRun the Task code-simplicity-reviewer() to see if we can simplify the code.\n\n### 5. Findings Synthesis and Todo Creation Using file-todos Skill\n\n ALL findings MUST be stored in the todos/ directory using the file-todos skill. Create todo files immediately after synthesis - do NOT present findings for user approval first. Use the skill for structured todo management. \n\n#### Step 1: Synthesize All Findings\n\n\nConsolidate all agent reports into a categorized list of findings.\nRemove duplicates, prioritize by severity and impact.\n\n\n\n\n- [ ] Collect findings from all parallel agents\n- [ ] Discard any findings that recommend deleting or gitignoring files in `docs/plans/` or `docs/solutions/` (see Protected Artifacts above)\n- [ ] Categorize by type: security, performance, architecture, quality, etc.\n- [ ] Assign severity levels: πŸ”΄ CRITICAL (P1), 🟑 IMPORTANT (P2), πŸ”΅ NICE-TO-HAVE (P3)\n- [ ] Remove duplicate or overlapping findings\n- [ ] Estimate effort for each finding (Small/Medium/Large)\n\n\n\n#### Step 2: Create Todo Files Using file-todos Skill\n\n Use the file-todos skill to create todo files for ALL findings immediately. Do NOT present findings one-by-one asking for user approval. Create all todo files in parallel using the skill, then summarize results to user. \n\n**Implementation Options:**\n\n**Option A: Direct File Creation (Fast)**\n\n- Create todo files directly using Write tool\n- All findings in parallel for speed\n- Use standard template from `.claude/skills/file-todos/assets/todo-template.md`\n- Follow naming convention: `{issue_id}-pending-{priority}-{description}.md`\n\n**Option B: Sub-Agents in Parallel (Recommended for Scale)** For large PRs with 15+ findings, use sub-agents to create finding files in parallel:\n\n```bash\n# Launch multiple finding-creator agents in parallel\nTask() - Create todos for first finding\nTask() - Create todos for second finding\nTask() - Create todos for third finding\netc. for each finding.\n```\n\nSub-agents can:\n\n- Process multiple findings simultaneously\n- Write detailed todo files with all sections filled\n- Organize findings by severity\n- Create comprehensive Proposed Solutions\n- Add acceptance criteria and work logs\n- Complete much faster than sequential processing\n\n**Execution Strategy:**\n\n1. Synthesize all findings into categories (P1/P2/P3)\n2. Group findings by severity\n3. Launch 3 parallel sub-agents (one per severity level)\n4. Each sub-agent creates its batch of todos using the file-todos skill\n5. Consolidate results and present summary\n\n**Process (Using file-todos Skill):**\n\n1. For each finding:\n\n - Determine severity (P1/P2/P3)\n - Write detailed Problem Statement and Findings\n - Create 2-3 Proposed Solutions with pros/cons/effort/risk\n - Estimate effort (Small/Medium/Large)\n - Add acceptance criteria and work log\n\n2. Use file-todos skill for structured todo management:\n\n ```bash\n skill: file-todos\n ```\n\n The skill provides:\n\n - Template location: `.claude/skills/file-todos/assets/todo-template.md`\n - Naming convention: `{issue_id}-{status}-{priority}-{description}.md`\n - YAML frontmatter structure: status, priority, issue_id, tags, dependencies\n - All required sections: Problem Statement, Findings, Solutions, etc.\n\n3. Create todo files in parallel:\n\n ```bash\n {next_id}-pending-{priority}-{description}.md\n ```\n\n4. Examples:\n\n ```\n 001-pending-p1-path-traversal-vulnerability.md\n 002-pending-p1-api-response-validation.md\n 003-pending-p2-concurrency-limit.md\n 004-pending-p3-unused-parameter.md\n ```\n\n5. Follow template structure from file-todos skill: `.claude/skills/file-todos/assets/todo-template.md`\n\n**Todo File Structure (from template):**\n\nEach todo must include:\n\n- **YAML frontmatter**: status, priority, issue_id, tags, dependencies\n- **Problem Statement**: What's broken/missing, why it matters\n- **Findings**: Discoveries from agents with evidence/location\n- **Proposed Solutions**: 2-3 options, each with pros/cons/effort/risk\n- **Recommended Action**: (Filled during triage, leave blank initially)\n- **Technical Details**: Affected files, components, database changes\n- **Acceptance Criteria**: Testable checklist items\n- **Work Log**: Dated record with actions and learnings\n- **Resources**: Links to PR, issues, documentation, similar patterns\n\n**File naming convention:**\n\n```\n{issue_id}-{status}-{priority}-{description}.md\n\nExamples:\n- 001-pending-p1-security-vulnerability.md\n- 002-pending-p2-performance-optimization.md\n- 003-pending-p3-code-cleanup.md\n```\n\n**Status values:**\n\n- `pending` - New findings, needs triage/decision\n- `ready` - Approved by manager, ready to work\n- `complete` - Work finished\n\n**Priority values:**\n\n- `p1` - Critical (blocks merge, security/data issues)\n- `p2` - Important (should fix, architectural/performance)\n- `p3` - Nice-to-have (enhancements, cleanup)\n\n**Tagging:** Always add `code-review` tag, plus: `security`, `performance`, `architecture`, `rails`, `quality`, etc.\n\n#### Step 3: Summary Report\n\nAfter creating all todo files, present comprehensive summary:\n\n````markdown\n## βœ… Code Review Complete\n\n**Review Target:** PR #XXXX - [PR Title] **Branch:** [branch-name]\n\n### Findings Summary:\n\n- **Total Findings:** [X]\n- **πŸ”΄ CRITICAL (P1):** [count] - BLOCKS MERGE\n- **🟑 IMPORTANT (P2):** [count] - Should Fix\n- **πŸ”΅ NICE-TO-HAVE (P3):** [count] - Enhancements\n\n### Created Todo Files:\n\n**P1 - Critical (BLOCKS MERGE):**\n\n- `001-pending-p1-{finding}.md` - {description}\n- `002-pending-p1-{finding}.md` - {description}\n\n**P2 - Important:**\n\n- `003-pending-p2-{finding}.md` - {description}\n- `004-pending-p2-{finding}.md` - {description}\n\n**P3 - Nice-to-Have:**\n\n- `005-pending-p3-{finding}.md` - {description}\n\n### Review Agents Used:\n\n- kieran-rails-reviewer\n- security-sentinel\n- performance-oracle\n- architecture-strategist\n- agent-native-reviewer\n- [other agents]\n\n### Next Steps:\n\n1. **Address P1 Findings**: CRITICAL - must be fixed before merge\n\n - Review each P1 todo in detail\n - Implement fixes or request exemption\n - Verify fixes before merging PR\n\n2. **Triage All Todos**:\n ```bash\n ls todos/*-pending-*.md # View all pending todos\n /triage # Use slash command for interactive triage\n ```\n````\n\n3. **Work on Approved Todos**:\n\n ```bash\n /resolve_todo_parallel # Fix all approved items efficiently\n ```\n\n4. **Track Progress**:\n - Rename file when status changes: pending β†’ ready β†’ complete\n - Update Work Log as you work\n - Commit todos: `git add todos/ && git commit -m \"refactor: add code review findings\"`\n\n### Severity Breakdown:\n\n**πŸ”΄ P1 (Critical - Blocks Merge):**\n\n- Security vulnerabilities\n- Data corruption risks\n- Breaking changes\n- Critical architectural issues\n\n**🟑 P2 (Important - Should Fix):**\n\n- Performance issues\n- Significant architectural concerns\n- Major code quality problems\n- Reliability issues\n\n**πŸ”΅ P3 (Nice-to-Have):**\n\n- Minor improvements\n- Code cleanup\n- Optimization opportunities\n- Documentation updates\n\n```\n\n### 7. End-to-End Testing (Optional)\n\n\n\n**First, detect the project type from PR files:**\n\n| Indicator | Project Type |\n|-----------|--------------|\n| `*.xcodeproj`, `*.xcworkspace`, `Package.swift` (iOS) | iOS/macOS |\n| `Gemfile`, `package.json`, `app/views/*`, `*.html.*` | Web |\n| Both iOS files AND web files | Hybrid (test both) |\n\n\n\n\n\nAfter presenting the Summary Report, offer appropriate testing based on project type:\n\n**For Web Projects:**\n```markdown\n**\"Want to run browser tests on the affected pages?\"**\n1. Yes - run `/test-browser`\n2. No - skip\n```\n\n**For iOS Projects:**\n```markdown\n**\"Want to run Xcode simulator tests on the app?\"**\n1. Yes - run `/xcode-test`\n2. No - skip\n```\n\n**For Hybrid Projects (e.g., Rails + Hotwire Native):**\n```markdown\n**\"Want to run end-to-end tests?\"**\n1. Web only - run `/test-browser`\n2. iOS only - run `/xcode-test`\n3. Both - run both commands\n4. No - skip\n```\n\n\n\n#### If User Accepts Web Testing:\n\nSpawn a subagent to run browser tests (preserves main context):\n\n```\nTask general-purpose(\"Run /test-browser for PR #[number]. Test all affected pages, check for console errors, handle failures by creating todos and fixing.\")\n```\n\nThe subagent will:\n1. Identify pages affected by the PR\n2. Navigate to each page and capture snapshots (using Playwright MCP or agent-browser CLI)\n3. Check for console errors\n4. Test critical interactions\n5. Pause for human verification on OAuth/email/payment flows\n6. Create P1 todos for any failures\n7. Fix and retry until all tests pass\n\n**Standalone:** `/test-browser [PR number]`\n\n#### If User Accepts iOS Testing:\n\nSpawn a subagent to run Xcode tests (preserves main context):\n\n```\nTask general-purpose(\"Run /xcode-test for scheme [name]. Build for simulator, install, launch, take screenshots, check for crashes.\")\n```\n\nThe subagent will:\n1. Verify XcodeBuildMCP is installed\n2. Discover project and schemes\n3. Build for iOS Simulator\n4. Install and launch app\n5. Take screenshots of key screens\n6. Capture console logs for errors\n7. Pause for human verification (Sign in with Apple, push, IAP)\n8. Create P1 todos for any failures\n9. Fix and retry until all tests pass\n\n**Standalone:** `/xcode-test [scheme]`\n\n### Important: P1 Findings Block Merge\n\nAny **πŸ”΄ P1 (CRITICAL)** findings must be addressed before merging the PR. Present these prominently and ensure they're resolved before accepting the PR.\n```" + }, + "workflows:work": { + "description": "Execute work plans efficiently while maintaining quality and finishing features", + "template": "# Work Plan Execution Command\n\nExecute a work plan efficiently while maintaining quality and finishing features.\n\n## Introduction\n\nThis command takes a work document (plan, specification, or todo file) and executes it systematically. The focus is on **shipping complete features** by understanding requirements quickly, following existing patterns, and maintaining quality throughout.\n\n## Input Document\n\n #$ARGUMENTS \n\n## Execution Workflow\n\n### Phase 1: Quick Start\n\n1. **Read Plan and Clarify**\n\n - Read the work document completely\n - Review any references or links provided in the plan\n - If anything is unclear or ambiguous, ask clarifying questions now\n - Get user approval to proceed\n - **Do not skip this** - better to ask questions now than build the wrong thing\n\n2. **Setup Environment**\n\n First, check the current branch:\n\n ```bash\n current_branch=$(git branch --show-current)\n default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')\n\n # Fallback if remote HEAD isn't set\n if [ -z \"$default_branch\" ]; then\n default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo \"main\" || echo \"master\")\n fi\n ```\n\n **If already on a feature branch** (not the default branch):\n - Ask: \"Continue working on `[current_branch]`, or create a new branch?\"\n - If continuing, proceed to step 3\n - If creating new, follow Option A or B below\n\n **If on the default branch**, choose how to proceed:\n\n **Option A: Create a new branch**\n ```bash\n git pull origin [default_branch]\n git checkout -b feature-branch-name\n ```\n Use a meaningful name based on the work (e.g., `feat/user-authentication`, `fix/email-validation`).\n\n **Option B: Use a worktree (recommended for parallel development)**\n ```bash\n skill: git-worktree\n # The skill will create a new branch from the default branch in an isolated worktree\n ```\n\n **Option C: Continue on the default branch**\n - Requires explicit user confirmation\n - Only proceed after user explicitly says \"yes, commit to [default_branch]\"\n - Never commit directly to the default branch without explicit permission\n\n **Recommendation**: Use worktree if:\n - You want to work on multiple features simultaneously\n - You want to keep the default branch clean while experimenting\n - You plan to switch between branches frequently\n\n3. **Create Todo List**\n - Use TodoWrite to break plan into actionable tasks\n - Include dependencies between tasks\n - Prioritize based on what needs to be done first\n - Include testing and quality check tasks\n - Keep tasks specific and completable\n\n### Phase 2: Execute\n\n1. **Task Execution Loop**\n\n For each task in priority order:\n\n ```\n while (tasks remain):\n - Mark task as in_progress in TodoWrite\n - Read any referenced files from the plan\n - Look for similar patterns in codebase\n - Implement following existing conventions\n - Write tests for new functionality\n - Run tests after changes\n - Mark task as completed in TodoWrite\n - Mark off the corresponding checkbox in the plan file ([ ] β†’ [x])\n - Evaluate for incremental commit (see below)\n ```\n\n **IMPORTANT**: Always update the original plan document by checking off completed items. Use the Edit tool to change `- [ ]` to `- [x]` for each task you finish. This keeps the plan as a living document showing progress and ensures no checkboxes are left unchecked.\n\n2. **Incremental Commits**\n\n After completing each task, evaluate whether to create an incremental commit:\n\n | Commit when... | Don't commit when... |\n |----------------|---------------------|\n | Logical unit complete (model, service, component) | Small part of a larger unit |\n | Tests pass + meaningful progress | Tests failing |\n | About to switch contexts (backend β†’ frontend) | Purely scaffolding with no behavior |\n | About to attempt risky/uncertain changes | Would need a \"WIP\" commit message |\n\n **Heuristic:** \"Can I write a commit message that describes a complete, valuable change? If yes, commit. If the message would be 'WIP' or 'partial X', wait.\"\n\n **Commit workflow:**\n ```bash\n # 1. Verify tests pass (use project's test command)\n # Examples: bin/rails test, npm test, pytest, go test, etc.\n\n # 2. Stage only files related to this logical unit (not `git add .`)\n git add \n\n # 3. Commit with conventional message\n git commit -m \"feat(scope): description of this unit\"\n ```\n\n **Handling merge conflicts:** If conflicts arise during rebasing or merging, resolve them immediately. Incremental commits make conflict resolution easier since each commit is small and focused.\n\n **Note:** Incremental commits use clean conventional messages without attribution footers. The final Phase 4 commit/PR includes the full attribution.\n\n3. **Follow Existing Patterns**\n\n - The plan should reference similar code - read those files first\n - Match naming conventions exactly\n - Reuse existing components where possible\n - Follow project coding standards (see CLAUDE.md)\n - When in doubt, grep for similar implementations\n\n4. **Test Continuously**\n\n - Run relevant tests after each significant change\n - Don't wait until the end to test\n - Fix failures immediately\n - Add new tests for new functionality\n\n5. **Figma Design Sync** (if applicable)\n\n For UI work with Figma designs:\n\n - Implement components following design specs\n - Use figma-design-sync agent iteratively to compare\n - Fix visual differences identified\n - Repeat until implementation matches design\n\n6. **Track Progress**\n - Keep TodoWrite updated as you complete tasks\n - Note any blockers or unexpected discoveries\n - Create new tasks if scope expands\n - Keep user informed of major milestones\n\n### Phase 3: Quality Check\n\n1. **Run Core Quality Checks**\n\n Always run before submitting:\n\n ```bash\n # Run full test suite (use project's test command)\n # Examples: bin/rails test, npm test, pytest, go test, etc.\n\n # Run linting (per CLAUDE.md)\n # Use linting-agent before pushing to origin\n ```\n\n2. **Consider Reviewer Agents** (Optional)\n\n Use for complex, risky, or large changes:\n\n - **code-simplicity-reviewer**: Check for unnecessary complexity\n - **kieran-rails-reviewer**: Verify Rails conventions (Rails projects)\n - **performance-oracle**: Check for performance issues\n - **security-sentinel**: Scan for security vulnerabilities\n - **cora-test-reviewer**: Review test quality (Rails projects with comprehensive test coverage)\n\n Run reviewers in parallel with Task tool:\n\n ```\n Task(code-simplicity-reviewer): \"Review changes for simplicity\"\n Task(kieran-rails-reviewer): \"Check Rails conventions\"\n ```\n\n Present findings to user and address critical issues.\n\n3. **Final Validation**\n - All TodoWrite tasks marked completed\n - All tests pass\n - Linting passes\n - Code follows existing patterns\n - Figma designs match (if applicable)\n - No console errors or warnings\n\n### Phase 4: Ship It\n\n1. **Create Commit**\n\n ```bash\n git add .\n git status # Review what's being committed\n git diff --staged # Check the changes\n\n # Commit with conventional format\n git commit -m \"$(cat <<'EOF'\n feat(scope): description of what and why\n\n Brief explanation if needed.\n\n πŸ€– Generated with [Claude Code](https://claude.com/claude-code)\n\n Co-Authored-By: Claude \n EOF\n )\"\n ```\n\n2. **Capture and Upload Screenshots for UI Changes** (REQUIRED for any UI work)\n\n For **any** design changes, new views, or UI modifications, you MUST capture and upload screenshots:\n\n **Step 1: Start dev server** (if not running)\n ```bash\n bin/dev # Run in background\n ```\n\n **Step 2: Capture screenshots with agent-browser CLI**\n ```bash\n agent-browser open http://localhost:3000/[route]\n agent-browser snapshot -i\n agent-browser screenshot output.png\n ```\n See the `agent-browser` skill for detailed usage.\n\n **Step 3: Upload using imgup skill**\n ```bash\n skill: imgup\n # Then upload each screenshot:\n imgup -h pixhost screenshot.png # pixhost works without API key\n # Alternative hosts: catbox, imagebin, beeimg\n ```\n\n **What to capture:**\n - **New screens**: Screenshot of the new UI\n - **Modified screens**: Before AND after screenshots\n - **Design implementation**: Screenshot showing Figma design match\n\n **IMPORTANT**: Always include uploaded image URLs in PR description. This provides visual context for reviewers and documents the change.\n\n3. **Create Pull Request**\n\n ```bash\n git push -u origin feature-branch-name\n\n gh pr create --title \"Feature: [Description]\" --body \"$(cat <<'EOF'\n ## Summary\n - What was built\n - Why it was needed\n - Key decisions made\n\n ## Testing\n - Tests added/modified\n - Manual testing performed\n\n ## Before / After Screenshots\n | Before | After |\n |--------|-------|\n | ![before](URL) | ![after](URL) |\n\n ## Figma Design\n [Link if applicable]\n\n ---\n\n [![Compound Engineered](https://img.shields.io/badge/Compound-Engineered-6366f1)](https://github.com/EveryInc/compound-engineering-plugin) πŸ€– Generated with [Claude Code](https://claude.com/claude-code)\n EOF\n )\"\n ```\n\n4. **Notify User**\n - Summarize what was completed\n - Link to PR\n - Note any follow-up work needed\n - Suggest next steps if applicable\n\n---\n\n## Swarm Mode (Optional)\n\nFor complex plans with multiple independent workstreams, enable swarm mode for parallel execution with coordinated agents.\n\n### When to Use Swarm Mode\n\n| Use Swarm Mode when... | Use Standard Mode when... |\n|------------------------|---------------------------|\n| Plan has 5+ independent tasks | Plan is linear/sequential |\n| Multiple specialists needed (review + test + implement) | Single-focus work |\n| Want maximum parallelism | Simpler mental model preferred |\n| Large feature with clear phases | Small feature or bug fix |\n\n### Enabling Swarm Mode\n\nTo trigger swarm execution, say:\n\n> \"Make a Task list and launch an army of agent swarm subagents to build the plan\"\n\nOr explicitly request: \"Use swarm mode for this work\"\n\n### Swarm Workflow\n\nWhen swarm mode is enabled, the workflow changes:\n\n1. **Create Team**\n ```\n Teammate({ operation: \"spawnTeam\", team_name: \"work-{timestamp}\" })\n ```\n\n2. **Create Task List with Dependencies**\n - Parse plan into TaskCreate items\n - Set up blockedBy relationships for sequential dependencies\n - Independent tasks have no blockers (can run in parallel)\n\n3. **Spawn Specialized Teammates**\n ```\n Task({\n team_name: \"work-{timestamp}\",\n name: \"implementer\",\n subagent_type: \"general-purpose\",\n prompt: \"Claim implementation tasks, execute, mark complete\",\n run_in_background: true\n })\n\n Task({\n team_name: \"work-{timestamp}\",\n name: \"tester\",\n subagent_type: \"general-purpose\",\n prompt: \"Claim testing tasks, run tests, mark complete\",\n run_in_background: true\n })\n ```\n\n4. **Coordinate and Monitor**\n - Team lead monitors task completion\n - Spawn additional workers as phases unblock\n - Handle plan approval if required\n\n5. **Cleanup**\n ```\n Teammate({ operation: \"requestShutdown\", target_agent_id: \"implementer\" })\n Teammate({ operation: \"requestShutdown\", target_agent_id: \"tester\" })\n Teammate({ operation: \"cleanup\" })\n ```\n\nSee the `orchestrating-swarms` skill for detailed swarm patterns and best practices.\n\n---\n\n## Key Principles\n\n### Start Fast, Execute Faster\n\n- Get clarification once at the start, then execute\n- Don't wait for perfect understanding - ask questions and move\n- The goal is to **finish the feature**, not create perfect process\n\n### The Plan is Your Guide\n\n- Work documents should reference similar code and patterns\n- Load those references and follow them\n- Don't reinvent - match what exists\n\n### Test As You Go\n\n- Run tests after each change, not at the end\n- Fix failures immediately\n- Continuous testing prevents big surprises\n\n### Quality is Built In\n\n- Follow existing patterns\n- Write tests for new code\n- Run linting before pushing\n- Use reviewer agents for complex/risky changes only\n\n### Ship Complete Features\n\n- Mark all tasks completed before moving on\n- Don't leave features 80% done\n- A finished feature that ships beats a perfect feature that doesn't\n\n## Quality Checklist\n\nBefore creating PR, verify:\n\n- [ ] All clarifying questions asked and answered\n- [ ] All TodoWrite tasks marked completed\n- [ ] Tests pass (run project's test command)\n- [ ] Linting passes (use linting-agent)\n- [ ] Code follows existing patterns\n- [ ] Figma designs match implementation (if applicable)\n- [ ] Before/after screenshots captured and uploaded (for UI changes)\n- [ ] Commit messages follow conventional format\n- [ ] PR description includes summary, testing notes, and screenshots\n- [ ] PR description includes Compound Engineered badge\n\n## When to Use Reviewer Agents\n\n**Don't use by default.** Use reviewer agents only when:\n\n- Large refactor affecting many files (10+)\n- Security-sensitive changes (authentication, permissions, data access)\n- Performance-critical code paths\n- Complex algorithms or business logic\n- User explicitly requests thorough review\n\nFor most features: tests + linting + following patterns is sufficient.\n\n## Common Pitfalls to Avoid\n\n- **Analysis paralysis** - Don't overthink, read the plan and execute\n- **Skipping clarifying questions** - Ask now, not after building wrong thing\n- **Ignoring plan references** - The plan has links for a reason\n- **Testing at the end** - Test continuously or suffer later\n- **Forgetting TodoWrite** - Track progress or lose track of what's done\n- **80% done syndrome** - Finish the feature, don't move on early\n- **Over-reviewing simple changes** - Save reviewer agents for complex work" + }, + "workflows:brainstorm": { + "description": "Explore requirements and approaches through collaborative dialogue before planning implementation", + "template": "# Brainstorm a Feature or Improvement\n\n**Note: The current year is 2026.** Use this when dating brainstorm documents.\n\nBrainstorming helps answer **WHAT** to build through collaborative dialogue. It precedes `/workflows:plan`, which answers **HOW** to build it.\n\n**Process knowledge:** Load the `brainstorming` skill for detailed question techniques, approach exploration patterns, and YAGNI principles.\n\n## Feature Description\n\n #$ARGUMENTS \n\n**If the feature description above is empty, ask the user:** \"What would you like to explore? Please describe the feature, problem, or improvement you're thinking about.\"\n\nDo not proceed until you have a feature description from the user.\n\n## Execution Flow\n\n### Phase 0: Assess Requirements Clarity\n\nEvaluate whether brainstorming is needed based on the feature description.\n\n**Clear requirements indicators:**\n- Specific acceptance criteria provided\n- Referenced existing patterns to follow\n- Described exact expected behavior\n- Constrained, well-defined scope\n\n**If requirements are already clear:**\nUse **AskUserQuestion tool** to suggest: \"Your requirements seem detailed enough to proceed directly to planning. Should I run `/workflows:plan` instead, or would you like to explore the idea further?\"\n\n### Phase 1: Understand the Idea\n\n#### 1.1 Repository Research (Lightweight)\n\nRun a quick repo scan to understand existing patterns:\n\n- Task repo-research-analyst(\"Understand existing patterns related to: \")\n\nFocus on: similar features, established patterns, CLAUDE.md guidance.\n\n#### 1.2 Collaborative Dialogue\n\nUse the **AskUserQuestion tool** to ask questions **one at a time**.\n\n**Guidelines (see `brainstorming` skill for detailed techniques):**\n- Prefer multiple choice when natural options exist\n- Start broad (purpose, users) then narrow (constraints, edge cases)\n- Validate assumptions explicitly\n- Ask about success criteria\n\n**Exit condition:** Continue until the idea is clear OR user says \"proceed\"\n\n### Phase 2: Explore Approaches\n\nPropose **2-3 concrete approaches** based on research and conversation.\n\nFor each approach, provide:\n- Brief description (2-3 sentences)\n- Pros and cons\n- When it's best suited\n\nLead with your recommendation and explain why. Apply YAGNIβ€”prefer simpler solutions.\n\nUse **AskUserQuestion tool** to ask which approach the user prefers.\n\n### Phase 3: Capture the Design\n\nWrite a brainstorm document to `docs/brainstorms/YYYY-MM-DD--brainstorm.md`.\n\n**Document structure:** See the `brainstorming` skill for the template format. Key sections: What We're Building, Why This Approach, Key Decisions, Open Questions.\n\nEnsure `docs/brainstorms/` directory exists before writing.\n\n### Phase 4: Handoff\n\nUse **AskUserQuestion tool** to present next steps:\n\n**Question:** \"Brainstorm captured. What would you like to do next?\"\n\n**Options:**\n1. **Proceed to planning** - Run `/workflows:plan` (will auto-detect this brainstorm)\n2. **Refine design further** - Continue exploring\n3. **Done for now** - Return later\n\n## Output Summary\n\nWhen complete, display:\n\n```\nBrainstorm complete!\n\nDocument: docs/brainstorms/YYYY-MM-DD--brainstorm.md\n\nKey decisions:\n- [Decision 1]\n- [Decision 2]\n\nNext: Run `/workflows:plan` when ready to implement.\n```\n\n## Important Guidelines\n\n- **Stay focused on WHAT, not HOW** - Implementation details belong in the plan\n- **Ask one question at a time** - Don't overwhelm\n- **Apply YAGNI** - Prefer simpler approaches\n- **Keep outputs concise** - 200-300 words per section max\n\nNEVER CODE! Just explore and document decisions." + }, + "workflows:compound": { + "description": "Document a recently solved problem to compound your team's knowledge", + "template": "# /compound\n\nCoordinate multiple subagents working in parallel to document a recently solved problem.\n\n## Purpose\n\nCaptures problem solutions while context is fresh, creating structured documentation in `docs/solutions/` with YAML frontmatter for searchability and future reference. Uses parallel subagents for maximum efficiency.\n\n**Why \"compound\"?** Each documented solution compounds your team's knowledge. The first time you solve a problem takes research. Document it, and the next occurrence takes minutes. Knowledge compounds.\n\n## Usage\n\n```bash\n/workflows:compound # Document the most recent fix\n/workflows:compound [brief context] # Provide additional context hint\n```\n\n## Execution Strategy: Parallel Subagents\n\nThis command launches multiple specialized subagents IN PARALLEL to maximize efficiency:\n\n### 1. **Context Analyzer** (Parallel)\n - Extracts conversation history\n - Identifies problem type, component, symptoms\n - Validates against solution schema\n - Returns: YAML frontmatter skeleton\n\n### 2. **Solution Extractor** (Parallel)\n - Analyzes all investigation steps\n - Identifies root cause\n - Extracts working solution with code examples\n - Returns: Solution content block\n\n### 3. **Related Docs Finder** (Parallel)\n - Searches `docs/solutions/` for related documentation\n - Identifies cross-references and links\n - Finds related GitHub issues\n - Returns: Links and relationships\n\n### 4. **Prevention Strategist** (Parallel)\n - Develops prevention strategies\n - Creates best practices guidance\n - Generates test cases if applicable\n - Returns: Prevention/testing content\n\n### 5. **Category Classifier** (Parallel)\n - Determines optimal `docs/solutions/` category\n - Validates category against schema\n - Suggests filename based on slug\n - Returns: Final path and filename\n\n### 6. **Documentation Writer** (Parallel)\n - Assembles complete markdown file\n - Validates YAML frontmatter\n - Formats content for readability\n - Creates the file in correct location\n\n### 7. **Optional: Specialized Agent Invocation** (Post-Documentation)\n Based on problem type detected, automatically invoke applicable agents:\n - **performance_issue** β†’ `performance-oracle`\n - **security_issue** β†’ `security-sentinel`\n - **database_issue** β†’ `data-integrity-guardian`\n - **test_failure** β†’ `cora-test-reviewer`\n - Any code-heavy issue β†’ `kieran-rails-reviewer` + `code-simplicity-reviewer`\n\n## What It Captures\n\n- **Problem symptom**: Exact error messages, observable behavior\n- **Investigation steps tried**: What didn't work and why\n- **Root cause analysis**: Technical explanation\n- **Working solution**: Step-by-step fix with code examples\n- **Prevention strategies**: How to avoid in future\n- **Cross-references**: Links to related issues and docs\n\n## Preconditions\n\n\n \n Problem has been solved (not in-progress)\n \n \n Solution has been verified working\n \n \n Non-trivial problem (not simple typo or obvious error)\n \n\n\n## What It Creates\n\n**Organized documentation:**\n\n- File: `docs/solutions/[category]/[filename].md`\n\n**Categories auto-detected from problem:**\n\n- build-errors/\n- test-failures/\n- runtime-errors/\n- performance-issues/\n- database-issues/\n- security-issues/\n- ui-bugs/\n- integration-issues/\n- logic-errors/\n\n## Success Output\n\n```\nβœ“ Parallel documentation generation complete\n\nPrimary Subagent Results:\n βœ“ Context Analyzer: Identified performance_issue in brief_system\n βœ“ Solution Extractor: Extracted 3 code fixes\n βœ“ Related Docs Finder: Found 2 related issues\n βœ“ Prevention Strategist: Generated test cases\n βœ“ Category Classifier: docs/solutions/performance-issues/\n βœ“ Documentation Writer: Created complete markdown\n\nSpecialized Agent Reviews (Auto-Triggered):\n βœ“ performance-oracle: Validated query optimization approach\n βœ“ kieran-rails-reviewer: Code examples meet Rails standards\n βœ“ code-simplicity-reviewer: Solution is appropriately minimal\n βœ“ every-style-editor: Documentation style verified\n\nFile created:\n- docs/solutions/performance-issues/n-plus-one-brief-generation.md\n\nThis documentation will be searchable for future reference when similar\nissues occur in the Email Processing or Brief System modules.\n\nWhat's next?\n1. Continue workflow (recommended)\n2. Link related documentation\n3. Update other references\n4. View documentation\n5. Other\n```\n\n## The Compounding Philosophy\n\nThis creates a compounding knowledge system:\n\n1. First time you solve \"N+1 query in brief generation\" β†’ Research (30 min)\n2. Document the solution β†’ docs/solutions/performance-issues/n-plus-one-briefs.md (5 min)\n3. Next time similar issue occurs β†’ Quick lookup (2 min)\n4. Knowledge compounds β†’ Team gets smarter\n\nThe feedback loop:\n\n```\nBuild β†’ Test β†’ Find Issue β†’ Research β†’ Improve β†’ Document β†’ Validate β†’ Deploy\n ↑ ↓\n β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜\n```\n\n**Each unit of engineering work should make subsequent units of work easierβ€”not harder.**\n\n## Auto-Invoke\n\n - \"that worked\" - \"it's fixed\" - \"working now\" - \"problem solved\" \n\n Use /workflows:compound [context] to document immediately without waiting for auto-detection. \n\n## Routes To\n\n`compound-docs` skill\n\n## Applicable Specialized Agents\n\nBased on problem type, these agents can enhance documentation:\n\n### Code Quality & Review\n- **kieran-rails-reviewer**: Reviews code examples for Rails best practices\n- **code-simplicity-reviewer**: Ensures solution code is minimal and clear\n- **pattern-recognition-specialist**: Identifies anti-patterns or repeating issues\n\n### Specific Domain Experts\n- **performance-oracle**: Analyzes performance_issue category solutions\n- **security-sentinel**: Reviews security_issue solutions for vulnerabilities\n- **cora-test-reviewer**: Creates test cases for prevention strategies\n- **data-integrity-guardian**: Reviews database_issue migrations and queries\n\n### Enhancement & Documentation\n- **best-practices-researcher**: Enriches solution with industry best practices\n- **every-style-editor**: Reviews documentation style and clarity\n- **framework-docs-researcher**: Links to Rails/gem documentation references\n\n### When to Invoke\n- **Auto-triggered** (optional): Agents can run post-documentation for enhancement\n- **Manual trigger**: User can invoke agents after /workflows:compound completes for deeper review\n\n## Related Commands\n\n- `/research [topic]` - Deep investigation (searches docs/solutions/ for patterns)\n- `/workflows:plan` - Planning workflow (references documented solutions)" + }, + "workflows:plan": { + "description": "Transform feature descriptions into well-structured project plans following conventions", + "template": "# Create a plan for a new feature or bug fix\n\n## Introduction\n\n**Note: The current year is 2026.** Use this when dating plans and searching for recent documentation.\n\nTransform feature descriptions, bug reports, or improvement ideas into well-structured markdown files issues that follow project conventions and best practices. This command provides flexible detail levels to match your needs.\n\n## Feature Description\n\n #$ARGUMENTS \n\n**If the feature description above is empty, ask the user:** \"What would you like to plan? Please describe the feature, bug fix, or improvement you have in mind.\"\n\nDo not proceed until you have a clear feature description from the user.\n\n### 0. Idea Refinement\n\n**Check for brainstorm output first:**\n\nBefore asking questions, look for recent brainstorm documents in `docs/brainstorms/` that match this feature:\n\n```bash\nls -la docs/brainstorms/*.md 2>/dev/null | head -10\n```\n\n**Relevance criteria:** A brainstorm is relevant if:\n- The topic (from filename or YAML frontmatter) semantically matches the feature description\n- Created within the last 14 days\n- If multiple candidates match, use the most recent one\n\n**If a relevant brainstorm exists:**\n1. Read the brainstorm document\n2. Announce: \"Found brainstorm from [date]: [topic]. Using as context for planning.\"\n3. Extract key decisions, chosen approach, and open questions\n4. **Skip the idea refinement questions below** - the brainstorm already answered WHAT to build\n5. Use brainstorm decisions as input to the research phase\n\n**If multiple brainstorms could match:**\nUse **AskUserQuestion tool** to ask which brainstorm to use, or whether to proceed without one.\n\n**If no brainstorm found (or not relevant), run idea refinement:**\n\nRefine the idea through collaborative dialogue using the **AskUserQuestion tool**:\n\n- Ask questions one at a time to understand the idea fully\n- Prefer multiple choice questions when natural options exist\n- Focus on understanding: purpose, constraints and success criteria\n- Continue until the idea is clear OR user says \"proceed\"\n\n**Gather signals for research decision.** During refinement, note:\n\n- **User's familiarity**: Do they know the codebase patterns? Are they pointing to examples?\n- **User's intent**: Speed vs thoroughness? Exploration vs execution?\n- **Topic risk**: Security, payments, external APIs warrant more caution\n- **Uncertainty level**: Is the approach clear or open-ended?\n\n**Skip option:** If the feature description is already detailed, offer:\n\"Your description is clear. Should I proceed with research, or would you like to refine it further?\"\n\n## Main Tasks\n\n### 1. Local Research (Always Runs - Parallel)\n\n\nFirst, I need to understand the project's conventions, existing patterns, and any documented learnings. This is fast and local - it informs whether external research is needed.\n\n\nRun these agents **in parallel** to gather local context:\n\n- Task repo-research-analyst(feature_description)\n- Task learnings-researcher(feature_description)\n\n**What to look for:**\n- **Repo research:** existing patterns, CLAUDE.md guidance, technology familiarity, pattern consistency\n- **Learnings:** documented solutions in `docs/solutions/` that might apply (gotchas, patterns, lessons learned)\n\nThese findings inform the next step.\n\n### 1.5. Research Decision\n\nBased on signals from Step 0 and findings from Step 1, decide on external research.\n\n**High-risk topics β†’ always research.** Security, payments, external APIs, data privacy. The cost of missing something is too high. This takes precedence over speed signals.\n\n**Strong local context β†’ skip external research.** Codebase has good patterns, CLAUDE.md has guidance, user knows what they want. External research adds little value.\n\n**Uncertainty or unfamiliar territory β†’ research.** User is exploring, codebase has no examples, new technology. External perspective is valuable.\n\n**Announce the decision and proceed.** Brief explanation, then continue. User can redirect if needed.\n\nExamples:\n- \"Your codebase has solid patterns for this. Proceeding without external research.\"\n- \"This involves payment processing, so I'll research current best practices first.\"\n\n### 1.5b. External Research (Conditional)\n\n**Only run if Step 1.5 indicates external research is valuable.**\n\nRun these agents in parallel:\n\n- Task best-practices-researcher(feature_description)\n- Task framework-docs-researcher(feature_description)\n\n### 1.6. Consolidate Research\n\nAfter all research steps complete, consolidate findings:\n\n- Document relevant file paths from repo research (e.g., `app/services/example_service.rb:42`)\n- **Include relevant institutional learnings** from `docs/solutions/` (key insights, gotchas to avoid)\n- Note external documentation URLs and best practices (if external research was done)\n- List related issues or PRs discovered\n- Capture CLAUDE.md conventions\n\n**Optional validation:** Briefly summarize findings and ask if anything looks off or missing before proceeding to planning.\n\n### 2. Issue Planning & Structure\n\n\nThink like a product manager - what would make this issue clear and actionable? Consider multiple perspectives\n\n\n**Title & Categorization:**\n\n- [ ] Draft clear, searchable issue title using conventional format (e.g., `feat: Add user authentication`, `fix: Cart total calculation`)\n- [ ] Determine issue type: enhancement, bug, refactor\n- [ ] Convert title to filename: add today's date prefix, strip prefix colon, kebab-case, add `-plan` suffix\n - Example: `feat: Add User Authentication` β†’ `2026-01-21-feat-add-user-authentication-plan.md`\n - Keep it descriptive (3-5 words after prefix) so plans are findable by context\n\n**Stakeholder Analysis:**\n\n- [ ] Identify who will be affected by this issue (end users, developers, operations)\n- [ ] Consider implementation complexity and required expertise\n\n**Content Planning:**\n\n- [ ] Choose appropriate detail level based on issue complexity and audience\n- [ ] List all necessary sections for the chosen template\n- [ ] Gather supporting materials (error logs, screenshots, design mockups)\n- [ ] Prepare code examples or reproduction steps if applicable, name the mock filenames in the lists\n\n### 3. SpecFlow Analysis\n\nAfter planning the issue structure, run SpecFlow Analyzer to validate and refine the feature specification:\n\n- Task spec-flow-analyzer(feature_description, research_findings)\n\n**SpecFlow Analyzer Output:**\n\n- [ ] Review SpecFlow analysis results\n- [ ] Incorporate any identified gaps or edge cases into the issue\n- [ ] Update acceptance criteria based on SpecFlow findings\n\n### 4. Choose Implementation Detail Level\n\nSelect how comprehensive you want the issue to be, simpler is mostly better.\n\n#### πŸ“„ MINIMAL (Quick Issue)\n\n**Best for:** Simple bugs, small improvements, clear features\n\n**Includes:**\n\n- Problem statement or feature description\n- Basic acceptance criteria\n- Essential context only\n\n**Structure:**\n\n````markdown\n---\ntitle: [Issue Title]\ntype: [feat|fix|refactor]\ndate: YYYY-MM-DD\n---\n\n# [Issue Title]\n\n[Brief problem/feature description]\n\n## Acceptance Criteria\n\n- [ ] Core requirement 1\n- [ ] Core requirement 2\n\n## Context\n\n[Any critical information]\n\n## MVP\n\n### test.rb\n\n```ruby\nclass Test\n def initialize\n @name = \"test\"\n end\nend\n```\n\n## References\n\n- Related issue: #[issue_number]\n- Documentation: [relevant_docs_url]\n````\n\n#### πŸ“‹ MORE (Standard Issue)\n\n**Best for:** Most features, complex bugs, team collaboration\n\n**Includes everything from MINIMAL plus:**\n\n- Detailed background and motivation\n- Technical considerations\n- Success metrics\n- Dependencies and risks\n- Basic implementation suggestions\n\n**Structure:**\n\n```markdown\n---\ntitle: [Issue Title]\ntype: [feat|fix|refactor]\ndate: YYYY-MM-DD\n---\n\n# [Issue Title]\n\n## Overview\n\n[Comprehensive description]\n\n## Problem Statement / Motivation\n\n[Why this matters]\n\n## Proposed Solution\n\n[High-level approach]\n\n## Technical Considerations\n\n- Architecture impacts\n- Performance implications\n- Security considerations\n\n## Acceptance Criteria\n\n- [ ] Detailed requirement 1\n- [ ] Detailed requirement 2\n- [ ] Testing requirements\n\n## Success Metrics\n\n[How we measure success]\n\n## Dependencies & Risks\n\n[What could block or complicate this]\n\n## References & Research\n\n- Similar implementations: [file_path:line_number]\n- Best practices: [documentation_url]\n- Related PRs: #[pr_number]\n```\n\n#### πŸ“š A LOT (Comprehensive Issue)\n\n**Best for:** Major features, architectural changes, complex integrations\n\n**Includes everything from MORE plus:**\n\n- Detailed implementation plan with phases\n- Alternative approaches considered\n- Extensive technical specifications\n- Resource requirements and timeline\n- Future considerations and extensibility\n- Risk mitigation strategies\n- Documentation requirements\n\n**Structure:**\n\n```markdown\n---\ntitle: [Issue Title]\ntype: [feat|fix|refactor]\ndate: YYYY-MM-DD\n---\n\n# [Issue Title]\n\n## Overview\n\n[Executive summary]\n\n## Problem Statement\n\n[Detailed problem analysis]\n\n## Proposed Solution\n\n[Comprehensive solution design]\n\n## Technical Approach\n\n### Architecture\n\n[Detailed technical design]\n\n### Implementation Phases\n\n#### Phase 1: [Foundation]\n\n- Tasks and deliverables\n- Success criteria\n- Estimated effort\n\n#### Phase 2: [Core Implementation]\n\n- Tasks and deliverables\n- Success criteria\n- Estimated effort\n\n#### Phase 3: [Polish & Optimization]\n\n- Tasks and deliverables\n- Success criteria\n- Estimated effort\n\n## Alternative Approaches Considered\n\n[Other solutions evaluated and why rejected]\n\n## Acceptance Criteria\n\n### Functional Requirements\n\n- [ ] Detailed functional criteria\n\n### Non-Functional Requirements\n\n- [ ] Performance targets\n- [ ] Security requirements\n- [ ] Accessibility standards\n\n### Quality Gates\n\n- [ ] Test coverage requirements\n- [ ] Documentation completeness\n- [ ] Code review approval\n\n## Success Metrics\n\n[Detailed KPIs and measurement methods]\n\n## Dependencies & Prerequisites\n\n[Detailed dependency analysis]\n\n## Risk Analysis & Mitigation\n\n[Comprehensive risk assessment]\n\n## Resource Requirements\n\n[Team, time, infrastructure needs]\n\n## Future Considerations\n\n[Extensibility and long-term vision]\n\n## Documentation Plan\n\n[What docs need updating]\n\n## References & Research\n\n### Internal References\n\n- Architecture decisions: [file_path:line_number]\n- Similar features: [file_path:line_number]\n- Configuration: [file_path:line_number]\n\n### External References\n\n- Framework documentation: [url]\n- Best practices guide: [url]\n- Industry standards: [url]\n\n### Related Work\n\n- Previous PRs: #[pr_numbers]\n- Related issues: #[issue_numbers]\n- Design documents: [links]\n```\n\n### 5. Issue Creation & Formatting\n\n\nApply best practices for clarity and actionability, making the issue easy to scan and understand\n\n\n**Content Formatting:**\n\n- [ ] Use clear, descriptive headings with proper hierarchy (##, ###)\n- [ ] Include code examples in triple backticks with language syntax highlighting\n- [ ] Add screenshots/mockups if UI-related (drag & drop or use image hosting)\n- [ ] Use task lists (- [ ]) for trackable items that can be checked off\n- [ ] Add collapsible sections for lengthy logs or optional details using `
` tags\n- [ ] Apply appropriate emoji for visual scanning (πŸ› bug, ✨ feature, πŸ“š docs, ♻️ refactor)\n\n**Cross-Referencing:**\n\n- [ ] Link to related issues/PRs using #number format\n- [ ] Reference specific commits with SHA hashes when relevant\n- [ ] Link to code using GitHub's permalink feature (press 'y' for permanent link)\n- [ ] Mention relevant team members with @username if needed\n- [ ] Add links to external resources with descriptive text\n\n**Code & Examples:**\n\n````markdown\n# Good example with syntax highlighting and line references\n\n\n```ruby\n# app/services/user_service.rb:42\ndef process_user(user)\n\n# Implementation here\n\nend\n```\n\n# Collapsible error logs\n\n
\nFull error stacktrace\n\n`Error details here...`\n\n
\n````\n\n**AI-Era Considerations:**\n\n- [ ] Account for accelerated development with AI pair programming\n- [ ] Include prompts or instructions that worked well during research\n- [ ] Note which AI tools were used for initial exploration (Claude, Copilot, etc.)\n- [ ] Emphasize comprehensive testing given rapid implementation\n- [ ] Document any AI-generated code that needs human review\n\n### 6. Final Review & Submission\n\n**Pre-submission Checklist:**\n\n- [ ] Title is searchable and descriptive\n- [ ] Labels accurately categorize the issue\n- [ ] All template sections are complete\n- [ ] Links and references are working\n- [ ] Acceptance criteria are measurable\n- [ ] Add names of files in pseudo code examples and todo lists\n- [ ] Add an ERD mermaid diagram if applicable for new model changes\n\n## Output Format\n\n**Filename:** Use the date and kebab-case filename from Step 2 Title & Categorization.\n\n```\ndocs/plans/YYYY-MM-DD---plan.md\n```\n\nExamples:\n- βœ… `docs/plans/2026-01-15-feat-user-authentication-flow-plan.md`\n- βœ… `docs/plans/2026-02-03-fix-checkout-race-condition-plan.md`\n- βœ… `docs/plans/2026-03-10-refactor-api-client-extraction-plan.md`\n- ❌ `docs/plans/2026-01-15-feat-thing-plan.md` (not descriptive - what \"thing\"?)\n- ❌ `docs/plans/2026-01-15-feat-new-feature-plan.md` (too vague - what feature?)\n- ❌ `docs/plans/2026-01-15-feat: user auth-plan.md` (invalid characters - colon and space)\n- ❌ `docs/plans/feat-user-auth-plan.md` (missing date prefix)\n\n## Post-Generation Options\n\nAfter writing the plan file, use the **AskUserQuestion tool** to present these options:\n\n**Question:** \"Plan ready at `docs/plans/YYYY-MM-DD---plan.md`. What would you like to do next?\"\n\n**Options:**\n1. **Open plan in editor** - Open the plan file for review\n2. **Run `/deepen-plan`** - Enhance each section with parallel research agents (best practices, performance, UI)\n3. **Run `/plan_review`** - Get feedback from reviewers (DHH, Kieran, Simplicity)\n4. **Start `/workflows:work`** - Begin implementing this plan locally\n5. **Start `/workflows:work` on remote** - Begin implementing in Claude Code on the web (use `&` to run in background)\n6. **Create Issue** - Create issue in project tracker (GitHub/Linear)\n7. **Simplify** - Reduce detail level\n\nBased on selection:\n- **Open plan in editor** β†’ Run `open docs/plans/.md` to open the file in the user's default editor\n- **`/deepen-plan`** β†’ Call the /deepen-plan command with the plan file path to enhance with research\n- **`/plan_review`** β†’ Call the /plan_review command with the plan file path\n- **`/workflows:work`** β†’ Call the /workflows:work command with the plan file path\n- **`/workflows:work` on remote** β†’ Run `/workflows:work docs/plans/.md &` to start work in background for Claude Code web\n- **Create Issue** β†’ See \"Issue Creation\" section below\n- **Simplify** β†’ Ask \"What should I simplify?\" then regenerate simpler version\n- **Other** (automatically provided) β†’ Accept free text for rework or specific changes\n\n**Note:** If running `/workflows:plan` with ultrathink enabled, automatically run `/deepen-plan` after plan creation for maximum depth and grounding.\n\nLoop back to options after Simplify or Other changes until user selects `/workflows:work` or `/plan_review`.\n\n## Issue Creation\n\nWhen user selects \"Create Issue\", detect their project tracker from CLAUDE.md:\n\n1. **Check for tracker preference** in user's CLAUDE.md (global or project):\n - Look for `project_tracker: github` or `project_tracker: linear`\n - Or look for mentions of \"GitHub Issues\" or \"Linear\" in their workflow section\n\n2. **If GitHub:**\n\n Use the title and type from Step 2 (already in context - no need to re-read the file):\n\n ```bash\n gh issue create --title \": \" --body-file <plan_path>\n ```\n\n3. **If Linear:**\n\n ```bash\n linear issue create --title \"<title>\" --description \"$(cat <plan_path>)\"\n ```\n\n4. **If no tracker configured:**\n Ask user: \"Which project tracker do you use? (GitHub/Linear/Other)\"\n - Suggest adding `project_tracker: github` or `project_tracker: linear` to their CLAUDE.md\n\n5. **After creation:**\n - Display the issue URL\n - Ask if they want to proceed to `/workflows:work` or `/plan_review`\n\nNEVER CODE! Just research and write the plan." + }, + "triage": { + "description": "Triage and categorize findings for the CLI todo system", + "template": "- First set the /model to Haiku\n- Then read all pending todos in the todos/ directory\n\nPresent all findings, decisions, or issues here one by one for triage. The goal is to go through each item and decide whether to add it to the CLI todo system.\n\n**IMPORTANT: DO NOT CODE ANYTHING DURING TRIAGE!**\n\nThis command is for:\n\n- Triaging code review findings\n- Processing security audit results\n- Reviewing performance analysis\n- Handling any other categorized findings that need tracking\n\n## Workflow\n\n### Step 1: Present Each Finding\n\nFor each finding, present in this format:\n\n```\n---\nIssue #X: [Brief Title]\n\nSeverity: πŸ”΄ P1 (CRITICAL) / 🟑 P2 (IMPORTANT) / πŸ”΅ P3 (NICE-TO-HAVE)\n\nCategory: [Security/Performance/Architecture/Bug/Feature/etc.]\n\nDescription:\n[Detailed explanation of the issue or improvement]\n\nLocation: [file_path:line_number]\n\nProblem Scenario:\n[Step by step what's wrong or could happen]\n\nProposed Solution:\n[How to fix it]\n\nEstimated Effort: [Small (< 2 hours) / Medium (2-8 hours) / Large (> 8 hours)]\n\n---\nDo you want to add this to the todo list?\n1. yes - create todo file\n2. next - skip this item\n3. custom - modify before creating\n```\n\n### Step 2: Handle User Decision\n\n**When user says \"yes\":**\n\n1. **Update existing todo file** (if it exists) or **Create new filename:**\n\n If todo already exists (from code review):\n\n - Rename file from `{id}-pending-{priority}-{desc}.md` β†’ `{id}-ready-{priority}-{desc}.md`\n - Update YAML frontmatter: `status: pending` β†’ `status: ready`\n - Keep issue_id, priority, and description unchanged\n\n If creating new todo:\n\n ```\n {next_id}-ready-{priority}-{brief-description}.md\n ```\n\n Priority mapping:\n\n - πŸ”΄ P1 (CRITICAL) β†’ `p1`\n - 🟑 P2 (IMPORTANT) β†’ `p2`\n - πŸ”΅ P3 (NICE-TO-HAVE) β†’ `p3`\n\n Example: `042-ready-p1-transaction-boundaries.md`\n\n2. **Update YAML frontmatter:**\n\n ```yaml\n ---\n status: ready # IMPORTANT: Change from \"pending\" to \"ready\"\n priority: p1 # or p2, p3 based on severity\n issue_id: \"042\"\n tags: [category, relevant-tags]\n dependencies: []\n ---\n ```\n\n3. **Populate or update the file:**\n\n ```yaml\n # [Issue Title]\n\n ## Problem Statement\n [Description from finding]\n\n ## Findings\n - [Key discoveries]\n - Location: [file_path:line_number]\n - [Scenario details]\n\n ## Proposed Solutions\n\n ### Option 1: [Primary solution]\n - **Pros**: [Benefits]\n - **Cons**: [Drawbacks if any]\n - **Effort**: [Small/Medium/Large]\n - **Risk**: [Low/Medium/High]\n\n ## Recommended Action\n [Filled during triage - specific action plan]\n\n ## Technical Details\n - **Affected Files**: [List files]\n - **Related Components**: [Components affected]\n - **Database Changes**: [Yes/No - describe if yes]\n\n ## Resources\n - Original finding: [Source of this issue]\n - Related issues: [If any]\n\n ## Acceptance Criteria\n - [ ] [Specific success criteria]\n - [ ] Tests pass\n - [ ] Code reviewed\n\n ## Work Log\n\n ### {date} - Approved for Work\n **By:** Claude Triage System\n **Actions:**\n - Issue approved during triage session\n - Status changed from pending β†’ ready\n - Ready to be picked up and worked on\n\n **Learnings:**\n - [Context and insights]\n\n ## Notes\n Source: Triage session on {date}\n ```\n\n4. **Confirm approval:** \"βœ… Approved: `{new_filename}` (Issue #{issue_id}) - Status: **ready** β†’ Ready to work on\"\n\n**When user says \"next\":**\n\n- **Delete the todo file** - Remove it from todos/ directory since it's not relevant\n- Skip to the next item\n- Track skipped items for summary\n\n**When user says \"custom\":**\n\n- Ask what to modify (priority, description, details)\n- Update the information\n- Present revised version\n- Ask again: yes/next/custom\n\n### Step 3: Continue Until All Processed\n\n- Process all items one by one\n- Track using TodoWrite for visibility\n- Don't wait for approval between items - keep moving\n\n### Step 4: Final Summary\n\nAfter all items processed:\n\n````markdown\n## Triage Complete\n\n**Total Items:** [X] **Todos Approved (ready):** [Y] **Skipped:** [Z]\n\n### Approved Todos (Ready for Work):\n\n- `042-ready-p1-transaction-boundaries.md` - Transaction boundary issue\n- `043-ready-p2-cache-optimization.md` - Cache performance improvement ...\n\n### Skipped Items (Deleted):\n\n- Item #5: [reason] - Removed from todos/\n- Item #12: [reason] - Removed from todos/\n\n### Summary of Changes Made:\n\nDuring triage, the following status updates occurred:\n\n- **Pending β†’ Ready:** Filenames and frontmatter updated to reflect approved status\n- **Deleted:** Todo files for skipped findings removed from todos/ directory\n- Each approved file now has `status: ready` in YAML frontmatter\n\n### Next Steps:\n\n1. View approved todos ready for work:\n ```bash\n ls todos/*-ready-*.md\n ```\n````\n\n2. Start work on approved items:\n\n ```bash\n /resolve_todo_parallel # Work on multiple approved items efficiently\n ```\n\n3. Or pick individual items to work on\n\n4. As you work, update todo status:\n - Ready β†’ In Progress (in your local context as you work)\n - In Progress β†’ Complete (rename file: ready β†’ complete, update frontmatter)\n\n```\n\n## Example Response Format\n\n```\n\n---\n\nIssue #5: Missing Transaction Boundaries for Multi-Step Operations\n\nSeverity: πŸ”΄ P1 (CRITICAL)\n\nCategory: Data Integrity / Security\n\nDescription: The google_oauth2_connected callback in GoogleOauthCallbacks concern performs multiple database operations without transaction protection. If any step fails midway, the database is left in an inconsistent state.\n\nLocation: app/controllers/concerns/google_oauth_callbacks.rb:13-50\n\nProblem Scenario:\n\n1. User.update succeeds (email changed)\n2. Account.save! fails (validation error)\n3. Result: User has changed email but no associated Account\n4. Next login attempt fails completely\n\nOperations Without Transaction:\n\n- User confirmation (line 13)\n- Waitlist removal (line 14)\n- User profile update (line 21-23)\n- Account creation (line 28-37)\n- Avatar attachment (line 39-45)\n- Journey creation (line 47)\n\nProposed Solution: Wrap all operations in ApplicationRecord.transaction do ... end block\n\nEstimated Effort: Small (30 minutes)\n\n---\n\nDo you want to add this to the todo list?\n\n1. yes - create todo file\n2. next - skip this item\n3. custom - modify before creating\n\n```\n\n## Important Implementation Details\n\n### Status Transitions During Triage\n\n**When \"yes\" is selected:**\n1. Rename file: `{id}-pending-{priority}-{desc}.md` β†’ `{id}-ready-{priority}-{desc}.md`\n2. Update YAML frontmatter: `status: pending` β†’ `status: ready`\n3. Update Work Log with triage approval entry\n4. Confirm: \"βœ… Approved: `{filename}` (Issue #{issue_id}) - Status: **ready**\"\n\n**When \"next\" is selected:**\n1. Delete the todo file from todos/ directory\n2. Skip to next item\n3. No file remains in the system\n\n### Progress Tracking\n\nEvery time you present a todo as a header, include:\n- **Progress:** X/Y completed (e.g., \"3/10 completed\")\n- **Estimated time remaining:** Based on how quickly you're progressing\n- **Pacing:** Monitor time per finding and adjust estimate accordingly\n\nExample:\n```\n\nProgress: 3/10 completed | Estimated time: ~2 minutes remaining\n\n```\n\n### Do Not Code During Triage\n\n- βœ… Present findings\n- βœ… Make yes/next/custom decisions\n- βœ… Update todo files (rename, frontmatter, work log)\n- ❌ Do NOT implement fixes or write code\n- ❌ Do NOT add detailed implementation details\n- ❌ That's for /resolve_todo_parallel phase\n```\n\nWhen done give these options\n\n```markdown\nWhat would you like to do next?\n\n1. run /resolve_todo_parallel to resolve the todos\n2. commit the todos\n3. nothing, go chill\n```" + }, + "changelog": { + "description": "Create engaging changelogs for recent merges to main branch", + "template": "You are a witty and enthusiastic product marketer tasked with creating a fun, engaging change log for an internal development team. Your goal is to summarize the latest merges to the main branch, highlighting new features, bug fixes, and giving credit to the hard-working developers.\n\n## Time Period\n\n- For daily changelogs: Look at PRs merged in the last 24 hours\n- For weekly summaries: Look at PRs merged in the last 7 days\n- Always specify the time period in the title (e.g., \"Daily\" vs \"Weekly\")\n- Default: Get the latest changes from the last day from the main branch of the repository\n\n## PR Analysis\n\nAnalyze the provided GitHub changes and related issues. Look for:\n\n1. New features that have been added\n2. Bug fixes that have been implemented\n3. Any other significant changes or improvements\n4. References to specific issues and their details\n5. Names of contributors who made the changes\n6. Use gh cli to lookup the PRs as well and the description of the PRs\n7. Check PR labels to identify feature type (feature, bug, chore, etc.)\n8. Look for breaking changes and highlight them prominently\n9. Include PR numbers for traceability\n10. Check if PRs are linked to issues and include issue context\n\n## Content Priorities\n\n1. Breaking changes (if any) - MUST be at the top\n2. User-facing features\n3. Critical bug fixes\n4. Performance improvements\n5. Developer experience improvements\n6. Documentation updates\n\n## Formatting Guidelines\n\nNow, create a change log summary with the following guidelines:\n\n1. Keep it concise and to the point\n2. Highlight the most important changes first\n3. Group similar changes together (e.g., all new features, all bug fixes)\n4. Include issue references where applicable\n5. Mention the names of contributors, giving them credit for their work\n6. Add a touch of humor or playfulness to make it engaging\n7. Use emojis sparingly to add visual interest\n8. Keep total message under 2000 characters for Discord\n9. Use consistent emoji for each section\n10. Format code/technical terms in backticks\n11. Include PR numbers in parentheses (e.g., \"Fixed login bug (#123)\")\n\n## Deployment Notes\n\nWhen relevant, include:\n\n- Database migrations required\n- Environment variable updates needed\n- Manual intervention steps post-deploy\n- Dependencies that need updating\n\nYour final output should be formatted as follows:\n\n<change_log>\n\n# πŸš€ [Daily/Weekly] Change Log: [Current Date]\n\n## 🚨 Breaking Changes (if any)\n\n[List any breaking changes that require immediate attention]\n\n## 🌟 New Features\n\n[List new features here with PR numbers]\n\n## πŸ› Bug Fixes\n\n[List bug fixes here with PR numbers]\n\n## πŸ› οΈ Other Improvements\n\n[List other significant changes or improvements]\n\n## πŸ™Œ Shoutouts\n\n[Mention contributors and their contributions]\n\n## πŸŽ‰ Fun Fact of the Day\n\n[Include a brief, work-related fun fact or joke]\n\n</change_log>\n\n## Style Guide Review\n\nNow review the changelog using the EVERY_WRITE_STYLE.md file and go one by one to make sure you are following the style guide. Use multiple agents, run in parallel to make it faster.\n\nRemember, your final output should only include the content within the <change_log> tags. Do not include any of your thought process or the original data in the output.\n\n## Discord Posting (Optional)\n\nYou can post changelogs to Discord by adding your own webhook URL:\n\n```\n# Set your Discord webhook URL\nDISCORD_WEBHOOK_URL=\"https://discord.com/api/webhooks/YOUR_WEBHOOK_ID/YOUR_WEBHOOK_TOKEN\"\n\n# Post using curl\ncurl -H \"Content-Type: application/json\" \\\n -d \"{\\\"content\\\": \\\"{{CHANGELOG}}\\\"}\" \\\n $DISCORD_WEBHOOK_URL\n```\n\nTo get a webhook URL, go to your Discord server β†’ Server Settings β†’ Integrations β†’ Webhooks β†’ New Webhook.\n\n## Error Handling\n\n- If no changes in the time period, post a \"quiet day\" message: \"🌀️ Quiet day! No new changes merged.\"\n- If unable to fetch PR details, list the PR numbers for manual review\n- Always validate message length before posting to Discord (max 2000 chars)\n\n## Schedule Recommendations\n\n- Run daily at 6 AM NY time for previous day's changes\n- Run weekly summary on Mondays for the previous week\n- Special runs after major releases or deployments\n\n## Audience Considerations\n\nAdjust the tone and detail level based on the channel:\n\n- **Dev team channels**: Include technical details, performance metrics, code snippets\n- **Product team channels**: Focus on user-facing changes and business impact\n- **Leadership channels**: Highlight progress on key initiatives and blockers" + }, + "slfg": { + "description": "Full autonomous engineering workflow using swarm mode for parallel execution", + "template": "Swarm-enabled LFG. Run these steps in order, parallelizing where indicated.\n\n## Sequential Phase\n\n1. `/ralph-wiggum:ralph-loop \"finish all slash commands\" --completion-promise \"DONE\"`\n2. `/workflows:plan $ARGUMENTS`\n3. `/compound-engineering:deepen-plan`\n4. `/workflows:work` β€” **Use swarm mode**: Make a Task list and launch an army of agent swarm subagents to build the plan\n\n## Parallel Phase\n\nAfter work completes, launch steps 5 and 6 as **parallel swarm agents** (both only need code to be written):\n\n5. `/workflows:review` β€” spawn as background Task agent\n6. `/compound-engineering:test-browser` β€” spawn as background Task agent\n\nWait for both to complete before continuing.\n\n## Finalize Phase\n\n7. `/compound-engineering:resolve_todo_parallel` β€” resolve any findings from the review\n8. `/compound-engineering:feature-video` β€” record the final walkthrough and add to PR\n9. Output `<promise>DONE</promise>` when video is in PR\n\nStart with step 1 now." + }, + "heal-skill": { + "description": "Fix incorrect SKILL.md files when a skill has wrong instructions or outdated API references", + "template": "<objective>\nUpdate a skill's SKILL.md and related files based on corrections discovered during execution.\n\nAnalyze the conversation to detect which skill is running, reflect on what went wrong, propose specific fixes, get user approval, then apply changes with optional commit.\n</objective>\n\n<context>\nSkill detection: !`ls -1 ./skills/*/SKILL.md | head -5`\n</context>\n\n<quick_start>\n<workflow>\n1. **Detect skill** from conversation context (invocation messages, recent SKILL.md references)\n2. **Reflect** on what went wrong and how you discovered the fix\n3. **Present** proposed changes with before/after diffs\n4. **Get approval** before making any edits\n5. **Apply** changes and optionally commit\n</workflow>\n</quick_start>\n\n<process>\n<step_1 name=\"detect_skill\">\nIdentify the skill from conversation context:\n\n- Look for skill invocation messages\n- Check which SKILL.md was recently referenced\n- Examine current task context\n\nSet: `SKILL_NAME=[skill-name]` and `SKILL_DIR=./skills/$SKILL_NAME`\n\nIf unclear, ask the user.\n</step_1>\n\n<step_2 name=\"reflection_and_analysis\">\nFocus on $ARGUMENTS if provided, otherwise analyze broader context.\n\nDetermine:\n- **What was wrong**: Quote specific sections from SKILL.md that are incorrect\n- **Discovery method**: Context7, error messages, trial and error, documentation lookup\n- **Root cause**: Outdated API, incorrect parameters, wrong endpoint, missing context\n- **Scope of impact**: Single section or multiple? Related files affected?\n- **Proposed fix**: Which files, which sections, before/after for each\n</step_2>\n\n<step_3 name=\"scan_affected_files\">\n```bash\nls -la $SKILL_DIR/\nls -la $SKILL_DIR/references/ 2>/dev/null\nls -la $SKILL_DIR/scripts/ 2>/dev/null\n```\n</step_3>\n\n<step_4 name=\"present_proposed_changes\">\nPresent changes in this format:\n\n```\n**Skill being healed:** [skill-name]\n**Issue discovered:** [1-2 sentence summary]\n**Root cause:** [brief explanation]\n\n**Files to be modified:**\n- [ ] SKILL.md\n- [ ] references/[file].md\n- [ ] scripts/[file].py\n\n**Proposed changes:**\n\n### Change 1: SKILL.md - [Section name]\n**Location:** Line [X] in SKILL.md\n\n**Current (incorrect):**\n```\n[exact text from current file]\n```\n\n**Corrected:**\n```\n[new text]\n```\n\n**Reason:** [why this fixes the issue]\n\n[repeat for each change across all files]\n\n**Impact assessment:**\n- Affects: [authentication/API endpoints/parameters/examples/etc.]\n\n**Verification:**\nThese changes will prevent: [specific error that prompted this]\n```\n</step_4>\n\n<step_5 name=\"request_approval\">\n```\nShould I apply these changes?\n\n1. Yes, apply and commit all changes\n2. Apply but don't commit (let me review first)\n3. Revise the changes (I'll provide feedback)\n4. Cancel (don't make changes)\n\nChoose (1-4):\n```\n\n**Wait for user response. Do not proceed without approval.**\n</step_5>\n\n<step_6 name=\"apply_changes\">\nOnly after approval (option 1 or 2):\n\n1. Use Edit tool for each correction across all files\n2. Read back modified sections to verify\n3. If option 1, commit with structured message showing what was healed\n4. Confirm completion with file list\n</step_6>\n</process>\n\n<success_criteria>\n- Skill correctly detected from conversation context\n- All incorrect sections identified with before/after\n- User approved changes before application\n- All edits applied across SKILL.md and related files\n- Changes verified by reading back\n- Commit created if user chose option 1\n- Completion confirmed with file list\n</success_criteria>\n\n<verification>\nBefore completing:\n\n- Read back each modified section to confirm changes applied\n- Ensure cross-file consistency (SKILL.md examples match references/)\n- Verify git commit created if option 1 was selected\n- Check no unintended files were modified\n</verification>" + }, + "agent-native-audit": { + "description": "Run comprehensive agent-native architecture review with scored principles", + "template": "# Agent-Native Architecture Audit\n\nConduct a comprehensive review of the codebase against agent-native architecture principles, launching parallel sub-agents for each principle and producing a scored report.\n\n## Core Principles to Audit\n\n1. **Action Parity** - \"Whatever the user can do, the agent can do\"\n2. **Tools as Primitives** - \"Tools provide capability, not behavior\"\n3. **Context Injection** - \"System prompt includes dynamic context about app state\"\n4. **Shared Workspace** - \"Agent and user work in the same data space\"\n5. **CRUD Completeness** - \"Every entity has full CRUD (Create, Read, Update, Delete)\"\n6. **UI Integration** - \"Agent actions immediately reflected in UI\"\n7. **Capability Discovery** - \"Users can discover what the agent can do\"\n8. **Prompt-Native Features** - \"Features are prompts defining outcomes, not code\"\n\n## Workflow\n\n### Step 1: Load the Agent-Native Skill\n\nFirst, invoke the agent-native-architecture skill to understand all principles:\n\n```\n/compound-engineering:agent-native-architecture\n```\n\nSelect option 7 (action parity) to load the full reference material.\n\n### Step 2: Launch Parallel Sub-Agents\n\nLaunch 8 parallel sub-agents using the Task tool with `subagent_type: Explore`, one for each principle. Each agent should:\n\n1. Enumerate ALL instances in the codebase (user actions, tools, contexts, data stores, etc.)\n2. Check compliance against the principle\n3. Provide a SPECIFIC SCORE like \"X out of Y (percentage%)\"\n4. List specific gaps and recommendations\n\n<sub-agents>\n\n**Agent 1: Action Parity**\n```\nAudit for ACTION PARITY - \"Whatever the user can do, the agent can do.\"\n\nTasks:\n1. Enumerate ALL user actions in frontend (API calls, button clicks, form submissions)\n - Search for API service files, fetch calls, form handlers\n - Check routes and components for user interactions\n2. Check which have corresponding agent tools\n - Search for agent tool definitions\n - Map user actions to agent capabilities\n3. Score: \"Agent can do X out of Y user actions\"\n\nFormat:\n## Action Parity Audit\n### User Actions Found\n| Action | Location | Agent Tool | Status |\n### Score: X/Y (percentage%)\n### Missing Agent Tools\n### Recommendations\n```\n\n**Agent 2: Tools as Primitives**\n```\nAudit for TOOLS AS PRIMITIVES - \"Tools provide capability, not behavior.\"\n\nTasks:\n1. Find and read ALL agent tool files\n2. Classify each as:\n - PRIMITIVE (good): read, write, store, list - enables capability without business logic\n - WORKFLOW (bad): encodes business logic, makes decisions, orchestrates steps\n3. Score: \"X out of Y tools are proper primitives\"\n\nFormat:\n## Tools as Primitives Audit\n### Tool Analysis\n| Tool | File | Type | Reasoning |\n### Score: X/Y (percentage%)\n### Problematic Tools (workflows that should be primitives)\n### Recommendations\n```\n\n**Agent 3: Context Injection**\n```\nAudit for CONTEXT INJECTION - \"System prompt includes dynamic context about app state\"\n\nTasks:\n1. Find context injection code (search for \"context\", \"system prompt\", \"inject\")\n2. Read agent prompts and system messages\n3. Enumerate what IS injected vs what SHOULD be:\n - Available resources (files, drafts, documents)\n - User preferences/settings\n - Recent activity\n - Available capabilities listed\n - Session history\n - Workspace state\n\nFormat:\n## Context Injection Audit\n### Context Types Analysis\n| Context Type | Injected? | Location | Notes |\n### Score: X/Y (percentage%)\n### Missing Context\n### Recommendations\n```\n\n**Agent 4: Shared Workspace**\n```\nAudit for SHARED WORKSPACE - \"Agent and user work in the same data space\"\n\nTasks:\n1. Identify all data stores/tables/models\n2. Check if agents read/write to SAME tables or separate ones\n3. Look for sandbox isolation anti-pattern (agent has separate data space)\n\nFormat:\n## Shared Workspace Audit\n### Data Store Analysis\n| Data Store | User Access | Agent Access | Shared? |\n### Score: X/Y (percentage%)\n### Isolated Data (anti-pattern)\n### Recommendations\n```\n\n**Agent 5: CRUD Completeness**\n```\nAudit for CRUD COMPLETENESS - \"Every entity has full CRUD\"\n\nTasks:\n1. Identify all entities/models in the codebase\n2. For each entity, check if agent tools exist for:\n - Create\n - Read\n - Update\n - Delete\n3. Score per entity and overall\n\nFormat:\n## CRUD Completeness Audit\n### Entity CRUD Analysis\n| Entity | Create | Read | Update | Delete | Score |\n### Overall Score: X/Y entities with full CRUD (percentage%)\n### Incomplete Entities (list missing operations)\n### Recommendations\n```\n\n**Agent 6: UI Integration**\n```\nAudit for UI INTEGRATION - \"Agent actions immediately reflected in UI\"\n\nTasks:\n1. Check how agent writes/changes propagate to frontend\n2. Look for:\n - Streaming updates (SSE, WebSocket)\n - Polling mechanisms\n - Shared state/services\n - Event buses\n - File watching\n3. Identify \"silent actions\" anti-pattern (agent changes state but UI doesn't update)\n\nFormat:\n## UI Integration Audit\n### Agent Action β†’ UI Update Analysis\n| Agent Action | UI Mechanism | Immediate? | Notes |\n### Score: X/Y (percentage%)\n### Silent Actions (anti-pattern)\n### Recommendations\n```\n\n**Agent 7: Capability Discovery**\n```\nAudit for CAPABILITY DISCOVERY - \"Users can discover what the agent can do\"\n\nTasks:\n1. Check for these 7 discovery mechanisms:\n - Onboarding flow showing agent capabilities\n - Help documentation\n - Capability hints in UI\n - Agent self-describes in responses\n - Suggested prompts/actions\n - Empty state guidance\n - Slash commands (/help, /tools)\n2. Score against 7 mechanisms\n\nFormat:\n## Capability Discovery Audit\n### Discovery Mechanism Analysis\n| Mechanism | Exists? | Location | Quality |\n### Score: X/7 (percentage%)\n### Missing Discovery\n### Recommendations\n```\n\n**Agent 8: Prompt-Native Features**\n```\nAudit for PROMPT-NATIVE FEATURES - \"Features are prompts defining outcomes, not code\"\n\nTasks:\n1. Read all agent prompts\n2. Classify each feature/behavior as defined in:\n - PROMPT (good): outcomes defined in natural language\n - CODE (bad): business logic hardcoded\n3. Check if behavior changes require prompt edit vs code change\n\nFormat:\n## Prompt-Native Features Audit\n### Feature Definition Analysis\n| Feature | Defined In | Type | Notes |\n### Score: X/Y (percentage%)\n### Code-Defined Features (anti-pattern)\n### Recommendations\n```\n\n</sub-agents>\n\n### Step 3: Compile Summary Report\n\nAfter all agents complete, compile a summary with:\n\n```markdown\n## Agent-Native Architecture Review: [Project Name]\n\n### Overall Score Summary\n\n| Core Principle | Score | Percentage | Status |\n|----------------|-------|------------|--------|\n| Action Parity | X/Y | Z% | βœ…/⚠️/❌ |\n| Tools as Primitives | X/Y | Z% | βœ…/⚠️/❌ |\n| Context Injection | X/Y | Z% | βœ…/⚠️/❌ |\n| Shared Workspace | X/Y | Z% | βœ…/⚠️/❌ |\n| CRUD Completeness | X/Y | Z% | βœ…/⚠️/❌ |\n| UI Integration | X/Y | Z% | βœ…/⚠️/❌ |\n| Capability Discovery | X/Y | Z% | βœ…/⚠️/❌ |\n| Prompt-Native Features | X/Y | Z% | βœ…/⚠️/❌ |\n\n**Overall Agent-Native Score: X%**\n\n### Status Legend\n- βœ… Excellent (80%+)\n- ⚠️ Partial (50-79%)\n- ❌ Needs Work (<50%)\n\n### Top 10 Recommendations by Impact\n\n| Priority | Action | Principle | Effort |\n|----------|--------|-----------|--------|\n\n### What's Working Excellently\n\n[List top 5 strengths]\n```\n\n## Success Criteria\n\n- [ ] All 8 sub-agents complete their audits\n- [ ] Each principle has a specific numeric score (X/Y format)\n- [ ] Summary table shows all scores and status indicators\n- [ ] Top 10 recommendations are prioritized by impact\n- [ ] Report identifies both strengths and gaps\n\n## Optional: Single Principle Audit\n\nIf $ARGUMENTS specifies a single principle (e.g., \"action parity\"), only run that sub-agent and provide detailed findings for that principle alone.\n\nValid arguments:\n- `action parity` or `1`\n- `tools` or `primitives` or `2`\n- `context` or `injection` or `3`\n- `shared` or `workspace` or `4`\n- `crud` or `5`\n- `ui` or `integration` or `6`\n- `discovery` or `7`\n- `prompt` or `features` or `8`" + }, + "deepen-plan": { + "description": "Enhance a plan with parallel research agents for each section to add depth, best practices, and implementation details", + "template": "# Deepen Plan - Power Enhancement Mode\n\n## Introduction\n\n**Note: The current year is 2026.** Use this when searching for recent documentation and best practices.\n\nThis command takes an existing plan (from `/workflows:plan`) and enhances each section with parallel research agents. Each major element gets its own dedicated research sub-agent to find:\n- Best practices and industry patterns\n- Performance optimizations\n- UI/UX improvements (if applicable)\n- Quality enhancements and edge cases\n- Real-world implementation examples\n\nThe result is a deeply grounded, production-ready plan with concrete implementation details.\n\n## Plan File\n\n<plan_path> #$ARGUMENTS </plan_path>\n\n**If the plan path above is empty:**\n1. Check for recent plans: `ls -la docs/plans/`\n2. Ask the user: \"Which plan would you like to deepen? Please provide the path (e.g., `docs/plans/2026-01-15-feat-my-feature-plan.md`).\"\n\nDo not proceed until you have a valid plan file path.\n\n## Main Tasks\n\n### 1. Parse and Analyze Plan Structure\n\n<thinking>\nFirst, read and parse the plan to identify each major section that can be enhanced with research.\n</thinking>\n\n**Read the plan file and extract:**\n- [ ] Overview/Problem Statement\n- [ ] Proposed Solution sections\n- [ ] Technical Approach/Architecture\n- [ ] Implementation phases/steps\n- [ ] Code examples and file references\n- [ ] Acceptance criteria\n- [ ] Any UI/UX components mentioned\n- [ ] Technologies/frameworks mentioned (Rails, React, Python, TypeScript, etc.)\n- [ ] Domain areas (data models, APIs, UI, security, performance, etc.)\n\n**Create a section manifest:**\n```\nSection 1: [Title] - [Brief description of what to research]\nSection 2: [Title] - [Brief description of what to research]\n...\n```\n\n### 2. Discover and Apply Available Skills\n\n<thinking>\nDynamically discover all available skills and match them to plan sections. Don't assume what skills exist - discover them at runtime.\n</thinking>\n\n**Step 1: Discover ALL available skills from ALL sources**\n\n```bash\n# 1. Project-local skills (highest priority - project-specific)\nls .claude/skills/\n\n# 2. User's global skills (~/.claude/)\nls ~/.claude/skills/\n\n# 3. compound-engineering plugin skills\nls ~/.claude/plugins/cache/*/compound-engineering/*/skills/\n\n# 4. ALL other installed plugins - check every plugin for skills\nfind ~/.claude/plugins/cache -type d -name \"skills\" 2>/dev/null\n\n# 5. Also check installed_plugins.json for all plugin locations\ncat ~/.claude/plugins/installed_plugins.json\n```\n\n**Important:** Check EVERY source. Don't assume compound-engineering is the only plugin. Use skills from ANY installed plugin that's relevant.\n\n**Step 2: For each discovered skill, read its SKILL.md to understand what it does**\n\n```bash\n# For each skill directory found, read its documentation\ncat [skill-path]/SKILL.md\n```\n\n**Step 3: Match skills to plan content**\n\nFor each skill discovered:\n- Read its SKILL.md description\n- Check if any plan sections match the skill's domain\n- If there's a match, spawn a sub-agent to apply that skill's knowledge\n\n**Step 4: Spawn a sub-agent for EVERY matched skill**\n\n**CRITICAL: For EACH skill that matches, spawn a separate sub-agent and instruct it to USE that skill.**\n\nFor each matched skill:\n```\nTask general-purpose: \"You have the [skill-name] skill available at [skill-path].\n\nYOUR JOB: Use this skill on the plan.\n\n1. Read the skill: cat [skill-path]/SKILL.md\n2. Follow the skill's instructions exactly\n3. Apply the skill to this content:\n\n[relevant plan section or full plan]\n\n4. Return the skill's full output\n\nThe skill tells you what to do - follow it. Execute the skill completely.\"\n```\n\n**Spawn ALL skill sub-agents in PARALLEL:**\n- 1 sub-agent per matched skill\n- Each sub-agent reads and uses its assigned skill\n- All run simultaneously\n- 10, 20, 30 skill sub-agents is fine\n\n**Each sub-agent:**\n1. Reads its skill's SKILL.md\n2. Follows the skill's workflow/instructions\n3. Applies the skill to the plan\n4. Returns whatever the skill produces (code, recommendations, patterns, reviews, etc.)\n\n**Example spawns:**\n```\nTask general-purpose: \"Use the dhh-rails-style skill at ~/.claude/plugins/.../dhh-rails-style. Read SKILL.md and apply it to: [Rails sections of plan]\"\n\nTask general-purpose: \"Use the frontend-design skill at ~/.claude/plugins/.../frontend-design. Read SKILL.md and apply it to: [UI sections of plan]\"\n\nTask general-purpose: \"Use the agent-native-architecture skill at ~/.claude/plugins/.../agent-native-architecture. Read SKILL.md and apply it to: [agent/tool sections of plan]\"\n\nTask general-purpose: \"Use the security-patterns skill at ~/.claude/skills/security-patterns. Read SKILL.md and apply it to: [full plan]\"\n```\n\n**No limit on skill sub-agents. Spawn one for every skill that could possibly be relevant.**\n\n### 3. Discover and Apply Learnings/Solutions\n\n<thinking>\nCheck for documented learnings from /workflows:compound. These are solved problems stored as markdown files. Spawn a sub-agent for each learning to check if it's relevant.\n</thinking>\n\n**LEARNINGS LOCATION - Check these exact folders:**\n\n```\ndocs/solutions/ <-- PRIMARY: Project-level learnings (created by /workflows:compound)\nβ”œβ”€β”€ performance-issues/\nβ”‚ └── *.md\nβ”œβ”€β”€ debugging-patterns/\nβ”‚ └── *.md\nβ”œβ”€β”€ configuration-fixes/\nβ”‚ └── *.md\nβ”œβ”€β”€ integration-issues/\nβ”‚ └── *.md\nβ”œβ”€β”€ deployment-issues/\nβ”‚ └── *.md\n└── [other-categories]/\n └── *.md\n```\n\n**Step 1: Find ALL learning markdown files**\n\nRun these commands to get every learning file:\n\n```bash\n# PRIMARY LOCATION - Project learnings\nfind docs/solutions -name \"*.md\" -type f 2>/dev/null\n\n# If docs/solutions doesn't exist, check alternate locations:\nfind .claude/docs -name \"*.md\" -type f 2>/dev/null\nfind ~/.claude/docs -name \"*.md\" -type f 2>/dev/null\n```\n\n**Step 2: Read frontmatter of each learning to filter**\n\nEach learning file has YAML frontmatter with metadata. Read the first ~20 lines of each file to get:\n\n```yaml\n---\ntitle: \"N+1 Query Fix for Briefs\"\ncategory: performance-issues\ntags: [activerecord, n-plus-one, includes, eager-loading]\nmodule: Briefs\nsymptom: \"Slow page load, multiple queries in logs\"\nroot_cause: \"Missing includes on association\"\n---\n```\n\n**For each .md file, quickly scan its frontmatter:**\n\n```bash\n# Read first 20 lines of each learning (frontmatter + summary)\nhead -20 docs/solutions/**/*.md\n```\n\n**Step 3: Filter - only spawn sub-agents for LIKELY relevant learnings**\n\nCompare each learning's frontmatter against the plan:\n- `tags:` - Do any tags match technologies/patterns in the plan?\n- `category:` - Is this category relevant? (e.g., skip deployment-issues if plan is UI-only)\n- `module:` - Does the plan touch this module?\n- `symptom:` / `root_cause:` - Could this problem occur with the plan?\n\n**SKIP learnings that are clearly not applicable:**\n- Plan is frontend-only β†’ skip `database-migrations/` learnings\n- Plan is Python β†’ skip `rails-specific/` learnings\n- Plan has no auth β†’ skip `authentication-issues/` learnings\n\n**SPAWN sub-agents for learnings that MIGHT apply:**\n- Any tag overlap with plan technologies\n- Same category as plan domain\n- Similar patterns or concerns\n\n**Step 4: Spawn sub-agents for filtered learnings**\n\nFor each learning that passes the filter:\n\n```\nTask general-purpose: \"\nLEARNING FILE: [full path to .md file]\n\n1. Read this learning file completely\n2. This learning documents a previously solved problem\n\nCheck if this learning applies to this plan:\n\n---\n[full plan content]\n---\n\nIf relevant:\n- Explain specifically how it applies\n- Quote the key insight or solution\n- Suggest where/how to incorporate it\n\nIf NOT relevant after deeper analysis:\n- Say 'Not applicable: [reason]'\n\"\n```\n\n**Example filtering:**\n```\n# Found 15 learning files, plan is about \"Rails API caching\"\n\n# SPAWN (likely relevant):\ndocs/solutions/performance-issues/n-plus-one-queries.md # tags: [activerecord] βœ“\ndocs/solutions/performance-issues/redis-cache-stampede.md # tags: [caching, redis] βœ“\ndocs/solutions/configuration-fixes/redis-connection-pool.md # tags: [redis] βœ“\n\n# SKIP (clearly not applicable):\ndocs/solutions/deployment-issues/heroku-memory-quota.md # not about caching\ndocs/solutions/frontend-issues/stimulus-race-condition.md # plan is API, not frontend\ndocs/solutions/authentication-issues/jwt-expiry.md # plan has no auth\n```\n\n**Spawn sub-agents in PARALLEL for all filtered learnings.**\n\n**These learnings are institutional knowledge - applying them prevents repeating past mistakes.**\n\n### 4. Launch Per-Section Research Agents\n\n<thinking>\nFor each major section in the plan, spawn dedicated sub-agents to research improvements. Use the Explore agent type for open-ended research.\n</thinking>\n\n**For each identified section, launch parallel research:**\n\n```\nTask Explore: \"Research best practices, patterns, and real-world examples for: [section topic].\nFind:\n- Industry standards and conventions\n- Performance considerations\n- Common pitfalls and how to avoid them\n- Documentation and tutorials\nReturn concrete, actionable recommendations.\"\n```\n\n**Also use Context7 MCP for framework documentation:**\n\nFor any technologies/frameworks mentioned in the plan, query Context7:\n```\nmcp__plugin_compound-engineering_context7__resolve-library-id: Find library ID for [framework]\nmcp__plugin_compound-engineering_context7__query-docs: Query documentation for specific patterns\n```\n\n**Use WebSearch for current best practices:**\n\nSearch for recent (2024-2026) articles, blog posts, and documentation on topics in the plan.\n\n### 5. Discover and Run ALL Review Agents\n\n<thinking>\nDynamically discover every available agent and run them ALL against the plan. Don't filter, don't skip, don't assume relevance. 40+ parallel agents is fine. Use everything available.\n</thinking>\n\n**Step 1: Discover ALL available agents from ALL sources**\n\n```bash\n# 1. Project-local agents (highest priority - project-specific)\nfind .claude/agents -name \"*.md\" 2>/dev/null\n\n# 2. User's global agents (~/.claude/)\nfind ~/.claude/agents -name \"*.md\" 2>/dev/null\n\n# 3. compound-engineering plugin agents (all subdirectories)\nfind ~/.claude/plugins/cache/*/compound-engineering/*/agents -name \"*.md\" 2>/dev/null\n\n# 4. ALL other installed plugins - check every plugin for agents\nfind ~/.claude/plugins/cache -path \"*/agents/*.md\" 2>/dev/null\n\n# 5. Check installed_plugins.json to find all plugin locations\ncat ~/.claude/plugins/installed_plugins.json\n\n# 6. For local plugins (isLocal: true), check their source directories\n# Parse installed_plugins.json and find local plugin paths\n```\n\n**Important:** Check EVERY source. Include agents from:\n- Project `.claude/agents/`\n- User's `~/.claude/agents/`\n- compound-engineering plugin (but SKIP workflow/ agents - only use review/, research/, design/, docs/)\n- ALL other installed plugins (agent-sdk-dev, frontend-design, etc.)\n- Any local plugins\n\n**For compound-engineering plugin specifically:**\n- USE: `agents/review/*` (all reviewers)\n- USE: `agents/research/*` (all researchers)\n- USE: `agents/design/*` (design agents)\n- USE: `agents/docs/*` (documentation agents)\n- SKIP: `agents/workflow/*` (these are workflow orchestrators, not reviewers)\n\n**Step 2: For each discovered agent, read its description**\n\nRead the first few lines of each agent file to understand what it reviews/analyzes.\n\n**Step 3: Launch ALL agents in parallel**\n\nFor EVERY agent discovered, launch a Task in parallel:\n\n```\nTask [agent-name]: \"Review this plan using your expertise. Apply all your checks and patterns. Plan content: [full plan content]\"\n```\n\n**CRITICAL RULES:**\n- Do NOT filter agents by \"relevance\" - run them ALL\n- Do NOT skip agents because they \"might not apply\" - let them decide\n- Launch ALL agents in a SINGLE message with multiple Task tool calls\n- 20, 30, 40 parallel agents is fine - use everything\n- Each agent may catch something others miss\n- The goal is MAXIMUM coverage, not efficiency\n\n**Step 4: Also discover and run research agents**\n\nResearch agents (like `best-practices-researcher`, `framework-docs-researcher`, `git-history-analyzer`, `repo-research-analyst`) should also be run for relevant plan sections.\n\n### 6. Wait for ALL Agents and Synthesize Everything\n\n<thinking>\nWait for ALL parallel agents to complete - skills, research agents, review agents, everything. Then synthesize all findings into a comprehensive enhancement.\n</thinking>\n\n**Collect outputs from ALL sources:**\n\n1. **Skill-based sub-agents** - Each skill's full output (code examples, patterns, recommendations)\n2. **Learnings/Solutions sub-agents** - Relevant documented learnings from /workflows:compound\n3. **Research agents** - Best practices, documentation, real-world examples\n4. **Review agents** - All feedback from every reviewer (architecture, security, performance, simplicity, etc.)\n5. **Context7 queries** - Framework documentation and patterns\n6. **Web searches** - Current best practices and articles\n\n**For each agent's findings, extract:**\n- [ ] Concrete recommendations (actionable items)\n- [ ] Code patterns and examples (copy-paste ready)\n- [ ] Anti-patterns to avoid (warnings)\n- [ ] Performance considerations (metrics, benchmarks)\n- [ ] Security considerations (vulnerabilities, mitigations)\n- [ ] Edge cases discovered (handling strategies)\n- [ ] Documentation links (references)\n- [ ] Skill-specific patterns (from matched skills)\n- [ ] Relevant learnings (past solutions that apply - prevent repeating mistakes)\n\n**Deduplicate and prioritize:**\n- Merge similar recommendations from multiple agents\n- Prioritize by impact (high-value improvements first)\n- Flag conflicting advice for human review\n- Group by plan section\n\n### 7. Enhance Plan Sections\n\n<thinking>\nMerge research findings back into the plan, adding depth without changing the original structure.\n</thinking>\n\n**Enhancement format for each section:**\n\n```markdown\n## [Original Section Title]\n\n[Original content preserved]\n\n### Research Insights\n\n**Best Practices:**\n- [Concrete recommendation 1]\n- [Concrete recommendation 2]\n\n**Performance Considerations:**\n- [Optimization opportunity]\n- [Benchmark or metric to target]\n\n**Implementation Details:**\n```[language]\n// Concrete code example from research\n```\n\n**Edge Cases:**\n- [Edge case 1 and how to handle]\n- [Edge case 2 and how to handle]\n\n**References:**\n- [Documentation URL 1]\n- [Documentation URL 2]\n```\n\n### 8. Add Enhancement Summary\n\nAt the top of the plan, add a summary section:\n\n```markdown\n## Enhancement Summary\n\n**Deepened on:** [Date]\n**Sections enhanced:** [Count]\n**Research agents used:** [List]\n\n### Key Improvements\n1. [Major improvement 1]\n2. [Major improvement 2]\n3. [Major improvement 3]\n\n### New Considerations Discovered\n- [Important finding 1]\n- [Important finding 2]\n```\n\n### 9. Update Plan File\n\n**Write the enhanced plan:**\n- Preserve original filename\n- Add `-deepened` suffix if user prefers a new file\n- Update any timestamps or metadata\n\n## Output Format\n\nUpdate the plan file in place (or if user requests a separate file, append `-deepened` after `-plan`, e.g., `2026-01-15-feat-auth-plan-deepened.md`).\n\n## Quality Checks\n\nBefore finalizing:\n- [ ] All original content preserved\n- [ ] Research insights clearly marked and attributed\n- [ ] Code examples are syntactically correct\n- [ ] Links are valid and relevant\n- [ ] No contradictions between sections\n- [ ] Enhancement summary accurately reflects changes\n\n## Post-Enhancement Options\n\nAfter writing the enhanced plan, use the **AskUserQuestion tool** to present these options:\n\n**Question:** \"Plan deepened at `[plan_path]`. What would you like to do next?\"\n\n**Options:**\n1. **View diff** - Show what was added/changed\n2. **Run `/plan_review`** - Get feedback from reviewers on enhanced plan\n3. **Start `/workflows:work`** - Begin implementing this enhanced plan\n4. **Deepen further** - Run another round of research on specific sections\n5. **Revert** - Restore original plan (if backup exists)\n\nBased on selection:\n- **View diff** β†’ Run `git diff [plan_path]` or show before/after\n- **`/plan_review`** β†’ Call the /plan_review command with the plan file path\n- **`/workflows:work`** β†’ Call the /workflows:work command with the plan file path\n- **Deepen further** β†’ Ask which sections need more research, then re-run those agents\n- **Revert** β†’ Restore from git or backup\n\n## Example Enhancement\n\n**Before (from /workflows:plan):**\n```markdown\n## Technical Approach\n\nUse React Query for data fetching with optimistic updates.\n```\n\n**After (from /workflows:deepen-plan):**\n```markdown\n## Technical Approach\n\nUse React Query for data fetching with optimistic updates.\n\n### Research Insights\n\n**Best Practices:**\n- Configure `staleTime` and `cacheTime` based on data freshness requirements\n- Use `queryKey` factories for consistent cache invalidation\n- Implement error boundaries around query-dependent components\n\n**Performance Considerations:**\n- Enable `refetchOnWindowFocus: false` for stable data to reduce unnecessary requests\n- Use `select` option to transform and memoize data at query level\n- Consider `placeholderData` for instant perceived loading\n\n**Implementation Details:**\n```typescript\n// Recommended query configuration\nconst queryClient = new QueryClient({\n defaultOptions: {\n queries: {\n staleTime: 5 * 60 * 1000, // 5 minutes\n retry: 2,\n refetchOnWindowFocus: false,\n },\n },\n});\n```\n\n**Edge Cases:**\n- Handle race conditions with `cancelQueries` on component unmount\n- Implement retry logic for transient network failures\n- Consider offline support with `persistQueryClient`\n\n**References:**\n- https://tanstack.com/query/latest/docs/react/guides/optimistic-updates\n- https://tkdodo.eu/blog/practical-react-query\n```\n\nNEVER CODE! Just research and enhance the plan." + }, + "release-docs": { + "description": "Build and update the documentation site with current plugin components", + "template": "# Release Documentation Command\n\nYou are a documentation generator for the compound-engineering plugin. Your job is to ensure the documentation site at `plugins/compound-engineering/docs/` is always up-to-date with the actual plugin components.\n\n## Overview\n\nThe documentation site is a static HTML/CSS/JS site based on the Evil Martians LaunchKit template. It needs to be regenerated whenever:\n\n- Agents are added, removed, or modified\n- Commands are added, removed, or modified\n- Skills are added, removed, or modified\n- MCP servers are added, removed, or modified\n\n## Step 1: Inventory Current Components\n\nFirst, count and list all current components:\n\n```bash\n# Count agents\nls plugins/compound-engineering/agents/*.md | wc -l\n\n# Count commands\nls plugins/compound-engineering/commands/*.md | wc -l\n\n# Count skills\nls -d plugins/compound-engineering/skills/*/ 2>/dev/null | wc -l\n\n# Count MCP servers\nls -d plugins/compound-engineering/mcp-servers/*/ 2>/dev/null | wc -l\n```\n\nRead all component files to get their metadata:\n\n### Agents\nFor each agent file in `plugins/compound-engineering/agents/*.md`:\n- Extract the frontmatter (name, description)\n- Note the category (Review, Research, Workflow, Design, Docs)\n- Get key responsibilities from the content\n\n### Commands\nFor each command file in `plugins/compound-engineering/commands/*.md`:\n- Extract the frontmatter (name, description, argument-hint)\n- Categorize as Workflow or Utility command\n\n### Skills\nFor each skill directory in `plugins/compound-engineering/skills/*/`:\n- Read the SKILL.md file for frontmatter (name, description)\n- Note any scripts or supporting files\n\n### MCP Servers\nFor each MCP server in `plugins/compound-engineering/mcp-servers/*/`:\n- Read the configuration and README\n- List the tools provided\n\n## Step 2: Update Documentation Pages\n\n### 2a. Update `docs/index.html`\n\nUpdate the stats section with accurate counts:\n```html\n<div class=\"stats-grid\">\n <div class=\"stat-card\">\n <span class=\"stat-number\">[AGENT_COUNT]</span>\n <span class=\"stat-label\">Specialized Agents</span>\n </div>\n <!-- Update all stat cards -->\n</div>\n```\n\nEnsure the component summary sections list key components accurately.\n\n### 2b. Update `docs/pages/agents.html`\n\nRegenerate the complete agents reference page:\n- Group agents by category (Review, Research, Workflow, Design, Docs)\n- Include for each agent:\n - Name and description\n - Key responsibilities (bullet list)\n - Usage example: `claude agent [agent-name] \"your message\"`\n - Use cases\n\n### 2c. Update `docs/pages/commands.html`\n\nRegenerate the complete commands reference page:\n- Group commands by type (Workflow, Utility)\n- Include for each command:\n - Name and description\n - Arguments (if any)\n - Process/workflow steps\n - Example usage\n\n### 2d. Update `docs/pages/skills.html`\n\nRegenerate the complete skills reference page:\n- Group skills by category (Development Tools, Content & Workflow, Image Generation)\n- Include for each skill:\n - Name and description\n - Usage: `claude skill [skill-name]`\n - Features and capabilities\n\n### 2e. Update `docs/pages/mcp-servers.html`\n\nRegenerate the MCP servers reference page:\n- For each server:\n - Name and purpose\n - Tools provided\n - Configuration details\n - Supported frameworks/services\n\n## Step 3: Update Metadata Files\n\nEnsure counts are consistent across:\n\n1. **`plugins/compound-engineering/.claude-plugin/plugin.json`**\n - Update `description` with correct counts\n - Update `components` object with counts\n - Update `agents`, `commands` arrays with current items\n\n2. **`.claude-plugin/marketplace.json`**\n - Update plugin `description` with correct counts\n\n3. **`plugins/compound-engineering/README.md`**\n - Update intro paragraph with counts\n - Update component lists\n\n## Step 4: Validate\n\nRun validation checks:\n\n```bash\n# Validate JSON files\ncat .claude-plugin/marketplace.json | jq .\ncat plugins/compound-engineering/.claude-plugin/plugin.json | jq .\n\n# Verify counts match\necho \"Agents in files: $(ls plugins/compound-engineering/agents/*.md | wc -l)\"\ngrep -o \"[0-9]* specialized agents\" plugins/compound-engineering/docs/index.html\n\necho \"Commands in files: $(ls plugins/compound-engineering/commands/*.md | wc -l)\"\ngrep -o \"[0-9]* slash commands\" plugins/compound-engineering/docs/index.html\n```\n\n## Step 5: Report Changes\n\nProvide a summary of what was updated:\n\n```\n## Documentation Release Summary\n\n### Component Counts\n- Agents: X (previously Y)\n- Commands: X (previously Y)\n- Skills: X (previously Y)\n- MCP Servers: X (previously Y)\n\n### Files Updated\n- docs/index.html - Updated stats and component summaries\n- docs/pages/agents.html - Regenerated with X agents\n- docs/pages/commands.html - Regenerated with X commands\n- docs/pages/skills.html - Regenerated with X skills\n- docs/pages/mcp-servers.html - Regenerated with X servers\n- plugin.json - Updated counts and component lists\n- marketplace.json - Updated description\n- README.md - Updated component lists\n\n### New Components Added\n- [List any new agents/commands/skills]\n\n### Components Removed\n- [List any removed agents/commands/skills]\n```\n\n## Dry Run Mode\n\nIf `--dry-run` is specified:\n- Perform all inventory and validation steps\n- Report what WOULD be updated\n- Do NOT write any files\n- Show diff previews of proposed changes\n\n## Error Handling\n\n- If component files have invalid frontmatter, report the error and skip\n- If JSON validation fails, report and abort\n- Always maintain a valid state - don't partially update\n\n## Post-Release\n\nAfter successful release:\n1. Suggest updating CHANGELOG.md with documentation changes\n2. Remind to commit with message: `docs: Update documentation site to match plugin components`\n3. Remind to push changes\n\n## Usage Examples\n\n```bash\n# Full documentation release\nclaude /release-docs\n\n# Preview changes without writing\nclaude /release-docs --dry-run\n\n# After adding new agents\nclaude /release-docs\n```" + }, + "deploy-docs": { + "description": "Validate and prepare documentation for GitHub Pages deployment", + "template": "# Deploy Documentation Command\n\nValidate the documentation site and prepare it for GitHub Pages deployment.\n\n## Step 1: Validate Documentation\n\nRun these checks:\n\n```bash\n# Count components\necho \"Agents: $(ls plugins/compound-engineering/agents/*.md | wc -l)\"\necho \"Commands: $(ls plugins/compound-engineering/commands/*.md | wc -l)\"\necho \"Skills: $(ls -d plugins/compound-engineering/skills/*/ 2>/dev/null | wc -l)\"\n\n# Validate JSON\ncat .claude-plugin/marketplace.json | jq . > /dev/null && echo \"βœ“ marketplace.json valid\"\ncat plugins/compound-engineering/.claude-plugin/plugin.json | jq . > /dev/null && echo \"βœ“ plugin.json valid\"\n\n# Check all HTML files exist\nfor page in index agents commands skills mcp-servers changelog getting-started; do\n if [ -f \"plugins/compound-engineering/docs/pages/${page}.html\" ] || [ -f \"plugins/compound-engineering/docs/${page}.html\" ]; then\n echo \"βœ“ ${page}.html exists\"\n else\n echo \"βœ— ${page}.html MISSING\"\n fi\ndone\n```\n\n## Step 2: Check for Uncommitted Changes\n\n```bash\ngit status --porcelain plugins/compound-engineering/docs/\n```\n\nIf there are uncommitted changes, warn the user to commit first.\n\n## Step 3: Deployment Instructions\n\nSince GitHub Pages deployment requires a workflow file with special permissions, provide these instructions:\n\n### First-time Setup\n\n1. Create `.github/workflows/deploy-docs.yml` with the GitHub Pages workflow\n2. Go to repository Settings > Pages\n3. Set Source to \"GitHub Actions\"\n\n### Deploying\n\nAfter merging to `main`, the docs will auto-deploy. Or:\n\n1. Go to Actions tab\n2. Select \"Deploy Documentation to GitHub Pages\"\n3. Click \"Run workflow\"\n\n### Workflow File Content\n\n```yaml\nname: Deploy Documentation to GitHub Pages\n\non:\n push:\n branches: [main]\n paths:\n - 'plugins/compound-engineering/docs/**'\n workflow_dispatch:\n\npermissions:\n contents: read\n pages: write\n id-token: write\n\nconcurrency:\n group: \"pages\"\n cancel-in-progress: false\n\njobs:\n deploy:\n environment:\n name: github-pages\n url: ${{ steps.deployment.outputs.page_url }}\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - uses: actions/configure-pages@v4\n - uses: actions/upload-pages-artifact@v3\n with:\n path: 'plugins/compound-engineering/docs'\n - uses: actions/deploy-pages@v4\n```\n\n## Step 4: Report Status\n\nProvide a summary:\n\n```\n## Deployment Readiness\n\nβœ“ All HTML pages present\nβœ“ JSON files valid\nβœ“ Component counts match\n\n### Next Steps\n- [ ] Commit any pending changes\n- [ ] Push to main branch\n- [ ] Verify GitHub Pages workflow exists\n- [ ] Check deployment at https://everyinc.github.io/every-marketplace/\n```" + }, + "resolve_parallel": { + "description": "Resolve all TODO comments using parallel processing", + "template": "Resolve all TODO comments using parallel processing.\n\n## Workflow\n\n### 1. Analyze\n\nGather the things todo from above.\n\n### 2. Plan\n\nCreate a TodoWrite list of all unresolved items grouped by type.Make sure to look at dependencies that might occur and prioritize the ones needed by others. For example, if you need to change a name, you must wait to do the others. Output a mermaid flow diagram showing how we can do this. Can we do everything in parallel? Do we need to do one first that leads to others in parallel? I'll put the to-dos in the mermaid diagram flow‑wise so the agent knows how to proceed in order.\n\n### 3. Implement (PARALLEL)\n\nSpawn a pr-comment-resolver agent for each unresolved item in parallel.\n\nSo if there are 3 comments, it will spawn 3 pr-comment-resolver agents in parallel. liek this\n\n1. Task pr-comment-resolver(comment1)\n2. Task pr-comment-resolver(comment2)\n3. Task pr-comment-resolver(comment3)\n\nAlways run all in parallel subagents/Tasks for each Todo item.\n\n### 4. Commit & Resolve\n\n- Commit changes\n- Push to remote" + }, + "lfg": { + "description": "Full autonomous engineering workflow", + "template": "Run these slash commands in order. Do not do anything else.\n\n1. `/ralph-wiggum:ralph-loop \"finish all slash commands\" --completion-promise \"DONE\"`\n2. `/workflows:plan $ARGUMENTS`\n3. `/compound-engineering:deepen-plan`\n4. `/workflows:work`\n5. `/workflows:review`\n6. `/compound-engineering:resolve_todo_parallel`\n7. `/compound-engineering:test-browser`\n8. `/compound-engineering:feature-video`\n9. Output `<promise>DONE</promise>` when video is in PR\n\nStart with step 1 now." + }, + "resolve_todo_parallel": { + "description": "Resolve all pending CLI todos using parallel processing", + "template": "Resolve all TODO comments using parallel processing.\n\n## Workflow\n\n### 1. Analyze\n\nGet all unresolved TODOs from the /todos/\\*.md directory\n\nIf any todo recommends deleting, removing, or gitignoring files in `docs/plans/` or `docs/solutions/`, skip it and mark it as `wont_fix`. These are compound-engineering pipeline artifacts that are intentional and permanent.\n\n### 2. Plan\n\nCreate a TodoWrite list of all unresolved items grouped by type.Make sure to look at dependencies that might occur and prioritize the ones needed by others. For example, if you need to change a name, you must wait to do the others. Output a mermaid flow diagram showing how we can do this. Can we do everything in parallel? Do we need to do one first that leads to others in parallel? I'll put the to-dos in the mermaid diagram flow‑wise so the agent knows how to proceed in order.\n\n### 3. Implement (PARALLEL)\n\nSpawn a pr-comment-resolver agent for each unresolved item in parallel.\n\nSo if there are 3 comments, it will spawn 3 pr-comment-resolver agents in parallel. liek this\n\n1. Task pr-comment-resolver(comment1)\n2. Task pr-comment-resolver(comment2)\n3. Task pr-comment-resolver(comment3)\n\nAlways run all in parallel subagents/Tasks for each Todo item.\n\n### 4. Commit & Resolve\n\n- Commit changes\n- Remove the TODO from the file, and mark it as resolved.\n- Push to remote" + } + }, + "mcp": { + "context7": { + "type": "remote", + "url": "https://mcp.context7.com/mcp", + "enabled": true + }, + + }, + "permission": { + "read": "allow", + "write": "allow", + "edit": "allow", + "bash": "allow", + "grep": "allow", + "glob": "allow", + "list": "allow", + "webfetch": "allow", + "skill": "allow", + "patch": "allow", + "task": "allow", + "question": "allow", + "todowrite": "allow", + "todoread": "allow" + }, + "tools": { + "read": true, + "write": true, + "edit": true, + "bash": true, + "grep": true, + "glob": true, + "list": true, + "webfetch": true, + "skill": true, + "patch": true, + "task": true, + "question": true, + "todowrite": true, + "todoread": true + }, + "provider": { + "openrouter": { + "models": { + "stepfun/step-3.5-flash": {} + } + }, + "local": { + "npm": "@ai-sdk/openai-compatible", + "name": "Local", + "options": { + "baseURL": "http://localhost:5082/v1" + }, + "models": { + "GLM-4.7-Flash": { + "name": "GLM-4.7-Flash" + }, + "Qwen3-VL": { + "name": "Qwen3-VL", + "modalities": { + "input": [ + "text", + "image" + ], + "output": [ + "text" + ] + } + }, + "Qwen3.5-122B-A10B": { + "name": "Qwen3.5-122B-A10B", + "modalities": { + "input": [ + "text", + "image" + ], + "output": [ + "text" + ] + } + }, + "Qwen3.6-35B-A3B": { + "name": "Qwen3.6-35B-A3B", + "modalities": { + "input": [ + "text", + "image" + ], + "output": [ + "text" + ] + } + }, + "MiniMax-M2.5": { + "name": "MiniMax-M2.5" + }, + "gemma-4-31B-it": { + "name": "gemma-4-31B-it", + "modalities": { + "input": [ + "text", + "image" + ], + "output": [ + "text" + ] + } + }, + "gemma-4-31B-it-speculative": { + "name": "gemma-4-31B-it-speculative" + }, + "Qwen3.6-27B-code": { + "name": "Qwen3.6-27B-code", + "modalities": { + "input": [ + "text", + "image" + ], + "output": [ + "text" + ] + } + }, + "Qwen3.6-27B": { + "name": "Qwen3.6-27B", + "modalities": { + "input": [ + "text", + "image" + ], + "output": [ + "text" + ] + } + }, + "Qwen3.6-27B-FP8": { + "name": "Qwen3.6-27B-FP8" + + } + } + } + } +}