From 78604399bbca90694262dd632c2d9b5378aa83e3 Mon Sep 17 00:00:00 2001 From: Jon Langevin Date: Mon, 25 May 2026 16:52:33 -0400 Subject: [PATCH] feat: rename project to autonomous dev kit --- .claude-plugin/marketplace.json | 18 +- .claude-plugin/plugin.json | 16 +- .codex/INSTALL.md | 52 ++- .cursor-plugin/plugin.json | 18 +- .github/FUNDING.yml | 2 +- .github/workflows/bump-version.yml | 2 +- .github/workflows/release-tag.yml | 8 +- .opencode/INSTALL.md | 42 +- .../plugins/{superpowers.js => autodev.js} | 18 +- LICENSE | 2 +- README.md | 114 +++--- RELEASE-NOTES.md | 178 ++++---- commands/brainstorm.md | 2 +- commands/execute-plan.md | 2 +- commands/write-plan.md | 2 +- docs/README.codex.md | 55 ++- docs/README.opencode.md | 100 ++--- docs/cross-llm-coverage.md | 8 +- .../2025-11-22-opencode-support-design.md | 44 +- ...5-11-22-opencode-support-implementation.md | 206 +++++----- ...-skills-improvements-from-user-feedback.md | 8 +- ...6-03-04-alignment-autonomy-teams-design.md | 4 +- .../2026-03-04-alignment-autonomy-teams.md | 38 +- ...ous-dev-kit-skills-improvements-design.md} | 6 +- ...autonomous-dev-kit-skills-improvements.md} | 8 +- ...2026-04-25-cross-llm-portability-design.md | 20 +- .../plans/2026-04-25-cross-llm-portability.md | 30 +- docs/plans/2026-04-25-p11-p12-patterns.md | 2 +- docs/roadmap.md | 2 +- docs/testing.md | 18 +- hooks/completion-claim-guard | 69 +++- hooks/posttool-pr-created | 24 +- hooks/pre-compact-snapshot | 57 +-- hooks/pre-tool-scope-guard | 25 +- hooks/pretool-pr-review-reminder | 20 +- hooks/prompt-strict-interpretation | 48 ++- hooks/record-activity | 47 ++- hooks/scope-lock-apply | 1 + hooks/session-start | 95 +++-- hooks/subagent-scope-guard | 60 ++- lib/skills-core.js | 34 +- skills/adversarial-design-review/SKILL.md | 61 ++- skills/alignment-check/SKILL.md | 8 +- skills/brainstorming/SKILL.md | 39 +- skills/condensed-pipeline-writing/SKILL.md | 144 +++++++ skills/dispatching-parallel-agents/SKILL.md | 4 +- skills/executing-plans/SKILL.md | 10 +- .../finishing-a-development-branch/SKILL.md | 10 +- skills/post-merge-retrospective/SKILL.md | 35 +- skills/pr-monitoring/SKILL.md | 14 +- skills/project-design-guidance/SKILL.md | 120 ++++++ skills/receiving-code-review/SKILL.md | 4 +- skills/recording-decisions/SKILL.md | 89 ++-- skills/requesting-code-review/SKILL.md | 8 +- skills/runtime-launch-validation/SKILL.md | 2 + skills/scope-lock/SKILL.md | 79 ++-- skills/subagent-driven-development/SKILL.md | 36 +- .../code-quality-reviewer-prompt.md | 2 +- skills/systematic-debugging/CREATION-LOG.md | 2 +- skills/systematic-debugging/SKILL.md | 8 +- .../root-cause-tracing.md | 2 +- skills/test-driven-development/SKILL.md | 2 + .../SKILL.md | 14 +- skills/using-git-worktrees/SKILL.md | 28 +- .../verification-before-completion/SKILL.md | 188 +++------ skills/writing-plans/SKILL.md | 92 +++-- skills/writing-skills/SKILL.md | 10 +- .../testing-skills-with-subagents.md | 2 +- tests/claude-code/README.md | 4 +- ...subagent-driven-development-integration.sh | 4 +- tests/cross-llm-coverage.md | 2 +- .../run-claude-describes-sdd.sh | 2 +- .../run-extended-multiturn-test.sh | 2 +- .../explicit-skill-requests/run-haiku-test.sh | 2 +- .../run-multiturn-test.sh | 2 +- tests/explicit-skill-requests/run-test.sh | 4 +- tests/hook-contracts.sh | 381 ++++++++++++++++++ tests/opencode/setup.sh | 18 +- tests/opencode/test-plugin-loading.sh | 24 +- tests/opencode/test-priority.sh | 44 +- tests/opencode/test-skills-core.sh | 64 +-- tests/opencode/test-tools.sh | 16 +- tests/plan-scope-check.sh | 3 +- tests/skill-activation-audit.sh | 38 +- tests/skill-compression-notes.sh | 33 ++ tests/skill-cross-refs.sh | 14 +- tests/skill-triggering/run-test.sh | 4 +- tests/subagent-driven-dev/go-fractals/plan.md | 4 +- .../go-fractals/scaffold.sh | 2 +- tests/subagent-driven-dev/run-test.sh | 6 +- tests/subagent-driven-dev/svelte-todo/plan.md | 2 +- .../svelte-todo/scaffold.sh | 2 +- 92 files changed, 2062 insertions(+), 1133 deletions(-) rename .opencode/plugins/{superpowers.js => autodev.js} (79%) rename docs/plans/{2026-04-25-superpowers-skills-improvements-design.md => 2026-04-25-autonomous-dev-kit-skills-improvements-design.md} (99%) rename docs/plans/{2026-04-25-superpowers-skills-improvements.md => 2026-04-25-autonomous-dev-kit-skills-improvements.md} (99%) create mode 100644 skills/condensed-pipeline-writing/SKILL.md create mode 100644 skills/project-design-guidance/SKILL.md rename skills/{using-superpowers => using-autodev}/SKILL.md (87%) create mode 100755 tests/hook-contracts.sh create mode 100755 tests/skill-compression-notes.sh diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 41eb612..93300e1 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -1,19 +1,19 @@ { - "name": "superpowers-dev", - "description": "Development marketplace for Superpowers core skills library", + "name": "autodev-dev", + "description": "Development marketplace for Autonomous Dev Kit", "owner": { - "name": "Jesse Vincent", - "email": "jesse@fsck.com" + "name": "Jon Langevin", + "email": "jon@gocodealone.com" }, "plugins": [ { - "name": "superpowers", - "description": "Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques", - "version": "5.7.2", + "name": "autodev", + "description": "Autonomous development workflow skills for coding agents", + "version": "6.0.0", "source": "./", "author": { - "name": "Jesse Vincent", - "email": "jesse@fsck.com" + "name": "Jon Langevin", + "email": "jon@gocodealone.com" } } ] diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index c2b27fe..24a0c18 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,13 +1,13 @@ { - "name": "superpowers", - "description": "Core skills library for Claude Code: TDD, debugging, collaboration patterns, and proven techniques", - "version": "5.7.2", + "name": "autodev", + "description": "Autonomous development workflow skills for coding agents: design, review, planning, execution, monitoring, and retrospectives", + "version": "6.0.0", "author": { - "name": "Jesse Vincent", - "email": "jesse@fsck.com" + "name": "Jon Langevin", + "email": "jon@gocodealone.com" }, - "homepage": "https://github.com/GoCodeAlone/claude-superpowers", - "repository": "https://github.com/GoCodeAlone/claude-superpowers", + "homepage": "https://github.com/GoCodeAlone/autonomous-dev-kit", + "repository": "https://github.com/GoCodeAlone/autonomous-dev-kit", "license": "MIT", - "keywords": ["skills", "tdd", "debugging", "collaboration", "best-practices", "workflows"] + "keywords": ["skills", "tdd", "debugging", "collaboration", "best-practices", "workflows", "agents", "autonomous-development"] } diff --git a/.codex/INSTALL.md b/.codex/INSTALL.md index 270b925..887c619 100644 --- a/.codex/INSTALL.md +++ b/.codex/INSTALL.md @@ -1,59 +1,79 @@ -# Installing Superpowers for Codex +# Installing Autonomous Dev Kit for Codex -Enable superpowers skills in Codex via native skill discovery. Just clone and symlink. +Enable autodev skills in Codex via native skill discovery. Prefer the +`skills` CLI when Node is available; clone and symlink manually as a fallback. ## Prerequisites - Git +- Node.js 18+ for `npx skills add` install ## Installation -1. **Clone the superpowers repository:** +### Recommended: Skills CLI + +From your project root: + +```bash +npx skills add GoCodeAlone/autonomous-dev-kit -a codex --skill '*' -y +``` + +For user/global install: + +```bash +npx skills add GoCodeAlone/autonomous-dev-kit -a codex --skill '*' -g -y +``` + +Restart Codex after install. + +### Manual fallback + +1. **Clone the autodev repository:** ```bash - git clone https://github.com/GoCodeAlone/claude-superpowers.git ~/.codex/superpowers + git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git ~/.codex/autodev ``` 2. **Create the skills symlink:** ```bash mkdir -p ~/.agents/skills - ln -s ~/.codex/superpowers/skills ~/.agents/skills/superpowers + ln -s ~/.codex/autodev/skills ~/.agents/skills/autodev ``` **Windows (PowerShell):** ```powershell New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.agents\skills" - cmd /c mklink /J "$env:USERPROFILE\.agents\skills\superpowers" "$env:USERPROFILE\.codex\superpowers\skills" + cmd /c mklink /J "$env:USERPROFILE\.agents\skills\autodev" "$env:USERPROFILE\.codex\autodev\skills" ``` 3. **Restart Codex** (quit and relaunch the CLI) to discover the skills. ## Migrating from old bootstrap -If you installed superpowers before native skill discovery, you need to: +If you installed autodev before native skill discovery, you need to: 1. **Update the repo:** ```bash - cd ~/.codex/superpowers && git pull + cd ~/.codex/autodev && git pull ``` 2. **Create the skills symlink** (step 2 above) — this is the new discovery mechanism. -3. **Remove the old bootstrap block** from `~/.codex/AGENTS.md` — any block referencing `superpowers-codex bootstrap` is no longer needed. +3. **Remove the old bootstrap block** from `~/.codex/AGENTS.md` — any block referencing `autodev-codex bootstrap` is no longer needed. 4. **Restart Codex.** ## Verify ```bash -ls -la ~/.agents/skills/superpowers +ls -la ~/.agents/skills/autodev ``` -You should see a symlink (or junction on Windows) pointing to your superpowers skills directory. +You should see a symlink (or junction on Windows) pointing to your autodev skills directory. ## Updating ```bash -cd ~/.codex/superpowers && git pull +cd ~/.codex/autodev && git pull ``` Skills update instantly through the symlink. @@ -61,19 +81,19 @@ Skills update instantly through the symlink. ## Uninstalling ```bash -rm ~/.agents/skills/superpowers +rm ~/.agents/skills/autodev ``` -Optionally delete the clone: `rm -rf ~/.codex/superpowers`. +Optionally delete the clone: `rm -rf ~/.codex/autodev`. ## Cross-LLM Behavior -Superpowers skills use `` blocks to gate Claude Code-only content. Codex skips those blocks automatically; no configuration needed. +Autonomous Dev Kit skills use `` blocks to gate Claude Code-only content. Codex skips those blocks automatically; no configuration needed. To enable host-conditional logic inside skills (so skills can adapt behavior per host), declare your host in `~/.codex/AGENTS.md`: ```markdown -# Superpowers host declaration +# Autonomous Dev Kit host declaration Host: codex ``` diff --git a/.cursor-plugin/plugin.json b/.cursor-plugin/plugin.json index e87074f..c0fdd75 100644 --- a/.cursor-plugin/plugin.json +++ b/.cursor-plugin/plugin.json @@ -1,16 +1,16 @@ { - "name": "superpowers", - "displayName": "Superpowers", - "description": "Core skills library: TDD, debugging, collaboration patterns, and proven techniques", - "version": "5.7.2", + "name": "autodev", + "displayName": "Autonomous Dev Kit", + "description": "Autonomous development workflow skills for coding agents", + "version": "6.0.0", "author": { - "name": "Jesse Vincent", - "email": "jesse@fsck.com" + "name": "Jon Langevin", + "email": "jon@gocodealone.com" }, - "homepage": "https://github.com/GoCodeAlone/claude-superpowers", - "repository": "https://github.com/GoCodeAlone/claude-superpowers", + "homepage": "https://github.com/GoCodeAlone/autonomous-dev-kit", + "repository": "https://github.com/GoCodeAlone/autonomous-dev-kit", "license": "MIT", - "keywords": ["skills", "tdd", "debugging", "collaboration", "best-practices", "workflows"], + "keywords": ["skills", "tdd", "debugging", "collaboration", "best-practices", "workflows", "agents", "autonomous-development"], "skills": "./skills/", "agents": "./agents/", "commands": "./commands/", diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index f646aa7..d5986f0 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -1,3 +1,3 @@ # These are supported funding model platforms -github: [obra] +github: [intel352] diff --git a/.github/workflows/bump-version.yml b/.github/workflows/bump-version.yml index 8c15026..11a19d5 100644 --- a/.github/workflows/bump-version.yml +++ b/.github/workflows/bump-version.yml @@ -120,7 +120,7 @@ jobs: echo "PR already open for $BRANCH (#$existing); skipping creation." exit 0 fi - body=$(printf 'Automated version bump to `%s`.\n\nWhen this PR merges, the `Release Tag` workflow will create tag `v%s` and dispatch the `superpowers-version-bump` event to `GoCodeAlone/superpowers-marketplace`.\n' "$TARGET_VERSION" "$TARGET_VERSION") + body=$(printf 'Automated version bump to `%s`.\n\nWhen this PR merges, the `Release Tag` workflow will create tag `v%s` and dispatch the `autodev-version-bump` event to `GoCodeAlone/claude-marketplace`.\n' "$TARGET_VERSION" "$TARGET_VERSION") gh pr create \ --base main \ --head "$BRANCH" \ diff --git a/.github/workflows/release-tag.yml b/.github/workflows/release-tag.yml index cb2bdf8..3210491 100644 --- a/.github/workflows/release-tag.yml +++ b/.github/workflows/release-tag.yml @@ -58,7 +58,7 @@ jobs: git push origin "v${TARGET_VERSION}" echo "created=true" >> "$GITHUB_OUTPUT" - - name: Notify superpowers-marketplace + - name: Notify claude-marketplace if: steps.tag.outputs.created == 'true' env: REPO_DISPATCH_TOKEN: ${{ secrets.REPO_DISPATCH_TOKEN }} @@ -71,12 +71,12 @@ jobs: response=$(curl -sL -w "\n%{http_code}" -X POST \ -H "Authorization: token ${REPO_DISPATCH_TOKEN}" \ -H "Accept: application/vnd.github.v3+json" \ - https://api.github.com/repos/GoCodeAlone/superpowers-marketplace/dispatches \ - -d "{\"event_type\": \"superpowers-version-bump\", \"client_payload\": {\"version\": \"${TARGET_VERSION}\"}}") + https://api.github.com/repos/GoCodeAlone/claude-marketplace/dispatches \ + -d "{\"event_type\": \"autodev-version-bump\", \"client_payload\": {\"version\": \"${TARGET_VERSION}\"}}") http_code=$(echo "$response" | tail -1) body=$(echo "$response" | head -n -1) if [[ "$http_code" -lt 200 || "$http_code" -ge 300 ]]; then echo "ERROR: marketplace dispatch failed (HTTP ${http_code}): ${body}" >&2 exit 1 fi - echo "Dispatched superpowers-version-bump event to GoCodeAlone/superpowers-marketplace (HTTP ${http_code})" + echo "Dispatched autodev-version-bump event to GoCodeAlone/claude-marketplace (HTTP ${http_code})" diff --git a/.opencode/INSTALL.md b/.opencode/INSTALL.md index bf5fa68..069c881 100644 --- a/.opencode/INSTALL.md +++ b/.opencode/INSTALL.md @@ -1,4 +1,4 @@ -# Installing Superpowers for OpenCode +# Installing Autonomous Dev Kit for OpenCode ## Prerequisites @@ -7,10 +7,10 @@ ## Installation Steps -### 1. Clone Superpowers +### 1. Clone Autonomous Dev Kit ```bash -git clone https://github.com/GoCodeAlone/claude-superpowers.git ~/.config/opencode/superpowers +git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git ~/.config/opencode/autodev ``` ### 2. Register the Plugin @@ -19,25 +19,25 @@ Create a symlink so OpenCode discovers the plugin: ```bash mkdir -p ~/.config/opencode/plugins -rm -f ~/.config/opencode/plugins/superpowers.js -ln -s ~/.config/opencode/superpowers/.opencode/plugins/superpowers.js ~/.config/opencode/plugins/superpowers.js +rm -f ~/.config/opencode/plugins/autodev.js +ln -s ~/.config/opencode/autodev/.opencode/plugins/autodev.js ~/.config/opencode/plugins/autodev.js ``` ### 3. Symlink Skills -Create a symlink so OpenCode's native skill tool discovers superpowers skills: +Create a symlink so OpenCode's native skill tool discovers autodev skills: ```bash mkdir -p ~/.config/opencode/skills -rm -rf ~/.config/opencode/skills/superpowers -ln -s ~/.config/opencode/superpowers/skills ~/.config/opencode/skills/superpowers +rm -rf ~/.config/opencode/skills/autodev +ln -s ~/.config/opencode/autodev/skills ~/.config/opencode/skills/autodev ``` ### 4. Restart OpenCode -Restart OpenCode. The plugin will automatically inject superpowers context. +Restart OpenCode. The plugin will automatically inject autodev context. -Verify by asking: "do you have superpowers?" +Verify by asking: "do you have autodev?" ## Usage @@ -54,7 +54,7 @@ use skill tool to list skills Use OpenCode's native `skill` tool to load a specific skill: ``` -use skill tool to load superpowers/brainstorming +use skill tool to load autodev/brainstorming ``` ### Personal Skills @@ -82,12 +82,12 @@ description: Use when [condition] - [what it does] Create project-specific skills in `.opencode/skills/` within your project. -**Skill Priority:** Project skills > Personal skills > Superpowers skills +**Skill Priority:** Project skills > Personal skills > Autonomous Dev Kit skills ## Updating ```bash -cd ~/.config/opencode/superpowers +cd ~/.config/opencode/autodev git pull ``` @@ -95,14 +95,14 @@ git pull ### Plugin not loading -1. Check plugin symlink: `ls -l ~/.config/opencode/plugins/superpowers.js` -2. Check source exists: `ls ~/.config/opencode/superpowers/.opencode/plugins/superpowers.js` +1. Check plugin symlink: `ls -l ~/.config/opencode/plugins/autodev.js` +2. Check source exists: `ls ~/.config/opencode/autodev/.opencode/plugins/autodev.js` 3. Check OpenCode logs for errors ### Skills not found -1. Check skills symlink: `ls -l ~/.config/opencode/skills/superpowers` -2. Verify it points to: `~/.config/opencode/superpowers/skills` +1. Check skills symlink: `ls -l ~/.config/opencode/skills/autodev` +2. Verify it points to: `~/.config/opencode/autodev/skills` 3. Use `skill` tool to list what's discovered ### Tool mapping @@ -115,12 +115,12 @@ When skills reference Claude Code tools: ## Cross-LLM Behavior -Superpowers skills use `` blocks to gate Claude Code-only content. OpenCode skips those blocks automatically; no configuration needed. +Autonomous Dev Kit skills use `` blocks to gate Claude Code-only content. OpenCode skips those blocks automatically; no configuration needed. To enable host-conditional logic inside skills (so skills can adapt behavior per host), declare your host in `~/.config/opencode/AGENTS.md`: ```markdown -# Superpowers host declaration +# Autonomous Dev Kit host declaration Host: opencode ``` @@ -128,5 +128,5 @@ Add this block once. Skills that inspect the host context will use it to pick th ## Getting Help -- Report issues: https://github.com/GoCodeAlone/claude-superpowers/issues -- Full documentation: https://github.com/GoCodeAlone/claude-superpowers/blob/main/docs/README.opencode.md +- Report issues: https://github.com/GoCodeAlone/autonomous-dev-kit/issues +- Full documentation: https://github.com/GoCodeAlone/autonomous-dev-kit/blob/main/docs/README.opencode.md diff --git a/.opencode/plugins/superpowers.js b/.opencode/plugins/autodev.js similarity index 79% rename from .opencode/plugins/superpowers.js rename to .opencode/plugins/autodev.js index 8ac9934..e9c9c9e 100644 --- a/.opencode/plugins/superpowers.js +++ b/.opencode/plugins/autodev.js @@ -1,7 +1,7 @@ /** - * Superpowers plugin for OpenCode.ai + * Autonomous Dev Kit plugin for OpenCode.ai * - * Injects superpowers bootstrap context via system prompt transform. + * Injects autodev bootstrap context via system prompt transform. * Skills are discovered via OpenCode's native skill tool from symlinked directory. */ @@ -46,16 +46,16 @@ const normalizePath = (p, homeDir) => { return path.resolve(normalized); }; -export const SuperpowersPlugin = async ({ client, directory }) => { +export const AutodevPlugin = async ({ client, directory }) => { const homeDir = os.homedir(); - const superpowersSkillsDir = path.resolve(__dirname, '../../skills'); + const autodevSkillsDir = path.resolve(__dirname, '../../skills'); const envConfigDir = normalizePath(process.env.OPENCODE_CONFIG_DIR, homeDir); const configDir = envConfigDir || path.join(homeDir, '.config/opencode'); // Helper to generate bootstrap content const getBootstrapContent = () => { - // Try to load using-superpowers skill - const skillPath = path.join(superpowersSkillsDir, 'using-superpowers', 'SKILL.md'); + // Try to load using-autodev skill + const skillPath = path.join(autodevSkillsDir, 'using-autodev', 'SKILL.md'); if (!fs.existsSync(skillPath)) return null; const fullContent = fs.readFileSync(skillPath, 'utf8'); @@ -69,13 +69,13 @@ When skills reference tools you don't have, substitute OpenCode equivalents: - \`Read\`, \`Write\`, \`Edit\`, \`Bash\` → Your native tools **Skills location:** -Superpowers skills are in \`${configDir}/skills/superpowers/\` +Autonomous Dev Kit skills are in \`${configDir}/skills/autodev/\` Use OpenCode's native \`skill\` tool to list and load skills.`; return ` -You have superpowers. +You have autodev. -**IMPORTANT: The using-superpowers skill content is included below. It is ALREADY LOADED - you are currently following it. Do NOT use the skill tool to load "using-superpowers" again - that would be redundant.** +**IMPORTANT: The using-autodev skill content is included below. It is ALREADY LOADED - you are currently following it. Do NOT use the skill tool to load "using-autodev" again - that would be redundant.** ${content} diff --git a/LICENSE b/LICENSE index abf0390..a15549f 100644 --- a/LICENSE +++ b/LICENSE @@ -1,6 +1,6 @@ MIT License -Copyright (c) 2025 Jesse Vincent +Copyright (c) 2025 Jon Langevin Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/README.md b/README.md index dbf36db..28bf553 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ -# Superpowers +# Autonomous Dev Kit -Superpowers is a complete software development workflow for your coding agents, built on top of a set of composable "skills" and some initial instructions that make sure your agent uses them. +Autonomous Dev Kit is a complete software development workflow for your coding agents, built on top of a set of composable "skills" and some initial instructions that make sure your agent uses them. ## How it works @@ -10,33 +10,26 @@ Once it's teased a spec out of the conversation, it shows it to you in chunks sh After you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow. It emphasizes true red/green TDD, YAGNI (You Aren't Gonna Need It), and DRY. -Next up, once you say "go", it launches a *subagent-driven-development* process, having agents work through each engineering task, inspecting and reviewing their work, and continuing forward. It's not uncommon for Claude to be able to work autonomously for a couple hours at a time without deviating from the plan you put together. +Next up, once you say "go", it launches a *subagent-driven-development* process, having agents work through each engineering task, inspecting and reviewing their work, and continuing forward. In capable hosts, agents can work autonomously for long stretches without deviating from the plan you put together. -There's a bunch more to it, but that's the core of the system. And because the skills trigger automatically, you don't need to do anything special. Your coding agent just has Superpowers. +There's a bunch more to it, but that's the core of the system. And because the skills trigger automatically, you don't need to do anything special. Your coding agent just has Autonomous Dev Kit. - -## Sponsorship - -If Superpowers has helped you do stuff that makes money and you are so inclined, I'd greatly appreciate it if you'd consider [sponsoring my opensource work](https://github.com/sponsors/obra). - -Thanks! - -- Jesse +Autonomous Dev Kit originated as a fork of Jesse Vincent's [Superpowers](https://github.com/obra/superpowers) repo. ## Installation -**Note:** Installation differs by platform. Claude Code or Cursor have built-in plugin marketplaces. Codex and OpenCode require manual setup. +**Note:** Installation differs by platform. Claude Code or Cursor have built-in plugin marketplaces. Codex can use the open `skills` CLI (`npx skills add`) or manual setup. OpenCode currently uses manual setup. ### Claude Code (via Plugin Marketplace) -If you have the upstream (obra) superpowers plugin installed, **uninstall it first** — both plugins use the same `superpowers` name and will conflict: +If you have the old `autodev` plugin installed, **uninstall it first** before installing `autodev`: ```bash # 1. Remove existing superpowers plugin (if installed) /plugin uninstall superpowers -# 2. Remove obra's marketplace (if registered) +# 2. Remove the old marketplace (if registered) /plugin marketplace remove superpowers-marketplace # 3. Restart Claude Code to apply removals @@ -47,10 +40,22 @@ Then in a fresh session, add the GoCodeAlone marketplace and install: ```bash # 4. Register the GoCodeAlone marketplace -/plugin marketplace add GoCodeAlone/superpowers-marketplace +/plugin marketplace add GoCodeAlone/claude-marketplace # 5. Install the plugin -/plugin install superpowers@superpowers-marketplace +/plugin install autodev@claude-marketplace +``` + +Alternatively, install the skills directly with the open Skills CLI: + +```bash +npx skills add GoCodeAlone/autonomous-dev-kit -a claude-code --skill '*' -y +``` + +For user/global install: + +```bash +npx skills add GoCodeAlone/autonomous-dev-kit -a claude-code --skill '*' -g -y ``` ### Cursor (via Plugin Marketplace) @@ -58,15 +63,29 @@ Then in a fresh session, add the GoCodeAlone marketplace and install: In Cursor Agent chat, install from marketplace: ```text -/plugin-add superpowers +/plugin-add autodev ``` ### Codex -Tell Codex: +From your project root, install with the open Skills CLI: +```bash +npx skills add GoCodeAlone/autonomous-dev-kit -a codex --skill '*' -y ``` -Fetch and follow instructions from https://raw.githubusercontent.com/GoCodeAlone/claude-superpowers/refs/heads/main/.codex/INSTALL.md + +For user/global install instead of project-local install: + +```bash +npx skills add GoCodeAlone/autonomous-dev-kit -a codex --skill '*' -g -y +``` + +Then restart Codex so it discovers the skills. + +Manual fallback: tell Codex: + +``` +Fetch and follow instructions from https://raw.githubusercontent.com/GoCodeAlone/autonomous-dev-kit/refs/heads/main/.codex/INSTALL.md ``` **Detailed docs:** [docs/README.codex.md](docs/README.codex.md) @@ -76,48 +95,48 @@ Fetch and follow instructions from https://raw.githubusercontent.com/GoCodeAlone Tell OpenCode: ``` -Fetch and follow instructions from https://raw.githubusercontent.com/GoCodeAlone/claude-superpowers/refs/heads/main/.opencode/INSTALL.md +Fetch and follow instructions from https://raw.githubusercontent.com/GoCodeAlone/autonomous-dev-kit/refs/heads/main/.opencode/INSTALL.md ``` **Detailed docs:** [docs/README.opencode.md](docs/README.opencode.md) ### Verify Installation -Start a new session in your chosen platform and ask for something that should trigger a skill (for example, "help me plan this feature" or "let's debug this issue"). The agent should automatically invoke the relevant superpowers skill. +Start a new session in your chosen platform and ask for something that should trigger a skill (for example, "help me plan this feature" or "let's debug this issue"). The agent should automatically invoke the relevant autodev skill. ## Cross-LLM Compatibility -Superpowers skills run on any host that supports the SKILL.md format. Host-specific tools (like Agent Teams) are conditioned with `` blocks so other hosts skip them gracefully. +Autonomous Dev Kit skills run on any host that supports the SKILL.md format. Host-specific tools (like Agent Teams) are conditioned with `` blocks so other hosts skip them gracefully. | Host | Install path | Native skill discovery | Notes | |---|---|---|---| -| Claude Code | `~/.claude/plugins/marketplace/superpowers/` | yes | Full Agent Teams support (experimental flag) | -| Codex | `~/.agents/skills/superpowers/` | yes | Sequential sub-agent dispatch; `/plan` slash; `/agent` switching | -| OpenCode | `~/.config/opencode/skills/superpowers/` | yes | Tool mapping documented in `.opencode/INSTALL.md` | -| Cursor | `/plugin-add superpowers` | yes (via plugin) | Plugin manifest defines skills/agents/commands/hooks | +| Claude Code | `~/.claude/plugins/marketplace/autodev/` | yes | Full Agent Teams support (experimental flag) | +| Codex | `~/.agents/skills/autodev/` | yes | Sequential sub-agent dispatch; `/plan` slash; `/agent` switching | +| OpenCode | `~/.config/opencode/skills/autodev/` | yes | Tool mapping documented in `.opencode/INSTALL.md` | +| Cursor | `/plugin-add autodev` | yes (via plugin) | Plugin manifest defines skills/agents/commands/hooks | Full capability matrix: [docs/cross-llm-coverage.md](docs/cross-llm-coverage.md) Per-skill host-conditional audit: [tests/cross-llm-coverage.md](tests/cross-llm-coverage.md) ## The Basic Workflow -1. **brainstorming** - Activates before writing code. Refines rough ideas through questions, explores alternatives, lists load-bearing assumptions, runs a self-challenge round, presents design in sections for validation. Soft cap of 5 question-batches; on exceed, agent presents best-current-approximation and asks user to approve / refine / extend the budget. Saves design document. +1. **brainstorming** - Activates before writing code. Refines rough ideas through questions, explores alternatives, applies project-wide design guidance, lists load-bearing assumptions, runs a self-challenge round, presents design in sections for validation. Designs now explicitly cover global guidance fit, security review, infrastructure impact, multi-component validation, assumptions, and rollback. Soft cap of 5 question-batches; on exceed, agent presents best-current-approximation and asks user to approve / refine / extend the budget. Saves design document. -2. **adversarial-design-review (design phase)** - Activates after design doc is committed. Adversarially attacks the *ideas* in the design (not just structure): unstated assumptions, repo-precedent conflicts, YAGNI violations, missing failure modes, security gaps, rollback story, simpler alternatives, user-intent drift. PASS/FAIL with max 2 revision cycles. +2. **adversarial-design-review (design phase)** - Activates after design doc is committed. Adversarially attacks the *ideas* in the design (not just structure): project-guidance conflicts, assumptions under attack, repo-precedent conflicts, YAGNI violations, missing failure modes, security/privacy gaps, infrastructure impact, multi-component validation, rollback story, simpler alternatives, user-intent drift. PASS/FAIL cycles continue while tangible issues appear; the loop stops when only nitpicks remain. 3. **recording-decisions** - Activates inside brainstorming and writing-plans whenever a non-trivial choice is made (divergence from precedent, trade-off between ≥2 plausible approaches, adversarial-review override, cross-skill structural change). Adds a numbered ADR in `decisions/` so the *why* survives renames and refactors. 4. **using-git-worktrees** - Activates after design approval. Creates isolated workspace on new branch, runs project setup, verifies clean test baseline. -5. **writing-plans** - Activates with approved design. Breaks work into bite-sized tasks (2-5 minutes each). Every task has exact file paths, complete code, verification steps. Runtime-affecting tasks include rollback notes. Plan MUST contain a `## Scope Manifest` block declaring PR Count, Tasks, Out-of-scope items, and a per-PR grouping table — this is the contract `scope-lock` enforces. +5. **writing-plans** - Activates with approved design. Breaks work into bite-sized tasks (2-5 minutes each). Every task has exact file paths, complete code, verification steps. Plans must map project guidance into tasks, wire security-sensitive behavior into verification, prove multi-component boundaries with integration/E2E checks where feasible, and validate infrastructure changes with render/plan/dry-run or safe-env apply. Runtime-affecting tasks include rollback notes. Plan MUST contain a `## Scope Manifest` block declaring PR Count, Tasks, Out-of-scope items, and a per-PR grouping table — this is the contract `scope-lock` enforces. -6. **adversarial-design-review (plan phase)** - Activates after plan doc is committed. Inherits the design checklist plus plan-specific scans: task granularity, verification-class match, hidden serial dependencies, rollback wiring. +6. **adversarial-design-review (plan phase)** - Activates after plan doc is committed. Inherits the design checklist plus plan-specific scans: task granularity, verification-class match, hidden serial dependencies, rollback wiring, missing integration proof, and infrastructure verification mismatch. 7. **alignment-check** - Activates after adversarial review of plan passes. Narrowly structural: every design requirement maps to a plan task; every plan task traces to a design requirement; the Scope Manifest is well-formed (forward + reverse + manifest trace via `tests/plan-scope-check.sh`). -8. **scope-lock** - Activates immediately after `alignment-check` PASS. Stamps the plan with `Locked `, computes the manifest's sha256 into `.scope-lock`, commits both. From this point until completion (or an explicit user-approved unlock), the task list, PR count, and feature scope are immutable. `subagent-driven-development` re-checks the lock between tasks; `finishing-a-development-branch` re-checks before any PR is created. +8. **scope-lock** - Activates immediately after `alignment-check` PASS. Stamps the plan with `Locked `, computes the manifest's sha256 into `.scope-lock`, commits both. From this point until completion (or an explicit user-approved amendment), the task list, PR count, and feature scope are immutable. Design backports that do not change the manifest are allowed; manifest changes go through ADR + alignment. The lock hash covers only the `## Scope Manifest` block, so explanatory design/task notes can evolve without invalidating scope. `subagent-driven-development` re-checks the lock between tasks; `finishing-a-development-branch` re-checks before any PR is created. -9. **subagent-driven-development** or **executing-plans** - Activates with a locked plan. Dispatches fresh subagent per task with two-stage review (spec compliance, then code quality). Between tasks, re-runs the scope-lock check; on lock drift, stops the line and surfaces the discrepancy. +9. **subagent-driven-development** or **executing-plans** - Activates with a locked plan. Dispatches fresh subagent per task with two-stage review (spec compliance, then code quality). Between tasks, re-runs the scope-lock check; on lock drift, stops the line and surfaces the discrepancy. Phase/task completions are logged in compressed JSONL to `.autodev/state/phase-progress.jsonl` when a locked plan continues. 10. **test-driven-development** - Activates during implementation. Enforces RED-GREEN-REFACTOR: write failing test, watch it fail, write minimal code, watch it pass, commit. Deletes code written before tests. @@ -127,21 +146,23 @@ Per-skill host-conditional audit: [tests/cross-llm-coverage.md](tests/cross-llm- 13. **pr-monitoring** - Activates after autonomous PR creation (one monitor per PR in the manifest). Watches CI and review comments; fixes failures and responds to feedback until green. -14. **post-merge-retrospective** - Activates after `pr-monitoring` exits successfully on a merged PR with green CI. Reads the design, plan, adversarial-review reports, code-review threads, and CI history; produces a short retro in `docs/retros/` scoring each adversarial finding (Prescient / Resolved upfront / False positive / Inconclusive), naming gate misses, and surfacing plugin-level follow-ups when patterns emerge across retros. +14. **post-merge-retrospective** - Activates after `pr-monitoring` exits successfully on a merged PR with green CI. Reads the design, plan, adversarial-review reports, code-review threads, and CI history; produces a short retro in `docs/retros/` scoring each adversarial finding (Prescient / Resolved upfront / False positive / Inconclusive), naming gate misses, and surfacing plugin-level follow-ups when patterns emerge across retros. If the retro reveals durable project-wide guidance, it updates `docs/design-guidance.md` in the same loop. **The agent checks for relevant skills before any task.** Mandatory workflows, not suggestions. ## Auditing skill activations -`tests/skill-activation-audit.sh` reads `.claude/superpowers-state/in-progress.jsonl` (the activity log written by the `record-activity` hook) and reports which pipeline gates fired during a session. Use it post-hoc when you want to confirm whether the autonomous pipeline ran end-to-end or stopped earlier than expected. Strictly local — never transmits anything. +`tests/skill-activation-audit.sh` reads `.claude/autodev-state/in-progress.jsonl` (the compressed activity log written by the `record-activity` hook) and reports which pipeline gates fired during a session. Use it post-hoc when you want to confirm whether the autonomous pipeline ran end-to-end or stopped earlier than expected. Strictly local — never transmits anything. -`tests/skill-cross-refs.sh` verifies that cross-skill references inside `skills/` and `agents/` markdown resolve (skill names, `Step N` references, `superpowers:` mentions). Run it before committing any skill edit that renames a skill or renumbers a step. +`tests/skill-cross-refs.sh` verifies that cross-skill references inside `skills/` and `agents/` markdown resolve (skill names, `Step N` references, `autodev:` mentions). Run it before committing any skill edit that renames a skill or renumbers a step. `tests/plan-scope-check.sh` verifies the Scope Manifest invariant. Three modes: `--plan ` (well-formedness — PR Count matches the grouping table; every task in the body appears in the table; etc.), `--verify-lock ` (manifest sha256 matches the `.scope-lock` file written at alignment time), and `--against-branch ` (planned branches in the manifest exist locally or on origin). The autonomous pipeline runs all three at the appropriate gates; CI can run `--plan` against every plan in `docs/plans/`. +`tests/hook-contracts.sh` verifies hook JSON and guard behavior without requiring Claude Code or Codex to be installed. It checks the host-neutral `hookSpecificOutput.additionalContext` schema, Stop-hook phase-continuation behavior, hard-blocker stops, compact JSONL state rows, and locked-plan backports that do not change the Scope Manifest. + ## Strict-interpretation invariant -Once a plan is locked, ambiguous user phrases — "reorder as needed", "create a PR", "test locally", "ship a demo", "be quick" — do NOT authorize rescoping, PR collapse, or partial-scope shipping. The agent picks the most-faithful-to-the-locked-manifest interpretation; if multiple strict readings remain plausible, it stops and asks. See the table in `skills/using-superpowers/SKILL.md` § "Strict-interpretation invariant" for the full mapping and the unlock path. +Once a plan is locked, ambiguous user phrases — "reorder as needed", "create a PR", "test locally", "ship a demo", "be quick" — do NOT authorize rescoping, PR collapse, or partial-scope shipping. The agent picks the most-faithful-to-the-locked-manifest interpretation; if multiple strict readings remain plausible, it stops and asks. See the table in `skills/using-autodev/SKILL.md` § "Strict-interpretation invariant" for the full mapping and the amendment path. ## What's Inside @@ -156,12 +177,14 @@ Once a plan is locked, ambiguous user phrases — "reorder as needed", "create a **Collaboration** - **brainstorming** - Socratic design refinement (with assumption-listing, self-challenge round, and a 5-batch question budget) -- **adversarial-design-review** - Adversarial attack on design and plan ideas before execution (two phases: design, plan) -- **recording-decisions** - ADRs in `decisions/` for non-trivial trade-offs, rejected alternatives, and user-approved scope reductions +- **project-design-guidance** - Reads or creates durable project-wide constraints before designs/plans and backfeeds durable lessons from retros +- **adversarial-design-review** - Adversarial attack on design and plan ideas before execution (two phases: design, plan), including project-guidance conflicts, security/privacy, infrastructure impact, and multi-component validation +- **recording-decisions** - ADRs in `decisions/` for non-trivial trade-offs, rejected alternatives, and user-approved manifest amendments - **writing-plans** - Detailed implementation plans (with mandatory Scope Manifest) - **executing-plans** - Batch execution with checkpoints - **alignment-check** - Structural design ↔ plan trace (forward + reverse + manifest) -- **scope-lock** - Once a plan passes alignment, the task list, PR count, and feature scope are immutable until completion or explicit user-approved reduction +- **scope-lock** - Once a plan passes alignment, the task list, PR count, and feature scope are immutable until completion or explicit user-approved amendment +- **condensed-pipeline-writing** - Compact internal format for design, review, planning, backport, and phase-progress artifacts - **dispatching-parallel-agents** - Concurrent subagent workflows - **requesting-code-review** - Pre-review checklist - **receiving-code-review** - Responding to feedback @@ -173,7 +196,7 @@ Once a plan is locked, ambiguous user phrases — "reorder as needed", "create a **Meta** - **writing-skills** - Create new skills following best practices (includes testing methodology) -- **using-superpowers** - Introduction to the skills system +- **using-autodev** - Introduction to the skills system ## Philosophy @@ -182,8 +205,6 @@ Once a plan is locked, ambiguous user phrases — "reorder as needed", "create a - **Complexity reduction** - Simplicity as primary goal - **Evidence over claims** - Verify before declaring success -Read more: [Superpowers for Claude Code](https://blog.fsck.com/2025/10/09/superpowers/) - ## Contributing Skills live directly in this repository. To contribute: @@ -200,7 +221,7 @@ See `skills/writing-skills/SKILL.md` for the complete guide. Skills update automatically when you update the plugin: ```bash -/plugin update superpowers +/plugin update autodev ``` ## License @@ -209,6 +230,5 @@ MIT License - see LICENSE file for details ## Support -- **Issues**: https://github.com/GoCodeAlone/claude-superpowers/issues -- **Marketplace**: https://github.com/GoCodeAlone/superpowers-marketplace -- **Upstream**: https://github.com/obra/superpowers +- **Issues**: https://github.com/GoCodeAlone/autonomous-dev-kit/issues +- **Marketplace**: https://github.com/GoCodeAlone/claude-marketplace diff --git a/RELEASE-NOTES.md b/RELEASE-NOTES.md index 07fc877..3537926 100644 --- a/RELEASE-NOTES.md +++ b/RELEASE-NOTES.md @@ -1,4 +1,38 @@ -# Superpowers Release Notes +# Autonomous Dev Kit Release Notes + +## v6.0.0 (2026-05-25) + +### Rename and ownership + +- Renamed the project from `claude-superpowers` to `autonomous-dev-kit`. +- Renamed the skill namespace from `superpowers:` to `autodev:`. +- Renamed the Claude plugin from `superpowers` to `autodev`. +- Renamed the entry skill from `using-superpowers` to `using-autodev`. +- Updated author metadata to Jon Langevin / `jon@gocodealone.com`. +- Updated repository references to `GoCodeAlone/autonomous-dev-kit`. +- Updated the Claude marketplace target to `GoCodeAlone/claude-marketplace`. + +### Hook and workflow hardening + +- Fixed hook JSON output to use host-compatible `hookSpecificOutput.additionalContext`. +- Added hook contract tests for SessionStart, UserPromptSubmit, PR reminders, + PreCompact snapshots, Stop-hook phase continuation, compact state rows, and + locked-plan design backports. +- Relaxed adversarial review loops so tangible issues continue driving + revisions, while nitpicks no longer keep the loop alive. +- Changed scope locks to hash only the `## Scope Manifest` block, allowing + design/backport notes without invalidating locked scope. +- Added phase-completion introspection and compressed phase-progress JSONL. + +### Design pipeline additions + +- Added `project-design-guidance` for durable project-wide design constraints. +- Added `condensed-pipeline-writing` for compact internal design/review/plan + artifacts and compact JSONL state. +- Added required security, infrastructure, and multi-component validation + checks across brainstorming, planning, adversarial review, and retros. +- Updated README and install docs with `npx skills add` commands for Claude + Code and Codex. ## v5.6.0 (2026-05-01) @@ -31,7 +65,7 @@ Three modes: Exit codes: `0` clean / `1` failures / `3` usage error. Wirable into CI. -### New invariant: strict-interpretation rule (in `using-superpowers`) +### New invariant: strict-interpretation rule (in `using-autodev`) When the autonomous pipeline is running and a user instruction is ambiguous, the agent MUST pick the **most-faithful-to-the-locked-manifest** interpretation. A table mapping common ambiguous phrases to their forbidden-loose and mandated-strict readings: @@ -53,7 +87,7 @@ When multiple strict interpretations remain plausible, the agent stops and asks. - **`finishing-a-development-branch`** — new Step 1d "Scope Completeness Check" verifies every manifest task has implementing commits and that the manifest's PR count matches reality. Autonomous mode now creates one PR per row in the PR Grouping table; collapsing is a stop-the-line error. PR body template includes a Scope Manifest section. - **`recording-decisions`** — fifth trigger condition added: user-approved scope reduction. ADR is cited from the manifest's `Status: Reduced …` line and from each PR body shipped under the reduced manifest. - **`pr-monitoring`** — autonomous mode spawns one monitor per PR (manifest-driven), not one monitor per branch. -- **`using-superpowers`** — pipeline auto-chain extended with explicit `scope-lock` step between alignment-check and subagent-driven-development. Strict-interpretation invariant added. +- **`using-autodev`** — pipeline auto-chain extended with explicit `scope-lock` step between alignment-check and subagent-driven-development. Strict-interpretation invariant added. ### Documentation @@ -92,7 +126,7 @@ Wired into `pr-monitoring`'s exit conditions. The retro is intentionally short **Skill-usage telemetry (`tests/skill-activation-audit.sh`)** -Parses `.claude/superpowers-state/in-progress.jsonl` (the activity log written by the existing `record-activity` PostToolUse hook) and reports which skills / agents fired during a session. Detects "expected but missing" pipeline gates by walking the canonical chain (brainstorming → adversarial-design-review → … → pr-monitoring). Strictly local; never transmits anything off the machine. Used directly by `post-merge-retrospective`. Exit code 2 when expected gates didn't fire so it can be wired into CI for automation runs. +Parses `.claude/autodev-state/in-progress.jsonl` (the activity log written by the existing `record-activity` PostToolUse hook) and reports which skills / agents fired during a session. Detects "expected but missing" pipeline gates by walking the canonical chain (brainstorming → adversarial-design-review → … → pr-monitoring). Strictly local; never transmits anything off the machine. Used directly by `post-merge-retrospective`. Exit code 2 when expected gates didn't fire so it can be wired into CI for automation runs. **Brainstorming cost-control gate (`skills/brainstorming/SKILL.md`)** @@ -102,7 +136,7 @@ Soft cap of 5 question-batches per brainstorming session. On exceed, the agent s New test that scans `skills/**/SKILL.md` and `agents/*.md` for cross-references and verifies they resolve: -- `/SKILL.md` paths and `superpowers:` mentions resolve to either a skills directory or an `agents/.md` file. +- `/SKILL.md` paths and `autodev:` mentions resolve to either a skills directory or an `agents/.md` file. - ` Step [a-z]?` references resolve to a heading or bold-line label in the cited skill. - Skips fenced code blocks (placeholder examples like `path/SKILL.md` inside ```code``` are not real references). @@ -197,8 +231,8 @@ Every existing review gate attacks code (`requesting-code-review`, spec-reviewer Long autonomous runs are now resilient to context compaction. Two hooks ship in `hooks/hooks.json`: -- **`SessionStart` (matcher `compact|resume`)** — re-injects a `` block into the resumed session containing the original task (extracted from the first user message in the transcript) and the last 30 superpowers activity entries. This re-anchors a compacted **subagent** to its original assignment and re-anchors the **lead orchestrator** to its place in the pipeline. The hook fires inside each session against its own transcript, so subagents recover their own task context automatically. -- **`PostToolUse` (matcher `Skill|Agent|Task.*`)** — appends each `Skill`, `Agent`, and `Task*`-family (`Task`, `TaskCreate`, `TaskList`, `TaskGet`, `TaskUpdate`, etc.) invocation to `.claude/superpowers-state/in-progress.jsonl` (capped at 200 lines; wiped on `startup|clear`, or when the session source can't be determined). Append+rotate is guarded by a `flock` when available so concurrent writes from the lead and subagents don't corrupt the JSONL. This is the activity log that the SessionStart hook replays. +- **`SessionStart` (matcher `compact|resume`)** — re-injects a `` block into the resumed session containing the original task (extracted from the first user message in the transcript) and the last 30 autodev activity entries. This re-anchors a compacted **subagent** to its original assignment and re-anchors the **lead orchestrator** to its place in the pipeline. The hook fires inside each session against its own transcript, so subagents recover their own task context automatically. +- **`PostToolUse` (matcher `Skill|Agent|Task.*`)** — appends each `Skill`, `Agent`, and `Task*`-family (`Task`, `TaskCreate`, `TaskList`, `TaskGet`, `TaskUpdate`, etc.) invocation to `.claude/autodev-state/in-progress.jsonl` (capped at 200 lines; wiped on `startup|clear`, or when the session source can't be determined). Append+rotate is guarded by a `flock` when available so concurrent writes from the lead and subagents don't corrupt the JSONL. This is the activity log that the SessionStart hook replays. The state file is project-local and in JSONL format. Both hooks no-op gracefully when `jq` is unavailable. On hosts without a documented hooks system (Codex, OpenCode), the same recovery pattern is described in prose as a manual discipline. @@ -259,7 +293,7 @@ Added autonomous mode: when invoked from the pipeline (not by user), skips the 4 When invoked from the brainstorming pipeline, skips user plan review, invokes alignment-check, and on PASS invokes subagent-driven-development automatically. Manual mode (direct invocation) preserves the existing execution choice prompt. -**`using-superpowers` pipeline documentation** +**`using-autodev` pipeline documentation** Updated Skill Priority section to document pipeline auto-chaining as item 3. "Let's build X" now explicitly routes through the autonomous pipeline after design approval. @@ -269,7 +303,7 @@ Updated Skill Priority section to document pipeline auto-chaining as item 3. "Le **Cursor support** -Superpowers now works with Cursor's plugin system. Includes a `.cursor-plugin/plugin.json` manifest and Cursor-specific installation instructions in the README. The SessionStart hook output now includes an `additional_context` field alongside the existing `hookSpecificOutput.additionalContext` for Cursor hook compatibility. +Autonomous Dev Kit now works with Cursor's plugin system. Includes a `.cursor-plugin/plugin.json` manifest and Cursor-specific installation instructions in the README. The SessionStart hook output now includes an `additional_context` field alongside the existing `hookSpecificOutput.additionalContext` for Cursor hook compatibility. ### Fixed @@ -287,7 +321,7 @@ This fixes SessionStart failures on Windows with spaces in paths, missing WSL, ` ## v4.3.0 (2026-02-12) -This fix should dramatically improve superpowers skills compliance and should reduce the chances of Claude entering its native plan mode unintentionally. +This fix should dramatically improve autodev skills compliance and should reduce the chances of Claude entering its native plan mode unintentionally. ### Changed @@ -301,7 +335,7 @@ Models were skipping the design phase and jumping straight to implementation ski - Anti-pattern callout for "this is too simple to need a design" — the exact rationalization models use to skip the process - Design section sizing based on section complexity, not project complexity -**Using-superpowers workflow graph intercepts EnterPlanMode** +**Using-autodev workflow graph intercepts EnterPlanMode** Added an `EnterPlanMode` intercept to the skill flow graph. When the model is about to enter Claude's native plan mode, it checks whether brainstorming has happened and routes through the brainstorming skill instead. Plan mode is never entered. @@ -309,7 +343,7 @@ Added an `EnterPlanMode` intercept to the skill flow graph. When the model is ab **SessionStart hook now runs synchronously** -Changed `async: true` to `async: false` in hooks.json. When async, the hook could fail to complete before the model's first turn, meaning using-superpowers instructions weren't in context for the first message. +Changed `async: true` to `async: false` in hooks.json. When async, the hook could fail to complete before the model's first turn, meaning using-autodev instructions weren't in context for the first message. ## v4.2.0 (2026-02-05) @@ -317,7 +351,7 @@ Changed `async: true` to `async: false` in hooks.json. When async, the hook coul **Codex: Replaced bootstrap CLI with native skill discovery** -The `superpowers-codex` bootstrap CLI, Windows `.cmd` wrapper, and related bootstrap content file have been removed. Codex now uses native skill discovery via `~/.agents/skills/superpowers/` symlink, so the old `use_skill`/`find_skills` CLI tools are no longer needed. +The `autodev-codex` bootstrap CLI, Windows `.cmd` wrapper, and related bootstrap content file have been removed. Codex now uses native skill discovery via `~/.agents/skills/autodev/` symlink, so the old `use_skill`/`find_skills` CLI tools are no longer needed. Installation is now just clone + symlink (documented in INSTALL.md). No Node.js dependency required. The old `~/.codex/skills/` path is deprecated. @@ -331,7 +365,7 @@ Fix: hooks.json now calls session-start.sh directly. Claude Code 2.1.x handles t **Windows: SessionStart hook runs async to prevent terminal freeze (#404, #413, #414, #419)** -The synchronous SessionStart hook blocked the TUI from entering raw mode on Windows, freezing all keyboard input. Running the hook async prevents the freeze while still injecting superpowers context. +The synchronous SessionStart hook blocked the TUI from entering raw mode on Windows, freezing all keyboard input. Running the hook async prevents the freeze while still injecting autodev context. **Windows: Fixed O(n^2) `escape_for_json` performance** @@ -339,7 +373,7 @@ The character-by-character loop using `${input:$i:1}` was O(n^2) in bash due to **Codex: Fixed Windows/PowerShell invocation (#285, #243)** -- Windows doesn't respect shebangs, so directly invoking the extensionless `superpowers-codex` script triggered an "Open with" dialog. All invocations now prefixed with `node`. +- Windows doesn't respect shebangs, so directly invoking the extensionless `autodev-codex` script triggered an "Open with" dialog. All invocations now prefixed with `node`. - Fixed `~/` path expansion on Windows — PowerShell doesn't expand `~` when passed as an argument to `node`. Changed to `$HOME` which expands correctly in both bash and PowerShell. **Codex: Fixed path resolution in installer** @@ -403,9 +437,9 @@ Changes: **OpenCode: Switched to native skills system** -Superpowers for OpenCode now uses OpenCode's native `skill` tool instead of custom `use_skill`/`find_skills` tools. This is a cleaner integration that works with OpenCode's built-in skill discovery. +Autonomous Dev Kit for OpenCode now uses OpenCode's native `skill` tool instead of custom `use_skill`/`find_skills` tools. This is a cleaner integration that works with OpenCode's built-in skill discovery. -**Migration required:** Skills must be symlinked to `~/.config/opencode/skills/superpowers/` (see updated installation docs). +**Migration required:** Skills must be symlinked to `~/.config/opencode/skills/autodev/` (see updated installation docs). ### Fixes @@ -431,7 +465,7 @@ Fix: hooks.json now calls session-start.sh directly. Claude Code 2.1.x handles t ### Improvements -**Strengthened using-superpowers skill for explicit skill requests** +**Strengthened using-autodev skill for explicit skill requests** Addressed a failure mode where Claude would skip invoking a skill even when the user explicitly requested it by name (e.g., "subagent-driven-development, please"). Claude would think "I know what that means" and start working directly instead of loading the skill. @@ -453,7 +487,7 @@ New test suite in `tests/explicit-skill-requests/` that verifies Claude correctl Added `disable-model-invocation: true` to all three slash commands (`/brainstorm`, `/execute-plan`, `/write-plan`). Claude can no longer invoke these commands via the Skill tool—they're restricted to manual user invocation only. -The underlying skills (`superpowers:brainstorming`, `superpowers:executing-plans`, `superpowers:writing-plans`) remain available for Claude to invoke autonomously. This change prevents confusion when Claude would invoke a command that just redirects to a skill anyway. +The underlying skills (`autodev:brainstorming`, `autodev:executing-plans`, `autodev:writing-plans`) remain available for Claude to invoke autonomously. This change prevents confusion when Claude would invoke a command that just redirects to a skill anyway. ## v4.0.1 (2025-12-23) @@ -461,11 +495,11 @@ The underlying skills (`superpowers:brainstorming`, `superpowers:executing-plans **Clarified how to access skills in Claude Code** -Fixed a confusing pattern where Claude would invoke a skill via the Skill tool, then try to Read the skill file separately. The `using-superpowers` skill now explicitly states that the Skill tool loads skill content directly—no need to read files. +Fixed a confusing pattern where Claude would invoke a skill via the Skill tool, then try to Read the skill file separately. The `using-autodev` skill now explicitly states that the Skill tool loads skill content directly—no need to read files. -- Added "How to Access Skills" section to `using-superpowers` +- Added "How to Access Skills" section to `using-autodev` - Changed "read the skill" → "invoke the skill" in instructions -- Updated slash commands to use fully qualified skill names (e.g., `superpowers:brainstorming`) +- Updated slash commands to use fully qualified skill names (e.g., `autodev:brainstorming`) **Added GitHub thread reply guidance to receiving-code-review** (h/t @ralphbean) @@ -537,7 +571,7 @@ Rewrote key skills using DOT/GraphViz flowcharts as the authoritative process de **The Description Trap** (documented in `writing-skills`): Discovered that skill descriptions override flowchart content when descriptions contain workflow summaries. Claude follows the short description instead of reading the detailed flowchart. Fix: descriptions must be trigger-only ("Use when X") with no process details. -**Skill priority in using-superpowers** +**Skill priority in using-autodev** When multiple skills apply, process skills (brainstorming, debugging) now explicitly come before implementation skills. "Build X" triggers brainstorming first, then domain skills. @@ -556,7 +590,7 @@ Description changed to imperative: "You MUST use this before any creative work ### Other Improvements - **render-graphs.js** - Tool to extract DOT diagrams from skills and render to SVG -- **Rationalizations table** in using-superpowers - Scannable format including new entries: "I need more context first", "Let me explore first", "This feels productive" +- **Rationalizations table** in using-autodev - Scannable format including new entries: "I need more context first", "Let me explore first", "This feels productive" - **docs/testing.md** - Guide to testing skills with Claude Code integration tests --- @@ -578,7 +612,7 @@ Description changed to imperative: "You MUST use this before any creative work - **OpenCode Bootstrap Refactor**: Switched from `chat.message` hook to `session.created` event for bootstrap injection - Bootstrap now injects at session creation via `session.prompt()` with `noReply: true` - - Explicitly tells the model that using-superpowers is already loaded to prevent redundant skill loading + - Explicitly tells the model that using-autodev is already loaded to prevent redundant skill loading - Consolidated bootstrap content generation into shared `getBootstrapContent()` helper - Cleaner single-implementation approach (removed fallback pattern) @@ -593,7 +627,7 @@ Description changed to imperative: "You MUST use this before any creative work - Message insertion pattern for skill persistence across context compaction - Automatic context injection via chat.message hook - Auto re-injection on session.compacted events - - Three-tier skill priority: project > personal > superpowers + - Three-tier skill priority: project > personal > autodev - Project-local skills support (`.opencode/skills/`) - Shared core module (`lib/skills-core.js`) for code reuse with Codex - Automated test suite with proper isolation (`tests/opencode/`) @@ -618,7 +652,7 @@ Description changed to imperative: "You MUST use this before any creative work ### Improvements -- Optimized superpowers bootstrap to eliminate redundant skill execution. The `using-superpowers` skill content is now provided directly in session context, with clear guidance to use the Skill tool only for other skills. This reduces overhead and prevents the confusing loop where agents would execute `using-superpowers` manually despite already having the content from session start. +- Optimized autodev bootstrap to eliminate redundant skill execution. The `using-autodev` skill content is now provided directly in session context, with clear guidance to use the Skill tool only for other skills. This reduces overhead and prevents the confusing loop where agents would execute `using-autodev` manually despite already having the content from session start. ## v3.4.0 (2025-10-30) @@ -642,10 +676,10 @@ Description changed to imperative: "You MUST use this before any creative work ### New Features **Experimental Codex Support** -- Added unified `superpowers-codex` script with bootstrap/use-skill/find-skills commands +- Added unified `autodev-codex` script with bootstrap/use-skill/find-skills commands - Cross-platform Node.js implementation (works on Windows, macOS, Linux) -- Namespaced skills: `superpowers:skill-name` for superpowers skills, `skill-name` for personal -- Personal skills override superpowers skills when names match +- Namespaced skills: `autodev:skill-name` for autodev skills, `skill-name` for personal +- Personal skills override autodev skills when names match - Clean skill display: shows name/description without raw frontmatter - Helpful context: shows supporting files directory for each skill - Tool mapping for Codex: TodoWrite→update_plan, subagents→manual fallback, etc. @@ -656,20 +690,20 @@ Description changed to imperative: "You MUST use this before any creative work - Single unified script instead of separate tools - Tool substitution system for Codex-specific equivalents - Simplified subagent handling (manual work instead of delegation) -- Updated terminology: "Superpowers skills" instead of "Core skills" +- Updated terminology: "Autonomous Dev Kit skills" instead of "Core skills" ### Files Added - `.codex/INSTALL.md` - Installation guide for Codex users -- `.codex/superpowers-bootstrap.md` - Bootstrap instructions with Codex adaptations -- `.codex/superpowers-codex` - Unified Node.js executable with all functionality +- `.codex/autodev-bootstrap.md` - Bootstrap instructions with Codex adaptations +- `.codex/autodev-codex` - Unified Node.js executable with all functionality -**Note:** Codex support is experimental. The integration provides core superpowers functionality but may require refinement based on user feedback. +**Note:** Codex support is experimental. The integration provides core autodev functionality but may require refinement based on user feedback. ## v3.2.3 (2025-10-23) ### Improvements -**Updated using-superpowers skill to use Skill tool instead of Read tool** +**Updated using-autodev skill to use Skill tool instead of Read tool** - Changed skill invocation instructions from Read tool to Skill tool - Updated description: "using Read tool" → "using Skill tool" - Updated step 3: "Use the Read tool" → "Use the Skill tool to read and run" @@ -678,13 +712,13 @@ Description changed to imperative: "You MUST use this before any creative work The Skill tool is the proper mechanism for invoking skills in Claude Code. This update corrects the bootstrap instructions to guide agents toward the correct tool. ### Files Changed -- Updated: `skills/using-superpowers/SKILL.md` - Changed tool references from Read to Skill +- Updated: `skills/using-autodev/SKILL.md` - Changed tool references from Read to Skill ## v3.2.2 (2025-10-21) ### Improvements -**Strengthened using-superpowers skill against agent rationalization** +**Strengthened using-autodev skill against agent rationalization** - Added EXTREMELY-IMPORTANT block with absolute language about mandatory skill checking - "If even 1% chance a skill applies, you MUST read it" - "You do not have a choice. You cannot rationalize your way out." @@ -700,23 +734,23 @@ The Skill tool is the proper mechanism for invoking skills in Claude Code. This These changes address observed agent behavior where they rationalize around skill usage despite clear instructions. The forceful language and pre-emptive counter-arguments aim to make non-compliance harder. ### Files Changed -- Updated: `skills/using-superpowers/SKILL.md` - Added three layers of enforcement to prevent skill-skipping rationalization +- Updated: `skills/using-autodev/SKILL.md` - Added three layers of enforcement to prevent skill-skipping rationalization ## v3.2.1 (2025-10-20) ### New Features **Code reviewer agent now included in plugin** -- Added `superpowers:code-reviewer` agent to plugin's `agents/` directory +- Added `autodev:code-reviewer` agent to plugin's `agents/` directory - Agent provides systematic code review against plans and coding standards - Previously required users to have personal agent configuration -- All skill references updated to use namespaced `superpowers:code-reviewer` +- All skill references updated to use namespaced `autodev:code-reviewer` - Fixes #55 ### Files Changed - New: `agents/code-reviewer.md` - Agent definition with review checklist and output format -- Updated: `skills/requesting-code-review/SKILL.md` - References to `superpowers:code-reviewer` -- Updated: `skills/subagent-driven-development/SKILL.md` - References to `superpowers:code-reviewer` +- Updated: `skills/requesting-code-review/SKILL.md` - References to `autodev:code-reviewer` +- Updated: `skills/subagent-driven-development/SKILL.md` - References to `autodev:code-reviewer` ## v3.2.0 (2025-10-18) @@ -732,8 +766,8 @@ These changes address observed agent behavior where they rationalize around skil ### Breaking Changes **Skill reference namespace standardization** -- All internal skill references now use `superpowers:` namespace prefix -- Updated format: `superpowers:test-driven-development` (previously just `test-driven-development`) +- All internal skill references now use `autodev:` namespace prefix +- Updated format: `autodev:test-driven-development` (previously just `test-driven-development`) - Affects all REQUIRED SUB-SKILL, RECOMMENDED SUB-SKILL, and REQUIRED BACKGROUND references - Aligns with how skills are invoked using the Skill tool - Files updated: brainstorming, executing-plans, subagent-driven-development, systematic-debugging, testing-skills-with-subagents, writing-plans, writing-skills @@ -749,7 +783,7 @@ These changes address observed agent behavior where they rationalize around skil ### Bug Fixes -- **Fixed command syntax in README** (#44) - Updated all command references to use correct namespaced syntax (`/superpowers:brainstorm` instead of `/brainstorm`). Plugin-provided commands are automatically namespaced by Claude Code to avoid conflicts between plugins. +- **Fixed command syntax in README** (#44) - Updated all command references to use correct namespaced syntax (`/autodev:brainstorm` instead of `/brainstorm`). Plugin-provided commands are automatically namespaced by Claude Code to avoid conflicts between plugins. ## v3.1.0 (2025-10-17) @@ -832,13 +866,13 @@ We now use Anthropic's first-party skills system! --- -# Superpowers v2.0.0 Release Notes +# Autonomous Dev Kit v2.0.0 Release Notes ## Overview -Superpowers v2.0 makes skills more accessible, maintainable, and community-driven through a major architectural shift. +Autonomous Dev Kit v2.0 makes skills more accessible, maintainable, and community-driven through a major architectural shift. -The headline change is **skills repository separation**: all skills, scripts, and documentation have moved from the plugin into a dedicated repository ([obra/superpowers-skills](https://github.com/obra/superpowers-skills)). This transforms superpowers from a monolithic plugin into a lightweight shim that manages a local clone of the skills repository. Skills auto-update on session start. Users fork and contribute improvements via standard git workflows. The skills library versions independently from the plugin. +The headline change is **skills repository separation**: all skills, scripts, and documentation have moved from the plugin into a dedicated repository ([GoCodeAlone/autonomous-dev-kit-skills](https://github.com/GoCodeAlone/autonomous-dev-kit-skills)). This transforms autodev from a monolithic plugin into a lightweight shim that manages a local clone of the skills repository. Skills auto-update on session start. Users fork and contribute improvements via standard git workflows. The skills library versions independently from the plugin. Beyond infrastructure, this release adds nine new skills focused on problem-solving, research, and architecture. We rewrote the core **using-skills** documentation with imperative tone and clearer structure, making it easier for Claude to understand when and how to use skills. **find-skills** now outputs paths you can paste directly into the Read tool, eliminating friction in the skills discovery workflow. @@ -848,11 +882,11 @@ Users experience seamless operation: the plugin handles cloning, forking, and up ### Skills Repository Separation -**The biggest change:** Skills no longer live in the plugin. They've been moved to a separate repository at [obra/superpowers-skills](https://github.com/obra/superpowers-skills). +**The biggest change:** Skills no longer live in the plugin. They've been moved to a separate repository at [GoCodeAlone/autonomous-dev-kit-skills](https://github.com/GoCodeAlone/autonomous-dev-kit-skills). **What this means for you:** -- **First install:** Plugin automatically clones skills to `~/.config/superpowers/skills/` +- **First install:** Plugin automatically clones skills to `~/.config/autodev/skills/` - **Forking:** During setup, you'll be offered the option to fork the skills repo (if `gh` is installed) - **Updates:** Skills auto-update on session start (fast-forward when possible) - **Contributing:** Work on branches, commit locally, submit PRs to upstream @@ -861,21 +895,21 @@ Users experience seamless operation: the plugin handles cloning, forking, and up **Migration:** If you have an existing installation: -1. Your old `~/.config/superpowers/.git` will be backed up to `~/.config/superpowers/.git.bak` -2. Old skills will be backed up to `~/.config/superpowers/skills.bak` -3. Fresh clone of obra/superpowers-skills will be created at `~/.config/superpowers/skills/` +1. Your old `~/.config/autodev/.git` will be backed up to `~/.config/autodev/.git.bak` +2. Old skills will be backed up to `~/.config/autodev/skills.bak` +3. Fresh clone of GoCodeAlone/autonomous-dev-kit-skills will be created at `~/.config/autodev/skills/` ### Removed Features -- **Personal superpowers overlay system** - Replaced with git branch workflow -- **setup-personal-superpowers hook** - Replaced by initialize-skills.sh +- **Personal autodev overlay system** - Replaced with git branch workflow +- **setup-personal-autodev hook** - Replaced by initialize-skills.sh ## New Features ### Skills Repository Infrastructure **Automatic Clone & Setup** (`lib/initialize-skills.sh`) -- Clones obra/superpowers-skills on first run +- Clones GoCodeAlone/autonomous-dev-kit-skills on first run - Offers fork creation if GitHub CLI is installed - Sets up upstream/origin remotes correctly - Handles migration from old installation @@ -946,21 +980,21 @@ If you have an existing installation: - Moved "skills behind" warning to end of output **Environment Variables** -- `SUPERPOWERS_SKILLS_ROOT` set to `~/.config/superpowers/skills` +- `SUPERPOWERS_SKILLS_ROOT` set to `~/.config/autodev/skills` - Used consistently throughout all paths ## Bug Fixes - Fixed duplicate upstream remote addition when forking - Fixed find-skills double "skills/" prefix in output -- Removed obsolete setup-personal-superpowers call from session-start +- Removed obsolete setup-personal-autodev call from session-start - Fixed path references throughout hooks and commands ## Documentation ### README - Updated for new skills repository architecture -- Prominent link to superpowers-skills repo +- Prominent link to autodev-skills repo - Updated auto-update description - Fixed skill names and references - Updated Meta skills list @@ -980,12 +1014,12 @@ If you have an existing installation: - `.claude-plugin/marketplace.json` - Local testing config **Removed:** -- `skills/` directory (82 files) - Now in obra/superpowers-skills -- `scripts/` directory - Now in obra/superpowers-skills/skills/using-skills/ -- `hooks/setup-personal-superpowers.sh` - Obsolete +- `skills/` directory (82 files) - Now in GoCodeAlone/autonomous-dev-kit-skills +- `scripts/` directory - Now in GoCodeAlone/autonomous-dev-kit-skills/skills/using-skills/ +- `hooks/setup-personal-autodev.sh` - Obsolete **Modified:** -- `hooks/session-start.sh` - Use skills from ~/.config/superpowers/skills +- `hooks/session-start.sh` - Use skills from ~/.config/autodev/skills - `commands/brainstorm.md` - Updated paths to SUPERPOWERS_SKILLS_ROOT - `commands/write-plan.md` - Updated paths to SUPERPOWERS_SKILLS_ROOT - `commands/execute-plan.md` - Updated paths to SUPERPOWERS_SKILLS_ROOT @@ -996,7 +1030,7 @@ If you have an existing installation: This release includes: - 20+ commits for skills repository separation - PR #1: Amplifier-inspired problem-solving and research skills -- PR #2: Personal superpowers overlay system (later replaced) +- PR #2: Personal autodev overlay system (later replaced) - Multiple skill refinements and documentation improvements ## Upgrade Instructions @@ -1005,8 +1039,8 @@ This release includes: ```bash # In Claude Code -/plugin marketplace add obra/superpowers-marketplace -/plugin install superpowers@superpowers-marketplace +/plugin marketplace add GoCodeAlone/claude-marketplace +/plugin install autodev@claude-marketplace ``` The plugin handles everything automatically. @@ -1015,12 +1049,12 @@ The plugin handles everything automatically. 1. **Backup your personal skills** (if you have any): ```bash - cp -r ~/.config/superpowers/skills ~/superpowers-skills-backup + cp -r ~/.config/autodev/skills ~/autodev-skills-backup ``` 2. **Update the plugin:** ```bash - /plugin update superpowers + /plugin update autodev ``` 3. **On next session start:** @@ -1044,7 +1078,7 @@ The plugin handles everything automatically. ### For Contributors -- Skills repository is now at https://github.com/obra/superpowers-skills +- Skills repository is now at https://github.com/GoCodeAlone/autonomous-dev-kit-skills - Fork → Branch → PR workflow - See skills/meta/writing-skills/SKILL.md for TDD approach to documentation @@ -1060,6 +1094,6 @@ None at this time. --- -**Full Changelog:** https://github.com/obra/superpowers/compare/dd013f6...main -**Skills Repository:** https://github.com/obra/superpowers-skills -**Issues:** https://github.com/obra/superpowers/issues +**Full Changelog:** https://github.com/GoCodeAlone/autonomous-dev-kit/compare/dd013f6...main +**Skills Repository:** https://github.com/GoCodeAlone/autonomous-dev-kit-skills +**Issues:** https://github.com/GoCodeAlone/autonomous-dev-kit/issues diff --git a/commands/brainstorm.md b/commands/brainstorm.md index 0fb3a89..035f33f 100644 --- a/commands/brainstorm.md +++ b/commands/brainstorm.md @@ -3,4 +3,4 @@ description: "You MUST use this before any creative work - creating features, bu disable-model-invocation: true --- -Invoke the superpowers:brainstorming skill and follow it exactly as presented to you +Invoke the autodev:brainstorming skill and follow it exactly as presented to you diff --git a/commands/execute-plan.md b/commands/execute-plan.md index c48f140..dc41658 100644 --- a/commands/execute-plan.md +++ b/commands/execute-plan.md @@ -3,4 +3,4 @@ description: Execute plan in batches with review checkpoints disable-model-invocation: true --- -Invoke the superpowers:executing-plans skill and follow it exactly as presented to you +Invoke the autodev:executing-plans skill and follow it exactly as presented to you diff --git a/commands/write-plan.md b/commands/write-plan.md index 12962fd..1a0fd03 100644 --- a/commands/write-plan.md +++ b/commands/write-plan.md @@ -3,4 +3,4 @@ description: Create detailed implementation plan with bite-sized tasks disable-model-invocation: true --- -Invoke the superpowers:writing-plans skill and follow it exactly as presented to you +Invoke the autodev:writing-plans skill and follow it exactly as presented to you diff --git a/docs/README.codex.md b/docs/README.codex.md index c098b72..e0da981 100644 --- a/docs/README.codex.md +++ b/docs/README.codex.md @@ -1,13 +1,27 @@ -# Superpowers for Codex +# Autonomous Dev Kit for Codex -Guide for using Superpowers with OpenAI Codex via native skill discovery. +Guide for using Autonomous Dev Kit with OpenAI Codex via native skill discovery. ## Quick Install -Tell Codex: +From your project root: + +```bash +npx skills add GoCodeAlone/autonomous-dev-kit -a codex --skill '*' -y +``` + +For user/global install: + +```bash +npx skills add GoCodeAlone/autonomous-dev-kit -a codex --skill '*' -g -y +``` + +Restart Codex after install. + +Manual fallback: tell Codex: ``` -Fetch and follow instructions from https://raw.githubusercontent.com/GoCodeAlone/claude-superpowers/refs/heads/main/.codex/INSTALL.md +Fetch and follow instructions from https://raw.githubusercontent.com/GoCodeAlone/autonomous-dev-kit/refs/heads/main/.codex/INSTALL.md ``` ## Manual Installation @@ -16,18 +30,19 @@ Fetch and follow instructions from https://raw.githubusercontent.com/GoCodeAlone - OpenAI Codex CLI - Git +- Node.js 18+ if using `npx skills add` ### Steps 1. Clone the repo: ```bash - git clone https://github.com/GoCodeAlone/claude-superpowers.git ~/.codex/superpowers + git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git ~/.codex/autodev ``` 2. Create the skills symlink: ```bash mkdir -p ~/.agents/skills - ln -s ~/.codex/superpowers/skills ~/.agents/skills/superpowers + ln -s ~/.codex/autodev/skills ~/.agents/skills/autodev ``` 3. Restart Codex. @@ -38,25 +53,25 @@ Use a junction instead of a symlink (works without Developer Mode): ```powershell New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.agents\skills" -cmd /c mklink /J "$env:USERPROFILE\.agents\skills\superpowers" "$env:USERPROFILE\.codex\superpowers\skills" +cmd /c mklink /J "$env:USERPROFILE\.agents\skills\autodev" "$env:USERPROFILE\.codex\autodev\skills" ``` ## How It Works -Codex has native skill discovery — it scans `~/.agents/skills/` at startup, parses SKILL.md frontmatter, and loads skills on demand. Superpowers skills are made visible through a single symlink: +Codex has native skill discovery — it scans `~/.agents/skills/` at startup, parses SKILL.md frontmatter, and loads skills on demand. Autonomous Dev Kit skills are made visible through a single symlink: ``` -~/.agents/skills/superpowers/ → ~/.codex/superpowers/skills/ +~/.agents/skills/autodev/ → ~/.codex/autodev/skills/ ``` -The `using-superpowers` skill is discovered automatically and enforces skill usage discipline — no additional configuration needed. +The `using-autodev` skill is discovered automatically and enforces skill usage discipline — no additional configuration needed. ## Usage Skills are discovered automatically. Codex activates them when: - You mention a skill by name (e.g., "use brainstorming") - The task matches a skill's description -- The `using-superpowers` skill directs Codex to use one +- The `using-autodev` skill directs Codex to use one ### Personal Skills @@ -84,7 +99,7 @@ The `description` field is how Codex decides when to activate a skill automatica ## Updating ```bash -cd ~/.codex/superpowers && git pull +cd ~/.codex/autodev && git pull ``` Skills update instantly through the symlink. @@ -92,22 +107,22 @@ Skills update instantly through the symlink. ## Uninstalling ```bash -rm ~/.agents/skills/superpowers +rm ~/.agents/skills/autodev ``` **Windows (PowerShell):** ```powershell -Remove-Item "$env:USERPROFILE\.agents\skills\superpowers" +Remove-Item "$env:USERPROFILE\.agents\skills\autodev" ``` -Optionally delete the clone: `rm -rf ~/.codex/superpowers` (Windows: `Remove-Item -Recurse -Force "$env:USERPROFILE\.codex\superpowers"`). +Optionally delete the clone: `rm -rf ~/.codex/autodev` (Windows: `Remove-Item -Recurse -Force "$env:USERPROFILE\.codex\autodev"`). ## Troubleshooting ### Skills not showing up -1. Verify the symlink: `ls -la ~/.agents/skills/superpowers` -2. Check skills exist: `ls ~/.codex/superpowers/skills` +1. Verify the symlink: `ls -la ~/.agents/skills/autodev` +2. Check skills exist: `ls ~/.codex/autodev/skills` 3. Restart Codex — skills are discovered at startup ### Windows junction issues @@ -116,7 +131,7 @@ Junctions normally work without special permissions. If creation fails, try runn ## Cross-LLM Behavior -Superpowers skills use `` blocks to gate content that only applies to Claude Code (Agent Teams, specific tool names, etc.). On Codex, those blocks are skipped — the rest of the skill runs as-is. +Autonomous Dev Kit skills use `` blocks to gate content that only applies to Claude Code (Agent Teams, specific tool names, etc.). On Codex, those blocks are skipped — the rest of the skill runs as-is. To let skills detect that they are running on Codex, add a host declaration to your `~/.codex/AGENTS.md`: @@ -128,5 +143,5 @@ This single line enables host-conditional skill logic. See `.codex/INSTALL.md` f ## Getting Help -- Report issues: https://github.com/GoCodeAlone/claude-superpowers/issues -- Main documentation: https://github.com/GoCodeAlone/claude-superpowers +- Report issues: https://github.com/GoCodeAlone/autonomous-dev-kit/issues +- Main documentation: https://github.com/GoCodeAlone/autonomous-dev-kit diff --git a/docs/README.opencode.md b/docs/README.opencode.md index ba3bd91..1f08d97 100644 --- a/docs/README.opencode.md +++ b/docs/README.opencode.md @@ -1,13 +1,13 @@ -# Superpowers for OpenCode +# Autonomous Dev Kit for OpenCode -Complete guide for using Superpowers with [OpenCode.ai](https://opencode.ai). +Complete guide for using Autonomous Dev Kit with [OpenCode.ai](https://opencode.ai). ## Quick Install Tell OpenCode: ``` -Clone https://github.com/GoCodeAlone/claude-superpowers to ~/.config/opencode/superpowers, then create directory ~/.config/opencode/plugins, then symlink ~/.config/opencode/superpowers/.opencode/plugins/superpowers.js to ~/.config/opencode/plugins/superpowers.js, then symlink ~/.config/opencode/superpowers/skills to ~/.config/opencode/skills/superpowers, then restart opencode. +Clone https://github.com/GoCodeAlone/autonomous-dev-kit to ~/.config/opencode/autodev, then create directory ~/.config/opencode/plugins, then symlink ~/.config/opencode/autodev/.opencode/plugins/autodev.js to ~/.config/opencode/plugins/autodev.js, then symlink ~/.config/opencode/autodev/skills to ~/.config/opencode/skills/autodev, then restart opencode. ``` ## Manual Installation @@ -20,23 +20,23 @@ Clone https://github.com/GoCodeAlone/claude-superpowers to ~/.config/opencode/su ### macOS / Linux ```bash -# 1. Install Superpowers (or update existing) -if [ -d ~/.config/opencode/superpowers ]; then - cd ~/.config/opencode/superpowers && git pull +# 1. Install Autonomous Dev Kit (or update existing) +if [ -d ~/.config/opencode/autodev ]; then + cd ~/.config/opencode/autodev && git pull else - git clone https://github.com/GoCodeAlone/claude-superpowers.git ~/.config/opencode/superpowers + git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git ~/.config/opencode/autodev fi # 2. Create directories mkdir -p ~/.config/opencode/plugins ~/.config/opencode/skills # 3. Remove old symlinks/directories if they exist -rm -f ~/.config/opencode/plugins/superpowers.js -rm -rf ~/.config/opencode/skills/superpowers +rm -f ~/.config/opencode/plugins/autodev.js +rm -rf ~/.config/opencode/skills/autodev # 4. Create symlinks -ln -s ~/.config/opencode/superpowers/.opencode/plugins/superpowers.js ~/.config/opencode/plugins/superpowers.js -ln -s ~/.config/opencode/superpowers/skills ~/.config/opencode/skills/superpowers +ln -s ~/.config/opencode/autodev/.opencode/plugins/autodev.js ~/.config/opencode/plugins/autodev.js +ln -s ~/.config/opencode/autodev/skills ~/.config/opencode/skills/autodev # 5. Restart OpenCode ``` @@ -44,11 +44,11 @@ ln -s ~/.config/opencode/superpowers/skills ~/.config/opencode/skills/superpower #### Verify Installation ```bash -ls -l ~/.config/opencode/plugins/superpowers.js -ls -l ~/.config/opencode/skills/superpowers +ls -l ~/.config/opencode/plugins/autodev.js +ls -l ~/.config/opencode/skills/autodev ``` -Both should show symlinks pointing to the superpowers directory. +Both should show symlinks pointing to the autodev directory. ### Windows @@ -65,22 +65,22 @@ Pick your shell below: [Command Prompt](#command-prompt) | [PowerShell](#powersh Run as Administrator, or with Developer Mode enabled: ```cmd -:: 1. Install Superpowers -git clone https://github.com/GoCodeAlone/claude-superpowers.git "%USERPROFILE%\.config\opencode\superpowers" +:: 1. Install Autonomous Dev Kit +git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git "%USERPROFILE%\.config\opencode\autodev" :: 2. Create directories mkdir "%USERPROFILE%\.config\opencode\plugins" 2>nul mkdir "%USERPROFILE%\.config\opencode\skills" 2>nul :: 3. Remove existing links (safe for reinstalls) -del "%USERPROFILE%\.config\opencode\plugins\superpowers.js" 2>nul -rmdir "%USERPROFILE%\.config\opencode\skills\superpowers" 2>nul +del "%USERPROFILE%\.config\opencode\plugins\autodev.js" 2>nul +rmdir "%USERPROFILE%\.config\opencode\skills\autodev" 2>nul :: 4. Create plugin symlink (requires Developer Mode or Admin) -mklink "%USERPROFILE%\.config\opencode\plugins\superpowers.js" "%USERPROFILE%\.config\opencode\superpowers\.opencode\plugins\superpowers.js" +mklink "%USERPROFILE%\.config\opencode\plugins\autodev.js" "%USERPROFILE%\.config\opencode\autodev\.opencode\plugins\autodev.js" :: 5. Create skills junction (works without special privileges) -mklink /J "%USERPROFILE%\.config\opencode\skills\superpowers" "%USERPROFILE%\.config\opencode\superpowers\skills" +mklink /J "%USERPROFILE%\.config\opencode\skills\autodev" "%USERPROFILE%\.config\opencode\autodev\skills" :: 6. Restart OpenCode ``` @@ -90,22 +90,22 @@ mklink /J "%USERPROFILE%\.config\opencode\skills\superpowers" "%USERPROFILE%\.co Run as Administrator, or with Developer Mode enabled: ```powershell -# 1. Install Superpowers -git clone https://github.com/GoCodeAlone/claude-superpowers.git "$env:USERPROFILE\.config\opencode\superpowers" +# 1. Install Autonomous Dev Kit +git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git "$env:USERPROFILE\.config\opencode\autodev" # 2. Create directories New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.config\opencode\plugins" New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.config\opencode\skills" # 3. Remove existing links (safe for reinstalls) -Remove-Item "$env:USERPROFILE\.config\opencode\plugins\superpowers.js" -Force -ErrorAction SilentlyContinue -Remove-Item "$env:USERPROFILE\.config\opencode\skills\superpowers" -Force -ErrorAction SilentlyContinue +Remove-Item "$env:USERPROFILE\.config\opencode\plugins\autodev.js" -Force -ErrorAction SilentlyContinue +Remove-Item "$env:USERPROFILE\.config\opencode\skills\autodev" -Force -ErrorAction SilentlyContinue # 4. Create plugin symlink (requires Developer Mode or Admin) -New-Item -ItemType SymbolicLink -Path "$env:USERPROFILE\.config\opencode\plugins\superpowers.js" -Target "$env:USERPROFILE\.config\opencode\superpowers\.opencode\plugins\superpowers.js" +New-Item -ItemType SymbolicLink -Path "$env:USERPROFILE\.config\opencode\plugins\autodev.js" -Target "$env:USERPROFILE\.config\opencode\autodev\.opencode\plugins\autodev.js" # 5. Create skills junction (works without special privileges) -New-Item -ItemType Junction -Path "$env:USERPROFILE\.config\opencode\skills\superpowers" -Target "$env:USERPROFILE\.config\opencode\superpowers\skills" +New-Item -ItemType Junction -Path "$env:USERPROFILE\.config\opencode\skills\autodev" -Target "$env:USERPROFILE\.config\opencode\autodev\skills" # 6. Restart OpenCode ``` @@ -115,21 +115,21 @@ New-Item -ItemType Junction -Path "$env:USERPROFILE\.config\opencode\skills\supe Note: Git Bash's native `ln` command copies files instead of creating symlinks. Use `cmd //c mklink` instead (the `//c` is Git Bash syntax for `/c`). ```bash -# 1. Install Superpowers -git clone https://github.com/GoCodeAlone/claude-superpowers.git ~/.config/opencode/superpowers +# 1. Install Autonomous Dev Kit +git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git ~/.config/opencode/autodev # 2. Create directories mkdir -p ~/.config/opencode/plugins ~/.config/opencode/skills # 3. Remove existing links (safe for reinstalls) -rm -f ~/.config/opencode/plugins/superpowers.js 2>/dev/null -rm -rf ~/.config/opencode/skills/superpowers 2>/dev/null +rm -f ~/.config/opencode/plugins/autodev.js 2>/dev/null +rm -rf ~/.config/opencode/skills/autodev 2>/dev/null # 4. Create plugin symlink (requires Developer Mode or Admin) -cmd //c "mklink \"$(cygpath -w ~/.config/opencode/plugins/superpowers.js)\" \"$(cygpath -w ~/.config/opencode/superpowers/.opencode/plugins/superpowers.js)\"" +cmd //c "mklink \"$(cygpath -w ~/.config/opencode/plugins/autodev.js)\" \"$(cygpath -w ~/.config/opencode/autodev/.opencode/plugins/autodev.js)\"" # 5. Create skills junction (works without special privileges) -cmd //c "mklink /J \"$(cygpath -w ~/.config/opencode/skills/superpowers)\" \"$(cygpath -w ~/.config/opencode/superpowers/skills)\"" +cmd //c "mklink /J \"$(cygpath -w ~/.config/opencode/skills/autodev)\" \"$(cygpath -w ~/.config/opencode/autodev/skills)\"" # 6. Restart OpenCode ``` @@ -181,7 +181,7 @@ use skill tool to list skills Use OpenCode's native `skill` tool to load a specific skill: ``` -use skill tool to load superpowers/brainstorming +use skill tool to load autodev/brainstorming ``` ### Personal Skills @@ -233,17 +233,17 @@ OpenCode discovers skills from these locations: 1. **Project skills** (`.opencode/skills/`) - Highest priority 2. **Personal skills** (`~/.config/opencode/skills/`) -3. **Superpowers skills** (`~/.config/opencode/skills/superpowers/`) - via symlink +3. **Autonomous Dev Kit skills** (`~/.config/opencode/skills/autodev/`) - via symlink ## Features ### Automatic Context Injection -The plugin automatically injects superpowers context via the `experimental.chat.system.transform` hook. This adds the "using-superpowers" skill content to the system prompt on every request. +The plugin automatically injects autodev context via the `experimental.chat.system.transform` hook. This adds the "using-autodev" skill content to the system prompt on every request. ### Native Skills Integration -Superpowers uses OpenCode's native `skill` tool for skill discovery and loading. Skills are symlinked into `~/.config/opencode/skills/superpowers/` so they appear alongside your personal and project skills. +Autonomous Dev Kit uses OpenCode's native `skill` tool for skill discovery and loading. Skills are symlinked into `~/.config/opencode/skills/autodev/` so they appear alongside your personal and project skills. ### Tool Mapping @@ -258,22 +258,22 @@ Skills written for Claude Code are automatically adapted for OpenCode. The boots ### Plugin Structure -**Location:** `~/.config/opencode/superpowers/.opencode/plugins/superpowers.js` +**Location:** `~/.config/opencode/autodev/.opencode/plugins/autodev.js` **Components:** - `experimental.chat.system.transform` hook for bootstrap injection -- Reads and injects the "using-superpowers" skill content +- Reads and injects the "using-autodev" skill content ### Skills -**Location:** `~/.config/opencode/skills/superpowers/` (symlink to `~/.config/opencode/superpowers/skills/`) +**Location:** `~/.config/opencode/skills/autodev/` (symlink to `~/.config/opencode/autodev/skills/`) Skills are discovered by OpenCode's native skill system. Each skill has a `SKILL.md` file with YAML frontmatter. ## Updating ```bash -cd ~/.config/opencode/superpowers +cd ~/.config/opencode/autodev git pull ``` @@ -283,14 +283,14 @@ Restart OpenCode to load the updates. ### Plugin not loading -1. Check plugin exists: `ls ~/.config/opencode/superpowers/.opencode/plugins/superpowers.js` +1. Check plugin exists: `ls ~/.config/opencode/autodev/.opencode/plugins/autodev.js` 2. Check symlink/junction: `ls -l ~/.config/opencode/plugins/` (macOS/Linux) or `dir /AL %USERPROFILE%\.config\opencode\plugins` (Windows) 3. Check OpenCode logs: `opencode run "test" --print-logs --log-level DEBUG` 4. Look for plugin loading message in logs ### Skills not found -1. Verify skills symlink: `ls -l ~/.config/opencode/skills/superpowers` (should point to superpowers/skills/) +1. Verify skills symlink: `ls -l ~/.config/opencode/skills/autodev` (should point to autodev/skills/) 2. Use OpenCode's `skill` tool to list available skills 3. Check skill structure: each skill needs a `SKILL.md` file with valid frontmatter @@ -302,13 +302,13 @@ If you see `Cannot find module` errors on Windows: ### Bootstrap not appearing -1. Verify using-superpowers skill exists: `ls ~/.config/opencode/superpowers/skills/using-superpowers/SKILL.md` +1. Verify using-autodev skill exists: `ls ~/.config/opencode/autodev/skills/using-autodev/SKILL.md` 2. Check OpenCode version supports `experimental.chat.system.transform` hook 3. Restart OpenCode after plugin changes ## Cross-LLM Behavior -Superpowers skills use `` blocks to gate content that only applies to Claude Code (Agent Teams, specific tool names, etc.). On OpenCode, those blocks are skipped — the rest of the skill runs as-is. +Autonomous Dev Kit skills use `` blocks to gate content that only applies to Claude Code (Agent Teams, specific tool names, etc.). On OpenCode, those blocks are skipped — the rest of the skill runs as-is. To let skills detect that they are running on OpenCode, add a host declaration to your `~/.config/opencode/AGENTS.md`: @@ -320,8 +320,8 @@ This single line enables host-conditional skill logic. See `.opencode/INSTALL.md ## Getting Help -- Report issues: https://github.com/GoCodeAlone/claude-superpowers/issues -- Main documentation: https://github.com/GoCodeAlone/claude-superpowers +- Report issues: https://github.com/GoCodeAlone/autonomous-dev-kit/issues +- Main documentation: https://github.com/GoCodeAlone/autonomous-dev-kit - OpenCode docs: https://opencode.ai/docs/ ## Testing @@ -330,13 +330,13 @@ Verify your installation: ```bash # Check plugin loads -opencode run --print-logs "hello" 2>&1 | grep -i superpowers +opencode run --print-logs "hello" 2>&1 | grep -i autodev # Check skills are discoverable -opencode run "use skill tool to list all skills" 2>&1 | grep -i superpowers +opencode run "use skill tool to list all skills" 2>&1 | grep -i autodev # Check bootstrap injection -opencode run "what superpowers do you have?" +opencode run "what autodev do you have?" ``` -The agent should mention having superpowers and be able to list skills from `superpowers/`. +The agent should mention having autodev and be able to list skills from `autodev/`. diff --git a/docs/cross-llm-coverage.md b/docs/cross-llm-coverage.md index a107232..64e5dbf 100644 --- a/docs/cross-llm-coverage.md +++ b/docs/cross-llm-coverage.md @@ -1,12 +1,12 @@ # Cross-LLM Capability Coverage -Host-by-host capability matrix for the Superpowers skills system. +Host-by-host capability matrix for the Autonomous Dev Kit skills system. `✅` = fully supported `⚠️` = partial / workaround required `❌` = not supported | Capability | Claude Code | Codex CLI | OpenCode | Cursor | |---|---|---|---|---| -| SKILL.md import | ✅ native | ✅ native | ✅ native | ✅ plugin manifest defines skills/agents/commands/hooks; install via `/plugin-add superpowers` | +| SKILL.md import | ✅ native | ✅ native | ✅ native | ✅ plugin manifest defines skills/agents/commands/hooks; install via `/plugin-add autodev` | | Sub-agent dispatch | ✅ `Agent` tool | ✅ natural language | ⚠️ `@mention` to peer sessions | ❌ not documented | | Agent Teams (persistent multi-agent DM) | ✅ experimental flag | ❌ | ❌ | ❌ | | Background agents | ✅ `run_in_background` | ⚠️ thread-based; no explicit background flag | ❌ not documented | ❌ not documented | @@ -16,7 +16,7 @@ Host-by-host capability matrix for the Superpowers skills system. | Task list / TodoWrite | ✅ built-in | ❌ no documented equivalent | ⚠️ `update_plan` mapping (see `.opencode/INSTALL.md`) | ⚠️ unknown | | AGENTS.md / project context | CLAUDE.md | AGENTS.md (+ `.override.md`) | AGENTS.md | n/a | | Host declaration for skill conditionals | `Host: claude-code` in CLAUDE.md | `Host: codex` in `~/.codex/AGENTS.md` | `Host: opencode` in `~/.config/opencode/AGENTS.md` | n/a | -| Skill discovery path (user scope) | `~/.claude/skills/` (personal skills); superpowers installed to `~/.claude/plugins/marketplace/superpowers/` via marketplace | `~/.agents/skills/` | `~/.config/opencode/skills/` | via plugin (no manual symlink) | +| Skill discovery path (user scope) | `~/.claude/skills/` (personal skills); autodev installed to `~/.claude/plugins/marketplace/autodev/` via marketplace | `~/.agents/skills/` | `~/.config/opencode/skills/` | via plugin (no manual symlink) | | Model tier vocabulary | role names → `haiku`/`sonnet`/`opus` (see `agents/model-tiers.md`) | role names → `gpt-5.4-mini`/`gpt-5.4`/`gpt-5.5` | role names → host-pass-through | role names → host-pass-through | ## Notes @@ -27,7 +27,7 @@ Host-by-host capability matrix for the Superpowers skills system. **Task list (Codex):** No built-in task-tracking tool is documented in Codex CLI. Skills that reference `TodoWrite` wrap those references in `` blocks; the host-neutral path uses prose checklists. -**Cursor:** The `.cursor-plugin/plugin.json` manifest defines `skills`, `agents`, `commands`, and `hooks`. Installation is via `/plugin-add superpowers` in the Cursor agent chat (same marketplace mechanism as Claude Code). Skill discovery path (user scope) is managed through the plugin; no manual symlink required. +**Cursor:** The `.cursor-plugin/plugin.json` manifest defines `skills`, `agents`, `commands`, and `hooks`. Installation is via `/plugin-add autodev` in the Cursor agent chat (same marketplace mechanism as Claude Code). Skill discovery path (user scope) is managed through the plugin; no manual symlink required. ## Related files diff --git a/docs/plans/2025-11-22-opencode-support-design.md b/docs/plans/2025-11-22-opencode-support-design.md index 144f1ce..1f2fc87 100644 --- a/docs/plans/2025-11-22-opencode-support-design.md +++ b/docs/plans/2025-11-22-opencode-support-design.md @@ -1,16 +1,16 @@ # OpenCode Support Design **Date:** 2025-11-22 -**Author:** Bot & Jesse +**Author:** Bot & Jon **Status:** Design Complete, Awaiting Implementation ## Overview -Add full superpowers support for OpenCode.ai using a native OpenCode plugin architecture that shares core functionality with the existing Codex implementation. +Add full autodev support for OpenCode.ai using a native OpenCode plugin architecture that shares core functionality with the existing Codex implementation. ## Background -OpenCode.ai is a coding agent similar to Claude Code and Codex. Previous attempts to port superpowers to OpenCode (PR #93, PR #116) used file-copying approaches. This design takes a different approach: building a native OpenCode plugin using their JavaScript/TypeScript plugin system while sharing code with the Codex implementation. +OpenCode.ai is a coding agent similar to Claude Code and Codex. Previous attempts to port autodev to OpenCode (PR #93, PR #116) used file-copying approaches. This design takes a different approach: building a native OpenCode plugin using their JavaScript/TypeScript plugin system while sharing code with the Codex implementation. ### Key Differences Between Platforms @@ -34,16 +34,16 @@ OpenCode.ai is a coding agent similar to Claude Code and Codex. Previous attempt - Used by both Codex and OpenCode implementations 2. **Platform-Specific Wrappers** - - Codex: CLI script (`.codex/superpowers-codex`) - - OpenCode: Plugin module (`.opencode/plugin/superpowers.js`) + - Codex: CLI script (`.codex/autodev-codex`) + - OpenCode: Plugin module (`.opencode/plugin/autodev.js`) 3. **Skill Directories** - - Core: `~/.config/opencode/superpowers/skills/` (or installed location) + - Core: `~/.config/opencode/autodev/skills/` (or installed location) - Personal: `~/.config/opencode/skills/` (shadows core skills) ### Code Reuse Strategy -Extract common functionality from `.codex/superpowers-codex` into shared module: +Extract common functionality from `.codex/autodev-codex` into shared module: ```javascript // lib/skills-core.js @@ -80,7 +80,7 @@ Loads a specific skill's content into the conversation (equivalent to Claude's S name: 'use_skill', description: 'Load and read a specific skill to guide your work', schema: z.object({ - skill_name: z.string().describe('Name of skill (e.g., "superpowers:brainstorming")') + skill_name: z.string().describe('Name of skill (e.g., "autodev:brainstorming")') }), execute: async ({ skill_name }) => { const { skillPath, content, frontmatter } = resolveAndReadSkill(skill_name); @@ -120,8 +120,8 @@ Lists all available skills with metadata. When a new session starts (`session.started` event): -1. **Inject using-superpowers content** - - Full content of the using-superpowers skill +1. **Inject using-autodev content** + - Full content of the using-autodev skill - Establishes mandatory workflows 2. **Run find_skills automatically** @@ -150,24 +150,24 @@ When a new session starts (`session.started` event): ### Plugin Structure ```javascript -// .opencode/plugin/superpowers.js +// .opencode/plugin/autodev.js const skillsCore = require('../../lib/skills-core'); const path = require('path'); const fs = require('fs'); const { z } = require('zod'); -export const SuperpowersPlugin = async ({ client, directory, $ }) => { - const superpowersDir = path.join(process.env.HOME, '.config/opencode/superpowers'); +export const AutodevPlugin = async ({ client, directory, $ }) => { + const autodevDir = path.join(process.env.HOME, '.config/opencode/autodev'); const personalDir = path.join(process.env.HOME, '.config/opencode/skills'); return { 'session.started': async () => { - const usingSuperpowers = await readSkill('using-superpowers'); + const usingAutodev = await readSkill('using-autodev'); const skillsList = await findAllSkills(); const toolMapping = getToolMappingInstructions(); return { - context: `${usingSuperpowers}\n\n${skillsList}\n\n${toolMapping}` + context: `${usingAutodev}\n\n${skillsList}\n\n${toolMapping}` }; }, @@ -198,16 +198,16 @@ export const SuperpowersPlugin = async ({ client, directory, $ }) => { ## File Structure ``` -superpowers/ +autodev/ ├── lib/ │ └── skills-core.js # NEW: Shared skill logic ├── .codex/ -│ ├── superpowers-codex # UPDATED: Use skills-core -│ ├── superpowers-bootstrap.md +│ ├── autodev-codex # UPDATED: Use skills-core +│ ├── autodev-bootstrap.md │ └── INSTALL.md ├── .opencode/ │ ├── plugin/ -│ │ └── superpowers.js # NEW: OpenCode plugin +│ │ └── autodev.js # NEW: OpenCode plugin │ └── INSTALL.md # NEW: Installation guide └── skills/ # Unchanged ``` @@ -217,12 +217,12 @@ superpowers/ ### Phase 1: Refactor Shared Core 1. Create `lib/skills-core.js` - - Extract frontmatter parsing from `.codex/superpowers-codex` + - Extract frontmatter parsing from `.codex/autodev-codex` - Extract skill discovery logic - Extract path resolution (with shadowing) - Update to use only `name` and `description` (no `when_to_use`) -2. Update `.codex/superpowers-codex` to use shared core +2. Update `.codex/autodev-codex` to use shared core - Import from `../lib/skills-core.js` - Remove duplicated code - Keep CLI wrapper logic @@ -234,7 +234,7 @@ superpowers/ ### Phase 2: Build OpenCode Plugin -1. Create `.opencode/plugin/superpowers.js` +1. Create `.opencode/plugin/autodev.js` - Import shared core from `../../lib/skills-core.js` - Implement plugin function - Define custom tools (use_skill, find_skills) diff --git a/docs/plans/2025-11-22-opencode-support-implementation.md b/docs/plans/2025-11-22-opencode-support-implementation.md index 1a7c1fb..daf8b31 100644 --- a/docs/plans/2025-11-22-opencode-support-implementation.md +++ b/docs/plans/2025-11-22-opencode-support-implementation.md @@ -1,8 +1,8 @@ # OpenCode Support Implementation Plan -> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. +> **For Claude:** REQUIRED SUB-SKILL: Use autodev:executing-plans to implement this plan task-by-task. -**Goal:** Add full superpowers support for OpenCode.ai with a native JavaScript plugin that shares core functionality with the existing Codex implementation. +**Goal:** Add full autodev support for OpenCode.ai with a native JavaScript plugin that shares core functionality with the existing Codex implementation. **Architecture:** Extract common skill discovery/parsing logic into `lib/skills-core.js`, refactor Codex to use it, then build OpenCode plugin using their native plugin API with custom tools and session hooks. @@ -16,7 +16,7 @@ **Files:** - Create: `lib/skills-core.js` -- Reference: `.codex/superpowers-codex` (lines 40-74) +- Reference: `.codex/autodev-codex` (lines 40-74) **Step 1: Create lib/skills-core.js with extractFrontmatter function** @@ -98,7 +98,7 @@ git commit -m "feat: create shared skills core module with frontmatter parser" **Files:** - Modify: `lib/skills-core.js` -- Reference: `.codex/superpowers-codex` (lines 97-136) +- Reference: `.codex/autodev-codex` (lines 97-136) **Step 1: Add findSkillsInDir function to skills-core.js** @@ -109,7 +109,7 @@ Add before `module.exports`: * Find all SKILL.md files in a directory recursively. * * @param {string} dir - Directory to search - * @param {string} sourceType - 'personal' or 'superpowers' for namespacing + * @param {string} sourceType - 'personal' or 'autodev' for namespacing * @param {number} maxDepth - Maximum recursion depth (default: 3) * @returns {Array<{path: string, name: string, description: string, sourceType: string}>} */ @@ -180,7 +180,7 @@ git commit -m "feat: add skill discovery function to core module" **Files:** - Modify: `lib/skills-core.js` -- Reference: `.codex/superpowers-codex` (lines 212-280) +- Reference: `.codex/autodev-codex` (lines 212-280) **Step 1: Add resolveSkillPath function** @@ -189,20 +189,20 @@ Add before `module.exports`: ```javascript /** * Resolve a skill name to its file path, handling shadowing - * (personal skills override superpowers skills). + * (personal skills override autodev skills). * - * @param {string} skillName - Name like "superpowers:brainstorming" or "my-skill" - * @param {string} superpowersDir - Path to superpowers skills directory + * @param {string} skillName - Name like "autodev:brainstorming" or "my-skill" + * @param {string} autodevDir - Path to autodev skills directory * @param {string} personalDir - Path to personal skills directory * @returns {{skillFile: string, sourceType: string, skillPath: string} | null} */ -function resolveSkillPath(skillName, superpowersDir, personalDir) { - // Strip superpowers: prefix if present - const forceSuperpowers = skillName.startsWith('superpowers:'); - const actualSkillName = forceSuperpowers ? skillName.replace(/^superpowers:/, '') : skillName; +function resolveSkillPath(skillName, autodevDir, personalDir) { + // Strip autodev: prefix if present + const forceAutodev = skillName.startsWith('autodev:'); + const actualSkillName = forceAutodev ? skillName.replace(/^autodev:/, '') : skillName; - // Try personal skills first (unless explicitly superpowers:) - if (!forceSuperpowers && personalDir) { + // Try personal skills first (unless explicitly autodev:) + if (!forceAutodev && personalDir) { const personalPath = path.join(personalDir, actualSkillName); const personalSkillFile = path.join(personalPath, 'SKILL.md'); if (fs.existsSync(personalSkillFile)) { @@ -214,14 +214,14 @@ function resolveSkillPath(skillName, superpowersDir, personalDir) { } } - // Try superpowers skills - if (superpowersDir) { - const superpowersPath = path.join(superpowersDir, actualSkillName); - const superpowersSkillFile = path.join(superpowersPath, 'SKILL.md'); - if (fs.existsSync(superpowersSkillFile)) { + // Try autodev skills + if (autodevDir) { + const autodevPath = path.join(autodevDir, actualSkillName); + const autodevSkillFile = path.join(autodevPath, 'SKILL.md'); + if (fs.existsSync(autodevSkillFile)) { return { - skillFile: superpowersSkillFile, - sourceType: 'superpowers', + skillFile: autodevSkillFile, + sourceType: 'autodev', skillPath: actualSkillName }; } @@ -259,7 +259,7 @@ git commit -m "feat: add skill path resolution with shadowing support" **Files:** - Modify: `lib/skills-core.js` -- Reference: `.codex/superpowers-codex` (lines 16-38) +- Reference: `.codex/autodev-codex` (lines 16-38) **Step 1: Add checkForUpdates function** @@ -333,7 +333,7 @@ git commit -m "feat: add git update checking to core module" ### Task 5: Update Codex to Import Shared Core **Files:** -- Modify: `.codex/superpowers-codex` (add import at top) +- Modify: `.codex/autodev-codex` (add import at top) **Step 1: Add import statement** @@ -345,13 +345,13 @@ const skillsCore = require('../lib/skills-core'); **Step 2: Verify syntax** -Run: `node -c .codex/superpowers-codex` +Run: `node -c .codex/autodev-codex` Expected: No output **Step 3: Commit** ```bash -git add .codex/superpowers-codex +git add .codex/autodev-codex git commit -m "refactor: import shared skills core in codex" ``` @@ -360,7 +360,7 @@ git commit -m "refactor: import shared skills core in codex" ### Task 6: Replace extractFrontmatter with Core Version **Files:** -- Modify: `.codex/superpowers-codex` (lines 40-74) +- Modify: `.codex/autodev-codex` (lines 40-74) **Step 1: Remove local extractFrontmatter function** @@ -374,13 +374,13 @@ Affected lines approximately: 90, 310 **Step 3: Verify script still works** -Run: `.codex/superpowers-codex find-skills | head -20` +Run: `.codex/autodev-codex find-skills | head -20` Expected: Shows list of skills **Step 4: Commit** ```bash -git add .codex/superpowers-codex +git add .codex/autodev-codex git commit -m "refactor: use shared extractFrontmatter in codex" ``` @@ -389,7 +389,7 @@ git commit -m "refactor: use shared extractFrontmatter in codex" ### Task 7: Replace findSkillsInDir with Core Version **Files:** -- Modify: `.codex/superpowers-codex` (lines 97-136, approximately) +- Modify: `.codex/autodev-codex` (lines 97-136, approximately) **Step 1: Remove local findSkillsInDir function** @@ -401,13 +401,13 @@ Replace calls from `findSkillsInDir(` to `skillsCore.findSkillsInDir(` **Step 3: Verify script still works** -Run: `.codex/superpowers-codex find-skills | head -20` +Run: `.codex/autodev-codex find-skills | head -20` Expected: Shows list of skills **Step 4: Commit** ```bash -git add .codex/superpowers-codex +git add .codex/autodev-codex git commit -m "refactor: use shared findSkillsInDir in codex" ``` @@ -416,7 +416,7 @@ git commit -m "refactor: use shared findSkillsInDir in codex" ### Task 8: Replace checkForUpdates with Core Version **Files:** -- Modify: `.codex/superpowers-codex` (lines 16-38, approximately) +- Modify: `.codex/autodev-codex` (lines 16-38, approximately) **Step 1: Remove local checkForUpdates function** @@ -428,13 +428,13 @@ Replace calls from `checkForUpdates(` to `skillsCore.checkForUpdates(` **Step 3: Verify script still works** -Run: `.codex/superpowers-codex bootstrap | head -50` +Run: `.codex/autodev-codex bootstrap | head -50` Expected: Shows bootstrap content **Step 4: Commit** ```bash -git add .codex/superpowers-codex +git add .codex/autodev-codex git commit -m "refactor: use shared checkForUpdates in codex" ``` @@ -445,7 +445,7 @@ git commit -m "refactor: use shared checkForUpdates in codex" ### Task 9: Create OpenCode Plugin Directory Structure **Files:** -- Create: `.opencode/plugin/superpowers.js` +- Create: `.opencode/plugin/autodev.js` **Step 1: Create directory** @@ -457,7 +457,7 @@ Run: `mkdir -p .opencode/plugin` #!/usr/bin/env node /** - * Superpowers plugin for OpenCode.ai + * Autonomous Dev Kit plugin for OpenCode.ai * * Provides custom tools for loading and discovering skills, * with automatic bootstrap on session start. @@ -469,13 +469,13 @@ const fs = require('fs'); const os = require('os'); const homeDir = os.homedir(); -const superpowersSkillsDir = path.join(homeDir, '.config/opencode/superpowers/skills'); +const autodevSkillsDir = path.join(homeDir, '.config/opencode/autodev/skills'); const personalSkillsDir = path.join(homeDir, '.config/opencode/skills'); /** * OpenCode plugin entry point */ -export const SuperpowersPlugin = async ({ project, client, $, directory, worktree }) => { +export const AutodevPlugin = async ({ project, client, $, directory, worktree }) => { return { // Custom tools and hooks will go here }; @@ -484,13 +484,13 @@ export const SuperpowersPlugin = async ({ project, client, $, directory, worktre **Step 3: Verify file was created** -Run: `ls -l .opencode/plugin/superpowers.js` +Run: `ls -l .opencode/plugin/autodev.js` Expected: File exists **Step 4: Commit** ```bash -git add .opencode/plugin/superpowers.js +git add .opencode/plugin/autodev.js git commit -m "feat: create opencode plugin scaffold" ``` @@ -499,14 +499,14 @@ git commit -m "feat: create opencode plugin scaffold" ### Task 10: Implement use_skill Tool **Files:** -- Modify: `.opencode/plugin/superpowers.js` +- Modify: `.opencode/plugin/autodev.js` **Step 1: Add use_skill tool implementation** Replace the plugin return statement with: ```javascript -export const SuperpowersPlugin = async ({ project, client, $, directory, worktree }) => { +export const AutodevPlugin = async ({ project, client, $, directory, worktree }) => { // Import zod for schema validation const { z } = await import('zod'); @@ -516,13 +516,13 @@ export const SuperpowersPlugin = async ({ project, client, $, directory, worktre name: 'use_skill', description: 'Load and read a specific skill to guide your work. Skills contain proven workflows, mandatory processes, and expert techniques.', schema: z.object({ - skill_name: z.string().describe('Name of the skill to load (e.g., "superpowers:brainstorming" or "my-custom-skill")') + skill_name: z.string().describe('Name of the skill to load (e.g., "autodev:brainstorming" or "my-custom-skill")') }), execute: async ({ skill_name }) => { - // Resolve skill path (handles shadowing: personal > superpowers) + // Resolve skill path (handles shadowing: personal > autodev) const resolved = skillsCore.resolveSkillPath( skill_name, - superpowersSkillsDir, + autodevSkillsDir, personalSkillsDir ); @@ -574,13 +574,13 @@ ${content}`; **Step 2: Verify syntax** -Run: `node -c .opencode/plugin/superpowers.js` +Run: `node -c .opencode/plugin/autodev.js` Expected: No output **Step 3: Commit** ```bash -git add .opencode/plugin/superpowers.js +git add .opencode/plugin/autodev.js git commit -m "feat: implement use_skill tool for opencode" ``` @@ -589,7 +589,7 @@ git commit -m "feat: implement use_skill tool for opencode" ### Task 11: Implement find_skills Tool **Files:** -- Modify: `.opencode/plugin/superpowers.js` +- Modify: `.opencode/plugin/autodev.js` **Step 1: Add find_skills tool to tools array** @@ -598,13 +598,13 @@ Add after the use_skill tool definition, before closing the tools array: ```javascript { name: 'find_skills', - description: 'List all available skills in the superpowers and personal skill libraries.', + description: 'List all available skills in the autodev and personal skill libraries.', schema: z.object({}), execute: async () => { // Find skills in both directories - const superpowersSkills = skillsCore.findSkillsInDir( - superpowersSkillsDir, - 'superpowers', + const autodevSkills = skillsCore.findSkillsInDir( + autodevSkillsDir, + 'autodev', 3 ); const personalSkills = skillsCore.findSkillsInDir( @@ -614,16 +614,16 @@ Add after the use_skill tool definition, before closing the tools array: ); // Combine and format skills list - const allSkills = [...personalSkills, ...superpowersSkills]; + const allSkills = [...personalSkills, ...autodevSkills]; if (allSkills.length === 0) { - return 'No skills found. Install superpowers skills to ~/.config/opencode/superpowers/skills/'; + return 'No skills found. Install autodev skills to ~/.config/opencode/autodev/skills/'; } let output = 'Available skills:\n\n'; for (const skill of allSkills) { - const namespace = skill.sourceType === 'personal' ? '' : 'superpowers:'; + const namespace = skill.sourceType === 'personal' ? '' : 'autodev:'; const skillName = skill.name || path.basename(skill.path); output += `${namespace}${skillName}\n`; @@ -640,13 +640,13 @@ Add after the use_skill tool definition, before closing the tools array: **Step 2: Verify syntax** -Run: `node -c .opencode/plugin/superpowers.js` +Run: `node -c .opencode/plugin/autodev.js` Expected: No output **Step 3: Commit** ```bash -git add .opencode/plugin/superpowers.js +git add .opencode/plugin/autodev.js git commit -m "feat: implement find_skills tool for opencode" ``` @@ -655,7 +655,7 @@ git commit -m "feat: implement find_skills tool for opencode" ### Task 12: Implement Session Start Hook **Files:** -- Modify: `.opencode/plugin/superpowers.js` +- Modify: `.opencode/plugin/autodev.js` **Step 1: Add session.started hook** @@ -663,16 +663,16 @@ After the tools array, add: ```javascript 'session.started': async () => { - // Read using-superpowers skill content - const usingSuperpowersPath = skillsCore.resolveSkillPath( - 'using-superpowers', - superpowersSkillsDir, + // Read using-autodev skill content + const usingAutodevPath = skillsCore.resolveSkillPath( + 'using-autodev', + autodevSkillsDir, personalSkillsDir ); - let usingSuperpowersContent = ''; - if (usingSuperpowersPath) { - const fullContent = fs.readFileSync(usingSuperpowersPath.skillFile, 'utf8'); + let usingAutodevContent = ''; + if (usingAutodevPath) { + const fullContent = fs.readFileSync(usingAutodevPath.skillFile, 'utf8'); // Strip frontmatter const lines = fullContent.split('\n'); let inFrontmatter = false; @@ -694,7 +694,7 @@ After the tools array, add: } } - usingSuperpowersContent = contentLines.join('\n').trim(); + usingAutodevContent = contentLines.join('\n').trim(); } // Tool mapping instructions @@ -712,28 +712,28 @@ When skills reference tools you don't have, substitute OpenCode equivalents: - Utilities and helpers specific to that skill **Skills naming:** -- Superpowers skills: \`superpowers:skill-name\` (from ~/.config/opencode/superpowers/skills/) +- Autonomous Dev Kit skills: \`autodev:skill-name\` (from ~/.config/opencode/autodev/skills/) - Personal skills: \`skill-name\` (from ~/.config/opencode/skills/) -- Personal skills override superpowers skills when names match +- Personal skills override autodev skills when names match `; // Check for updates (non-blocking) const hasUpdates = skillsCore.checkForUpdates( - path.join(homeDir, '.config/opencode/superpowers') + path.join(homeDir, '.config/opencode/autodev') ); const updateNotice = hasUpdates ? - '\n\n⚠️ **Updates available!** Run `cd ~/.config/opencode/superpowers && git pull` to update superpowers.' : + '\n\n⚠️ **Updates available!** Run `cd ~/.config/opencode/autodev && git pull` to update autodev.' : ''; // Return context to inject into session return { context: ` -You have superpowers. +You have autodev. -**Below is the full content of your 'superpowers:using-superpowers' skill - your introduction to using skills. For all other skills, use the 'use_skill' tool:** +**Below is the full content of your 'autodev:using-autodev' skill - your introduction to using skills. For all other skills, use the 'use_skill' tool:** -${usingSuperpowersContent} +${usingAutodevContent} ${toolMapping}${updateNotice} ` @@ -743,13 +743,13 @@ ${toolMapping}${updateNotice} **Step 2: Verify syntax** -Run: `node -c .opencode/plugin/superpowers.js` +Run: `node -c .opencode/plugin/autodev.js` Expected: No output **Step 3: Commit** ```bash -git add .opencode/plugin/superpowers.js +git add .opencode/plugin/autodev.js git commit -m "feat: implement session.started hook for opencode" ``` @@ -765,7 +765,7 @@ git commit -m "feat: implement session.started hook for opencode" **Step 1: Create installation guide** ```markdown -# Installing Superpowers for OpenCode +# Installing Autonomous Dev Kit for OpenCode ## Prerequisites @@ -775,27 +775,27 @@ git commit -m "feat: implement session.started hook for opencode" ## Installation Steps -### 1. Install Superpowers Skills +### 1. Install Autonomous Dev Kit Skills ```bash -# Clone superpowers skills to OpenCode config directory -mkdir -p ~/.config/opencode/superpowers -git clone https://github.com/obra/superpowers.git ~/.config/opencode/superpowers +# Clone autodev skills to OpenCode config directory +mkdir -p ~/.config/opencode/autodev +git clone https://github.com/GoCodeAlone/autonomous-dev-kit.git ~/.config/opencode/autodev ``` ### 2. Install the Plugin -The plugin is included in the superpowers repository you just cloned. +The plugin is included in the autodev repository you just cloned. OpenCode will automatically discover it from: -- `~/.config/opencode/superpowers/.opencode/plugin/superpowers.js` +- `~/.config/opencode/autodev/.opencode/plugin/autodev.js` Or you can link it to the project-local plugin directory: ```bash # In your OpenCode project mkdir -p .opencode/plugin -ln -s ~/.config/opencode/superpowers/.opencode/plugin/superpowers.js .opencode/plugin/superpowers.js +ln -s ~/.config/opencode/autodev/.opencode/plugin/autodev.js .opencode/plugin/autodev.js ``` ### 3. Restart OpenCode @@ -803,7 +803,7 @@ ln -s ~/.config/opencode/superpowers/.opencode/plugin/superpowers.js .opencode/p Restart OpenCode to load the plugin. On the next session, you should see: ``` -You have superpowers. +You have autodev. ``` ## Usage @@ -821,7 +821,7 @@ use find_skills tool Use the `use_skill` tool to load a specific skill: ``` -use use_skill tool with skill_name: "superpowers:brainstorming" +use use_skill tool with skill_name: "autodev:brainstorming" ``` ### Personal Skills @@ -845,12 +845,12 @@ description: Use when [condition] - [what it does] [Your skill content here] ``` -Personal skills override superpowers skills with the same name. +Personal skills override autodev skills with the same name. ## Updating ```bash -cd ~/.config/opencode/superpowers +cd ~/.config/opencode/autodev git pull ``` @@ -858,13 +858,13 @@ git pull ### Plugin not loading -1. Check plugin file exists: `ls ~/.config/opencode/superpowers/.opencode/plugin/superpowers.js` +1. Check plugin file exists: `ls ~/.config/opencode/autodev/.opencode/plugin/autodev.js` 2. Check OpenCode logs for errors 3. Verify Node.js is installed: `node --version` ### Skills not found -1. Verify skills directory exists: `ls ~/.config/opencode/superpowers/skills` +1. Verify skills directory exists: `ls ~/.config/opencode/autodev/skills` 2. Use `find_skills` tool to see what's discovered 3. Check file structure: each skill should have a `SKILL.md` file @@ -878,8 +878,8 @@ When a skill references a Claude Code tool you don't have: ## Getting Help -- Report issues: https://github.com/obra/superpowers/issues -- Documentation: https://github.com/obra/superpowers +- Report issues: https://github.com/GoCodeAlone/autonomous-dev-kit/issues +- Documentation: https://github.com/GoCodeAlone/autonomous-dev-kit ``` **Step 2: Verify file created** @@ -908,7 +908,7 @@ Find the section about supported platforms (search for "Codex" in the file), and ```markdown ### OpenCode -Superpowers works with [OpenCode.ai](https://opencode.ai) through a native JavaScript plugin. +Autonomous Dev Kit works with [OpenCode.ai](https://opencode.ai) through a native JavaScript plugin. **Installation:** See [.opencode/INSTALL.md](.opencode/INSTALL.md) @@ -982,21 +982,21 @@ git commit -m "docs: add opencode support to release notes" ### Task 16: Test Codex Still Works **Files:** -- Test: `.codex/superpowers-codex` +- Test: `.codex/autodev-codex` **Step 1: Test find-skills command** -Run: `.codex/superpowers-codex find-skills | head -20` +Run: `.codex/autodev-codex find-skills | head -20` Expected: Shows list of skills with names and descriptions **Step 2: Test use-skill command** -Run: `.codex/superpowers-codex use-skill superpowers:brainstorming | head -20` +Run: `.codex/autodev-codex use-skill autodev:brainstorming | head -20` Expected: Shows brainstorming skill content **Step 3: Test bootstrap command** -Run: `.codex/superpowers-codex bootstrap | head -30` +Run: `.codex/autodev-codex bootstrap | head -30` Expected: Shows bootstrap content with instructions **Step 4: If all tests pass, record success** @@ -1015,7 +1015,7 @@ No commit needed - this is verification only. Run: ```bash ls -l lib/skills-core.js -ls -l .opencode/plugin/superpowers.js +ls -l .opencode/plugin/autodev.js ls -l .opencode/INSTALL.md ``` @@ -1029,7 +1029,7 @@ Expected: .opencode/ ├── INSTALL.md └── plugin/ - └── superpowers.js + └── autodev.js ``` **Step 3: If structure correct, proceed** @@ -1057,8 +1057,8 @@ Expected: Shows all commits from this implementation Create a completion summary showing: - Total commits made -- Files created: `lib/skills-core.js`, `.opencode/plugin/superpowers.js`, `.opencode/INSTALL.md` -- Files modified: `.codex/superpowers-codex`, `README.md`, `RELEASE-NOTES.md` +- Files created: `lib/skills-core.js`, `.opencode/plugin/autodev.js`, `.opencode/INSTALL.md` +- Files modified: `.codex/autodev-codex`, `README.md`, `RELEASE-NOTES.md` - Testing performed: Codex commands verified - Ready for: Testing with actual OpenCode installation @@ -1086,9 +1086,9 @@ These steps require OpenCode to be installed and are not part of the automated i ## Success Criteria - [ ] `lib/skills-core.js` created with all core functions -- [ ] `.codex/superpowers-codex` refactored to use shared core +- [ ] `.codex/autodev-codex` refactored to use shared core - [ ] Codex commands still work (find-skills, use-skill, bootstrap) -- [ ] `.opencode/plugin/superpowers.js` created with tools and hooks +- [ ] `.opencode/plugin/autodev.js` created with tools and hooks - [ ] Installation guide created - [ ] README and RELEASE-NOTES updated - [ ] All changes committed diff --git a/docs/plans/2025-11-28-skills-improvements-from-user-feedback.md b/docs/plans/2025-11-28-skills-improvements-from-user-feedback.md index 52a8b0e..3e83977 100644 --- a/docs/plans/2025-11-28-skills-improvements-from-user-feedback.md +++ b/docs/plans/2025-11-28-skills-improvements-from-user-feedback.md @@ -2,7 +2,7 @@ **Date:** 2025-11-28 **Status:** Draft -**Source:** Two Claude instances using superpowers in real development scenarios +**Source:** Two Claude instances using autodev in real development scenarios --- @@ -507,7 +507,7 @@ Directly addresses the failure pattern from feedback. BEFORE writing any tests: 1. Read testing-anti-patterns skill: - Use Skill tool: superpowers:testing-anti-patterns + Use Skill tool: autodev:testing-anti-patterns 2. Apply gate functions from that skill when: - Writing mocks @@ -640,7 +640,7 @@ How do we know these improvements work? 1. **Configuration verification:** - Zero instances of "test passed but wrong config was used" - - Jesse doesn't say "that's not actually testing what you think" + - Jon doesn't say "that's not actually testing what you think" 2. **Process hygiene:** - Zero instances of "test hit wrong server" @@ -699,7 +699,7 @@ How do we know these improvements work? - testing-anti-patterns: Mock-interface drift - requesting-code-review: Explicit file reading -**Test Phase 2 with Jesse before finalizing:** +**Test Phase 2 with Jon before finalizing:** - Get feedback on self-reflection impact - Validate process hygiene approach - Confirm skills reading requirement is worth overhead diff --git a/docs/plans/2026-03-04-alignment-autonomy-teams-design.md b/docs/plans/2026-03-04-alignment-autonomy-teams-design.md index ae6ec66..276e8d9 100644 --- a/docs/plans/2026-03-04-alignment-autonomy-teams-design.md +++ b/docs/plans/2026-03-04-alignment-autonomy-teams-design.md @@ -5,7 +5,7 @@ ## Goal -Enhance claude-superpowers with three capabilities: (1) design-to-plan alignment verification, (2) Agent Teams as the default execution mode, and (3) full autonomy after design approval including automated PR monitoring. +Enhance autonomous-dev-kit with three capabilities: (1) design-to-plan alignment verification, (2) Agent Teams as the default execution mode, and (3) full autonomy after design approval including automated PR monitoring. ## Architecture @@ -150,4 +150,4 @@ Check for Agent Teams availability (TeamCreate tool presence or `CLAUDE_CODE_EXP | `skills/finishing-a-development-branch/SKILL.md` | Modify: auto-PR path | | `skills/alignment-check/SKILL.md` | Create | | `skills/pr-monitoring/SKILL.md` | Create | -| `skills/using-superpowers/SKILL.md` | Modify: updated workflow, new skills | +| `skills/using-autodev/SKILL.md` | Modify: updated workflow, new skills | diff --git a/docs/plans/2026-03-04-alignment-autonomy-teams.md b/docs/plans/2026-03-04-alignment-autonomy-teams.md index fcf355f..a44a2b1 100644 --- a/docs/plans/2026-03-04-alignment-autonomy-teams.md +++ b/docs/plans/2026-03-04-alignment-autonomy-teams.md @@ -1,6 +1,6 @@ # Alignment, Autonomy & Agent Teams Implementation Plan -> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. +> **For Claude:** REQUIRED SUB-SKILL: Use autodev:executing-plans to implement this plan task-by-task. **Goal:** Add design-to-plan alignment verification, Agent Teams as the default execution mode, and full autonomy after design approval with automated PR monitoring. @@ -252,7 +252,7 @@ Agent tool (general-purpose, model: sonnet, run_in_background: true): **Uses:** - `gh` CLI for all GitHub operations -- `superpowers:systematic-debugging` principles for CI failure analysis +- `autodev:systematic-debugging` principles for CI failure analysis ``` **Step 2: Verify the file was created correctly** @@ -428,8 +428,8 @@ When running autonomously (design already approved, no user interaction): 1. Save the plan to `docs/plans/.md` 2. Commit the plan -3. Invoke `superpowers:alignment-check` to verify design-to-plan alignment -4. On PASS: invoke `superpowers:subagent-driven-development` (which uses Agent Teams when available) +3. Invoke `autodev:alignment-check` to verify design-to-plan alignment +4. On PASS: invoke `autodev:subagent-driven-development` (which uses Agent Teams when available) 5. Do NOT ask the user for execution choice — the pipeline is autonomous ### Manual Mode (direct invocation) @@ -445,13 +445,13 @@ When invoked directly by the user (not from brainstorming pipeline): **Which approach?"** **If Subagent-Driven chosen:** -- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development +- **REQUIRED SUB-SKILL:** Use autodev:subagent-driven-development - Stay in this session - Fresh subagent per task + code review **If Parallel Session chosen:** - Guide them to open new session in worktree -- **REQUIRED SUB-SKILL:** New session uses superpowers:executing-plans +- **REQUIRED SUB-SKILL:** New session uses autodev:executing-plans ``` **Step 2: Review the full modified file** @@ -692,7 +692,7 @@ Wait for all shutdown approvals, then: TeamDelete() ``` -Invoke `superpowers:finishing-a-development-branch`. +Invoke `autodev:finishing-a-development-branch`. ## Legacy Mode (Sequential Subagents) @@ -732,16 +732,16 @@ When Agent Teams is not available, fall back to the original sequential flow: ## Integration **Required workflow skills:** -- **superpowers:using-git-worktrees** - REQUIRED: Set up isolated workspace before starting -- **superpowers:writing-plans** - Creates the plan this skill executes -- **superpowers:alignment-check** - Verifies plan matches design (autonomous mode) -- **superpowers:finishing-a-development-branch** - Complete development after all tasks +- **autodev:using-git-worktrees** - REQUIRED: Set up isolated workspace before starting +- **autodev:writing-plans** - Creates the plan this skill executes +- **autodev:alignment-check** - Verifies plan matches design (autonomous mode) +- **autodev:finishing-a-development-branch** - Complete development after all tasks **Subagents/teammates should use:** -- **superpowers:test-driven-development** - Follow TDD for each task +- **autodev:test-driven-development** - Follow TDD for each task **Alternative workflow:** -- **superpowers:executing-plans** - Use for parallel session instead of same-session execution +- **autodev:executing-plans** - Use for parallel session instead of same-session execution ``` **Step 2: Update implementer-prompt.md with team messaging** @@ -864,7 +864,7 @@ Replace the existing Integration section (lines 195-201) with: - **executing-plans** (Step 5) - After all batches complete **Calls (autonomous mode):** -- **superpowers:pr-monitoring** - After PR creation, monitors CI and reviews +- **autodev:pr-monitoring** - After PR creation, monitors CI and reviews **Pairs with:** - **using-git-worktrees** - Cleans up worktree created by that skill @@ -879,14 +879,14 @@ git commit -m "feat: finishing-a-development-branch autonomous PR creation and m --- -### Task 7: Modify `using-superpowers` Skill — Update Workflow & Skills List +### Task 7: Modify `using-autodev` Skill — Update Workflow & Skills List **Files:** -- Modify: `skills/using-superpowers/SKILL.md` +- Modify: `skills/using-autodev/SKILL.md` **Step 1: Add new skills to the skill priority section** -In `skills/using-superpowers/SKILL.md`, update the "Skill Priority" section (after line 79) to include the new skills. Replace: +In `skills/using-autodev/SKILL.md`, update the "Skill Priority" section (after line 79) to include the new skills. Replace: ``` ## Skill Priority @@ -919,8 +919,8 @@ When multiple skills could apply, use this order: **Step 2: Commit** ```bash -git add skills/using-superpowers/SKILL.md -git commit -m "feat: using-superpowers updated with autonomous pipeline skills" +git add skills/using-autodev/SKILL.md +git commit -m "feat: using-autodev updated with autonomous pipeline skills" ``` --- diff --git a/docs/plans/2026-04-25-superpowers-skills-improvements-design.md b/docs/plans/2026-04-25-autonomous-dev-kit-skills-improvements-design.md similarity index 99% rename from docs/plans/2026-04-25-superpowers-skills-improvements-design.md rename to docs/plans/2026-04-25-autonomous-dev-kit-skills-improvements-design.md index bba32a6..cb0cfb5 100644 --- a/docs/plans/2026-04-25-superpowers-skills-improvements-design.md +++ b/docs/plans/2026-04-25-autonomous-dev-kit-skills-improvements-design.md @@ -1,4 +1,4 @@ -# Superpowers Skills Improvements — Design +# Autonomous Dev Kit Skills Improvements — Design **Status:** Approved by user; full execution pipeline will run. **Branch:** `feat/skills-improvements-from-failure-modes` @@ -10,7 +10,7 @@ Multi-agent autonomous development sessions over recent weeks revealed ten failu The driving observation: a third-party adversarial code reviewer running on a fresh diff read consistently catches bugs that the team's own reviewer agent has already approved — same base LLM, same diff, very different outcomes. The framing differs, the brief differs, the loop differs, and the result differs by order of magnitude. Closing that gap is the single highest-impact change in this design. -This work targets the public `claude-superpowers` skill set. **All changes are generic** — no project, company, technology, or incident references bleed in. Lessons abstract; specifics scrub. +This work targets the public `autonomous-dev-kit` skill set. **All changes are generic** — no project, company, technology, or incident references bleed in. Lessons abstract; specifics scrub. ## Goals @@ -329,4 +329,4 @@ The implementer will create these fixtures as part of the work and document the ## Approval -Approved by user via the autonomous-mode brainstorm dispatch with full pipeline (brainstorm → writing-plans → alignment-check → subagent-driven-development → finishing → pr-monitoring). Implementer: per the orchestrator's team configuration. PR(s) targeted at `GoCodeAlone/claude-superpowers` main with newly-active branch protection. +Approved by user via the autonomous-mode brainstorm dispatch with full pipeline (brainstorm → writing-plans → alignment-check → subagent-driven-development → finishing → pr-monitoring). Implementer: per the orchestrator's team configuration. PR(s) targeted at `GoCodeAlone/autonomous-dev-kit` main with newly-active branch protection. diff --git a/docs/plans/2026-04-25-superpowers-skills-improvements.md b/docs/plans/2026-04-25-autonomous-dev-kit-skills-improvements.md similarity index 99% rename from docs/plans/2026-04-25-superpowers-skills-improvements.md rename to docs/plans/2026-04-25-autonomous-dev-kit-skills-improvements.md index 13ab9f8..db7a22b 100644 --- a/docs/plans/2026-04-25-superpowers-skills-improvements.md +++ b/docs/plans/2026-04-25-autonomous-dev-kit-skills-improvements.md @@ -1,6 +1,6 @@ -# Superpowers Skills Improvements — Implementation Plan +# Autonomous Dev Kit Skills Improvements — Implementation Plan -> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. +> **For Claude:** REQUIRED SUB-SKILL: Use autodev:executing-plans to implement this plan task-by-task. **Goal:** Address ten observed failure patterns in the autonomous-development pipeline by upgrading six existing skills and adding one new mini-skill for cross-cutting runtime-launch validation. @@ -10,7 +10,7 @@ **Sanitization:** Public skill set — every example, fixture, and comment must be generic. No specific project, company, version, or incident references. Generic technology terms used as examples (e.g. Go, Markdown, bash) are fine. -**Design doc:** `docs/plans/2026-04-25-superpowers-skills-improvements-design.md` (commit 6bb1833) +**Design doc:** `docs/plans/2026-04-25-autodev-skills-improvements-design.md` (commit 6bb1833) --- @@ -1069,7 +1069,7 @@ When the orchestrator wants the pipeline to halt after alignment-check (no execu 1. Save the plan to `docs/plans/.md` as normal. 2. Commit the plan as normal. -3. Invoke `superpowers:alignment-check` as normal. +3. Invoke `autodev:alignment-check` as normal. 4. **On alignment PASS: STOP.** Do NOT invoke subagent-driven-development. 5. The plan + design sit in `docs/plans/` for future execution. The orchestrator (or a future invocation) can resume by passing the plan to `subagent-driven-development` directly. diff --git a/docs/plans/2026-04-25-cross-llm-portability-design.md b/docs/plans/2026-04-25-cross-llm-portability-design.md index f595bb5..67467d5 100644 --- a/docs/plans/2026-04-25-cross-llm-portability-design.md +++ b/docs/plans/2026-04-25-cross-llm-portability-design.md @@ -1,6 +1,6 @@ # Cross-LLM Portability Design -**Goal:** Make the superpowers skills repo first-class on Claude Code, Codex, OpenCode, and Cursor without forking content per host. +**Goal:** Make the autodev skills repo first-class on Claude Code, Codex, OpenCode, and Cursor without forking content per host. **Status:** Design only. Implementation will be queued to a separate plan and dispatched to implementer agents. @@ -10,14 +10,14 @@ ## Problem -The superpowers repo currently ships installers for four hosts (Claude Code, Codex, OpenCode, Cursor) but the skill bodies are heavily Claude-specific. An audit of the 17 skills found: +The autodev repo currently ships installers for four hosts (Claude Code, Codex, OpenCode, Cursor) but the skill bodies are heavily Claude-specific. An audit of the 17 skills found: - 11 of 17 skills (65%) reference Claude-only tool names: `TodoWrite`, `TaskCreate`, `TaskList`, `TeamCreate`, `SendMessage`, `Agent`, `Monitor`. - 8 of 17 reference Claude model tier names (`Sonnet`, `Opus`, `Haiku`) that have no analogue in other hosts. - Several skills assume Claude-specific UX features such as the `EnterPlanMode` tool / `Shift+Tab` gesture. - One skill (`subagent-driven-development`) is built around a Claude experimental feature (Agent Teams + persistent named teammates + cross-agent chat) that has **no equivalent on any other host**. -The Codex install plumbing already symlinks `~/.agents/skills/superpowers` — which is exactly the path Codex documents for user-scope skill discovery. The plumbing is correct; **the bleed is in the content**. +The Codex install plumbing already symlinks `~/.agents/skills/autodev` — which is exactly the path Codex documents for user-scope skill discovery. The plumbing is correct; **the bleed is in the content**. A non-Claude user installing these skills will read prose that references tools their host does not expose, model names their host does not understand, and gestures that don't exist. Skills with this content cannot reliably trigger their intended behavior on a non-Claude host. @@ -28,7 +28,7 @@ A non-Claude user installing these skills will read prose that references tools - The existing install model (clone + symlink, `git pull` for updates) must keep working. No installer-time forking of skill content. - Skills must remain a **single source of truth** on disk. Every host reads the same files. - Frontmatter must remain `name` + `description` only. SKILL.md frontmatter is constrained to those two fields by Claude's spec; Codex follows the same convention. Adding new top-level fields breaks Claude's loader. -- Existing user-facing skill names (e.g. `superpowers:brainstorming`) must remain stable. No renames. +- Existing user-facing skill names (e.g. `autodev:brainstorming`) must remain stable. No renames. - Branch protection on `main` is active; every change is a PR, no direct push. - This repo is public — all content remains free of internal-project / company / version / incident references. @@ -83,7 +83,7 @@ The host context is established by a small preamble in each host's entry point f **Cons:** - Skill bodies grow somewhat (each conditional adds prose). -- Model has to read the right host section. Mitigated by (a) tagging sections with explicit ``-style markers, (b) putting the host-detection rule prominently in `using-superpowers`. +- Model has to read the right host section. Mitigated by (a) tagging sections with explicit ``-style markers, (b) putting the host-detection rule prominently in `using-autodev`. - Requires discipline: every author touching a skill must keep all host paths in sync. ### Option C — top-level "tool alias" registry file @@ -191,11 +191,11 @@ This is precisely the "Legacy Mode (Sequential Subagents)" path already document #### 4.2 Shared task list (TodoWrite / TaskCreate) -Used in `executing-plans`, `subagent-driven-development`, `using-superpowers`. Claude has `TodoWrite` (single-agent) and `TaskCreate` (Agent Teams shared list). OpenCode has `update_plan`. Codex and Cursor have no built-in. +Used in `executing-plans`, `subagent-driven-development`, `using-autodev`. Claude has `TodoWrite` (single-agent) and `TaskCreate` (Agent Teams shared list). OpenCode has `update_plan`. Codex and Cursor have no built-in. **Fallback for hosts without a task-list tool:** in-prose checklist in the conversation transcript. The orchestrator maintains a markdown checklist in chat output; sub-agents are passed a copy. Less ergonomic than a real task tool but functionally equivalent for a single session. -We document this fallback once in `using-superpowers` and reference it from the skills that depend on the pattern. +We document this fallback once in `using-autodev` and reference it from the skills that depend on the pattern. #### 4.3 Plan Mode (`EnterPlanMode` + Shift-Tab) @@ -251,7 +251,7 @@ Estimated: 5–15 line diff per skill. - `subagent-driven-development` — heaviest; rewritten around Sequential Mode default with Agent Teams as Claude-only addendum. - `dispatching-parallel-agents` — `Task("…")` examples need host-conditional rewrite. - `writing-plans` — Plan Mode logic gets host-conditional update; Sonnet/Opus/Haiku → role names. -- `using-superpowers` — Skill tool references already host-conditional; add explicit host-detection pointer + task-list fallback. +- `using-autodev` — Skill tool references already host-conditional; add explicit host-detection pointer + task-list fallback. - `executing-plans` — `TodoWrite` references → "shared task list" + fallback. - `writing-skills` — already mentions `~/.agents/skills/` for Codex; expand with host-conditional rewrite + the alias-marker convention. @@ -283,7 +283,7 @@ This pairs the documentation discipline with a mechanical guard against regressi **Risk: model ignores the host marker and reads the wrong section.** Mitigation: -- The marker convention is documented in `using-superpowers` (the entry-point skill the model loads first). +- The marker convention is documented in `using-autodev` (the entry-point skill the model loads first). - Skills include short explicit cues like "On Codex, do X." inside the conditional block, so even a model that under-weighs the marker tends to do the right thing. - The `tests/skill-content-grep.sh` guard catches the common error of authoring host-specific content outside a marker. @@ -339,4 +339,4 @@ The following questions were open at design time and have since been resolved: ## Next step -Hand off to `superpowers:writing-plans` in `--design-only` mode. The plan will halt at alignment-check PASS for orchestrator review; implementation will be dispatched separately. +Hand off to `autodev:writing-plans` in `--design-only` mode. The plan will halt at alignment-check PASS for orchestrator review; implementation will be dispatched separately. diff --git a/docs/plans/2026-04-25-cross-llm-portability.md b/docs/plans/2026-04-25-cross-llm-portability.md index 67f8f57..12f203c 100644 --- a/docs/plans/2026-04-25-cross-llm-portability.md +++ b/docs/plans/2026-04-25-cross-llm-portability.md @@ -1,8 +1,8 @@ # Cross-LLM Portability Implementation Plan -> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. +> **For Claude:** REQUIRED SUB-SKILL: Use autodev:executing-plans to implement this plan task-by-task. -**Goal:** Make the 17 superpowers skills first-class on Claude Code, Codex, OpenCode, and Cursor by replacing brand-specific tool names + model tiers with host-conditional sections + a role-based vocabulary, with a CI guard against regression. +**Goal:** Make the 17 autodev skills first-class on Claude Code, Codex, OpenCode, and Cursor by replacing brand-specific tool names + model tiers with host-conditional sections + a role-based vocabulary, with a CI guard against regression. **Architecture:** Single-source skills on disk. Inline `` markers gate host-specific paragraphs. Model tiers expressed by role (`fast` / `balanced` / `frontier` / `coding-specialist`) and resolved through `agents/model-tiers.md`. Workflow patterns with no cross-host equivalent (Agent Teams, shared task list, EnterPlanMode) get explicit fallbacks. A grep guard keeps Claude-only tokens out of host-neutral text. @@ -14,7 +14,7 @@ **Design-only mode is active** (orchestrator passed `--design-only`). -After alignment-check PASS, **STOP**. Do not invoke `superpowers:subagent-driven-development`. The plan + design sit in `docs/plans/` for the team's persistent implementer agents to execute. +After alignment-check PASS, **STOP**. Do not invoke `autodev:subagent-driven-development`. The plan + design sit in `docs/plans/` for the team's persistent implementer agents to execute. ## Reading order for the implementer @@ -50,7 +50,7 @@ The plan is grouped so an orchestrator can dispatch each group as a self-contain |---|---|---|---| | A. Infrastructure | 1, 2, 3 | small | PR-A: shared infra (model tiers + grep guard + writing-skills marker convention) | | B. Group II rewrites | 4, 5, 6, 7, 8 | small × 5 | PR-B: moderate-bleed skills (alignment-check, pr-monitoring, receiving-code-review, finishing-a-development-branch, brainstorming) | -| C. Group III rewrites | 9, 10, 11, 12, 13, 14 | medium × 6 | PR-C: heavy-bleed skills (subagent-driven-development, dispatching-parallel-agents, writing-plans, using-superpowers, executing-plans, writing-skills extension) | +| C. Group III rewrites | 9, 10, 11, 12, 13, 14 | medium × 6 | PR-C: heavy-bleed skills (subagent-driven-development, dispatching-parallel-agents, writing-plans, using-autodev, executing-plans, writing-skills extension) | | D. Documentation | 15, 15b, 15c, 16, 17 | small | PR-D: README + INSTALL.md updates | | E. Coverage table | 18 | small | PR-E: tests/cross-llm-coverage.md | @@ -774,10 +774,10 @@ git commit -m "skill(writing-plans): host-conditional plan mode + role tiers" --- -## Task 12: Rewrite `using-superpowers` (entry-point skill — important) +## Task 12: Rewrite `using-autodev` (entry-point skill — important) **Files:** -- Modify: `skills/using-superpowers/SKILL.md` +- Modify: `skills/using-autodev/SKILL.md` **Bleed:** mentions `Skill` tool; mentions `TodoWrite`; entire file structure assumes Claude tooling. @@ -838,7 +838,7 @@ Restructure the surrounding paragraph so the rule "create one tracking entry per **Step 4: Grep-clean** ```bash -guard_out="$(./tests/skill-content-grep.sh 2>&1)"; printf '%s\n' "$guard_out" | grep using-superpowers || true +guard_out="$(./tests/skill-content-grep.sh 2>&1)"; printf '%s\n' "$guard_out" | grep using-autodev || true ``` Expect no matches. @@ -846,8 +846,8 @@ Expect no matches. **Step 5: Commit** ```bash -git add skills/using-superpowers/SKILL.md -git commit -m "skill(using-superpowers): host-aware skill access + checklist tool" +git add skills/using-autodev/SKILL.md +git commit -m "skill(using-autodev): host-aware skill access + checklist tool" ``` **Verification class:** Skill content. @@ -959,9 +959,9 @@ apply only to the named host(s); unmarked content applies to every host. | Host | Install path | Native skill discovery | Notes | |---|---|---|---| -| Claude Code | `~/.claude/plugins/marketplace/superpowers/` | yes | Full Agent Teams support (experimental flag) | -| Codex | `~/.agents/skills/superpowers/` | yes | Sequential sub-agent dispatch; `/plan` slash; `/agent` switching | -| OpenCode | `~/.config/opencode/skills/superpowers/` | yes | Tool mapping documented in `.opencode/INSTALL.md` | +| Claude Code | `~/.claude/plugins/marketplace/autodev/` | yes | Full Agent Teams support (experimental flag) | +| Codex | `~/.agents/skills/autodev/` | yes | Sequential sub-agent dispatch; `/plan` slash; `/agent` switching | +| OpenCode | `~/.config/opencode/skills/autodev/` | yes | Tool mapping documented in `.opencode/INSTALL.md` | | Cursor | manual reference | partial | Plugin manifest stub; install path TBD | See `agents/model-tiers.md` for the role-based model vocabulary used across @@ -1197,7 +1197,7 @@ host-neutral. Updated whenever a skill changes. | systematic-debugging | host-neutral | host-neutral | host-neutral | host-neutral | already portable | | test-driven-development | host-neutral | host-neutral | host-neutral | host-neutral | already portable | | using-git-worktrees | host-neutral | host-neutral | host-neutral | host-neutral | already portable | -| using-superpowers | host-conditional | host-conditional | host-conditional | host-conditional | entry-point host detection | +| using-autodev | host-conditional | host-conditional | host-conditional | host-conditional | entry-point host detection | | verification-before-completion | host-neutral | host-neutral | host-neutral | host-neutral | already portable | | writing-plans | host-conditional | host-conditional | host-conditional | host-conditional | plan-mode block + role tiers | | writing-skills | host-conditional | host-conditional | host-conditional | host-conditional | marker convention | @@ -1248,6 +1248,6 @@ After alignment-check PASS: 1. Save the plan ✅ (this document). 2. Commit the plan. -3. Invoke `superpowers:alignment-check`. -4. **On PASS: STOP.** Do NOT invoke `superpowers:subagent-driven-development`. Return summary to orchestrator. +3. Invoke `autodev:alignment-check`. +4. **On PASS: STOP.** Do NOT invoke `autodev:subagent-driven-development`. Return summary to orchestrator. 5. **On FAIL:** revise based on drift items; re-run alignment-check (max 2 cycles); STOP regardless. diff --git a/docs/plans/2026-04-25-p11-p12-patterns.md b/docs/plans/2026-04-25-p11-p12-patterns.md index d77700c..3da5566 100644 --- a/docs/plans/2026-04-25-p11-p12-patterns.md +++ b/docs/plans/2026-04-25-p11-p12-patterns.md @@ -1,6 +1,6 @@ # P11/P12 Skill Patterns Implementation Plan -> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. +> **For Claude:** REQUIRED SUB-SKILL: Use autodev:executing-plans to implement this plan task-by-task. **Goal:** Add P11 (shortcut bias / band-aid fixes) and P12 (one-sided boundary wiring) as named, defined patterns across three skills: requesting-code-review, test-driven-development, runtime-launch-validation. diff --git a/docs/roadmap.md b/docs/roadmap.md index bc7679d..0d83f5a 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -6,7 +6,7 @@ This file used to track items that had been considered but deferred. Those items |---|---| | Decision log / ADRs | `skills/recording-decisions/SKILL.md` + `decisions/` directory + `decisions/0000-template.md` | | Post-merge retrospective | `skills/post-merge-retrospective/SKILL.md` + `docs/retros/` directory; wired into `pr-monitoring` exit | -| Skill-usage telemetry | `tests/skill-activation-audit.sh` (reads `.claude/superpowers-state/in-progress.jsonl`) | +| Skill-usage telemetry | `tests/skill-activation-audit.sh` (reads `.claude/autodev-state/in-progress.jsonl`) | | Brainstorming cost-control gate | 5-batch soft cap section in `skills/brainstorming/SKILL.md` | | Cross-skill consistency invariants | `tests/skill-cross-refs.sh` | diff --git a/docs/testing.md b/docs/testing.md index 6f87afe..1a2823e 100644 --- a/docs/testing.md +++ b/docs/testing.md @@ -1,6 +1,6 @@ -# Testing Superpowers Skills +# Testing Autonomous Dev Kit Skills -This document describes how to test Superpowers skills, particularly the integration tests for complex skills like `subagent-driven-development`. +This document describes how to test Autonomous Dev Kit skills, particularly the integration tests for complex skills like `subagent-driven-development`. ## Overview @@ -33,9 +33,9 @@ cd tests/claude-code ### Requirements -- Must run from the **superpowers plugin directory** (not from temp directories) +- Must run from the **autodev plugin directory** (not from temp directories) - Claude Code must be installed and available as `claude` command -- Local dev marketplace must be enabled: `"superpowers@superpowers-dev": true` in `~/.claude/settings.json` +- Local dev marketplace must be enabled: `"autodev@autodev-dev": true` in `~/.claude/settings.json` ## Integration Test: subagent-driven-development @@ -149,8 +149,8 @@ python3 tests/claude-code/analyze-token-usage.py ~/.claude/projects//dev/null || true) # When true the agent was already told to continue once; let the stop proceed. stop_hook_active=$(printf '%s' "$hook_input" | jq -r '.stop_hook_active // false' 2>/dev/null || echo "false") [ "$stop_hook_active" = "true" ] && exit 0 +last_assistant_message=$(printf '%s' "$hook_input" | jq -r '.last_assistant_message // .assistant_message // empty' 2>/dev/null || true) +transcript_path=$(printf '%s' "$hook_input" | jq -r '.transcript_path // empty' 2>/dev/null || true) +if [ -z "$last_assistant_message" ] && [ -n "$transcript_path" ] && [ -f "$transcript_path" ]; then + last_assistant_message=$(jq -rs ' + map(select((.type // "") == "assistant")) | + (last // empty) as $last | + ($last.message.content // $last.content // "") | + if type == "string" then . + elif type == "array" then ([.[] | select((.type // "") == "text") | (.text // "")] | join("\n")) + else "" end + ' "$transcript_path" 2>/dev/null || true) +fi block() { local reason="$1" - printf '{"decision":"block","reason":%s}\n' \ - "$(printf '%s' "$reason" | jq -Rs .)" - exit 2 + if command -v jq >/dev/null 2>&1; then + jq -n --arg reason "$reason" '{decision:"block",reason:$reason}' + else + printf '%s\n' "$reason" >&2 + fi + exit 0 } # ── Find locked plans ──────────────────────────────────────────────────────── @@ -59,7 +74,7 @@ while IFS= read -r plan; do # ── Hash verification: was the manifest edited behind the lock? ────────── if [ -x "$checker" ]; then if ! bash "$checker" --verify-lock "$plan" >/dev/null 2>&1; then - failures="${failures} • ${plan_name}: Scope Manifest hash does not match the lock file (.scope-lock). The manifest was edited after it was locked, bypassing the unlock path.\n" + failures="${failures} • ${plan_name}: Scope Manifest hash does not match the lock file (.scope-lock). The manifest was edited after it was locked without the amendment path.\n" fi fi @@ -71,16 +86,52 @@ while IFS= read -r plan; do fi done <<< "$locked_plans" -[ -z "$failures" ] && exit 0 +if [ -z "$failures" ]; then + completionish="false" + if printf '%s' "$last_assistant_message" | grep -qiE '\b(done|complete|completed|finished|implemented|ready|all set|final|pull request|PR created|phase complete|task complete)\b'; then + completionish="true" + fi + + waiting_for_user="false" + if printf '%s' "$last_assistant_message" | grep -qiE '(blocked|blocker|waiting for|need(s)? (your|user|human) (approval|input|confirmation)|deploy to production|production deploy|destructive|delete production|drop production)'; then + waiting_for_user="true" + fi + + if [ "$completionish" = "true" ] && [ "$waiting_for_user" != "true" ]; then + first_plan=$(printf '%s\n' "$locked_plans" | head -1) + first_plan_name=$(basename "$first_plan") + progress_file="${cwd_dir}/.autodev/state/phase-progress.jsonl" + block "Completion checkpoint — locked plan still in effect: ${first_plan_name} + +Before stopping, decide whether this is: + 1. A phase/task completion inside the locked design, or + 2. Completion of the entire locked design. + +If this is only a phase/task completion: + - Append one compact JSONL row to ${progress_file}: {\"ts\":\"\",\"ev\":\"phase\",\"pl\":\"${first_plan_name}\",\"ph\":\"\",\"st\":\"done\",\"e\":\"\",\"nx\":\"\"} + - Continue automatically into the next phase/task from the Scope Manifest. + +Only stop if one of these is true: + - The entire locked design is complete and verified. + - There is a hard blocker that requires human input. + - The next action is a production deploy or destructive production change without already-recorded human approval. + +Use autodev:verification-before-completion before any completion claim." + fi + + exit 0 +fi block "Completion blocked — scope-manifest integrity problems detected before stop: ${failures} Resolve these before declaring done: - 1. If the manifest was edited directly, go through the unlock path: + 1. If the manifest was edited directly, go through the amendment path: recording-decisions → update manifest → re-run alignment-check. 2. If the structural check failed, fix the manifest to match the plan body. 3. After resolving, run: tests/plan-scope-check.sh --verify-lock and confirm it exits 0 before stopping. -See skills/scope-lock/SKILL.md for the unlock path." +See skills/scope-lock/SKILL.md for the amendment path." + +# Unreachable: block exits. diff --git a/hooks/posttool-pr-created b/hooks/posttool-pr-created index 8879de7..ce3c67f 100755 --- a/hooks/posttool-pr-created +++ b/hooks/posttool-pr-created @@ -46,29 +46,23 @@ pr_url=$(printf '%s' "$tool_response" \ pr_hint="for the PR you just created: ${pr_url}" -# Escape a string for embedding inside a JSON string value. -escape_for_json() { - local s="$1" - s="${s//\\/\\\\}" - s="${s//\"/\\\"}" - s="${s//$'\n'/\\n}" - s="${s//$'\r'/\\r}" - s="${s//$'\t'/\\t}" - printf '%s' "$s" -} - reminder="" reminder+="You just ran \`gh pr create\`. " -reminder+="You MUST now invoke \`superpowers:pr-monitoring\` ${pr_hint}. " +reminder+="You MUST now invoke \`autodev:pr-monitoring\` ${pr_hint}. " reminder+="Prefer a single monitoring agent covering all PRs in this session to avoid GitHub API rate limits. " reminder+="One agent per PR is acceptable if the PRs are on unrelated codebases or a previous shared monitor was rate-limited. " reminder+="Draft PRs still trigger CI and receive bot reviews, so monitoring is required regardless of draft state. " reminder+="Do NOT declare the task complete until pr-monitoring has been started. " -reminder+="See superpowers:pr-monitoring for usage." +reminder+="See autodev:pr-monitoring for usage." reminder+="" -escaped=$(escape_for_json "$reminder") +emit_additional_context() { + local event_name="$1" + local context="$2" + jq -n --arg event "$event_name" --arg context "$context" \ + '{hookSpecificOutput:{hookEventName:$event,additionalContext:$context}}' +} -printf '{"additional_context":"%s"}\n' "$escaped" +emit_additional_context "PostToolUse" "$reminder" exit 0 diff --git a/hooks/pre-compact-snapshot b/hooks/pre-compact-snapshot index 18a179d..13364d4 100755 --- a/hooks/pre-compact-snapshot +++ b/hooks/pre-compact-snapshot @@ -2,13 +2,13 @@ # hooks/pre-compact-snapshot # PreCompact hook: snapshots the current lock state before a context compaction. # -# Writes each locked plan's name and manifest hash to the superpowers-state +# Writes each locked plan's name and manifest hash to the autodev-state # file so that the SessionStart hook can detect lock-state changes after the # compacted context is restored (e.g., if a plan was locked or unlocked during # a long session and then the context was compacted, the resumption context will # include the lock state so the agent does not re-derive intent). # -# Also injects the snapshot as additional_context so the compacted transcript +# Also injects the snapshot as hookSpecificOutput.additionalContext so the compacted transcript # itself retains the lock state. # # Global opt-out: set SUPERPOWERS_HOOKS_DISABLE=1 @@ -46,8 +46,21 @@ if [ -d "$plans_dir" ]; then manifest_hash=$(awk 'NF && !/^#/ {print; exit}' "$lock_file" 2>/dev/null || true) state_section="${state_section} ${plan_name}: ${status_line} (manifest-sha256: ${manifest_hash:-unknown})\n" else + manifest_hash="" state_section="${state_section} ${plan_name}: ${status_line} (no lock file — not yet locked or lock file missing)\n" fi + + ts=$(date -u +"%Y-%m-%dT%H:%M:%SZ") + entry=$(jq -nc \ + --arg ts "$ts" \ + --arg pl "$plan_name" \ + --arg st "$status_line" \ + --arg h "$manifest_hash" \ + '{ts:$ts,ev:"lock",pl:$pl,st:$st} + (if $h != "" then {h:$h} else {} end)' 2>/dev/null || true) + if [ -n "$entry" ]; then + pending_entries="${pending_entries:-}${entry} +" + fi done < <(find "$plans_dir" -maxdepth 1 -name '*.md' \ ! -name '*-design.md' ! -name 'README.md' 2>/dev/null \ | grep -v '\.scope-lock' | sort || true) @@ -58,43 +71,33 @@ if [ -z "$state_section" ]; then exit 0 fi -# ── Append to superpowers-state file ───────────────────────────────────────── -STATE_DIR="${cwd_dir}/.claude/superpowers-state" +# ── Append to autodev-state file ───────────────────────────────────────── +STATE_DIR="${cwd_dir}/.claude/autodev-state" mkdir -p "$STATE_DIR" 2>/dev/null || true STATE_FILE="${STATE_DIR}/in-progress.jsonl" LOCK_FILE="${STATE_DIR}/.in-progress.lock" ts=$(date -u +"%Y-%m-%dT%H:%M:%SZ") -entry=$(jq -nc \ - --arg ts "$ts" \ - --arg tool "PreCompact" \ - --arg detail "lock-snapshot: ${state_section}" \ - '{ts: $ts, tool: $tool, detail: $detail}' 2>/dev/null || true) - -if [ -n "$entry" ]; then - printf '%s\n' "$entry" >> "$STATE_FILE" 2>/dev/null || true + +if [ -n "${pending_entries:-}" ]; then + printf '%s' "$pending_entries" >> "$STATE_FILE" 2>/dev/null || true fi -# ── Inject as additional_context ───────────────────────────────────────────── -snapshot_text=" +# ── Inject as additionalContext ────────────────────────────────────────────── +snapshot_text=" Pre-compaction scope-lock state (verify these after resuming): ${state_section} If any plan shows Locked status, treat the locked manifest as the authoritative contract. Do not re-derive scope from the conversation history. Use tests/plan-scope-check.sh --verify-lock to confirm the hash is intact. -" - -escape_for_json() { - local s="$1" - s="${s//\\/\\\\}" - s="${s//\"/\\\"}" - s="${s//$'\n'/\\n}" - s="${s//$'\r'/\\r}" - s="${s//$'\t'/\\t}" - printf '%s' "$s" -} +" -snapshot_escaped=$(escape_for_json "$snapshot_text") +emit_additional_context() { + local event_name="$1" + local context="$2" + jq -n --arg event "$event_name" --arg context "$context" \ + '{hookSpecificOutput:{hookEventName:$event,additionalContext:$context}}' +} -printf '{"additional_context":"%s"}\n' "$snapshot_escaped" +emit_additional_context "PreCompact" "$snapshot_text" exit 0 diff --git a/hooks/pre-tool-scope-guard b/hooks/pre-tool-scope-guard index a9c3e72..b9b7113 100755 --- a/hooks/pre-tool-scope-guard +++ b/hooks/pre-tool-scope-guard @@ -12,7 +12,12 @@ # Write / Edit / MultiEdit tool # — *.scope-lock files (agent path: hooks/scope-lock-apply via Bash; # operator path: SUPERPOWERS_SCOPE_LOCK_WRITE=1) -# — docs/plans/*.md when plan is Locked (unless SUPERPOWERS_PLAN_LOCK_WRITE=1) +# +# Locked plan/design markdown is intentionally not blocked here. The lock is +# over the Scope Manifest hash, not every explanatory paragraph. Design +# backports, bug notes, and assumption corrections are legitimate as long as +# the manifest hash still verifies; manifest drift is caught before push/PR +# creation and at Stop time. # # Global opt-out: set SUPERPOWERS_HOOKS_DISABLE=1 in the *operator's* terminal # environment before starting the session. The agent cannot set this itself. @@ -104,7 +109,7 @@ case "$tool_name" in locked_plan=$(find_locked_plan) if [ -n "$locked_plan" ]; then if ! verify_lock "$locked_plan"; then - block "Locked plan hash mismatch: $(basename "$locked_plan") — the Scope Manifest has been modified since it was locked. This means either the plan was edited directly (bypassing the unlock path) or the scope-lock file was corrupted. Resolve via the scope-lock unlock path (recording-decisions → update manifest → re-run alignment-check) before pushing or creating PRs." + block "Locked plan hash mismatch: $(basename "$locked_plan") — the Scope Manifest has been modified since it was locked. This means either the manifest was edited without the amendment path or the scope-lock file was corrupted. Resolve via the scope-lock amendment path (recording-decisions → update manifest → re-run alignment-check) before pushing or creating PRs." fi fi fi @@ -155,21 +160,17 @@ case "$tool_name" in _reason="${_reason} and writes the lock file via shell redirection (which is not blocked)." _reason="${_reason} Direct Write/Edit calls break the manifest integrity guarantee" _reason="${_reason} and allow silent scope tampering." - _reason="${_reason} To update the lock legitimately after a scope reduction:" - _reason="${_reason} use the unlock path (recording-decisions → update manifest" + _reason="${_reason} To update the lock legitimately after a manifest amendment:" + _reason="${_reason} use the amendment path (recording-decisions → update manifest" _reason="${_reason} → re-run alignment-check → re-run scope-lock-apply)." block "$_reason" fi fi - # ── 6. Locked plan files (blocked unless sentinel env var) ────────── - if printf '%s' "$fpath" | grep -qE 'docs/plans/[^/]+\.md$'; then - if [ "${SUPERPOWERS_PLAN_LOCK_WRITE:-}" != "1" ] && [ -f "$fpath" ]; then - if grep -q '\*\*Status:\*\* Locked' "$fpath" 2>/dev/null; then - block "Editing '$(basename "$fpath")' is blocked — this plan is Locked. Direct plan edits bypass the unlock path and silently break the manifest hash. To modify the plan: (1) invoke recording-decisions to document the approved scope reduction as an ADR, (2) follow the scope-lock unlock path (update manifest → re-stamp lock). The unlock path is defined in skills/scope-lock/SKILL.md." - fi - fi - fi + # ── 6. Locked plan/design files ───────────────────────────────────── + # Allowed here. See file header: the push/PR/Stop hash guards enforce + # the Scope Manifest invariant without preventing legitimate design + # backports or non-manifest corrections. done <<< "$file_paths" ;; esac diff --git a/hooks/pretool-pr-review-reminder b/hooks/pretool-pr-review-reminder index 925676c..a74bbfa 100755 --- a/hooks/pretool-pr-review-reminder +++ b/hooks/pretool-pr-review-reminder @@ -29,17 +29,6 @@ cmd=$(printf '%s' "$hook_input" | jq -r '.tool_input.command // empty' 2>/dev/nu # Only act on PR creation commands. printf '%s' "$cmd" | grep -q 'gh pr create' || exit 0 -# Escape a string for embedding inside a JSON string value. -escape_for_json() { - local s="$1" - s="${s//\\/\\\\}" - s="${s//\"/\\\"}" - s="${s//$'\n'/\\n}" - s="${s//$'\r'/\\r}" - s="${s//$'\t'/\\t}" - printf '%s' "$s" -} - reminder=$(cat <<'REMINDER' Before and after running `gh pr create`: @@ -54,8 +43,13 @@ Before and after running `gh pr create`: REMINDER ) -escaped=$(escape_for_json "$reminder") +emit_additional_context() { + local event_name="$1" + local context="$2" + jq -n --arg event "$event_name" --arg context "$context" \ + '{hookSpecificOutput:{hookEventName:$event,additionalContext:$context}}' +} -printf '{"additional_context":"%s"}\n' "$escaped" +emit_additional_context "PreToolUse" "$reminder" exit 0 diff --git a/hooks/prompt-strict-interpretation b/hooks/prompt-strict-interpretation index b9d0bfb..e3b4359 100755 --- a/hooks/prompt-strict-interpretation +++ b/hooks/prompt-strict-interpretation @@ -5,7 +5,7 @@ # to rescope, collapse PRs, or skip pipeline discipline — and a locked plan # exists in the current workspace. # -# Does NOT block the prompt. Injects additional_context so the model sees the +# Does NOT block the prompt. Injects hookSpecificOutput.additionalContext so the model sees the # reminder before it starts planning its response. # # Global opt-out: set SUPERPOWERS_HOOKS_DISABLE=1 @@ -111,37 +111,51 @@ Locked plan: ${locked_plan_name} This phrase has historically been used as license to rescope, collapse PRs, or skip pipeline discipline. Under a Locked plan it authorizes NONE of those things. -Mandated interpretations (from skills/using-superpowers/SKILL.md): +Mandated interpretations (from skills/using-autodev/SKILL.md): "reorder as needed" → reorder tasks within the same PR only; manifest unchanged "create a PR" → create the number of PRs in the Scope Manifest's PR Grouping table "test locally" → run every task's declared verification steps; CI still runs "make it work" → implement the full manifest; surface blockers, do not trim scope - "ship a demo" → no demo mode exists; ship the locked manifest or invoke unlock path + "ship a demo" → no demo mode exists; ship the locked manifest or invoke amendment path "be quick / be efficient" → parallelism, not skipping "go autonomous / auto mode"→ no discipline bypass; pipeline runs in full regardless "go ahead / just do it" → proceed with the locked manifest; gates still apply If the user's intent genuinely conflicts with the locked manifest, STOP and ask. Do not pick a looser interpretation and proceed. The locked manifest wins until -the user goes through the unlock path (recording-decisions + re-run alignment-check). +the user goes through the amendment path (recording-decisions + re-run alignment-check). -See skills/scope-lock/SKILL.md for the unlock path. +See skills/scope-lock/SKILL.md for the amendment path. REMINDER ) -# Escape for JSON embedding. -escape_for_json() { - local s="$1" - s="${s//\\/\\\\}" - s="${s//\"/\\\"}" - s="${s//$'\n'/\\n}" - s="${s//$'\r'/\\r}" - s="${s//$'\t'/\\t}" - printf '%s' "$s" +emit_additional_context() { + local event_name="$1" + local context="$2" + if command -v jq >/dev/null 2>&1; then + jq -n --arg event "$event_name" --arg context "$context" \ + '{hookSpecificOutput:{hookEventName:$event,additionalContext:$context}}' + return 0 + fi + if command -v python3 >/dev/null 2>&1; then + EVENT_NAME="$event_name" CONTEXT="$context" python3 - <<'PY' +import json +import os + +print(json.dumps({ + "hookSpecificOutput": { + "hookEventName": os.environ["EVENT_NAME"], + "additionalContext": os.environ["CONTEXT"], + } +})) +PY + return 0 + fi + # No safe JSON encoder available. Exit successfully with no output rather + # than risk invalid hook JSON that breaks the host. + return 0 } -reminder_escaped=$(escape_for_json "$reminder") - -printf '{"additional_context":"%s"}\n' "$reminder_escaped" +emit_additional_context "UserPromptSubmit" "$reminder" exit 0 diff --git a/hooks/record-activity b/hooks/record-activity index d5ab221..b1486e7 100755 --- a/hooks/record-activity +++ b/hooks/record-activity @@ -1,7 +1,7 @@ #!/usr/bin/env bash -# PostToolUse hook: record superpowers-relevant activity +# PostToolUse hook: record autodev-relevant activity # -# Appends an entry to .claude/superpowers-state/in-progress.jsonl every time +# Appends a compact entry to .claude/autodev-state/in-progress.jsonl every time # the lead/orchestrator agent invokes a Skill, Agent, or Task* tool # (Task, TaskCreate, TaskList, TaskGet, TaskUpdate, etc.). The session-start # hook replays this file on compact|resume so the agent can resume the @@ -24,14 +24,13 @@ case "$tool_name" in Skill) skill=$(printf '%s' "$hook_input" | jq -r '.tool_input.skill // ""' 2>/dev/null || true) args=$(printf '%s' "$hook_input" | jq -r '.tool_input.args // ""' 2>/dev/null || true) - detail="skill=${skill}" - [ -n "$args" ] && detail="${detail} args=${args:0:80}" + ev="skill" ;; Agent|Task) sa_type=$(printf '%s' "$hook_input" | jq -r '.tool_input.subagent_type // "general-purpose"' 2>/dev/null || true) desc=$(printf '%s' "$hook_input" | jq -r '.tool_input.description // ""' 2>/dev/null || true) bg=$(printf '%s' "$hook_input" | jq -r '.tool_input.run_in_background // false' 2>/dev/null || true) - detail="agent=${sa_type} desc=\"${desc:0:120}\" bg=${bg}" + ev="agent" ;; Task*) # Task family tools (TaskCreate/TaskList/TaskGet/TaskUpdate/etc.) @@ -40,27 +39,45 @@ case "$tool_name" in sa_type=$(printf '%s' "$hook_input" | jq -r '.tool_input.subagent_type // ""' 2>/dev/null || true) desc=$(printf '%s' "$hook_input" | jq -r '.tool_input.description // .tool_input.title // ""' 2>/dev/null || true) task_id=$(printf '%s' "$hook_input" | jq -r '.tool_input.id // .tool_input.task_id // ""' 2>/dev/null || true) - detail="task_tool=${tool_name}" - [ -n "$sa_type" ] && detail="${detail} agent=${sa_type}" - [ -n "$task_id" ] && detail="${detail} id=${task_id}" - [ -n "$desc" ] && detail="${detail} desc=\"${desc:0:120}\"" + ev="task" ;; *) exit 0 ;; esac -STATE_DIR="${cwd_dir}/.claude/superpowers-state" +STATE_DIR="${cwd_dir}/.claude/autodev-state" mkdir -p "$STATE_DIR" 2>/dev/null || exit 0 STATE_FILE="${STATE_DIR}/in-progress.jsonl" LOCK_FILE="${STATE_DIR}/.in-progress.lock" ts=$(date -u +"%Y-%m-%dT%H:%M:%SZ") -entry=$(jq -nc \ - --arg ts "$ts" \ - --arg tool "$tool_name" \ - --arg detail "$detail" \ - '{ts: $ts, tool: $tool, detail: $detail}' 2>/dev/null || true) +case "$ev" in + skill) + entry=$(jq -nc \ + --arg ts "$ts" \ + --arg sk "$skill" \ + --arg args "${args:0:80}" \ + '{ts:$ts,ev:"skill",sk:$sk} + (if $args != "" then {args:$args} else {} end)' 2>/dev/null || true) + ;; + agent) + entry=$(jq -nc \ + --arg ts "$ts" \ + --arg ag "$sa_type" \ + --arg d "${desc:0:120}" \ + --argjson bg "$bg" \ + '{ts:$ts,ev:"agent",ag:$ag,bg:$bg} + (if $d != "" then {d:$d} else {} end)' 2>/dev/null || true) + ;; + task) + entry=$(jq -nc \ + --arg ts "$ts" \ + --arg tt "$tool_name" \ + --arg ag "$sa_type" \ + --arg id "$task_id" \ + --arg d "${desc:0:120}" \ + '{ts:$ts,ev:"task",tt:$tt} + (if $ag != "" then {ag:$ag} else {} end) + (if $id != "" then {id:$id} else {} end) + (if $d != "" then {d:$d} else {} end)' 2>/dev/null || true) + ;; +esac [ -z "$entry" ] && exit 0 # Append + cap under a lock so concurrent invocations from lead + subagents diff --git a/hooks/scope-lock-apply b/hooks/scope-lock-apply index 5dc858a..6b2a885 100755 --- a/hooks/scope-lock-apply +++ b/hooks/scope-lock-apply @@ -52,6 +52,7 @@ trap 'rm -f "$tmpfile"' EXIT awk ' /^## Scope Manifest[[:space:]]*$/ { in_section = 1; print; next } in_section && /^## / { in_section = 0 } + in_section && /^### Task [0-9]+[A-Za-z]*([: ]|$)/ { in_section = 0 } in_section { print } ' "$plan" > "$tmpfile" diff --git a/hooks/session-start b/hooks/session-start index 7c5755f..8fa354b 100755 --- a/hooks/session-start +++ b/hooks/session-start @@ -1,10 +1,10 @@ #!/usr/bin/env bash -# SessionStart hook for superpowers plugin +# SessionStart hook for autodev plugin # # On every session start (startup|resume|clear|compact) this loads the -# using-superpowers skill so the skills system is available before the first +# using-autodev skill so the skills system is available before the first # turn. On compact|resume it ALSO injects a "resumption context" block that: -# - replays recent superpowers activity from .claude/superpowers-state/in-progress.jsonl +# - replays recent autodev activity from .claude/autodev-state/in-progress.jsonl # (so a lead orchestrator knows which skills + subagents were in flight), and # - extracts the first user message from the session transcript # (so a subagent that just compacted can re-read its original task). @@ -31,7 +31,7 @@ if command -v jq >/dev/null 2>&1; then [ -n "$cwd_from_hook" ] && cwd_dir="$cwd_from_hook" fi -STATE_DIR="${cwd_dir}/.claude/superpowers-state" +STATE_DIR="${cwd_dir}/.claude/autodev-state" STATE_FILE="${STATE_DIR}/in-progress.jsonl" # Wipe stale state at the start of a brand-new (or cleared) session. @@ -48,7 +48,15 @@ if { [ "$source_kind" = "compact" ] || [ "$source_kind" = "resume" ]; } && comma activity="" if [ -f "$STATE_FILE" ]; then activity=$(tail -n 30 "$STATE_FILE" \ - | jq -r '"- " + .ts + " " + .tool + " " + (.detail // "")' 2>/dev/null \ + | jq -r ' + "- " + (.ts // "?") + " " + + (if (.ev // "") == "skill" then "skill " + (.sk // "?") + (if .args then " " + .args else "" end) + elif (.ev // "") == "agent" then "agent " + (.ag // "?") + (if .d then " " + .d else "" end) + elif (.ev // "") == "task" then "task " + (.tt // "?") + (if .id then " id=" + .id else "" end) + (if .d then " " + .d else "" end) + elif (.ev // "") == "lock" then "lock " + (.pl // "?") + " " + (.st // "?") + (if .h then " h=" + .h[0:12] else "" end) + elif (.ev // "") == "phase" then "phase " + (.pl // "?") + " " + (.ph // "?") + " " + (.st // "?") + (if .nx then " nx=" + .nx else "" end) + else (.tool // "?") + " " + (.detail // .d // "") + end)' 2>/dev/null \ || tail -n 30 "$STATE_FILE") fi @@ -66,7 +74,7 @@ if { [ "$source_kind" = "compact" ] || [ "$source_kind" = "resume" ]; } && comma fi if [ -n "$activity" ] || [ -n "$original_task" ]; then - resumption_section=$'\n\n' + resumption_section=$'\n\n' case "$source_kind" in compact) source_phrase="just had a context-compaction event" ;; resume) source_phrase="just resumed from a previous transcript" ;; @@ -75,7 +83,7 @@ if { [ "$source_kind" = "compact" ] || [ "$source_kind" = "resume" ]; } && comma resumption_section+=$'\nThe session '"$source_phrase"$'. BEFORE answering the next message, reorient yourself using the context below. If you were mid-pipeline (brainstorming → writing-plans → alignment-check → subagent-driven-development → finishing-a-development-branch → pr-monitoring), pick up where you left off rather than re-deriving intent.' if [ -n "$original_task" ]; then # The first user message can contain arbitrary markup (tag-like - # tokens, even a literal ""), + # tokens, even a literal ""), # which would terminate or nest inside the resumption block we # just opened. Wrap it in a fenced code block and pick a fence # length that does not appear inside the content. @@ -86,47 +94,62 @@ if { [ "$source_kind" = "compact" ] || [ "$source_kind" = "resume" ]; } && comma resumption_section+=$'\n\n## Original task (first user message in this session)\n\n'"${fence}"$'\n'"${original_task}"$'\n'"${fence}" fi if [ -n "$activity" ]; then - resumption_section+=$'\n\n## Recent superpowers activity (most recent 30 events)\n\n'"$activity" - resumption_section+=$'\n\nIf any of those entries are dispatched subagents, check their status (still active? errored? rate-limited? zombied?) using your host\'s task-listing mechanism before proceeding. See superpowers:subagent-driven-development for the watchdog cadence and host-specific tools.' + resumption_section+=$'\n\n## Recent autodev activity (most recent 30 events)\n\n'"$activity" + resumption_section+=$'\n\nIf any of those entries are dispatched subagents, check their status (still active? errored? rate-limited? zombied?) using your host\'s task-listing mechanism before proceeding. See autodev:subagent-driven-development for the watchdog cadence and host-specific tools.' fi - resumption_section+=$'\n' + resumption_section+=$'\n' fi fi # Legacy skills warning (preserved from upstream). warning_message="" -legacy_skills_dir="${HOME}/.config/superpowers/skills" +legacy_skills_dir="${HOME}/.config/autodev/skills" if [ -d "$legacy_skills_dir" ]; then - warning_message=$'\n\nIN YOUR FIRST REPLY AFTER SEEING THIS MESSAGE YOU MUST TELL THE USER:⚠️ **WARNING:** Superpowers now uses Claude Code\'s skills system. Custom skills in ~/.config/superpowers/skills will not be read. Move custom skills to ~/.claude/skills instead. To make this message go away, remove ~/.config/superpowers/skills' + warning_message=$'\n\nIN YOUR FIRST REPLY AFTER SEEING THIS MESSAGE YOU MUST TELL THE USER:⚠️ **WARNING:** Autonomous Dev Kit now uses Claude Code\'s skills system. Custom skills in ~/.config/autodev/skills will not be read. Move custom skills to ~/.claude/skills instead. To make this message go away, remove ~/.config/autodev/skills' fi -using_superpowers_content=$(cat "${PLUGIN_ROOT}/skills/using-superpowers/SKILL.md" 2>&1 || echo "Error reading using-superpowers skill") - -# Escape string for JSON embedding using bash parameter substitution. -escape_for_json() { - local s="$1" - s="${s//\\/\\\\}" - s="${s//\"/\\\"}" - s="${s//$'\n'/\\n}" - s="${s//$'\r'/\\r}" - s="${s//$'\t'/\\t}" - printf '%s' "$s" -} +using_autodev_content=$(cat "${PLUGIN_ROOT}/skills/using-autodev/SKILL.md" 2>&1 || echo "Error reading using-autodev skill") + +session_context=$(cat < +You have autodev. + +**Below is the full content of your 'autodev:using-autodev' skill - your introduction to using skills. For all other skills, use the 'Skill' tool:** -using_superpowers_escaped=$(escape_for_json "$using_superpowers_content") -warning_escaped=$(escape_for_json "$warning_message") -resumption_escaped=$(escape_for_json "$resumption_section") +${using_autodev_content} -session_context="\nYou have superpowers.\n\n**Below is the full content of your 'superpowers:using-superpowers' skill - your introduction to using skills. For all other skills, use the 'Skill' tool:**\n\n${using_superpowers_escaped}\n\n${warning_escaped}${resumption_escaped}\n" +${warning_message}${resumption_section} + +CONTEXT +) -cat </dev/null 2>&1; then + jq -n --arg event "$event_name" --arg context "$context" \ + '{hookSpecificOutput:{hookEventName:$event,additionalContext:$context}}' + return 0 + fi + if command -v python3 >/dev/null 2>&1; then + EVENT_NAME="$event_name" CONTEXT="$context" python3 - <<'PY' +import json +import os + +print(json.dumps({ + "hookSpecificOutput": { + "hookEventName": os.environ["EVENT_NAME"], + "additionalContext": os.environ["CONTEXT"], + } +})) +PY + return 0 + fi + # No safe JSON encoder available. Exit successfully with no output rather + # than risk invalid hook JSON that breaks the host. + return 0 } -EOF + +emit_additional_context "SessionStart" "$session_context" exit 0 diff --git a/hooks/subagent-scope-guard b/hooks/subagent-scope-guard index 601b281..22e5190 100755 --- a/hooks/subagent-scope-guard +++ b/hooks/subagent-scope-guard @@ -1,13 +1,13 @@ #!/usr/bin/env bash # hooks/subagent-scope-guard -# SubagentStop hook: checks that a subagent did not modify protected files -# (*.scope-lock, locked docs/plans/*.md) as part of its work. +# SubagentStop hook: checks that a subagent did not modify .scope-lock files +# or drift a locked Scope Manifest as part of its work. # # A subagent should never write scope-lock files directly (only alignment-check -# via the scope-lock skill does that) and should never edit a locked plan file -# (only the unlock path does that). If either is detected the subagent's stop -# is blocked so the lead agent is alerted before the subagent's changes are -# accepted. +# via the scope-lock skill does that). Locked plan/design markdown may be +# backported, but the Scope Manifest hash must still verify. If either protected +# invariant is violated, the subagent's stop is blocked so the lead agent is +# alerted before the subagent's changes are accepted. # # Honoured stop_hook_active flag to avoid infinite loops — the guard fires once. # @@ -55,16 +55,7 @@ if command -v git >/dev/null 2>&1; then done <<< "$scope_lock_dirty" fi - # Uncommitted changes to docs/plans/*.md - plan_dirty=$(git status --porcelain 2>/dev/null \ - | awk '{print $2}' | grep '^docs/plans/.*\.md$' | grep -v '\.scope-lock' || true) - if [ -n "$plan_dirty" ]; then - while IFS= read -r f; do - violations="${violations} • Uncommitted change to plan file: ${f}\n" - done <<< "$plan_dirty" - fi - - # Last commit: did it touch scope-lock or locked plan files? + # Last commit: did it touch scope-lock files? if git rev-parse --verify HEAD >/dev/null 2>&1; then last_commit_files=$(git diff-tree --no-commit-id -r --name-only HEAD 2>/dev/null || true) @@ -75,16 +66,20 @@ if command -v git >/dev/null 2>&1; then done <<< "$lock_in_commit" fi - plans_in_commit=$(printf '%s' "$last_commit_files" \ - | grep '^docs/plans/.*\.md$' | grep -v '\.scope-lock' || true) - if [ -n "$plans_in_commit" ]; then - while IFS= read -r f; do - # Only flag if the plan is currently Locked - if [ -f "$f" ] && grep -q '\*\*Status:\*\* Locked' "$f" 2>/dev/null; then - violations="${violations} • Last commit modified a Locked plan file: ${f}\n" - fi - done <<< "$plans_in_commit" - fi + fi + + # Locked plan files may be edited for design backports or notes, but + # their Scope Manifest hash must still match the lock file. + checker="${cwd_dir}/tests/plan-scope-check.sh" + if [ -x "$checker" ] && [ -d "${cwd_dir}/docs/plans" ]; then + locked_plans=$(grep -rl '\*\*Status:\*\* Locked' "${cwd_dir}/docs/plans" 2>/dev/null \ + | grep '\.md$' | grep -v '\.scope-lock' || true) + while IFS= read -r plan; do + [ -z "$plan" ] && continue + if ! bash "$checker" --verify-lock "$plan" >/dev/null 2>&1; then + violations="${violations} • Locked Scope Manifest hash mismatch: ${plan#${cwd_dir}/}\n" + fi + done <<< "$locked_plans" fi cd "$_saved_pwd" @@ -96,13 +91,14 @@ fi block "Subagent stop blocked — protected files were modified: ${violations} -Subagents must not write .scope-lock files or edit Locked plan files directly. -These files are controlled exclusively by the scope-lock skill via the unlock path. +Subagents must not write .scope-lock files or change a Locked Scope Manifest +without the amendment path. Non-manifest design backports are allowed if the +manifest hash still verifies. Before this subagent's changes are accepted: - 1. Revert the protected-file changes (git checkout -- ). - 2. If a scope change is genuinely needed, surface it to the lead agent and - go through the unlock path: recording-decisions → update manifest → + 1. Revert unauthorized .scope-lock or manifest changes. + 2. If a manifest change is genuinely needed, surface it to the lead agent and + go through the amendment path: recording-decisions → update manifest → re-run alignment-check. -See skills/scope-lock/SKILL.md for the unlock path." +See skills/scope-lock/SKILL.md for the amendment path." diff --git a/lib/skills-core.js b/lib/skills-core.js index 5e5bb70..4a613b4 100644 --- a/lib/skills-core.js +++ b/lib/skills-core.js @@ -55,7 +55,7 @@ function extractFrontmatter(filePath) { * Find all SKILL.md files in a directory recursively. * * @param {string} dir - Directory to search - * @param {string} sourceType - 'personal' or 'superpowers' for namespacing + * @param {string} sourceType - 'personal' or 'autodev' for namespacing * @param {number} maxDepth - Maximum recursion depth (default: 3) * @returns {Array<{path: string, name: string, description: string, sourceType: string}>} */ @@ -98,20 +98,20 @@ function findSkillsInDir(dir, sourceType, maxDepth = 3) { /** * Resolve a skill name to its file path, handling shadowing - * (personal skills override superpowers skills). + * (personal skills override autodev skills). * - * @param {string} skillName - Name like "superpowers:brainstorming" or "my-skill" - * @param {string} superpowersDir - Path to superpowers skills directory + * @param {string} skillName - Name like "autodev:brainstorming" or "my-skill" + * @param {string} autodevDir - Path to autodev skills directory * @param {string} personalDir - Path to personal skills directory * @returns {{skillFile: string, sourceType: string, skillPath: string} | null} */ -function resolveSkillPath(skillName, superpowersDir, personalDir) { - // Strip superpowers: prefix if present - const forceSuperpowers = skillName.startsWith('superpowers:'); - const actualSkillName = forceSuperpowers ? skillName.replace(/^superpowers:/, '') : skillName; +function resolveSkillPath(skillName, autodevDir, personalDir) { + // Strip autodev: prefix if present + const forceAutodev = skillName.startsWith('autodev:'); + const actualSkillName = forceAutodev ? skillName.replace(/^autodev:/, '') : skillName; - // Try personal skills first (unless explicitly superpowers:) - if (!forceSuperpowers && personalDir) { + // Try personal skills first (unless explicitly autodev:) + if (!forceAutodev && personalDir) { const personalPath = path.join(personalDir, actualSkillName); const personalSkillFile = path.join(personalPath, 'SKILL.md'); if (fs.existsSync(personalSkillFile)) { @@ -123,14 +123,14 @@ function resolveSkillPath(skillName, superpowersDir, personalDir) { } } - // Try superpowers skills - if (superpowersDir) { - const superpowersPath = path.join(superpowersDir, actualSkillName); - const superpowersSkillFile = path.join(superpowersPath, 'SKILL.md'); - if (fs.existsSync(superpowersSkillFile)) { + // Try autodev skills + if (autodevDir) { + const autodevPath = path.join(autodevDir, actualSkillName); + const autodevSkillFile = path.join(autodevPath, 'SKILL.md'); + if (fs.existsSync(autodevSkillFile)) { return { - skillFile: superpowersSkillFile, - sourceType: 'superpowers', + skillFile: autodevSkillFile, + sourceType: 'autodev', skillPath: actualSkillName }; } diff --git a/skills/adversarial-design-review/SKILL.md b/skills/adversarial-design-review/SKILL.md index 0c17549..ec13cba 100644 --- a/skills/adversarial-design-review/SKILL.md +++ b/skills/adversarial-design-review/SKILL.md @@ -3,6 +3,8 @@ name: adversarial-design-review description: Use after a design or implementation plan is drafted, before downstream skills accept it - adversarially attacks the ideas in the artifact (not just structural coverage) to surface unstated assumptions, repo-precedent conflicts, YAGNI violations, missing failure modes, security gaps, and simpler alternatives the author didn't consider --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Adversarial Design / Plan Review ## Overview @@ -82,11 +84,14 @@ checklist is the floor, not the ceiling. Additional findings are welcome. | Class | Definition | |---|---| -| **Unstated assumptions** | Load-bearing claims that aren't written down. "We assume the upstream API is idempotent." "We assume single-tenant." "We assume the user has admin." List them. Flag any where, if the assumption is wrong, the design collapses. | +| **Project-guidance conflicts** | Read `docs/design-guidance.md` or equivalent project guidance. Does the artifact violate product direction, architecture constraints, UX/domain principles, quality/security/ops requirements, or non-goals? Cite both the guidance path/section and the conflicting design/plan section. If guidance is missing and the design does not show Q&A capture, flag it. | +| **Assumptions under attack** | Load-bearing claims, stated or unstated. "We assume the upstream API is idempotent." "We assume single-tenant." "We assume the user has admin." Challenge each assumption, name how it could be false, and flag any where a false assumption collapses the design. | | **Repo-precedent conflicts** | Does this design fight existing patterns, skills, or conventions in this repo? Cite the conflicting `path/file.md:line`. If the design proposes a new pattern that contradicts an established one, the design must justify the divergence. | | **YAGNI violations** | Features in the design that aren't justified by stated requirements. Configuration knobs nobody asked for. Generality nobody needs. Future-proofing for cases that may never arrive. | | **Missing failure modes** | What fails first under partial failure, network partition, restart-mid-operation, malformed input, adversarial input, the dependency being down? If the design doesn't address it, flag it. | -| **Security / privacy at architecture level** | Auth boundaries, secret flow, blast radius on compromise, PII exposure, log leakage, CSRF/SSRF/auth-confused-deputy at the design level (not at the code level — that's `requesting-code-review`'s job). | +| **Security / privacy at architecture level** | Auth/authz boundaries, secret flow, least privilege, blast radius on compromise, PII exposure, log leakage, dependency/trust boundary, abuse case, CSRF/SSRF/auth-confused-deputy at the design level (not at the code level — that's `requesting-code-review`'s job). | +| **Infrastructure impact** | Does the design create/change/destroy cloud resources, queues, storage, migrations, network exposure, secrets, IAM, scaling, cost, deploy order, or rollback requirements? If impact is absent or hand-waved, flag it. If production approval is required, it must be explicit. | +| **Multi-component validation** | Does the design prove the real boundary works across components (API+DB, app+worker, frontend+backend, plugin+host, CLI+service, IaC+runtime)? Mock-only validation on both sides is insufficient unless justified. | | **Rollback story** | How do we undo this if it goes wrong in production? For any change class that runtime-launch-validation already triggers on (build/deployment/version pins/startup config/migrations/plugin loading), the design MUST specify a rollback path. If absent → finding. | | **Simpler alternative not considered** | Name the laziest plausible solution. Did the design consider it and reject it for stated reasons? If not → finding. "Couldn't this be a flat file?" "Couldn't this be a cron job?" "Couldn't this be a single SQL view?" | | **User-intent drift** | Re-read the original ask. Does the design solve what the user asked for, or does it solve a different problem that was easier to design for? Compare the design's stated goals against the user's stated goals; flag drift. | @@ -102,6 +107,8 @@ inherits the design's blast radius) and adds: | **Verification-class mismatch** | For each task, does its verification step match its change class per the table in `skills/writing-plans/SKILL.md` ("Verification per change class")? A schema migration verified by unit tests = finding. An API endpoint with no curl invocation = finding. | | **Hidden serial dependencies** | Tasks the plan claims are independent but actually share state (same file, same DB row, same config key). If executed in parallel, they'll collide. Flag any such pair. | | **Missing rollback wiring** | The design specifies a rollback story (per the design-phase class above). Is it actually implemented in the plan as a task or step? Or is it a paragraph nobody is going to write code for? | +| **Missing integration proof** | For multi-component changes, does the plan include an end-to-end or integration verification that exercises the real boundary? If it only tests each component with mocks, flag it unless the design explicitly justified that as sufficient. | +| **Infrastructure verification mismatch** | For infrastructure-affecting changes, does the plan verify render/plan/apply/dry-run, secret wiring, migration order, rollback, and post-deploy health as appropriate? If not, flag it. | ## Process @@ -115,14 +122,19 @@ inherits the design's blast radius) and adds: 3. **Spot-check the repo for precedent conflicts.** Grep for related skills, similar designs in `docs/plans/`, established patterns. Cite what you find. -4. **Run every bug-class check** in the relevant checklist. For each class, +4. **Read project design guidance.** Invoke `autodev:project-design-guidance` + or read its canonical file (`docs/design-guidance.md`) if present. Guidance + conflicts are findings, not style preferences. +5. **Run every bug-class check** in the relevant checklist. For each class, record one of: - **Finding** with file/section + severity (Critical / Important / Minor) - **Clean** with a one-sentence note on what you specifically checked -5. **Surface options, not just objections.** For findings, propose a +6. **Surface options, not just objections.** For findings, propose a concrete fix or alternative. "This design assumes X" → "Alternative: state X explicitly, and add a fallback if X is false at runtime." -6. **Write the report.** Format below. Commit verdict: PASS / FAIL. +7. **Write the report.** Format below. Commit verdict: PASS / FAIL. + Use `autodev:condensed-pipeline-writing` for report density unless the + user asked for prose. ## Report format @@ -145,7 +157,8 @@ inherits the design's blast radius) and adds: **Bug-class scan transcript:** | Class | Result | Note | |---|---|---| -| Unstated assumptions | Finding / Clean | | +| Project-guidance conflicts | Finding / Clean | | +| Assumptions under attack | Finding / Clean | | | Repo-precedent conflicts | Finding / Clean | | | ... | ... | ... | @@ -166,19 +179,41 @@ list every class with a result, even if the result is Clean. - **FAIL** — one or more Critical findings, OR Important findings the author has not addressed. +## Revision Loop + On FAIL: - Feed findings back to the upstream skill (`brainstorming` for design phase, `writing-plans` for plan phase). - The upstream skill revises the artifact based on Critical and Important findings, then re-invokes adversarial review. -- **Max 2 revision cycles** before escalating to the user with a summary of - unresolved findings. This mirrors the bound in - `skills/alignment-check/SKILL.md`. +- Continue revision cycles while the review is finding tangible Critical or + Important issues: broken assumptions, missing failure handling, security + exposure, scope drift, verification gaps, rollback gaps, or concrete repo + precedent conflicts. +- Stop the loop when remaining findings are only nitpicks: wording, formatting, + preference-level alternatives, harmless duplication, or low-confidence + concerns that do not change design/plan behavior. Record them as Minor and + PASS with the nitpicks listed. +- If two consecutive cycles produce no new tangible Critical/Important issue + classes and only rephrase prior concerns, treat the loop as converged. Do not + keep cycling just to satisfy the "find at least three things wrong" framing. - The user may **override** a finding (mark it accepted with reasoning). Overrides are recorded in the artifact (e.g., "Reviewer flagged X as YAGNI; accepted because Y") so the decision is durable. +## Backporting During Execution + +If implementation or verification later disproves a design assumption: + +1. Append a dated `Backport` note to the design doc using + `autodev:condensed-pipeline-writing`. +2. State the failed assumption, evidence, and corrected design behavior. +3. If the Scope Manifest is unchanged, no unlock is required; the lock protects + the manifest, not explanatory design text. +4. If tasks, PR count, or shipped scope changes, use the `scope-lock` amendment + path before pushing or claiming completion. + On PASS: - For `--phase=design`: invoke `writing-plans`. @@ -203,6 +238,7 @@ Agent tool (general-purpose, model: balanced): Read these files: - - (only for --phase=plan) + - docs/design-guidance.md or equivalent project guidance, if present - The original user ask (paste it inline below). USER ASK (verbatim): @@ -235,9 +271,10 @@ Agent tool (general-purpose, model: balanced): Run the adversarial review inline: read the design (and plan, if -`--phase=plan`), perform every bug-class scan in the checklist, and produce -the Report format above. The framing requirements still apply — adversarial -mindset, ≥3 findings or full transcript, no reflexive approval. +`--phase=plan`) plus `docs/design-guidance.md` or equivalent project guidance, +perform every bug-class scan in the checklist, and produce the Report format +above. The framing requirements still apply — adversarial mindset, ≥3 findings +or full transcript, no reflexive approval. ## Integration diff --git a/skills/alignment-check/SKILL.md b/skills/alignment-check/SKILL.md index 879b131..00898f2 100644 --- a/skills/alignment-check/SKILL.md +++ b/skills/alignment-check/SKILL.md @@ -3,6 +3,8 @@ name: alignment-check description: Use after writing-plans to verify the implementation plan covers all design requirements without drift or scope creep --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Design-to-Plan Alignment Check ## Overview @@ -127,10 +129,10 @@ Re-run alignment check after revision. **Max 2 revision cycles** before escalati ## On PASS -After alignment passes, **lock the plan's scope** so subsequent execution cannot silently rescope. Invoke `superpowers:scope-lock` with the plan path. The scope-lock skill: +After alignment passes, **lock the plan's scope** so subsequent execution cannot silently rescope. Invoke `autodev:scope-lock` with the plan path. The scope-lock skill: 1. Stamps the plan's `**Status:**` line with `Locked `. -2. Writes the lock file by running `bash "${CLAUDE_PLUGIN_ROOT}/hooks/scope-lock-apply" ` (do **not** use the Write tool — it is blocked for `*.scope-lock` paths). The helper computes the manifest's sha256 and writes `.scope-lock` via shell redirection. +2. Writes the lock file by running the repo/plugin helper, e.g. `bash hooks/scope-lock-apply ` from the autodev checkout or `bash "${CLAUDE_PLUGIN_ROOT}/hooks/scope-lock-apply" ` when that host env var is present. Do **not** use the Write tool for `*.scope-lock` paths. The helper computes the manifest's sha256 and writes `.scope-lock` via shell redirection. 3. Commits both files (`chore: lock scope for (alignment passed)`). After the lock is in place, proceed to execution: @@ -147,6 +149,6 @@ If the plan does NOT contain a `## Scope Manifest` section, alignment-check fail **Calls:** - `writing-plans` (on FAIL) — for plan revision -- `superpowers:scope-lock` (on PASS) — to apply the post-alignment lock that prevents silent rescoping during execution +- `autodev:scope-lock` (on PASS) — to apply the post-alignment lock that prevents silent rescoping during execution - `subagent-driven-development` (on PASS, autonomous mode) — to begin execution - `tests/plan-scope-check.sh --plan ` (during the manifest trace) — programmatic check that the plan's Scope Manifest is well-formed diff --git a/skills/brainstorming/SKILL.md b/skills/brainstorming/SKILL.md index bba5a4e..0614eab 100644 --- a/skills/brainstorming/SKILL.md +++ b/skills/brainstorming/SKILL.md @@ -3,6 +3,8 @@ name: brainstorming description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation." --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Brainstorming Ideas Into Designs ## Overview @@ -24,20 +26,22 @@ Every project goes through this process. A todo list, a single-function utility, You MUST create a task for each of these items and complete them in order: 1. **Explore project context** — check files, docs, recent commits -2. **Ask clarifying questions** — adaptive batching: group related questions to reduce round-trips; use targeted singles for follow-ups -3. **Propose 2-3 approaches** — with trade-offs and your recommendation -4. **List load-bearing assumptions explicitly** — every design rests on assumptions ("upstream API is idempotent", "single-tenant", "user has admin"); write them down so the adversarial reviewer can attack them -5. **Self-challenge round** — before presenting to the user, role-play a skeptic against your own design and surface the top 3 doubts (see "Self-challenge round" below). Cleans up obvious issues before the user sees the design. -6. **Present design** — in sections scaled to their complexity, get user approval after each section. Include the assumption list and the top doubts surfaced by the self-challenge so the user sees them. -7. **Write design doc** — save to `docs/plans/YYYY-MM-DD--design.md` and commit. The doc MUST include an `## Assumptions` section and a `## Rollback` section for change classes that affect runtime (build, deployment, version pins, startup config, migrations, plugin loading paths) — same trigger list as `runtime-launch-validation`. -8. **Adversarial design review** — invoke `adversarial-design-review --phase=design`. On FAIL, revise per findings and re-run (max 2 cycles). On PASS, proceed. -9. **Transition to implementation** — invoke writing-plans skill to create implementation plan +2. **Apply project design guidance** — invoke `autodev:project-design-guidance`; read existing guidance or run its Q&A if no durable guidance exists +3. **Ask clarifying questions** — adaptive batching: group related questions to reduce round-trips; use targeted singles for follow-ups +4. **Propose 2-3 approaches** — with trade-offs and your recommendation +5. **List load-bearing assumptions explicitly** — every design rests on assumptions ("upstream API is idempotent", "single-tenant", "user has admin"); write them down so the adversarial reviewer can attack them +6. **Self-challenge round** — before presenting to the user, role-play a skeptic against your own design and surface the top 3 doubts (see "Self-challenge round" below). Cleans up obvious issues before the user sees the design. +7. **Present design** — in sections scaled to their complexity, get user approval after each section. Include the assumption list, project-guidance fit, and the top doubts surfaced by the self-challenge so the user sees them. +8. **Write design doc** — save to `docs/plans/YYYY-MM-DD--design.md` and commit. Use `autodev:condensed-pipeline-writing` for internal density. The doc MUST include `## Global Design Guidance`, `## Security Review`, `## Infrastructure Impact`, `## Multi-Component Validation`, `## Assumptions`, and a `## Rollback` section for change classes that affect runtime (build, deployment, version pins, startup config, migrations, plugin loading paths) — same trigger list as `runtime-launch-validation`. +9. **Adversarial design review** — invoke `adversarial-design-review --phase=design`. On FAIL, revise per tangible Critical/Important findings and re-run until the review converges to no tangible issues (remaining nitpicks become Minor PASS items). On PASS, proceed. +10. **Transition to implementation** — invoke writing-plans skill to create implementation plan ## Process Flow ```dot digraph brainstorming { "Explore project context" [shape=box]; + "Apply project guidance" [shape=box]; "Ask clarifying questions" [shape=box]; "Propose 2-3 approaches" [shape=box]; "List assumptions" [shape=box]; @@ -48,7 +52,8 @@ digraph brainstorming { "Adversarial design review" [shape=diamond]; "Invoke writing-plans skill" [shape=doublecircle]; - "Explore project context" -> "Ask clarifying questions"; + "Explore project context" -> "Apply project guidance"; + "Apply project guidance" -> "Ask clarifying questions"; "Ask clarifying questions" -> "Propose 2-3 approaches"; "Propose 2-3 approaches" -> "List assumptions"; "List assumptions" -> "Self-challenge round"; @@ -68,6 +73,7 @@ digraph brainstorming { **Understanding the idea:** - Check out the current project state first (files, docs, recent commits) +- Invoke `autodev:project-design-guidance` before finalizing questions or approaches. If no durable guidance exists, ask the guidance Q&A first so the feature-specific brainstorm is not designed in isolation. - Ask questions using adaptive batching — group related questions to reduce round-trips: - **First batch:** covers purpose, constraints, scope, and tech choices - **Follow-ups:** Targeted single questions based on interesting or ambiguous answers @@ -93,7 +99,7 @@ digraph brainstorming { - Once you believe you understand what you're building, present the design - Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced - Ask after each section whether it looks right so far -- Cover: architecture, components, data flow, error handling, testing, **assumptions** (load-bearing claims), **rollback** (for runtime-affecting change classes) +- Cover: architecture, components, data flow, error handling, testing, **global design guidance fit**, **security review**, **infrastructure impact**, **multi-component validation**, **assumptions** (load-bearing claims), **rollback** (for runtime-affecting change classes) - Include the top 3 doubts surfaced by the self-challenge round so the user can react before approving - Be ready to go back and clarify if something doesn't make sense @@ -138,10 +144,10 @@ When the user wants design exploration without execution, they pass `--design-on **Behavior under `--design-only`:** -1. Run the full brainstorming flow (explore context → questions → approaches → assumptions → self-challenge → design → write design doc → commit). -2. Invoke `adversarial-design-review --phase=design`. On FAIL, revise the design and re-run (max 2 cycles). On persistent FAIL, escalate to user with unresolved findings — no plan dispatched. +1. Run the full brainstorming flow (explore context → project-design-guidance → questions → approaches → assumptions → self-challenge → design → write design doc → commit). +2. Invoke `adversarial-design-review --phase=design`. On FAIL, revise the design and re-run while tangible Critical/Important findings remain. When only nitpicks remain, record them as Minor and proceed on PASS. Escalate only for unresolved tangible findings that require user input — no plan dispatched. 3. On PASS, invoke writing-plans, propagating the `--design-only` flag. -4. writing-plans honors the flag: adversarial-design-review (plan phase) PASS → alignment-check PASS → STOP (no execution dispatched). On FAIL at any gate, writing-plans revises and re-checks per its normal FAIL handling, then stops — still no execution dispatched. On persistent FAIL (after max 2 revision cycles per gate), escalates to user — no execution dispatched regardless. +4. writing-plans honors the flag: adversarial-design-review (plan phase) PASS → alignment-check PASS → STOP (no execution dispatched). On FAIL at any gate, writing-plans revises and re-checks per its normal FAIL handling, then stops — still no execution dispatched. On persistent tangible findings that require user input, escalates to user — no execution dispatched regardless. 5. The pipeline ends with a committed design doc + plan in `docs/plans/` plus the adversarial review reports. **Default (no flag):** brainstorming → adversarial-design-review (design) → writing-plans → adversarial-design-review (plan) → alignment-check → subagent-driven-development → … (autonomous handoff to execution). @@ -150,7 +156,7 @@ When the user wants design exploration without execution, they pass `--design-on **Documentation:** - Write the validated design to `docs/plans/YYYY-MM-DD--design.md` -- Include explicit `## Assumptions` and `## Rollback` sections (the latter only required for change classes that affect runtime — see the trigger list in `runtime-launch-validation` / `finishing-a-development-branch` Step 1b) +- Include explicit `## Global Design Guidance`, `## Security Review`, `## Infrastructure Impact`, `## Multi-Component Validation`, `## Assumptions`, and `## Rollback` sections (rollback only required for change classes that affect runtime — see the trigger list in `runtime-launch-validation` / `finishing-a-development-branch` Step 1b) - Use elements-of-style:writing-clearly-and-concisely skill if available - **Record decisions** — if the design triggers any condition in `skills/recording-decisions/SKILL.md` (divergence from precedent, non-trivial trade-off between ≥2 plausible approaches, adversarial-review override, cross-skill structural change), invoke `recording-decisions` to add an ADR in `decisions/`, then cite it from this design doc - Commit the design document to git (and any new ADRs in the same commit) @@ -158,13 +164,13 @@ When the user wants design exploration without execution, they pass `--design-on **Adversarial review (mandatory):** - Invoke `adversarial-design-review --phase=design` against the committed design - On PASS, proceed to autonomous handoff -- On FAIL, revise the design based on Critical and Important findings and re-run (max 2 cycles before escalating to the user with unresolved findings) +- On FAIL, revise the design based on Critical and Important findings and re-run until the review stops finding tangible issues; remaining nitpicks are recorded as Minor and do not keep the loop alive - The user may override a finding (mark it accepted with reasoning recorded in the design doc) **Autonomous handoff:** - This is the user's **last interaction point** — everything after runs autonomously - Invoke the writing-plans skill with autonomous context: the design is approved AND adversarially reviewed, no further user input needed -- The writing-plans skill will prefer Claude's Plan Mode if available (Claude Code), falling back to its built-in planning process in other environments +- The writing-plans skill will prefer host-native planning mode when available, falling back to its built-in planning process otherwise - The pipeline from here: writing-plans → adversarial-design-review (plan phase) → alignment-check → team execution → PR creation → PR monitoring - Do NOT invoke any other skill. `adversarial-design-review` runs first; on PASS, writing-plans is the next step. It handles the rest of the autonomous pipeline. @@ -175,6 +181,7 @@ When the user wants design exploration without execution, they pass `--design-on - **YAGNI ruthlessly** - Remove unnecessary features from all designs - **Explore alternatives** - Always propose 2-3 approaches before settling - **Make assumptions explicit** - Load-bearing assumptions belong in writing, not in the agent's head +- **Inherit project guidance** - Every design reads or creates project-wide guidance before choosing an approach - **Self-challenge before presenting** - Cleans up obvious issues; saves the user a round-trip - **Adversarial review before execution** - The cheapest place to kill a bad idea is before the plan is written - **Incremental validation** - Present design, get approval before moving on diff --git a/skills/condensed-pipeline-writing/SKILL.md b/skills/condensed-pipeline-writing/SKILL.md new file mode 100644 index 0000000..f22945f --- /dev/null +++ b/skills/condensed-pipeline-writing/SKILL.md @@ -0,0 +1,144 @@ +--- +name: condensed-pipeline-writing +description: Use when producing design docs, adversarial review reports, implementation plans, progress logs, or phase handoffs where token efficiency matters and precision must be preserved +--- + +# Condensed Pipeline Writing + +## Overview + +Use compact, structured writing for internal pipeline artifacts. The goal is +lower token use without losing decisions, evidence, assumptions, constraints, +or file paths. + +This skill applies to: +- design docs in `docs/plans/*-design.md` +- implementation plans in `docs/plans/*.md` +- adversarial review reports +- scope/backport notes +- phase-progress logs and handoffs + +It does not apply to user-facing explanations, PR descriptions, commit +messages, code comments, or public documentation unless the user asks for terse +format. + +## Core Rules + +- Prefer tables, tagged bullets, and short fragments over paragraphs. +- Keep every fact that affects implementation, review, rollback, or scope. +- Remove throat-clearing, restated goals, apologies, and generic process prose. +- Use stable labels so later agents can grep and cite sections. +- Preserve code, commands, paths, URLs, identifiers, versions, error strings, + regex, SQL, JSON, YAML, and quoted user requirements verbatim. + +## Symbols + +Use these only in internal artifacts: + +| Symbol | Meaning | +|---|---| +| `→` | leads to / becomes / then | +| `∴` | therefore / conclusion | +| `!` | required / must | +| `?` | unknown / needs validation | +| `⊥` | forbidden / impossible | +| `≠` | not equal / conflicts | +| `≤` / `≥` | at most / at least | +| `&` | and | +| `|` | or, except inside Markdown tables | + +Avoid clever notation. If a symbol makes a sentence ambiguous, use words. + +## Artifact Shapes + +**Assumption row** + +```markdown +| id | assumption | challenge | fallback | +|---|---|---|---| +| A1 | Codex parses hook stdout as JSON when non-empty | invalid JSON blocks hook | emit schema JSON via `jq -n`; no encoder → no output | +``` + +**Finding row** + +```markdown +| sev | class | loc | issue | fix | +|---|---|---|---|---| +| Important | hook schema | `hooks/session-start` | top-level `additional_context` risks host mismatch | emit `hookSpecificOutput.additionalContext` only | +``` + +**Plan task** + +```markdown +T3 hook JSON tests +Files: `tests/hook-contracts.sh` +Steps: +1. payload → `hooks/session-start` +2. parse via `jq -e` +3. assert `.hookSpecificOutput.additionalContext` +Verify: `tests/hook-contracts.sh` → PASS +``` + +**Compressed JSONL state row** + +```json +{"ts":"2026-05-25T20:01:51Z","ev":"phase","pl":"docs/plans/x.md","ph":"T3","st":"done","e":"tests/hook-contracts.sh PASS","nx":"T4"} +``` + +## Compressed State + +JSON/JSONL state is internal pipeline data. Use compact stable keys: + +| key | meaning | +|---|---| +| `ts` | UTC timestamp | +| `ev` | event enum: `skill`, `agent`, `task`, `lock`, `phase`, `blk` | +| `sk` | skill name | +| `args` | truncated skill args | +| `ag` | agent/subagent type | +| `tt` | task tool name | +| `id` | task/agent id | +| `pl` | plan path/name | +| `ph` | phase/task id | +| `st` | status enum | +| `h` | lock/hash prefix or digest | +| `e` | evidence | +| `nx` | next action | +| `blk` | blocker | +| `d` | short fallback detail; avoid unless no structured key fits | + +Prefer enums and path/id references over prose. Keep old parsers tolerant during +migration (`tool/detail` legacy rows may exist). Do not store long prompts, +transcripts, or review bodies in state; state should re-anchor agents, not +duplicate artifacts. + +## Density Targets + +- Design section: 3-7 bullets or one table, not a long essay. +- Adversarial report: one row per finding; one row per clean bug class. +- Plan task: exact files, exact commands, exact expected output; no motivational prose. +- Handoff/state: current state, evidence, next action, blockers. Nothing else. + +## Backport Notes + +When execution disproves an assumption or reveals a bug in the design, write a +small backport note: + +```markdown +### Backport YYYY-MM-DD: + +Cause: +Change: +Scope: no manifest change | manifest change requires re-lock +Evidence: `` → +``` + +Keep backports factual. Do not rewrite history; append the correction. + +## Common Mistakes + +- Cutting a caveat that changes behavior. +- Replacing exact expected output with "works." +- Compressing public/user-facing text until it sounds cryptic. +- Using symbols inside code, commands, JSON, YAML, or quoted strings. +- Hiding uncertainty. Mark it with `?` and state how to resolve it. diff --git a/skills/dispatching-parallel-agents/SKILL.md b/skills/dispatching-parallel-agents/SKILL.md index 33b1485..63ee0d0 100644 --- a/skills/dispatching-parallel-agents/SKILL.md +++ b/skills/dispatching-parallel-agents/SKILL.md @@ -3,6 +3,8 @@ name: dispatching-parallel-agents description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Dispatching Parallel Agents ## Overview @@ -64,7 +66,7 @@ Each agent gets: ### 3. Dispatch in Parallel ```typescript -// In Claude Code / AI environment +// In any agent environment with task dispatch Task("Fix agent-tool-abort.test.ts failures") Task("Fix batch-completion-behavior.test.ts failures") Task("Fix tool-approval-race-conditions.test.ts failures") diff --git a/skills/executing-plans/SKILL.md b/skills/executing-plans/SKILL.md index dc381f5..5862853 100644 --- a/skills/executing-plans/SKILL.md +++ b/skills/executing-plans/SKILL.md @@ -3,6 +3,8 @@ name: executing-plans description: Use when you have a written implementation plan to execute in a separate session with review checkpoints --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Executing Plans ## Overview @@ -54,7 +56,7 @@ Based on feedback: After all tasks complete and verified: - Announce: "I'm using the finishing-a-development-branch skill to complete this work." -- **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch +- **REQUIRED SUB-SKILL:** Use autodev:finishing-a-development-branch - Follow that skill to verify tests, present options, execute choice ## When to Stop and Ask for Help @@ -87,6 +89,6 @@ After all tasks complete and verified: ## Integration **Required workflow skills:** -- **superpowers:using-git-worktrees** - REQUIRED: Set up isolated workspace before starting -- **superpowers:writing-plans** - Creates the plan this skill executes -- **superpowers:finishing-a-development-branch** - Complete development after all tasks +- **autodev:using-git-worktrees** - REQUIRED: Set up isolated workspace before starting +- **autodev:writing-plans** - Creates the plan this skill executes +- **autodev:finishing-a-development-branch** - Complete development after all tasks diff --git a/skills/finishing-a-development-branch/SKILL.md b/skills/finishing-a-development-branch/SKILL.md index 119448f..b17e5cb 100644 --- a/skills/finishing-a-development-branch/SKILL.md +++ b/skills/finishing-a-development-branch/SKILL.md @@ -3,6 +3,8 @@ name: finishing-a-development-branch description: Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Finishing a Development Branch ## Overview @@ -57,7 +59,7 @@ When running in the autonomous pipeline (invoked from subagent-driven-developmen ## Changes - 🤖 Generated with [Claude Code](https://claude.com/claude-code) + Generated by the implementing agent. EOF )" ``` @@ -143,12 +145,12 @@ Action: - **Missing tasks:** stop. Do NOT create any PR. Report exactly which task(s) have no implementing commits, and ask the user one of: > Tasks have no implementing commits on this branch. Options: > 1. Implement the missing tasks (preferred). - > 2. Approve a scope reduction — I will invoke `recording-decisions` to write an ADR removing those tasks from the manifest, then re-run `alignment-check` against the reduced design+plan. + > 2. Approve a scope amendment — I will invoke `recording-decisions` to write an ADR, backport the design if needed, update the manifest, then re-run `alignment-check` against the amended design+plan. > 3. Abort the PR creation; keep the branch as-is for inspection. > > Which option? - **PR count mismatch (autonomous mode):** if the manifest expects N PRs but the branch layout produced fewer, the agent must split the branch via `git rebase --onto` per the manifest's grouping table — NOT collapse the manifest. Collapsing N planned PRs into 1 is exactly the failure mode `scope-lock` exists to prevent. -- **Locked-hash mismatch:** the manifest has been edited after the lock. Surface the diff and stop. The user must either revert the edit or go through the unlock path (`recording-decisions` + re-run alignment-check). +- **Locked-hash mismatch:** the manifest has been edited after the lock. Surface the diff and stop. The user must either revert the edit or go through the amendment path (`recording-decisions` + re-run alignment-check). Do not proceed past Step 1d on any failure without explicit user direction. There is no "demo mode" — see the anti-patterns in `skills/scope-lock/SKILL.md`. @@ -312,7 +314,7 @@ git worktree remove - **executing-plans** (Step 5) - After all batches complete **Calls (autonomous mode):** -- **superpowers:pr-monitoring** - After PR creation, monitors CI and reviews +- **autodev:pr-monitoring** - After PR creation, monitors CI and reviews **Pairs with:** - **using-git-worktrees** - Cleans up worktree created by that skill diff --git a/skills/post-merge-retrospective/SKILL.md b/skills/post-merge-retrospective/SKILL.md index 32a7803..7162671 100644 --- a/skills/post-merge-retrospective/SKILL.md +++ b/skills/post-merge-retrospective/SKILL.md @@ -3,6 +3,8 @@ name: post-merge-retrospective description: Use after a PR has merged and CI is green - reads design, plan, adversarial-review reports, code-review threads, and CI history to produce a short retrospective in docs/retros/ that closes the loop on which gates worked and which didn't --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Post-Merge Retrospective ## Overview @@ -47,11 +49,20 @@ If the PR was opened ad-hoc (no design / plan in `docs/plans/`), this skill exit For each unique CI failure on the branch, ask: was this caught by `verification-before-completion` / `runtime-launch-validation` / something else, or did it slip past every local gate? Slips are gate misses too. 5. **Score skill activations.** - Read `.claude/superpowers-state/in-progress.jsonl` (if present in the repo's `.claude/` directory) and verify the expected pipeline ran. The canonical chain documented in `skills/using-superpowers/SKILL.md` is: + Read `.claude/autodev-state/in-progress.jsonl` (if present in the repo's `.claude/` directory) and verify the expected pipeline ran. The canonical chain documented in `skills/using-autodev/SKILL.md` is: `brainstorming → adversarial-design-review (design) → writing-plans → adversarial-design-review (plan) → alignment-check → subagent-driven-development → finishing-a-development-branch → pr-monitoring → post-merge-retrospective`. For each gate that was *expected* to fire and didn't, that's a missed-activation. Use `tests/skill-activation-audit.sh` (this repo) to confirm what fired — note that the audit script reports each skill once even when invoked twice (e.g., adversarial-design-review for both phases), so cross-check phase counts against the JSONL `args=--phase=` entries when both phases are required. -6. **Write the retro.** +6. **Backfeed project design guidance.** + Invoke `autodev:project-design-guidance`. If the merged work reveals a + durable cross-design lesson, update `docs/design-guidance.md` in the same + commit as the retro. Durable lessons include language/runtime/framework + direction changes, new product/application modes, deployment/compliance/ + privacy/operations constraints, repeated gate misses that should become a + design principle, or false assumptions in existing guidance. Do not append + one-off implementation trivia. + +7. **Write the retro.** Save to `docs/retros/YYYY-MM-DD--retro.md` using the format below. Commit it. ## Retro format @@ -85,7 +96,7 @@ If there are zero gate misses, write: "No gate misses this PR. All downstream is ## Missed skill activations -Pipeline gates expected to fire (per `using-superpowers`): list any that didn't. Pull from `tests/skill-activation-audit.sh`. +Pipeline gates expected to fire (per `using-autodev`): list any that didn't. Pull from `tests/skill-activation-audit.sh`. | Gate | Fired? | Notes | |---|---|---| @@ -107,6 +118,12 @@ Pipeline gates expected to fire (per `using-superpowers`): list any that didn't. If a gate miss recurs across multiple retros, propose a concrete plugin change: a new bug class in `adversarial-design-review`, a new line in `runtime-launch-validation`, a new entry in `tests/skill-cross-refs.sh`. Cite the prior retros. If no plugin-level changes are warranted, say so. + +## Project guidance updates + +| Guidance file | Change | Reason | +|---|---|---| +| `docs/design-guidance.md` | | | ``` ## Dispatch @@ -131,17 +148,22 @@ The retro is intentionally short. Long retros don't get read. The format above f - `pr-monitoring` — on its successful exit (CI green + reviews resolved). - Manual — any merged PR with matching artifacts. -**Calls:** none. Retro is a leaf; the next iteration of the pipeline picks up cross-retro patterns when an author writes the next design. +**Calls:** +- `project-design-guidance` — when the retro identifies a durable cross-design + guidance change. **Reads:** - `docs/plans/` (design, plan, adversarial-review reports) - `decisions/` (ADRs cited from the design / plan) - `gh pr view`, `gh pr review-comments`, `gh run list` -- `.claude/superpowers-state/in-progress.jsonl` (if present) +- `.claude/autodev-state/in-progress.jsonl` (if present) - `tests/skill-activation-audit.sh` (this repo) +- `docs/design-guidance.md` or equivalent project guidance, if present **Writes:** - `docs/retros/YYYY-MM-DD--retro.md` +- `docs/design-guidance.md` when the retro identifies a durable cross-design + guidance change ## Anti-patterns @@ -149,3 +171,6 @@ The retro is intentionally short. Long retros don't get read. The format above f - **Validating the work.** This isn't "did we ship the right thing?" — that's the user's call. This is "did the gates do their job?" — that's a process question with binary answers per gate. - **Skipping the gate-miss table.** "Everything went great" is fine as a statement, but the table format forces you to walk every code-review comment and CI failure. Skipping it means signal is being lost. - **Acting on a single retro.** Plugin-level follow-ups require pattern across retros. One miss is signal; two is a trend. +- **Failing to backfeed durable guidance.** If the application changes language, + product mode, deployment model, compliance posture, or another cross-design + constraint, update project guidance so the next design inherits it. diff --git a/skills/pr-monitoring/SKILL.md b/skills/pr-monitoring/SKILL.md index aefa7db..a395cd4 100644 --- a/skills/pr-monitoring/SKILL.md +++ b/skills/pr-monitoring/SKILL.md @@ -3,6 +3,8 @@ name: pr-monitoring description: Use after creating a PR to automatically monitor CI checks and review comments, fixing issues and pushing updates autonomously --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # PR Monitoring ## Overview @@ -191,7 +193,7 @@ Agent tool (general-purpose, model: balanced, run_in_background: true): **On all PRs complete (clean exit):** - For each PR that is merged AND whose base-branch CI is green for the merge commit AND that has a design + plan in `docs/plans/` for its branch, invoke - `superpowers:post-merge-retrospective` to produce a retro in `docs/retros/`. + `autodev:post-merge-retrospective` to produce a retro in `docs/retros/`. - Report final status. **On session timeout (60-minute limit reached):** @@ -205,7 +207,7 @@ Agent tool (general-purpose, model: balanced, run_in_background: true): - PR # : PRs complete: - PR # : all checks green, no open threads - Action required: restart superpowers:pr-monitoring for the PRs listed above. + Action required: restart autodev:pr-monitoring for the PRs listed above. ``` Then exit. The orchestrator (lead agent) will read this report via the @@ -238,7 +240,7 @@ status report listing which PRs still need attention, then exit. The orchestrato should start a new monitor for the remaining PRs. When a PR has merged with green base-branch CI and a design + plan exist in -`docs/plans/` for its branch, invoke `superpowers:post-merge-retrospective` to +`docs/plans/` for its branch, invoke `autodev:post-merge-retrospective` to write a retro in `docs/retros/`. If the PR was closed without merge, skip the retro and exit cleanly. @@ -259,7 +261,7 @@ retro and exit cleanly. When the monitor agent times out (60 min), it writes a `PR-MONITOR TIMEOUT REPORT` to its output. The orchestrator (lead agent) should watch for this via the activity -log, read the report, and start a new `superpowers:pr-monitoring` agent scoped to +log, read the report, and start a new `autodev:pr-monitoring` agent scoped to only the PRs still listed as needing attention. Repeat until all PRs are clean. ## Integration @@ -268,8 +270,8 @@ only the PRs still listed as needing attention. Repeat until all PRs are clean. - `finishing-a-development-branch` (autonomous mode) — after PR creation **Calls:** -- `superpowers:post-merge-retrospective` — on its own clean exit when the PR has merged with green base-branch CI +- `autodev:post-merge-retrospective` — on its own clean exit when the PR has merged with green base-branch CI **Uses:** - `gh` CLI for all GitHub operations -- `superpowers:systematic-debugging` principles for CI failure analysis +- `autodev:systematic-debugging` principles for CI failure analysis diff --git a/skills/project-design-guidance/SKILL.md b/skills/project-design-guidance/SKILL.md new file mode 100644 index 0000000..8236ce1 --- /dev/null +++ b/skills/project-design-guidance/SKILL.md @@ -0,0 +1,120 @@ +--- +name: project-design-guidance +description: Use before brainstorming, design docs, implementation plans, or retros when project-wide design constraints may exist or need to be created +--- + +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + +# Project Design Guidance + +Global guidance = durable constraints every design inherits: product direction, architecture boundaries, UX/domain rules, security/ops posture, infra/deploy limits, non-goals. No isolated design. + +## Canon + +Prefer `docs/design-guidance.md`. + +If equivalent exists, use + cite it instead of duplicating: `docs/product-guidance.md`, `docs/architecture.md`, `docs/technical-strategy.md`, repo `AGENTS.md`/`CLAUDE.md`, ADRs with cross-cutting direction. Add pointer file only if discoverability is poor. + +## Pre-Design Gate + +1. Search: + ```bash + rg -n "design guidance|product direction|architecture principles|non-goals|constraints|strategy" AGENTS.md CLAUDE.md README.md docs decisions 2>/dev/null + ``` +2. If found: read, cite under design `## Global Design Guidance`. +3. If absent: ask Q&A before final design; save to `docs/design-guidance.md` unless human declines. +4. Every design states either `Guidance: docs/design-guidance.md` or `Guidance: none found; Q&A captured here`. + +## Q&A + +Ask max 2 batches. + +Batch 1: +- Product: optimize for what across project? speed, reliability, low ops, rich UX, portability, cost, local-first? +- Architecture: preferred/forbidden languages, frameworks, stores, integrations, hosts, boundaries? +- Quality/security/release: must preserve what? compat, audit logs, no PII logs, rollback, offline, flags, prod approval? + +Batch 2 if unclear: +- User/domain principles? +- Non-goals? +- Evolution triggers: language/runtime change, new product line, deploy model change, enterprise/compliance need, repeated retro miss? + +## File Shape + +```markdown +# Design Guidance + +**Status:** Active +**Last updated:** YYYY-MM-DD +**Source:** human Q&A | retro | ADR + +## Product Direction +- ... + +## Architecture Constraints +- ... + +## UX / Domain Principles +- ... + +## Quality / Security / Operations +- ... + +## Infrastructure / Integration Impact +- cloud resources, network paths, secrets, migrations, queues, storage, cost, + scaling, env differences, deploy approval + +## Multi-Component Validation +- proof across real boundaries: app+DB, API+worker, plugin+host, frontend+backend, + CLI+service, IaC+runtime + +## Non-Goals +- ... + +## Evolution Triggers +- ... + +## Change Log +| Date | Source | Change | +|---|---|---| +``` + +## Apply + +Design must include: + +```markdown +## Global Design Guidance + +Source: `docs/design-guidance.md` + +| guidance | design response | +|---|---| +| | | +``` + +Plan must turn relevant guidance into tasks/verification: code, tests, deploy wiring, rollback, privacy, UX, ops. Intentional guidance violation → ADR before plan. + +Every non-trivial design answers: + +- Security review: auth/authz, secrets, PII/logging, abuse case, deps/trust boundary, least privilege. +- Infra impact: resources create/change/destroy, migrations, network exposure, cost/scale, deploy/rollback, prod approval. +- Multi-component validation: smallest real integration/e2e proof; no mock-only boundary proof. + +## Retro Backfeed + +During `post-merge-retrospective`, update guidance only for durable future-design lessons: +- language/runtime/framework direction changed +- app/product/user segment evolved +- deploy/compliance/privacy/ops constraints changed +- repeated gate miss needs explicit principle +- guidance assumption proved false + +Append dated `Change Log` row + edit relevant section. If file missing, create only when lesson affects future designs. One-off implementation trivia stays in retro. + +## Smells + +- Treating guidance as optional for "small" features. +- Copying all guidance into every design; cite + summarize touched constraints. +- Retro noise that would not change next design. +- Silent guidance violation. diff --git a/skills/receiving-code-review/SKILL.md b/skills/receiving-code-review/SKILL.md index 4ea72cd..a7356ad 100644 --- a/skills/receiving-code-review/SKILL.md +++ b/skills/receiving-code-review/SKILL.md @@ -3,6 +3,8 @@ name: receiving-code-review description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Code Review Reception ## Overview @@ -27,7 +29,7 @@ WHEN receiving code review feedback: ## Forbidden Responses **NEVER:** -- "You're absolutely right!" (explicit CLAUDE.md violation) +- "You're absolutely right!" (performative; usually violates agent guidance) - "Great point!" / "Excellent feedback!" (performative) - "Let me implement that now" (before verification) diff --git a/skills/recording-decisions/SKILL.md b/skills/recording-decisions/SKILL.md index ac5cfd5..60009ba 100644 --- a/skills/recording-decisions/SKILL.md +++ b/skills/recording-decisions/SKILL.md @@ -3,91 +3,70 @@ name: recording-decisions description: Use when the design or plan makes a non-trivial trade-off that future contributors will need context for - records an Architecture Decision Record (ADR) in decisions/ so the rejected alternatives and reasoning are durable, not lost in transcript history --- -# Recording Decisions - -## Overview - -Architecture Decision Records (ADRs) capture the **why** behind a choice — particularly the alternatives that were rejected and the reasoning. Designs in `docs/plans/` say *what* we built; ADRs say *why this and not that*. +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. -`adversarial-design-review` produces a report alongside each design that lists "Options the author may not have considered" and a verdict reasoning paragraph. That covers idea-level alternatives at one moment in time. ADRs are the persistent index across the project: a rename, a refactor, or a new contributor's "why is it like this?" question goes through `decisions/`, not through hunting for the right adversarial-review report inside an old design folder. +# Recording Decisions -**Core principle:** record once, in a stable location, with a stable number, in Michael Nygard's three-section format. +ADR = durable "why this, not that." Design/plan = what; ADR = trade-off, rejected paths, consequences. -## When to use this skill +## Use -Invoke this skill when **any** of these conditions hold: +Write ADR when ≥1 true: -1. **Divergence from precedent.** The design / plan picks a path that differs from a previously-established pattern in this repo (e.g., a different testing strategy, a different state-management choice, a different deployment shape than other components). -2. **Non-trivial trade-off.** The design weighs ≥2 plausible approaches and picks one for reasons that won't be obvious from reading the code. A flat file vs. SQLite vs. Postgres choice. A library-pin floor (`>=X.Y`) vs. exact pin (`==X.Y.Z`) decision. Sync vs. async. Polling vs. webhook. -3. **Adversarial-review override.** The design author accepted an adversarial-review finding as "yes, but here's why" rather than fixing it. The acceptance reasoning belongs in an ADR so future contributors don't re-litigate. -4. **Cross-skill structural change.** Any change that affects multiple skills' integration (e.g., introducing a new gate in the autonomous pipeline, renaming a step that other skills cite). -5. **User-approved scope reduction.** The user explicitly approved removing tasks or PRs from a locked manifest (see `skills/scope-lock/SKILL.md`'s unlock path). The ADR records which tasks/PRs were dropped, why, and what carries over to a future plan. This ADR is then cited from the manifest's `**Status:** Reduced …` line and from the PR body of every PR shipped under the reduced manifest. +| trigger | record | +|---|---| +| precedent Δ | repo pattern changed | +| real trade-off | ≥2 plausible options, choice not obvious from code | +| review override | Important/Critical finding accepted-with-reason, not fixed | +| cross-skill shape Δ | pipeline/gate/contract affects multiple skills | +| locked manifest amendment | human-approved scope/task/PR change; cite from manifest + PRs | -If none of the five conditions hold, an ADR is not required. ADRs are not for every commit — they are for choices that future contributors will read the code and ask "why is it like this?" about. +Skip if no future maintainer would ask "why?" -## Process +## Flow -1. **Pick the next free number.** ADRs are numbered sequentially: `0000-template.md`, `0001-...md`, `0002-...md`. With four-digit zero-padded prefixes, lexicographic sort is equivalent to numeric sort: +1. Find next id: ```bash ls decisions/ | grep -E '^[0-9]{4}-' | sort | tail -1 ``` - Take the prefix of the result and add 1. -2. **Copy the template.** - ```bash - cp decisions/0000-template.md decisions/NNNN-.md - ``` - The slug is kebab-case, ≤6 words: `0007-pin-postgres-major-version-only.md`. -3. **Fill the three sections.** Context, Decision, Consequences. Each section is short (≤150 words is a good target). If you can't say it in 150 words, the trade-off probably isn't crisp yet. -4. **Set status.** New ADRs start as `Status: Accepted`. Superseded ADRs are not deleted — they get `Status: Superseded by NNNN` and the new ADR cites them in its Context. -5. **Cite from the design / plan.** The design or plan that triggered the ADR MUST cite it: `See decisions/0007-pin-postgres-major-version-only.md`. This is the back-link that makes ADRs discoverable. -6. **Commit alongside the design / plan.** ADRs are committed in the same commit as the design (when triggered by `brainstorming`) or the same commit as the plan (when triggered by `writing-plans`). +2. Copy `decisions/0000-template.md` → `decisions/NNNN-short-slug.md`; slug kebab, ≤6 words. +3. Fill Context/Decision/Consequences. Target ≤150 words/section. +4. Status: new = `Accepted`; old decision changed = old `Superseded by NNNN`, new cites old. +5. Back-link from triggering design/plan: `See decisions/NNNN-short-slug.md`. +6. Commit ADR with the design/plan that made the choice. -## ADR format (Michael Nygard, lightly extended) +## Template ```markdown # NNNN. **Status:** Accepted | Superseded by MMMM | Deprecated **Date:** YYYY-MM-DD -**Decision-makers:** -**Related:** , , , +**Decision-makers:** +**Related:** , , , ## Context - + ## Decision - because . Be precise. Name the alternatives -considered and rejected, with one sentence each on why they were rejected.> + ## Consequences - +<2-5 effects. Include positive + negative. Include undo/migration cost.> ``` -## Integration - -**Called by:** -- `brainstorming` — when the design triggers any of the four conditions above. -- `writing-plans` — when the plan introduces a non-obvious choice not already covered by an ADR. -- `adversarial-design-review` — recommended when an Important finding is accepted by the author with reasoning. -- Manual — any contributor recording a decision retroactively. +## Smells -**Calls:** none. ADRs are leaves; they record state, not next steps. +- "We built X" → task log, not ADR. +- Proposal/future tense → design doc until accepted. +- Editing accepted ADR body → write superseding ADR. +- No alternatives → not an ADR. -## Anti-patterns - -- **ADR for every task.** ADRs are for choices, not for documenting work. If the entry is just "we built feature X", it belongs in the design / plan / commit message, not in `decisions/`. -- **ADR as future tense.** ADRs record decisions that have been made, not proposals. Use the design doc for proposals; promote to an ADR after the choice is locked. -- **Editing accepted ADRs.** Accepted ADRs are immutable except for status changes (Accepted → Superseded by NNNN). To change the decision, write a new ADR that supersedes the old one. The old one stays in the repo; future contributors need to see the history. -- **Skipping the alternatives.** "Decision: use Postgres" with no rejected alternatives is a non-ADR. The Nygard format demands the trade-off — without it, it's a glorified README entry. +## Integration -## Why this skill is light by design +Called by: `brainstorming`, `writing-plans`, `adversarial-design-review`, manual retroactive recording. -ADRs work when they're cheap to write and hard to dodge. This skill is intentionally short: a numbering rule, a template, a four-condition trigger, and a commit convention. The heavy lifting (figuring out what to write) lives in the design and adversarial-review process. This skill is the storage protocol. +Calls: none. diff --git a/skills/requesting-code-review/SKILL.md b/skills/requesting-code-review/SKILL.md index e6b0129..fb57660 100644 --- a/skills/requesting-code-review/SKILL.md +++ b/skills/requesting-code-review/SKILL.md @@ -3,6 +3,8 @@ name: requesting-code-review description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Requesting Code Review ## Reviewer brief — adversarial framing @@ -122,7 +124,7 @@ Reviewer must justify the verdict in one sentence: Reflexive SHIP-IT without justification is forbidden. -Dispatch superpowers:code-reviewer subagent to catch issues before they cascade. +Dispatch autodev:code-reviewer subagent to catch issues before they cascade. **Core principle:** Review early, review often. @@ -215,7 +217,7 @@ You: Let me request code review before proceeding. BASE_SHA=$(git rev-parse HEAD~1) # or: git log --oneline | grep "Task 1" | head -1 | awk '{print $1}' HEAD_SHA=$(git rev-parse HEAD) -[Dispatch superpowers:code-reviewer subagent — brief filled in verbatim from the review-request template:] +[Dispatch autodev:code-reviewer subagent — brief filled in verbatim from the review-request template:] You are a code reviewer with adversarial framing. Find at least three things wrong with this code, even if they seem minor — or, if fewer than three are @@ -255,7 +257,7 @@ Verdict: REQUEST-CHANGES — one Important finding (missing progress indicators) You: [Fix progress indicators, extract constant, push new commit] -[Dispatch superpowers:code-reviewer subagent — round 2, full diff re-read, same verbatim brief] +[Dispatch autodev:code-reviewer subagent — round 2, full diff re-read, same verbatim brief] HEAD_SHA=$(git rev-parse HEAD) # re-run: HEAD now points to the new fix commit(s) (diff range $BASE_SHA..$HEAD_SHA — same base, new tip that includes the fix commits) diff --git a/skills/runtime-launch-validation/SKILL.md b/skills/runtime-launch-validation/SKILL.md index 107cb4c..497c429 100644 --- a/skills/runtime-launch-validation/SKILL.md +++ b/skills/runtime-launch-validation/SKILL.md @@ -3,6 +3,8 @@ name: runtime-launch-validation description: Use after unit tests pass, before merge, when a change affects runtime behavior — launch the built artifact under realistic conditions and observe its behavior --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Runtime Launch Validation ## Iron Law diff --git a/skills/scope-lock/SKILL.md b/skills/scope-lock/SKILL.md index 3e0edbd..7323086 100644 --- a/skills/scope-lock/SKILL.md +++ b/skills/scope-lock/SKILL.md @@ -3,11 +3,13 @@ name: scope-lock description: Use whenever the autonomous pipeline reaches alignment-check PASS - locks the plan's task list, PR count, and feature scope so the executing agent cannot silently rescope, collapse PRs, or ship partial work as a "demo" without explicit user approval recorded as an ADR --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Scope Lock ## Overview -After `alignment-check` passes, the implementation plan is **locked**: task list, PR count, and feature scope are immutable until the work completes (or the user explicitly approves a reduction). This skill defines what "locked" means, what unlocks it, and how the rest of the pipeline must behave under the lock. +After `alignment-check` passes, the implementation plan is **locked**: task list, PR count, and feature scope are immutable until the work completes (or the user explicitly approves an amendment). This skill defines what "locked" means, what unlocks it, and how the rest of the pipeline must behave under the lock. **Why this skill exists:** observed failure mode — an agent told to "continue autonomously, create a PR, also test locally, reorder as needed" interpreted "reorder as needed" as license to rescope, collapsed a 6-PR plan into a single PR, and shipped a partial-scope solution as a "demo". Each step looked plausible in isolation. Cumulatively the agent went off the rails. The lock makes each of those steps individually visible and individually blockable. @@ -22,7 +24,7 @@ Manual invocation: - **At lock time** (after alignment passes): stamp the plan and record the manifest hash. - **At execution checkpoints** (between tasks): verify reality still matches the lock. - **At completion time** (before PR creation): assert manifest is fully satisfied. -- **At unlock time** (user-approved scope reduction): record the reduction as an ADR, update the manifest, re-stamp. +- **At amendment time** (user-approved scope change, or bug/assumption backport that changes the manifest): record the amendment as an ADR, update the design/plan/manifest, re-stamp. ## The Scope Manifest @@ -47,31 +49,35 @@ The manifest is a section the plan author writes during `writing-plans`. After ` | 2 | | Task 3, Task 4 | feat/-2 | | ... | ... | ... | ... | -**Status:** Draft | Locked YYYY-MM-DDTHH:MM:SSZ | Reduced YYYY-MM-DDTHH:MM:SSZ (see decisions/NNNN) +**Status:** Draft | Locked YYYY-MM-DDTHH:MM:SSZ | Amended YYYY-MM-DDTHH:MM:SSZ (see decisions/NNNN) ``` Every plan task ID listed under `Tasks` in the table must exist in the plan body. Every task in the plan body must appear in exactly one PR row. If the work is genuinely a single PR, the table has one row — the row still has to exist. Single-PR plans are not exempt from the manifest; they are exempt only from the multi-PR PR-count assertion. +The lock hash covers only this Scope Manifest block. The block ends at the next +H2 heading or the first `### Task N:` heading, whichever comes first. Design +backports and task notes outside the manifest do not change the lock hash. + ## Lock state machine ``` alignment-check PASS Draft ─────────────────────────────────► Locked ▲ │ - │ │ user approves scope reduction; + │ │ user approves manifest amendment; │ alignment-check FAIL → revise │ recording-decisions writes ADR; │ ▼ - │ Reduced + │ Amended │ │ - │ │ re-run alignment-check on the reduced plan + │ │ re-run alignment-check on amended plan └──────────────────────────────────────────┘ ``` - **Draft**: the plan author is still revising. No execution is permitted. - **Locked**: alignment passed. The manifest hash is recorded. Execution is permitted; renegotiation is not. -- **Reduced**: the user explicitly approved a scope reduction; an ADR was written; the manifest was updated; alignment was re-run on the reduced plan, which produced a new Locked stamp. The original Locked stamp is preserved in the ADR's Context for audit. +- **Amended**: the user explicitly approved a manifest change, or a bug/assumption backport required one; an ADR was written; design/plan/manifest were updated; alignment was re-run on the amended plan, which produced a new Locked stamp. The original Locked stamp is preserved in the ADR's Context for audit. There is no "Expanded" state by design. Adding scope mid-flight requires going back to Draft (re-do brainstorming for the new scope). This is intentional friction. @@ -79,26 +85,47 @@ There is no "Expanded" state by design. Adding scope mid-flight requires going b While `Status: Locked …`, the following are **stop-the-line errors** for any pipeline skill: -1. **Dropping a task.** A task in the manifest cannot be skipped. If the agent encounters a task that turns out to be infeasible, it MUST surface this to the user and request a scope reduction (which goes through the unlock path, not a unilateral skip). +1. **Dropping a task.** A task in the manifest cannot be skipped. If the agent encounters a task that turns out to be infeasible, it MUST surface this to the user and request a manifest amendment (not perform a unilateral skip). 2. **Adding a task not in the manifest.** Discovering "we also need to do X" mid-execution is not a license to silently add X. Either X is already implied by an existing task (then it goes under that task) or X is new scope (then it goes through brainstorming + a new design + a new plan or an explicit manifest amendment). 3. **Collapsing PRs.** If the manifest has 3 PR rows, the autonomous pipeline must produce 3 PRs. Collapsing into 1 PR is a stop-the-line error even if "all the code is the same". 4. **Splitting a PR.** Same rule in reverse. The grouping table is the contract. -5. **Re-ordering tasks within the same PR is allowed.** Re-ordering tasks across PRs is **not** allowed without an unlock — it changes which task ships in which PR, which changes review boundaries. -6. **"Reorder as needed", "create a PR", "test locally", and similar imperative-but-vague user phrases do NOT authorize any of the above.** These phrases speak to *how* the agent runs the manifest, not to *what* is in the manifest. See the strict-interpretation rule in `using-superpowers`. +5. **Re-ordering tasks within the same PR is allowed.** Re-ordering tasks across PRs is **not** allowed without an amendment — it changes which task ships in which PR, which changes review boundaries. +6. **"Reorder as needed", "create a PR", "test locally", and similar imperative-but-vague user phrases do NOT authorize any of the above.** These phrases speak to *how* the agent runs the manifest, not to *what* is in the manifest. See the strict-interpretation rule in `using-autodev`. + +## Design Backport Path (no manifest change) + +If execution or verification disproves a design assumption, reveals a bug in +the design, or clarifies an edge case, append a backport note to the design +doc. This does **not** require unlocking when the Scope Manifest is unchanged. + +Required steps: + +1. Append a dated `Backport` note to `docs/plans/*-design.md`. +2. State: failed assumption, evidence, corrected behavior, and whether manifest + scope changes. +3. Use `autodev:condensed-pipeline-writing` to keep the note compact. +4. If the plan tasks, PR count, or shipped scope remain unchanged, continue + execution. The `.scope-lock` hash should still verify. + +The lock protects the manifest, not every explanatory paragraph. Backporting +facts into the design is expected and must not be blocked by hooks. -## Unlock path (user-approved scope reduction) +## Amendment Path (manifest change) -If during execution the agent or the user determines that a task or PR should be removed: +If during execution the agent or the user determines that tasks, PR grouping, or +shipped scope should change: 1. **Stop the line.** Pause execution; do not commit or push anything that depends on the dropped scope. -2. **Surface the proposed reduction explicitly.** State which tasks would be removed, which PRs are affected, and why. Do not paraphrase a vague user phrase as approval. -3. **Wait for explicit user confirmation.** "Yes, remove tasks 4 and 5" — exact tasks named, exact reduction acknowledged. Anything less than this MUST be treated as not-yet-approved. -4. **Invoke `recording-decisions`** with reduction-specific context: which tasks/PRs are dropped, what was rejected, what carries over (or gets re-planned). The ADR is the audit record. -5. **Update the manifest in place.** Remove the dropped task rows; update `**PR Count:**` and `**Tasks:**`; flip status to `Reduced YYYY-MM-DDTHH:MM:SSZ (see decisions/NNNN-...md)`. -6. **Re-run `alignment-check`** on the reduced plan. The reduced manifest must still cover every requirement in the (possibly also reduced) design. If the design was not also reduced, alignment will fail — that's the correct behavior. The user must reduce the design first via a new `brainstorming --design-only` pass. -7. **On alignment PASS,** the lock re-engages with a new `Locked` stamp. +2. **Surface the proposed amendment explicitly.** State which tasks/PRs/design requirements change and why. Do not paraphrase a vague user phrase as approval. +3. **Wait for explicit user confirmation unless the change is already explicitly approved in the current user request.** Example: "Yes, remove tasks 4 and 5" or "Yes, add task 6 for the discovered hook schema bug." +4. **Invoke `recording-decisions`** with amendment-specific context: what changes, what was rejected, what carries over (or gets re-planned). The ADR is the audit record. +5. **Backport the design first.** Append the dated correction to the design doc, including evidence that made the original assumption false. +6. **Update the manifest in place.** Update task rows, `**PR Count:**`, `**Tasks:**`, and status to `Amended YYYY-MM-DDTHH:MM:SSZ (see decisions/NNNN-...md)`. +7. **Re-run `alignment-check`** on the amended design + plan. The amended manifest must cover every requirement in the amended design. +8. **On alignment PASS,** the lock re-engages with a new `Locked` stamp. -The unlock path is intentionally heavyweight. Cheap unlock = no lock at all. +The amendment path is intentionally heavyweight when manifest scope changes. +Cheap manifest edits = no lock at all. ## Lock enforcement at each pipeline stage @@ -106,7 +133,7 @@ The unlock path is intentionally heavyweight. Cheap unlock = no lock at all. - After PASS, edit the plan's `**Status:**` line to `Locked `. - Write the lock file by running the helper via Bash (do **not** use the Write tool — the Write tool is blocked for `*.scope-lock` paths by the scope guard hook): ``` - bash "${CLAUDE_PLUGIN_ROOT}/hooks/scope-lock-apply" + bash hooks/scope-lock-apply ``` The helper extracts the `## Scope Manifest` section, computes its sha256, and writes `.scope-lock` via shell redirection. It prints the path and hash prefix on success, or an error message and exits non-zero on failure. - Commit both files in the same commit: `chore: lock scope for (alignment passed)`. @@ -125,15 +152,15 @@ The unlock path is intentionally heavyweight. Cheap unlock = no lock at all. - Reads the per-PR grouping table to know which monitor instance handles which PR. **`post-merge-retrospective` (already wired):** -- Reads the manifest and stamps to know what was promised vs. what shipped. A reduced manifest is fine; an undocumented reduction is a gate miss. +- Reads the manifest and stamps to know what was promised vs. what shipped. An amended manifest is fine; an undocumented reduction or expansion is a gate miss. ## Anti-patterns - **"The plan is just a guide."** No. After alignment PASS, the plan is the contract. Treating the plan as advisory after lock is the failure mode this skill exists to prevent. - **Collapsing PRs because "they're all related."** Relatedness does not justify collapse. The PR grouping table reflects review-friendliness and rollback granularity, not just code locality. -- **Treating user vagueness as license.** "Reorder as needed" does not mean "rescope as needed". When in doubt, the agent picks the strictest interpretation and surfaces it. See `using-superpowers` strict-interpretation invariant. -- **Silently dropping a task because it turned out to be hard.** That's the unlock path's job. A unilateral skip is a contract breach. -- **"Demo" framing.** Once the manifest is locked, there is no demo mode. Either you ship the contract or you go through the unlock path. "Let me just get something working" is exactly the rationalization this skill blocks. +- **Treating user vagueness as license.** "Reorder as needed" does not mean "rescope as needed". When in doubt, the agent picks the strictest interpretation and surfaces it. See `using-autodev` strict-interpretation invariant. +- **Silently dropping a task because it turned out to be hard.** That's the amendment path's job. A unilateral skip is a contract breach. +- **"Demo" framing.** Once the manifest is locked, there is no demo mode. Either you ship the contract or you go through the amendment path. "Let me just get something working" is exactly the rationalization this skill blocks. ## Integration @@ -144,7 +171,7 @@ The unlock path is intentionally heavyweight. Cheap unlock = no lock at all. - Manual — when a user asks "are we still on plan?" the agent runs the check. **Calls:** -- `recording-decisions` — when the user explicitly approves a scope reduction. +- `recording-decisions` — when the user explicitly approves a manifest amendment. - `tests/plan-scope-check.sh` — for the programmatic verification. **Reads:** @@ -155,7 +182,7 @@ The unlock path is intentionally heavyweight. Cheap unlock = no lock at all. **Writes:** - `docs/plans/.md` — the `**Status:**` line, on lock or reduce. - `docs/plans/.md.scope-lock` — the manifest hash file. -- (via `recording-decisions`) `decisions/NNNN-scope-reduction-.md`. +- (via `recording-decisions`) `decisions/NNNN-scope-amendment-.md`. ## Why a separate skill diff --git a/skills/subagent-driven-development/SKILL.md b/skills/subagent-driven-development/SKILL.md index f2b2d3d..807005d 100644 --- a/skills/subagent-driven-development/SKILL.md +++ b/skills/subagent-driven-development/SKILL.md @@ -3,6 +3,8 @@ name: subagent-driven-development description: Use when executing implementation plans with independent tasks in the current session --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Subagent-Driven Development Execute a plan using either a role-based subagent team or sequential subagents, with two-stage review: spec compliance first, then code quality. @@ -232,7 +234,7 @@ Wait for all shutdown approvals, then: TeamDelete() ``` -Invoke `superpowers:finishing-a-development-branch`. +Invoke `autodev:finishing-a-development-branch`. @@ -258,8 +260,8 @@ For each task in the plan: exits non-zero, stop the line: the manifest has drifted from the locked hash, or reality has drifted from the manifest. Surface the specific discrepancy to the user and wait for instruction. Do NOT silently re-lock or proceed. See - `skills/scope-lock/SKILL.md` for the unlock path (which requires explicit user - approval and an ADR via `recording-decisions`). + `skills/scope-lock/SKILL.md` for the amendment path (which requires explicit + user approval and an ADR via `recording-decisions` when the manifest changes). 1. **Dispatch implementer subagent** — provide the full task text, the design doc path, and the working directory in the prompt. Use `./implementer-prompt.md` as the base template. 2. **Answer questions** if the implementer surfaces blockers. @@ -271,7 +273,7 @@ For each task in the plan: 7. If quality issues found → implementer fixes → re-review until approved. 8. Mark task complete and move to the next. -After all tasks: run `bash tests/plan-scope-check.sh --plan --verify-lock ` one final time, then invoke `superpowers:finishing-a-development-branch`. If the scope check fails, do not invoke finishing — surface the discrepancy first. +After all tasks: run `bash tests/plan-scope-check.sh --plan --verify-lock ` one final time, then invoke `autodev:finishing-a-development-branch`. If the scope check fails, do not invoke finishing — surface the discrepancy first. @@ -284,7 +286,9 @@ Codex subagents do not share a task list. Use these conventions instead: - **Handoff surface**: use git branch names (`task-N-`) and PR diffs as the review surface. The spec-reviewer and code-reviewer read the PR diff, not a task record. - **Progress tracking**: after each task completes, record completion in the orchestrating - agent's own context (e.g., a local list) rather than a shared task table. + agent's own context and append a compact JSONL row + (`{"ev":"phase","pl":"...","ph":"...","st":"done","e":"...","nx":"..."}`) to + `.autodev/state/phase-progress.jsonl` when a locked plan remains active. - **No DM channel**: pass reviewer output back to the orchestrator as a return value; the orchestrator decides whether to re-dispatch the implementer. @@ -298,7 +302,7 @@ Codex subagents do not share a task list. Use these conventions instead: - Start implementation on main/master without explicit user consent - Skip reviews (spec compliance OR code quality) - Skip the scope-lock checkpoint between tasks (Step 0 in Sequential Mode; equivalent watchdog cadence in Agent Teams Mode — see Resilience section) -- Drop a task because it turned out to be hard. Surface the obstruction to the user; the unlock path in `skills/scope-lock/SKILL.md` is the only sanctioned way to remove a task from the manifest. +- Drop a task because it turned out to be hard. Surface the obstruction to the user; the amendment path in `skills/scope-lock/SKILL.md` is the only sanctioned way to remove a task from the manifest. - Add a task that isn't in the manifest. Discovering "we also need X" mid-execution is not a license to silently add it. Either it's already covered by an existing task, or it's a manifest amendment (which requires going back through brainstorming for the new scope). - Collapse PRs. The manifest's PR Grouping table is a contract; if it has 3 rows, the work ships as 3 PRs. - Proceed with unfixed issues @@ -322,16 +326,16 @@ Codex subagents do not share a task list. Use these conventions instead: ## Integration **Required workflow skills:** -- **superpowers:using-git-worktrees** - REQUIRED: Set up isolated workspace before starting -- **superpowers:writing-plans** - Creates the plan this skill executes -- **superpowers:alignment-check** - Verifies plan matches design (autonomous mode) -- **superpowers:finishing-a-development-branch** - Complete development after all tasks +- **autodev:using-git-worktrees** - REQUIRED: Set up isolated workspace before starting +- **autodev:writing-plans** - Creates the plan this skill executes +- **autodev:alignment-check** - Verifies plan matches design (autonomous mode) +- **autodev:finishing-a-development-branch** - Complete development after all tasks **Subagents/teammates should use:** -- **superpowers:test-driven-development** - Follow TDD for each task +- **autodev:test-driven-development** - Follow TDD for each task **Alternative workflow:** -- **superpowers:executing-plans** - Use for parallel session instead of same-session execution +- **autodev:executing-plans** - Use for parallel session instead of same-session execution --- @@ -351,12 +355,12 @@ How the re-orientation context arrives depends on the host: -Hooks automate it. The plugin's `SessionStart` hook (matcher `compact|resume`) fires inside the compacted session and injects a `` block containing: +Hooks automate it. The plugin's `SessionStart` hook (matcher `compact|resume`) fires inside the compacted session and injects a `` block containing: - The first user message from the transcript (the "original task") — this is what re-anchors a compacted **subagent** to its assignment. -- Recent superpowers activity (last 30 entries from `.claude/superpowers-state/in-progress.jsonl`) — this is what re-anchors the **lead** in the pipeline. +- Recent autodev activity (last 30 entries from `.claude/autodev-state/in-progress.jsonl`) — this is what re-anchors the **lead** in the pipeline. -Activity is captured by a `PostToolUse` hook (matcher `Skill|Agent|Task.*`) that appends each invocation to the JSONL state file (capped at 200 lines; wiped on `startup|clear` or when the session source can't be determined). The state file is project-local at `.claude/superpowers-state/in-progress.jsonl`. +Activity is captured by a `PostToolUse` hook (matcher `Skill|Agent|Task.*`) that appends each invocation as compressed JSONL (`ev`, `sk`, `ag`, `tt`, `d`) capped at 200 lines; wiped on `startup|clear` or when the session source can't be determined. The state file is project-local at `.claude/autodev-state/in-progress.jsonl`. You don't opt in. When you see the resumption block, treat it as authoritative and reorient before responding. @@ -414,7 +418,7 @@ Subagents are teammates, not infrastructure. If one keeps producing low-quality - 3 cumulative quality issues across tasks in one session → stop dispatching that subagent_type for the remainder of the session; re-route its work to an alternative. - A subagent that ignores explicit guidance twice in a row → stop using it; the issue is the agent profile, not the prompt. -When you rotate, briefly state the rotation in user-facing text ("Rotating off `general-purpose` for review tasks — two consecutive rejections; using `superpowers:code-reviewer` instead") so the user has a chance to redirect. +When you rotate, briefly state the rotation in user-facing text ("Rotating off `general-purpose` for review tasks — two consecutive rejections; using `autodev:code-reviewer` instead") so the user has a chance to redirect. ### Why these patterns diff --git a/skills/subagent-driven-development/code-quality-reviewer-prompt.md b/skills/subagent-driven-development/code-quality-reviewer-prompt.md index 165571d..f123ab5 100644 --- a/skills/subagent-driven-development/code-quality-reviewer-prompt.md +++ b/skills/subagent-driven-development/code-quality-reviewer-prompt.md @@ -15,7 +15,7 @@ Use this template when dispatching a code quality reviewer subagent. ``` -Task tool (superpowers:code-reviewer): +Task tool (autodev:code-reviewer): Use template at skills/requesting-code-review/code-reviewer.md WHAT_WAS_IMPLEMENTED: [from implementer's report] diff --git a/skills/systematic-debugging/CREATION-LOG.md b/skills/systematic-debugging/CREATION-LOG.md index 024d00a..0d9fa85 100644 --- a/skills/systematic-debugging/CREATION-LOG.md +++ b/skills/systematic-debugging/CREATION-LOG.md @@ -4,7 +4,7 @@ Reference example of extracting, structuring, and bulletproofing a critical skil ## Source Material -Extracted debugging framework from `/Users/jesse/.claude/CLAUDE.md`: +Extracted debugging framework from `/Users/jon/.claude/CLAUDE.md`: - 4-phase systematic process (Investigation → Pattern Analysis → Hypothesis → Implementation) - Core mandate: ALWAYS find root cause, NEVER fix symptoms - Rules designed to resist time pressure and rationalization diff --git a/skills/systematic-debugging/SKILL.md b/skills/systematic-debugging/SKILL.md index 111d2a9..bcdd719 100644 --- a/skills/systematic-debugging/SKILL.md +++ b/skills/systematic-debugging/SKILL.md @@ -3,6 +3,8 @@ name: systematic-debugging description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Systematic Debugging ## Overview @@ -176,7 +178,7 @@ You MUST complete each phase before proceeding to the next. - Automated test if possible - One-off test script if no framework - MUST have before fixing - - Use the `superpowers:test-driven-development` skill for writing proper failing tests + - Use the `autodev:test-driven-development` skill for writing proper failing tests 2. **Implement Single Fix** - Address the root cause identified @@ -284,8 +286,8 @@ These techniques are part of systematic debugging and available in this director - **`condition-based-waiting.md`** - Replace arbitrary timeouts with condition polling **Related skills:** -- **superpowers:test-driven-development** - For creating failing test case (Phase 4, Step 1) -- **superpowers:verification-before-completion** - Verify fix worked before claiming success +- **autodev:test-driven-development** - For creating failing test case (Phase 4, Step 1) +- **autodev:verification-before-completion** - Verify fix worked before claiming success ## Real-World Impact diff --git a/skills/systematic-debugging/root-cause-tracing.md b/skills/systematic-debugging/root-cause-tracing.md index 9484774..662111d 100644 --- a/skills/systematic-debugging/root-cause-tracing.md +++ b/skills/systematic-debugging/root-cause-tracing.md @@ -33,7 +33,7 @@ digraph when_to_use { ### 1. Observe the Symptom ``` -Error: git init failed in /Users/jesse/project/packages/core +Error: git init failed in /Users/jon/project/packages/core ``` ### 2. Find Immediate Cause diff --git a/skills/test-driven-development/SKILL.md b/skills/test-driven-development/SKILL.md index 336a257..2fc7255 100644 --- a/skills/test-driven-development/SKILL.md +++ b/skills/test-driven-development/SKILL.md @@ -3,6 +3,8 @@ name: test-driven-development description: Use when implementing any feature or bugfix, before writing implementation code --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Test-Driven Development (TDD) ## Overview diff --git a/skills/using-superpowers/SKILL.md b/skills/using-autodev/SKILL.md similarity index 87% rename from skills/using-superpowers/SKILL.md rename to skills/using-autodev/SKILL.md index 72474b1..9260ff3 100644 --- a/skills/using-superpowers/SKILL.md +++ b/skills/using-autodev/SKILL.md @@ -1,8 +1,10 @@ --- -name: using-superpowers +name: using-autodev description: Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill. @@ -13,9 +15,7 @@ This is not negotiable. This is not optional. You cannot rationalize your way ou ## How to Access Skills -**In Claude Code:** Use the `Skill` tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files. - -**In other environments:** Check your platform's documentation for how skills are loaded. +Use the current host's skill-loading mechanism. When a skill is invoked or loaded, follow its instructions directly. Do not bypass the skill body by relying on memory of similarly named workflows. # Using Skills @@ -83,7 +83,7 @@ When multiple skills could apply, use this order: 3. **Pipeline skills auto-chain** — these invoke each other automatically in the autonomous pipeline: brainstorming → adversarial-design-review (design phase) → writing-plans → adversarial-design-review (plan phase) → alignment-check → **scope-lock** → subagent-driven-development → finishing-a-development-branch → pr-monitoring → post-merge-retrospective - Cross-cutting skills invoked from within the pipeline when conditions trigger: `recording-decisions` (when designs/plans make non-trivial trade-offs, including user-approved scope reductions); `scope-lock` (re-checked at every per-task checkpoint and before PR creation). + Cross-cutting skills invoked from within the pipeline when conditions trigger: `project-design-guidance` (before designs/plans and during retros when durable guidance changes); `recording-decisions` (when designs/plans make non-trivial trade-offs, including user-approved manifest amendments); `scope-lock` (re-checked at every per-task checkpoint and before PR creation); `condensed-pipeline-writing` (for dense internal design/review/plan artifacts). "Let's build X" → brainstorming first, then the pipeline runs autonomously after design approval. "Fix this bug" → debugging first, then domain-specific skills. @@ -110,7 +110,7 @@ When the autonomous pipeline is running and a user instruction is **ambiguous**, | "create a PR" | create one PR for whatever subset is convenient | create the number of PRs in the manifest's PR Grouping table | | "test locally" | skip CI; ship something that "works on my machine" | run the verification steps every plan task declares; CI still runs at the end | | "make it work" / "just get something working" | trim scope until the partial result runs | implement the full manifest; if blocked, surface the blocker | -| "ship a demo" | partial scope + happy-path-only tests | there is no demo mode; either ship the locked manifest or invoke the unlock path | +| "ship a demo" | partial scope + happy-path-only tests | there is no demo mode; either ship the locked manifest or invoke the amendment path | | "do whatever you think is best" | unilaterally restructure plan | do the locked manifest; surface choices not covered by the manifest | | "be efficient" / "be quick" | drop tests, drop reviews, drop tasks | run the pipeline at full discipline; speed comes from parallelism, not from skipping | | "go autonomous" / "run autonomously" / "auto mode" / "auto-mode" | treat as license to rescope, collapse PRs, skip pipeline discipline, or remove checkpoints | "autonomous" means running without interrupting the user — it does not relax any pipeline rule; all gates, checkpoints, and manifest constraints still apply | @@ -118,6 +118,6 @@ When the autonomous pipeline is running and a user instruction is **ambiguous**, **When multiple strict interpretations remain plausible**, the agent stops and asks. Picking one and proceeding is not allowed. The cheapest place to catch a misinterpretation is before any commit; the most expensive is after a PR is opened. -**Locked plans are inviolate.** If the user phrase appears to conflict with the locked manifest in `docs/plans/.md`, the locked manifest wins until the user goes through the unlock path defined in `skills/scope-lock/SKILL.md`. "I told you to reorder" does not retroactively authorize rescoping; "yes, drop tasks 4 and 5" does (and triggers `recording-decisions`). +**Locked plans are inviolate.** If the user phrase appears to conflict with the locked manifest in `docs/plans/.md`, the locked manifest wins until the user goes through the amendment path defined in `skills/scope-lock/SKILL.md`. "I told you to reorder" does not retroactively authorize rescoping; "yes, drop tasks 4 and 5" does (and triggers `recording-decisions`). This rule is **rigid**, not flexible. Do not adapt it. The whole point is that ambiguity is resolved upward, never sideways. diff --git a/skills/using-git-worktrees/SKILL.md b/skills/using-git-worktrees/SKILL.md index e153843..159077c 100644 --- a/skills/using-git-worktrees/SKILL.md +++ b/skills/using-git-worktrees/SKILL.md @@ -3,6 +3,8 @@ name: using-git-worktrees description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Using Git Worktrees ## Overview @@ -27,23 +29,23 @@ ls -d worktrees 2>/dev/null # Alternative **If found:** Use that directory. If both exist, `.worktrees` wins. -### 2. Check CLAUDE.md +### 2. Check Agent Guidance ```bash -grep -i "worktree.*director" CLAUDE.md 2>/dev/null +grep -i "worktree.*director" AGENTS.md CLAUDE.md 2>/dev/null ``` **If preference specified:** Use it without asking. ### 3. Ask User -If no directory exists and no CLAUDE.md preference: +If no directory exists and no agent-guidance preference: ``` No worktree directory found. Where should I create worktrees? 1. .worktrees/ (project-local, hidden) -2. ~/.config/superpowers/worktrees// (global location) +2. ~/.config/autodev/worktrees// (global location) Which would you prefer? ``` @@ -61,14 +63,14 @@ git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/d **If NOT ignored:** -Per Jesse's rule "Fix broken things immediately": +Per Jon's rule "Fix broken things immediately": 1. Add appropriate line to .gitignore 2. Commit the change 3. Proceed with worktree creation **Why critical:** Prevents accidentally committing worktree contents to repository. -### For Global Directory (~/.config/superpowers/worktrees) +### For Global Directory (~/.config/autodev/worktrees) No .gitignore verification needed - outside project entirely. @@ -88,8 +90,8 @@ case $LOCATION in .worktrees|worktrees) path="$LOCATION/$BRANCH_NAME" ;; - ~/.config/superpowers/worktrees/*) - path="~/.config/superpowers/worktrees/$project/$BRANCH_NAME" + ~/.config/autodev/worktrees/*) + path="~/.config/autodev/worktrees/$project/$BRANCH_NAME" ;; esac @@ -148,7 +150,7 @@ Ready to implement | `.worktrees/` exists | Use it (verify ignored) | | `worktrees/` exists | Use it (verify ignored) | | Both exist | Use `.worktrees/` | -| Neither exists | Check CLAUDE.md → Ask user | +| Neither exists | Check agent guidance → Ask user | | Directory not ignored | Add to .gitignore + commit | | Tests fail during baseline | Report failures + ask | | No package.json/Cargo.toml | Skip dependency install | @@ -163,7 +165,7 @@ Ready to implement ### Assuming directory location - **Problem:** Creates inconsistency, violates project conventions -- **Fix:** Follow priority: existing > CLAUDE.md > ask +- **Fix:** Follow priority: existing > agent guidance > ask ### Proceeding with failing tests @@ -186,7 +188,7 @@ You: I'm using the using-git-worktrees skill to set up an isolated workspace. [Run npm install] [Run npm test - 47 passing] -Worktree ready at /Users/jesse/myproject/.worktrees/auth +Worktree ready at /Users/jon/myproject/.worktrees/auth Tests passing (47 tests, 0 failures) Ready to implement auth feature ``` @@ -198,10 +200,10 @@ Ready to implement auth feature - Skip baseline test verification - Proceed with failing tests without asking - Assume directory location when ambiguous -- Skip CLAUDE.md check +- Skip agent-guidance check **Always:** -- Follow directory priority: existing > CLAUDE.md > ask +- Follow directory priority: existing > agent guidance > ask - Verify directory is ignored for project-local - Auto-detect and run project setup - Verify clean test baseline diff --git a/skills/verification-before-completion/SKILL.md b/skills/verification-before-completion/SKILL.md index 2f14076..2ebba41 100644 --- a/skills/verification-before-completion/SKILL.md +++ b/skills/verification-before-completion/SKILL.md @@ -3,137 +3,63 @@ name: verification-before-completion description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Verification Before Completion -## Overview +## Law + +`NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE` + +No fresh command this turn → no pass/fixed/done/complete claim. Evidence before assertion. + +## Gate + +Before any success/completion wording: + +1. ID proof: which command/check proves it? +2. Run full command fresh. +3. Read full output + exit code + failure count. +4. Compare output to claim. +5. State actual status with evidence; only claim success if output proves it. + +Skip step = unverified claim. + +## Claim Matrix + +| claim | needs | not enough | +|---|---|---| +| tests pass | test output: exit 0 / 0 fail | old run, "should" | +| lint clean | linter output: 0 errors | partial scan | +| build works | build exit 0 | tests/lint only | +| bug fixed | original symptom/regression passes | code changed | +| regression test works | red → green proof | green only | +| agent completed | inspect diff + verify | agent report | +| requirements met | checklist vs plan/design | tests alone | + +## Red Flags + +Stop before saying: "should", "probably", "seems", "done", "fixed", "works", "all set", "perfect", "complete", "passes" unless fresh proof exists. + +Also stop before commit/PR/next task if verification has not run after final edits. + +## Patterns + +Tests: +`run tests → read 34/34 pass → "Tests pass: exited 0."` + +Regression: +`write test → pass → revert fix → must fail → restore fix → pass` + +Build: +`run build → exit 0`; lint is not build. + +Requirements: +`re-read plan/design → checklist each item → report gaps or evidence`. + +Delegation: +`agent says done → inspect VCS diff → run verification → report observed state`. + +## Bottom Line -Claiming work is complete without verification is dishonesty, not efficiency. - -**Core principle:** Evidence before claims, always. - -**Violating the letter of this rule is violating the spirit of this rule.** - -## The Iron Law - -``` -NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE -``` - -If you haven't run the verification command in this message, you cannot claim it passes. - -## The Gate Function - -``` -BEFORE claiming any status or expressing satisfaction: - -1. IDENTIFY: What command proves this claim? -2. RUN: Execute the FULL command (fresh, complete) -3. READ: Full output, check exit code, count failures -4. VERIFY: Does output confirm the claim? - - If NO: State actual status with evidence - - If YES: State claim WITH evidence -5. ONLY THEN: Make the claim - -Skip any step = lying, not verifying -``` - -## Common Failures - -| Claim | Requires | Not Sufficient | -|-------|----------|----------------| -| Tests pass | Test command output: 0 failures | Previous run, "should pass" | -| Linter clean | Linter output: 0 errors | Partial check, extrapolation | -| Build succeeds | Build command: exit 0 | Linter passing, logs look good | -| Bug fixed | Test original symptom: passes | Code changed, assumed fixed | -| Regression test works | Red-green cycle verified | Test passes once | -| Agent completed | VCS diff shows changes | Agent reports "success" | -| Requirements met | Line-by-line checklist | Tests passing | - -## Red Flags - STOP - -- Using "should", "probably", "seems to" -- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.) -- About to commit/push/PR without verification -- Trusting agent success reports -- Relying on partial verification -- Thinking "just this once" -- Tired and wanting work over -- **ANY wording implying success without having run verification** - -## Rationalization Prevention - -| Excuse | Reality | -|--------|---------| -| "Should work now" | RUN the verification | -| "I'm confident" | Confidence ≠ evidence | -| "Just this once" | No exceptions | -| "Linter passed" | Linter ≠ compiler | -| "Agent said success" | Verify independently | -| "I'm tired" | Exhaustion ≠ excuse | -| "Partial check is enough" | Partial proves nothing | -| "Different words so rule doesn't apply" | Spirit over letter | - -## Key Patterns - -**Tests:** -``` -✅ [Run test command] [See: 34/34 pass] "All tests pass" -❌ "Should pass now" / "Looks correct" -``` - -**Regression tests (TDD Red-Green):** -``` -✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass) -❌ "I've written a regression test" (without red-green verification) -``` - -**Build:** -``` -✅ [Run build] [See: exit 0] "Build passes" -❌ "Linter passed" (linter doesn't check compilation) -``` - -**Requirements:** -``` -✅ Re-read plan → Create checklist → Verify each → Report gaps or completion -❌ "Tests pass, phase complete" -``` - -**Agent delegation:** -``` -✅ Agent reports success → Check VCS diff → Verify changes → Report actual state -❌ Trust agent report -``` - -## Why This Matters - -From 24 failure memories: -- your human partner said "I don't believe you" - trust broken -- Undefined functions shipped - would crash -- Missing requirements shipped - incomplete features -- Time wasted on false completion → redirect → rework -- Violates: "Honesty is a core value. If you lie, you'll be replaced." - -## When To Apply - -**ALWAYS before:** -- ANY variation of success/completion claims -- ANY expression of satisfaction -- ANY positive statement about work state -- Committing, PR creation, task completion -- Moving to next task -- Delegating to agents - -**Rule applies to:** -- Exact phrases -- Paraphrases and synonyms -- Implications of success -- ANY communication suggesting completion/correctness - -## The Bottom Line - -**No shortcuts for verification.** - -Run the command. Read the output. THEN claim the result. - -This is non-negotiable. +Run the proof. Read it. Then claim exactly what it proves. diff --git a/skills/writing-plans/SKILL.md b/skills/writing-plans/SKILL.md index 8c77727..6732235 100644 --- a/skills/writing-plans/SKILL.md +++ b/skills/writing-plans/SKILL.md @@ -3,6 +3,8 @@ name: writing-plans description: Use when you have a spec or requirements for a multi-step task, before touching code --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Writing Plans ## Overview @@ -17,35 +19,35 @@ Assume they are a skilled developer, but know almost nothing about our toolset o **Save plans to:** `docs/plans/YYYY-MM-DD-.md` -## Plan Mode Detection +## Native Planning Mode Detection -**Prefer Claude's Plan Mode when available.** If you are running in Claude Code and can enter Plan Mode (e.g. via `Shift+Tab` or the `/plan` command), use it to draft the implementation plan. If Claude's Plan Mode is not available (Cursor, Codex, OpenCode, or other environments), use the Built-In Planning Process below. +**Prefer host-native planning mode when available.** If the current agent interface offers a dedicated planning mode, use it to draft the implementation plan. If no planning mode is available, use the Built-In Planning Process below. -### Using Claude's Plan Mode (Claude Code) +### Using Host-Native Planning Mode -1. **Enter Plan Mode** — explore the codebase, analyze the design, and draft the implementation plan using Claude's native Plan Mode +1. **Enter planning mode** — explore the codebase, analyze the design, and draft the implementation plan using the host's native planning workflow 2. **Follow the plan format below** — structure your Plan Mode output using the same Plan Document Header and Task Structure defined in this skill -3. **Exit Plan Mode** — once the plan is fully drafted +3. **Exit planning mode** — once the plan is fully drafted 4. **Save the plan** — write the plan to `docs/plans/YYYY-MM-DD-.md` using the exact format from Plan Document Header and Task Structure sections below 5. **Continue the pipeline** — proceed to Execution Handoff as normal The plan document you save MUST follow the same format described in Plan Document Header and Task Structure below, regardless of whether it was drafted in Plan Mode or with the built-in process. This ensures downstream skills (alignment-check, executing-plans, subagent-driven-development) work correctly. -### Built-In Planning Process (Non-Claude Code) +### Built-In Planning Process -When Claude's Plan Mode is not available, use the full planning process described in the sections below to write the plan directly. +When host-native planning mode is not available, use the full planning process described in the sections below to write the plan directly. ## Autonomous Mode When invoked from brainstorming with autonomous context (design already approved AND adversarially reviewed): 1. **Skip user plan review** — write the plan directly without presenting it for approval -2. **Invoke `superpowers:adversarial-design-review --phase=plan`** — adversarially attack the plan (and inherited design) before structural alignment is checked -3. **On adversarial-review PASS** — invoke `superpowers:alignment-check` -4. **On adversarial-review FAIL** — revise the plan based on Critical and Important findings, re-run adversarial review (max 2 cycles per gate) -5. **On alignment PASS** — invoke `superpowers:subagent-driven-development` to begin execution +2. **Invoke `autodev:adversarial-design-review --phase=plan`** — adversarially attack the plan (and inherited design) before structural alignment is checked +3. **On adversarial-review PASS** — invoke `autodev:alignment-check` +4. **On adversarial-review FAIL** — revise the plan based on tangible Critical and Important findings, re-run adversarial review until it converges to no tangible issues; remaining nitpicks become Minor PASS items +5. **On alignment PASS** — invoke `autodev:subagent-driven-development` to begin execution 6. **On alignment FAIL** — revise the plan based on drift items, re-check (max 2 cycles) -7. **On persistent FAIL at any gate** — escalate to user with unresolved findings/drift summary +7. **On persistent FAIL at any gate** — escalate to user only when unresolved tangible findings/drift require human input The autonomous flag propagates through the entire pipeline: writing-plans → adversarial-design-review (plan phase) → alignment-check → execution → PR creation → PR monitoring. @@ -61,13 +63,13 @@ Do not add YAML frontmatter to signal design-only mode. Saved plan documents mus 1. Save the plan to `docs/plans/YYYY-MM-DD-.md` as normal. 2. Commit the plan as normal. -3. Invoke `superpowers:adversarial-design-review --phase=plan` as normal. -4. On adversarial-review FAIL: revise the plan based on findings and re-run adversarial review (max 2 cycles). -5. On adversarial-review PASS: invoke `superpowers:alignment-check` as normal. -6. **On alignment PASS: STOP.** Do NOT invoke `superpowers:subagent-driven-development`. -7. **On alignment FAIL:** revise the plan based on drift items and run `superpowers:alignment-check` again, with a maximum of 2 alignment-check cycles total. If a revised plan passes alignment, still STOP and do not proceed to execution. -8. **On persistent FAIL at any gate (after the cycle bound for that gate):** escalate to the user with an unresolved findings/drift summary. Do NOT invoke `superpowers:subagent-driven-development` or dispatch any execution. -9. The plan + design + adversarial review reports sit in `docs/plans/` for future execution. The orchestrator (or a future invocation) can resume by passing the plan to `superpowers:subagent-driven-development` directly once gate issues are resolved. +3. Invoke `autodev:adversarial-design-review --phase=plan` as normal. +4. On adversarial-review FAIL: revise the plan based on tangible findings and re-run adversarial review until it converges to no tangible issues. +5. On adversarial-review PASS: invoke `autodev:alignment-check` as normal. +6. **On alignment PASS: STOP.** Do NOT invoke `autodev:subagent-driven-development`. +7. **On alignment FAIL:** revise the plan based on drift items and run `autodev:alignment-check` again, with a maximum of 2 alignment-check cycles total. If a revised plan passes alignment, still STOP and do not proceed to execution. +8. **On persistent FAIL at any gate:** escalate to the user with an unresolved findings/drift summary only when tangible findings or drift require human input. Do NOT invoke `autodev:subagent-driven-development` or dispatch any execution. +9. The plan + design + adversarial review reports sit in `docs/plans/` for future execution. The orchestrator (or a future invocation) can resume by passing the plan to `autodev:subagent-driven-development` directly once gate issues are resolved. **When to use:** @@ -75,7 +77,7 @@ Do not add YAML frontmatter to signal design-only mode. Saved plan documents mus - Cross-cutting designs that affect multiple workstreams; lock the design in before any one workstream starts. - Designs with prerequisites in-flight elsewhere; queue the plan now, execute when prerequisites land. -**Default (no flag):** `superpowers:adversarial-design-review --phase=plan` PASS → `superpowers:alignment-check` PASS → invoke `superpowers:subagent-driven-development`. Adversarial review runs **before** alignment check so that idea-level findings are resolved before structural trace. +**Default (no flag):** `autodev:adversarial-design-review --phase=plan` PASS → `autodev:alignment-check` PASS → invoke `autodev:subagent-driven-development`. Adversarial review runs **before** alignment check so that idea-level findings are resolved before structural trace. ## Verification per change class @@ -93,6 +95,8 @@ When writing a plan task, the verification step must match the change class. A g | Plugin / extension | load into host + exercise representative call | exit 0; representative call returns expected value | | Documentation / comments | spell-check + render preview | no broken anchors | | Hook / trigger / event handler | fire the event; observe handler runs | logged side effect confirmed; assertion passes | +| Multi-component boundary | run an integration/E2E path with real adjacent components where feasible | request/event crosses boundary; downstream side effect observed | +| Infrastructure change | render/validate/plan/dry-run plus targeted apply in safe env when available | expected resource diff; no destructive prod action without approval | These examples are illustrative minimums; per-task `Expected:` fields must be literal values the check can assert against. @@ -100,6 +104,24 @@ Every plan task must include the verification step appropriate to its change cla The rollback note exists so that adversarial-design-review (plan phase) can verify the design's rollback story is actually wired into the plan, not orphaned in a paragraph. Plans without rollback notes for runtime-affecting tasks will fail adversarial review. +## Multi-Component and Infrastructure Proof + +Plans must turn design-level validation into executable checks: + +- **Multi-component systems:** include at least one task or verification step that + exercises the real boundary. Examples: API writes DB and worker consumes row; + frontend calls backend and renders returned state; plugin loads in host and + executes representative call; CLI command reaches service and observes side + effect. Mock-only tests are allowed only when the design explains why the real + boundary cannot be exercised locally. +- **Infrastructure changes:** include render/validate/plan/dry-run checks for + IaC or deployment config. If a safe sandbox apply is available, include it. + Destructive or production actions require explicit human approval already + recorded in the plan. +- **Security-sensitive changes:** include verification for auth/authz behavior, + secret redaction, least-privilege permissions, and representative abuse cases + when applicable. + ## Recording decisions If the plan introduces a non-trivial choice that wasn't already captured by an ADR cited in the design (e.g., a library pick, a sync-vs-async choice, a polling-vs-webhook decision made at plan time rather than at design time), invoke `skills/recording-decisions/SKILL.md` to add an ADR in `decisions/` and cite it from the relevant task. ADRs are how the *why* survives renames and refactors; the design and plan answer *what*. @@ -108,6 +130,20 @@ If every decision in the plan is already covered by ADRs cited from the design, The plan author writes the expected output literally — not "passes tests" but "logs `engine ready` within 10 seconds and `/healthz` returns 200". +## Project Design Guidance + +Before writing tasks, invoke `autodev:project-design-guidance` and read the +guidance source cited by the design's `## Global Design Guidance` section. + +Plans must map guidance to work: + +- If guidance requires behavior, add or cite a task that implements it. +- If guidance requires verification, include the exact command or inspection. +- If guidance requires rollback, privacy, observability, accessibility, or + deployment safeguards, wire those into relevant tasks. +- If the plan intentionally violates guidance, cite the ADR that approves the + exception. Without an ADR, the plan should fail adversarial review. + ## Bite-Sized Task Granularity **Each step is one action (2-5 minutes):** @@ -124,7 +160,7 @@ The plan author writes the expected output literally — not "passes tests" but ```markdown # [Feature Name] Implementation Plan -> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. +> **For the implementing agent:** REQUIRED SUB-SKILL: Use autodev:executing-plans to implement this plan task-by-task. **Goal:** [One sentence describing what this builds] @@ -227,12 +263,12 @@ git commit -m "feat: add specific feature" When running autonomously (design already approved AND adversarially reviewed, no user interaction): -1. Save the plan to `docs/plans/.md` +1. Save the plan to `docs/plans/.md` using `autodev:condensed-pipeline-writing` for internal density 2. Commit the plan -3. Invoke `superpowers:adversarial-design-review --phase=plan` to attack the plan's ideas -4. On adversarial-review PASS: invoke `superpowers:alignment-check` to verify design-to-plan structural alignment -5. On alignment PASS: invoke `superpowers:subagent-driven-development` (which uses Agent Teams when available) -6. On any FAIL: revise per findings/drift, re-run that gate (max 2 cycles per gate), then either continue or escalate to user +3. Invoke `autodev:adversarial-design-review --phase=plan` to attack the plan's ideas +4. On adversarial-review PASS: invoke `autodev:alignment-check` to verify design-to-plan structural alignment +5. On alignment PASS: invoke `autodev:subagent-driven-development` (which uses Agent Teams when available) +6. On adversarial-review FAIL: revise per tangible findings and re-run until no tangible Critical/Important issues remain; on alignment FAIL: revise per drift and re-check (max 2 alignment cycles), then either continue or escalate to user when human input is required 7. Do NOT ask the user for execution choice — the pipeline is autonomous ### Manual Mode (direct invocation) @@ -248,10 +284,10 @@ When invoked directly by the user (not from brainstorming pipeline): **Which approach?"** **If Subagent-Driven chosen:** -- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development +- **REQUIRED SUB-SKILL:** Use autodev:subagent-driven-development - Stay in this session - Fresh subagent per task + code review **If Parallel Session chosen:** - Guide them to open new session in worktree -- **REQUIRED SUB-SKILL:** New session uses superpowers:executing-plans +- **REQUIRED SUB-SKILL:** New session uses autodev:executing-plans diff --git a/skills/writing-skills/SKILL.md b/skills/writing-skills/SKILL.md index 6c73f7a..bb32a1e 100644 --- a/skills/writing-skills/SKILL.md +++ b/skills/writing-skills/SKILL.md @@ -3,6 +3,8 @@ name: writing-skills description: Use when creating new skills, editing existing skills, or verifying skills work before deployment --- +> Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand. + # Writing Skills ## Overview @@ -15,7 +17,7 @@ You write test cases (pressure scenarios with subagents), watch them fail (basel **Core principle:** If you didn't watch an agent fail without the skill, you don't know if the skill teaches the right thing. -**REQUIRED BACKGROUND:** You MUST understand superpowers:test-driven-development before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill adapts TDD to documentation. +**REQUIRED BACKGROUND:** You MUST understand autodev:test-driven-development before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill adapts TDD to documentation. **Official guidance:** For Anthropic's official skill authoring best practices, see anthropic-best-practices.md. This document provides additional patterns and guidelines that complement the TDD-focused approach in this skill. @@ -359,8 +361,8 @@ wc -w skills/path/SKILL.md **When writing documentation that references other skills:** Use skill name only, with explicit requirement markers: -- ✅ Good: `**REQUIRED SUB-SKILL:** Use superpowers:test-driven-development` -- ✅ Good: `**REQUIRED BACKGROUND:** You MUST understand superpowers:systematic-debugging` +- ✅ Good: `**REQUIRED SUB-SKILL:** Use autodev:test-driven-development` +- ✅ Good: `**REQUIRED BACKGROUND:** You MUST understand autodev:systematic-debugging` - ❌ Bad: `See skills/testing/test-driven-development` (unclear if required) - ❌ Bad: `@skills/testing/test-driven-development/SKILL.md` (force-loads, burns context) @@ -469,7 +471,7 @@ Edit skill without testing? Same violation. - Don't "adapt" while running tests - Delete means delete -**REQUIRED BACKGROUND:** The superpowers:test-driven-development skill explains why this matters. Same principles apply to documentation. +**REQUIRED BACKGROUND:** The autodev:test-driven-development skill explains why this matters. Same principles apply to documentation. ## Testing All Skill Types diff --git a/skills/writing-skills/testing-skills-with-subagents.md b/skills/writing-skills/testing-skills-with-subagents.md index a5acfea..53d9d9c 100644 --- a/skills/writing-skills/testing-skills-with-subagents.md +++ b/skills/writing-skills/testing-skills-with-subagents.md @@ -10,7 +10,7 @@ You run scenarios without the skill (RED - watch agent fail), write skill addres **Core principle:** If you didn't watch an agent fail without the skill, you don't know if the skill prevents the right failures. -**REQUIRED BACKGROUND:** You MUST understand superpowers:test-driven-development before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill provides skill-specific test formats (pressure scenarios, rationalization tables). +**REQUIRED BACKGROUND:** You MUST understand autodev:test-driven-development before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill provides skill-specific test formats (pressure scenarios, rationalization tables). **Complete worked example:** See examples/CLAUDE_MD_TESTING.md for a full test campaign testing CLAUDE.md documentation variants. diff --git a/tests/claude-code/README.md b/tests/claude-code/README.md index e53647b..94f6958 100644 --- a/tests/claude-code/README.md +++ b/tests/claude-code/README.md @@ -1,6 +1,6 @@ # Claude Code Skills Tests -Automated tests for superpowers skills using Claude Code CLI. +Automated tests for autodev skills using Claude Code CLI. ## Overview @@ -9,7 +9,7 @@ This test suite verifies that skills are loaded correctly and Claude follows the ## Requirements - Claude Code CLI installed and in PATH (`claude --version` should work) -- Local superpowers plugin installed (see main README for installation) +- Local autodev plugin installed (see main README for installation) ## Running Tests diff --git a/tests/claude-code/test-subagent-driven-development-integration.sh b/tests/claude-code/test-subagent-driven-development-integration.sh index ddb0c12..dc404bd 100755 --- a/tests/claude-code/test-subagent-driven-development-integration.sh +++ b/tests/claude-code/test-subagent-driven-development-integration.sh @@ -135,7 +135,7 @@ EOF # Note: We use a longer timeout since this is integration testing # Use --allowed-tools to enable tool usage in headless mode -# IMPORTANT: Run from superpowers directory so local dev skills are available +# IMPORTANT: Run from autodev directory so local dev skills are available PROMPT="Change to directory $TEST_PROJECT and then execute the implementation plan at docs/plans/implementation-plan.md using the subagent-driven-development skill. IMPORTANT: Follow the skill exactly. I will be verifying that you: @@ -186,7 +186,7 @@ echo "" # Test 1: Skill was invoked echo "Test 1: Skill tool invoked..." -if grep -q '"name":"Skill".*"skill":"superpowers:subagent-driven-development"' "$SESSION_FILE"; then +if grep -q '"name":"Skill".*"skill":"autodev:subagent-driven-development"' "$SESSION_FILE"; then echo " [PASS] subagent-driven-development skill was invoked" else echo " [FAIL] Skill was not invoked" diff --git a/tests/cross-llm-coverage.md b/tests/cross-llm-coverage.md index 97e4924..e6fc73e 100644 --- a/tests/cross-llm-coverage.md +++ b/tests/cross-llm-coverage.md @@ -22,7 +22,7 @@ host-neutral. Updated whenever a skill changes. | systematic-debugging | host-neutral | host-neutral | host-neutral | host-neutral | already portable (Group I) | | test-driven-development | host-neutral | host-neutral | host-neutral | host-neutral | already portable (Group I) | | using-git-worktrees | host-neutral | host-neutral | host-neutral | host-neutral | already portable (Group I) | -| using-superpowers | host-neutral | host-neutral | host-neutral | host-neutral | host-access phrasing is prose-based ("In Claude Code: … In other environments: …"); no forbidden tokens | +| using-autodev | host-neutral | host-neutral | host-neutral | host-neutral | host-access phrasing is prose-based ("In Claude Code: … In other environments: …"); no forbidden tokens | | verification-before-completion | host-neutral | host-neutral | host-neutral | host-neutral | already portable (Group I) | | writing-plans | host-neutral | host-neutral | host-neutral | host-neutral | Plan Mode reference is prose-based ("If you are running in Claude Code…"); no `` blocks needed | | writing-skills | host-conditional | host-conditional | host-conditional | host-conditional | `TodoWrite` checklist and tier-brand names wrapped in `` blocks | diff --git a/tests/explicit-skill-requests/run-claude-describes-sdd.sh b/tests/explicit-skill-requests/run-claude-describes-sdd.sh index 6424d89..07a9921 100755 --- a/tests/explicit-skill-requests/run-claude-describes-sdd.sh +++ b/tests/explicit-skill-requests/run-claude-describes-sdd.sh @@ -8,7 +8,7 @@ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" PLUGIN_DIR="$(cd "$SCRIPT_DIR/../.." && pwd)" TIMESTAMP=$(date +%s) -OUTPUT_DIR="/tmp/superpowers-tests/${TIMESTAMP}/explicit-skill-requests/claude-describes" +OUTPUT_DIR="/tmp/autodev-tests/${TIMESTAMP}/explicit-skill-requests/claude-describes" mkdir -p "$OUTPUT_DIR" PROJECT_DIR="$OUTPUT_DIR/project" diff --git a/tests/explicit-skill-requests/run-extended-multiturn-test.sh b/tests/explicit-skill-requests/run-extended-multiturn-test.sh index 81bc0f2..45c2ad5 100755 --- a/tests/explicit-skill-requests/run-extended-multiturn-test.sh +++ b/tests/explicit-skill-requests/run-extended-multiturn-test.sh @@ -8,7 +8,7 @@ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" PLUGIN_DIR="$(cd "$SCRIPT_DIR/../.." && pwd)" TIMESTAMP=$(date +%s) -OUTPUT_DIR="/tmp/superpowers-tests/${TIMESTAMP}/explicit-skill-requests/extended-multiturn" +OUTPUT_DIR="/tmp/autodev-tests/${TIMESTAMP}/explicit-skill-requests/extended-multiturn" mkdir -p "$OUTPUT_DIR" PROJECT_DIR="$OUTPUT_DIR/project" diff --git a/tests/explicit-skill-requests/run-haiku-test.sh b/tests/explicit-skill-requests/run-haiku-test.sh index 6cf893a..6b67f75 100755 --- a/tests/explicit-skill-requests/run-haiku-test.sh +++ b/tests/explicit-skill-requests/run-haiku-test.sh @@ -8,7 +8,7 @@ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" PLUGIN_DIR="$(cd "$SCRIPT_DIR/../.." && pwd)" TIMESTAMP=$(date +%s) -OUTPUT_DIR="/tmp/superpowers-tests/${TIMESTAMP}/explicit-skill-requests/haiku" +OUTPUT_DIR="/tmp/autodev-tests/${TIMESTAMP}/explicit-skill-requests/haiku" mkdir -p "$OUTPUT_DIR" PROJECT_DIR="$OUTPUT_DIR/project" diff --git a/tests/explicit-skill-requests/run-multiturn-test.sh b/tests/explicit-skill-requests/run-multiturn-test.sh index 4561248..a028f90 100755 --- a/tests/explicit-skill-requests/run-multiturn-test.sh +++ b/tests/explicit-skill-requests/run-multiturn-test.sh @@ -11,7 +11,7 @@ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" PLUGIN_DIR="$(cd "$SCRIPT_DIR/../.." && pwd)" TIMESTAMP=$(date +%s) -OUTPUT_DIR="/tmp/superpowers-tests/${TIMESTAMP}/explicit-skill-requests/multiturn" +OUTPUT_DIR="/tmp/autodev-tests/${TIMESTAMP}/explicit-skill-requests/multiturn" mkdir -p "$OUTPUT_DIR" # Create project directory (conversation is cwd-based) diff --git a/tests/explicit-skill-requests/run-test.sh b/tests/explicit-skill-requests/run-test.sh index 2e0bdd3..025adb2 100755 --- a/tests/explicit-skill-requests/run-test.sh +++ b/tests/explicit-skill-requests/run-test.sh @@ -21,11 +21,11 @@ fi # Get the directory where this script lives SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" -# Get the superpowers plugin root (two levels up) +# Get the autodev plugin root (two levels up) PLUGIN_DIR="$(cd "$SCRIPT_DIR/../.." && pwd)" TIMESTAMP=$(date +%s) -OUTPUT_DIR="/tmp/superpowers-tests/${TIMESTAMP}/explicit-skill-requests/${SKILL_NAME}" +OUTPUT_DIR="/tmp/autodev-tests/${TIMESTAMP}/explicit-skill-requests/${SKILL_NAME}" mkdir -p "$OUTPUT_DIR" # Read prompt from file diff --git a/tests/hook-contracts.sh b/tests/hook-contracts.sh new file mode 100755 index 0000000..78450a1 --- /dev/null +++ b/tests/hook-contracts.sh @@ -0,0 +1,381 @@ +#!/usr/bin/env bash +# tests/hook-contracts.sh — regression tests for hook JSON contracts. + +set -euo pipefail + +REPO_ROOT="$(cd "$(dirname "$0")/.." && pwd)" +cd "$REPO_ROOT" + +failures=0 + +fail() { + printf 'FAIL: %s\n' "$*" >&2 + failures=$((failures + 1)) +} + +pass() { + printf 'PASS: %s\n' "$*" +} + +require_jq() { + if ! command -v jq >/dev/null 2>&1; then + printf 'SKIP: jq not found; hook contract tests require jq\n' + exit 0 + fi +} + +run_hook() { + local hook="$1" + local payload="$2" + printf '%s' "$payload" | "hooks/${hook}" +} + +assert_hook_context_json() { + local name="$1" + local event="$2" + local output="$3" + + if ! printf '%s' "$output" | jq -e . >/dev/null 2>&1; then + fail "${name}: output is not valid JSON: ${output}" + return + fi + if ! printf '%s' "$output" | jq -e --arg event "$event" ' + .hookSpecificOutput.hookEventName == $event and + (.hookSpecificOutput.additionalContext | type == "string") and + (.hookSpecificOutput.additionalContext | length > 0) and + has("additional_context") | not + ' >/dev/null; then + fail "${name}: output does not match host-neutral additionalContext schema: ${output}" + return + fi + pass "${name}: emits valid ${event} additionalContext JSON" +} + +test_session_start_json() { + local output + output="$(run_hook session-start '{"source":"startup","cwd":"'"$REPO_ROOT"'"}')" + assert_hook_context_json "session-start" "SessionStart" "$output" +} + +test_prompt_strict_json() { + local tmp + tmp="$(mktemp -d)" + trap 'rm -rf "$tmp"' RETURN + mkdir -p "$tmp/docs/plans" + cat >"$tmp/docs/plans/example.md" <<'PLAN' +# Example Plan + +## Scope Manifest + +**PR Count:** 1 +**Tasks:** 1 +**Out of scope:** +- (none) + +**PR Grouping:** + +| PR # | Title | Tasks | Branch | +|------|-------|-------|--------| +| 1 | Example | Task 1 | feat/example | + +**Status:** Locked 2026-05-25T00:00:00Z + +### Task 1: Example +PLAN + + local output + output="$(run_hook prompt-strict-interpretation '{"prompt":"go ahead and create a PR","cwd":"'"$tmp"'"}')" + assert_hook_context_json "prompt-strict-interpretation" "UserPromptSubmit" "$output" +} + +test_prompt_strict_no_output_without_trigger() { + local output + output="$(run_hook prompt-strict-interpretation '{"prompt":"please inspect the file","cwd":"'"$REPO_ROOT"'"}')" + if [ -n "$output" ]; then + fail "prompt-strict-interpretation: expected no output without trigger, got: ${output}" + return + fi + pass "prompt-strict-interpretation: no output without trigger" +} + +test_pretool_pr_review_json() { + local output + output="$(run_hook pretool-pr-review-reminder '{"tool_name":"Bash","tool_input":{"command":"gh pr create --title test --body test"},"cwd":"'"$REPO_ROOT"'"}')" + assert_hook_context_json "pretool-pr-review-reminder" "PreToolUse" "$output" +} + +test_posttool_pr_created_json() { + local output + output="$(run_hook posttool-pr-created '{"tool_name":"Bash","tool_input":{"command":"gh pr create --title test --body test"},"tool_response":"https://github.com/owner/repo/pull/123","cwd":"'"$REPO_ROOT"'"}')" + assert_hook_context_json "posttool-pr-created" "PostToolUse" "$output" +} + +test_pre_compact_snapshot_json() { + local tmp + tmp="$(mktemp -d)" + trap 'rm -rf "$tmp"' RETURN + mkdir -p "$tmp/docs/plans" + cat >"$tmp/docs/plans/example.md" <<'PLAN' +# Example Plan + +## Scope Manifest + +**PR Count:** 1 +**Tasks:** 1 +**Out of scope:** +- (none) + +**PR Grouping:** + +| PR # | Title | Tasks | Branch | +|------|-------|-------|--------| +| 1 | Example | Task 1 | feat/example | + +**Status:** Locked 2026-05-25T00:00:00Z + +### Task 1: Example +PLAN + bash hooks/scope-lock-apply "$tmp/docs/plans/example.md" >/dev/null + + local output + output="$(run_hook pre-compact-snapshot '{"cwd":"'"$tmp"'"}')" + assert_hook_context_json "pre-compact-snapshot" "PreCompact" "$output" + + local state_file="$tmp/.claude/autodev-state/in-progress.jsonl" + if ! jq -e 'select(.ev == "lock" and .pl == "example.md" and (.h | type == "string"))' "$state_file" >/dev/null; then + fail "pre-compact-snapshot: expected compact lock state row in ${state_file}" + return + fi + pass "pre-compact-snapshot: writes compact lock state row" +} + +test_completion_continuation_block() { + local tmp + tmp="$(mktemp -d)" + trap 'rm -rf "$tmp"' RETURN + mkdir -p "$tmp/docs/plans" "$tmp/tests" + cat >"$tmp/docs/plans/example.md" <<'PLAN' +# Example Plan + +## Scope Manifest + +**PR Count:** 1 +**Tasks:** 1 +**Out of scope:** +- (none) + +**PR Grouping:** + +| PR # | Title | Tasks | Branch | +|------|-------|-------|--------| +| 1 | Example | Task 1 | feat/example | + +**Status:** Locked 2026-05-25T00:00:00Z + +### Task 1: Example +PLAN + cp tests/plan-scope-check.sh "$tmp/tests/plan-scope-check.sh" + chmod +x "$tmp/tests/plan-scope-check.sh" + bash hooks/scope-lock-apply "$tmp/docs/plans/example.md" >/dev/null + + local output + output="$(run_hook completion-claim-guard '{"cwd":"'"$tmp"'","stop_hook_active":false,"last_assistant_message":"Task 1 complete."}')" + if ! printf '%s' "$output" | jq -e ' + .decision == "block" and + (.reason | contains("phase/task completion")) and + (.reason | contains("phase-progress.jsonl")) + ' >/dev/null; then + fail "completion-claim-guard: expected phase-continuation block JSON, got: ${output}" + return + fi + pass "completion-claim-guard: blocks phase completion and requests progress log" +} + +test_completion_allows_hard_blocker() { + local tmp + tmp="$(mktemp -d)" + trap 'rm -rf "$tmp"' RETURN + mkdir -p "$tmp/docs/plans" "$tmp/tests" + cat >"$tmp/docs/plans/example.md" <<'PLAN' +# Example Plan + +## Scope Manifest + +**PR Count:** 1 +**Tasks:** 1 +**Out of scope:** +- (none) + +**PR Grouping:** + +| PR # | Title | Tasks | Branch | +|------|-------|-------|--------| +| 1 | Example | Task 1 | feat/example | + +**Status:** Locked 2026-05-25T00:00:00Z + +### Task 1: Example +PLAN + cp tests/plan-scope-check.sh "$tmp/tests/plan-scope-check.sh" + chmod +x "$tmp/tests/plan-scope-check.sh" + bash hooks/scope-lock-apply "$tmp/docs/plans/example.md" >/dev/null + + local output + output="$(run_hook completion-claim-guard '{"cwd":"'"$tmp"'","stop_hook_active":false,"last_assistant_message":"Blocked: need human approval before deploy to production."}')" + if [ -n "$output" ]; then + fail "completion-claim-guard: expected no output for hard blocker, got: ${output}" + return + fi + pass "completion-claim-guard: allows hard blocker stop" +} + +test_pretool_allows_locked_plan_text_edit() { + local tmp + tmp="$(mktemp -d)" + trap 'rm -rf "$tmp"' RETURN + mkdir -p "$tmp/docs/plans" "$tmp/tests" + cat >"$tmp/docs/plans/example.md" <<'PLAN' +# Example Plan + +## Scope Manifest + +**PR Count:** 1 +**Tasks:** 1 +**Out of scope:** +- (none) + +**PR Grouping:** + +| PR # | Title | Tasks | Branch | +|------|-------|-------|--------| +| 1 | Example | Task 1 | feat/example | + +**Status:** Locked 2026-05-25T00:00:00Z + +### Task 1: Example +PLAN + local output + output="$(run_hook pre-tool-scope-guard '{"tool_name":"Edit","tool_input":{"file_path":"'"$tmp"'/docs/plans/example.md"},"cwd":"'"$tmp"'"}')" + if [ -n "$output" ]; then + fail "pre-tool-scope-guard: expected locked plan text edit to pass, got: ${output}" + return + fi + pass "pre-tool-scope-guard: allows locked plan/design text edits" +} + +test_subagent_allows_non_manifest_plan_backport() { + local tmp + tmp="$(mktemp -d)" + trap 'rm -rf "$tmp"' RETURN + mkdir -p "$tmp/docs/plans" "$tmp/tests" + cp tests/plan-scope-check.sh "$tmp/tests/plan-scope-check.sh" + chmod +x "$tmp/tests/plan-scope-check.sh" + cat >"$tmp/docs/plans/example.md" <<'PLAN' +# Example Plan + +## Scope Manifest + +**PR Count:** 1 +**Tasks:** 1 +**Out of scope:** +- (none) + +**PR Grouping:** + +| PR # | Title | Tasks | Branch | +|------|-------|-------|--------| +| 1 | Example | Task 1 | feat/example | + +**Status:** Locked 2026-05-25T00:00:00Z + +### Task 1: Example +PLAN + bash hooks/scope-lock-apply "$tmp/docs/plans/example.md" >/dev/null + git -C "$tmp" init -q + git -C "$tmp" config user.email test@example.com + git -C "$tmp" config user.name "Hook Test" + git -C "$tmp" add docs tests + git -C "$tmp" commit -q -m initial + printf '\n### Backport 2026-05-25: note\n\nCause: test\nChange: no manifest change\n' >>"$tmp/docs/plans/example.md" + + local output + output="$(run_hook subagent-scope-guard '{"cwd":"'"$tmp"'","stop_hook_active":false}')" + if [ -n "$output" ]; then + fail "subagent-scope-guard: expected non-manifest plan backport to pass, got: ${output}" + return + fi + pass "subagent-scope-guard: allows non-manifest locked plan backports" +} + +test_record_activity_compact_state() { + local tmp + tmp="$(mktemp -d)" + trap 'rm -rf "$tmp"' RETURN + + run_hook record-activity '{"tool_name":"Skill","tool_input":{"skill":"autodev:brainstorming","args":"design compact state"},"cwd":"'"$tmp"'"}' >/dev/null + run_hook record-activity '{"tool_name":"Agent","tool_input":{"subagent_type":"reviewer","description":"check implementation","run_in_background":true},"cwd":"'"$tmp"'"}' >/dev/null + run_hook record-activity '{"tool_name":"TaskUpdate","tool_input":{"task_id":"T1","title":"phase complete","subagent_type":"builder"},"cwd":"'"$tmp"'"}' >/dev/null + + local state_file="$tmp/.claude/autodev-state/in-progress.jsonl" + if ! jq -s -e ' + . as $rows | + ($rows | any(.ev == "skill" and .sk == "autodev:brainstorming" and (has("tool") | not) and (has("detail") | not))) and + ($rows | any(.ev == "agent" and .ag == "reviewer" and .bg == true and (has("tool") | not) and (has("detail") | not))) and + ($rows | any(.ev == "task" and .tt == "TaskUpdate" and .ag == "builder" and .id == "T1" and (has("tool") | not) and (has("detail") | not))) + ' "$state_file" >/dev/null; then + fail "record-activity: expected compact skill/agent/task JSONL rows" + return + fi + pass "record-activity: writes compact skill/agent/task state rows" +} + +test_skill_activation_audit_reads_compact_state() { + local tmp state_file output status + tmp="$(mktemp -d)" + trap 'rm -rf "$tmp"' RETURN + state_file="$tmp/in-progress.jsonl" + cat >"$state_file" <<'JSONL' +{"ts":"2026-05-25T00:00:00Z","ev":"skill","sk":"autodev:brainstorming"} +{"ts":"2026-05-25T00:00:01Z","ev":"agent","ag":"reviewer","bg":true} +JSONL + + set +e + output="$(./tests/skill-activation-audit.sh "$state_file" 2>&1)" + status=$? + set -e + + if [ "$status" -ne 2 ]; then + fail "skill-activation-audit: expected pipeline-gap exit 2 for partial compact pipeline, got ${status}: ${output}" + return + fi + if ! printf '%s' "$output" | grep -q 'brainstorming'; then + fail "skill-activation-audit: compact skill row not reported: ${output}" + return + fi + if ! printf '%s' "$output" | grep -q 'reviewer'; then + fail "skill-activation-audit: compact agent row not reported: ${output}" + return + fi + pass "skill-activation-audit: reads compact state rows" +} + +require_jq +test_session_start_json +test_prompt_strict_json +test_prompt_strict_no_output_without_trigger +test_pretool_pr_review_json +test_posttool_pr_created_json +test_pre_compact_snapshot_json +test_completion_continuation_block +test_completion_allows_hard_blocker +test_pretool_allows_locked_plan_text_edit +test_subagent_allows_non_manifest_plan_backport +test_record_activity_compact_state +test_skill_activation_audit_reads_compact_state + +if [ "$failures" -ne 0 ]; then + printf '\n%d hook contract test(s) failed.\n' "$failures" >&2 + exit 1 +fi + +printf '\nAll hook contract tests passed.\n' diff --git a/tests/opencode/setup.sh b/tests/opencode/setup.sh index 0defde2..9a331a2 100755 --- a/tests/opencode/setup.sh +++ b/tests/opencode/setup.sh @@ -13,18 +13,18 @@ export XDG_CONFIG_HOME="$TEST_HOME/.config" export OPENCODE_CONFIG_DIR="$TEST_HOME/.config/opencode" # Install plugin to test location -mkdir -p "$HOME/.config/opencode/superpowers" -cp -r "$REPO_ROOT/lib" "$HOME/.config/opencode/superpowers/" -cp -r "$REPO_ROOT/skills" "$HOME/.config/opencode/superpowers/" +mkdir -p "$HOME/.config/opencode/autodev" +cp -r "$REPO_ROOT/lib" "$HOME/.config/opencode/autodev/" +cp -r "$REPO_ROOT/skills" "$HOME/.config/opencode/autodev/" # Copy plugin directory -mkdir -p "$HOME/.config/opencode/superpowers/.opencode/plugins" -cp "$REPO_ROOT/.opencode/plugins/superpowers.js" "$HOME/.config/opencode/superpowers/.opencode/plugins/" +mkdir -p "$HOME/.config/opencode/autodev/.opencode/plugins" +cp "$REPO_ROOT/.opencode/plugins/autodev.js" "$HOME/.config/opencode/autodev/.opencode/plugins/" # Register plugin via symlink mkdir -p "$HOME/.config/opencode/plugins" -ln -sf "$HOME/.config/opencode/superpowers/.opencode/plugins/superpowers.js" \ - "$HOME/.config/opencode/plugins/superpowers.js" +ln -sf "$HOME/.config/opencode/autodev/.opencode/plugins/autodev.js" \ + "$HOME/.config/opencode/plugins/autodev.js" # Create test skills in different locations for testing @@ -57,8 +57,8 @@ PROJECT_SKILL_MARKER_67890 EOF echo "Setup complete: $TEST_HOME" -echo "Plugin installed to: $HOME/.config/opencode/superpowers/.opencode/plugins/superpowers.js" -echo "Plugin registered at: $HOME/.config/opencode/plugins/superpowers.js" +echo "Plugin installed to: $HOME/.config/opencode/autodev/.opencode/plugins/autodev.js" +echo "Plugin registered at: $HOME/.config/opencode/plugins/autodev.js" echo "Test project at: $TEST_HOME/test-project" # Helper function for cleanup (call from tests or trap) diff --git a/tests/opencode/test-plugin-loading.sh b/tests/opencode/test-plugin-loading.sh index 052e9de..2e3f393 100755 --- a/tests/opencode/test-plugin-loading.sh +++ b/tests/opencode/test-plugin-loading.sh @@ -1,6 +1,6 @@ #!/usr/bin/env bash # Test: Plugin Loading -# Verifies that the superpowers plugin loads correctly in OpenCode +# Verifies that the autodev plugin loads correctly in OpenCode set -euo pipefail SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)" @@ -15,15 +15,15 @@ trap cleanup_test_env EXIT # Test 1: Verify plugin file exists and is registered echo "Test 1: Checking plugin registration..." -if [ -L "$HOME/.config/opencode/plugins/superpowers.js" ]; then +if [ -L "$HOME/.config/opencode/plugins/autodev.js" ]; then echo " [PASS] Plugin symlink exists" else - echo " [FAIL] Plugin symlink not found at $HOME/.config/opencode/plugins/superpowers.js" + echo " [FAIL] Plugin symlink not found at $HOME/.config/opencode/plugins/autodev.js" exit 1 fi # Verify symlink target exists -if [ -f "$(readlink -f "$HOME/.config/opencode/plugins/superpowers.js")" ]; then +if [ -f "$(readlink -f "$HOME/.config/opencode/plugins/autodev.js")" ]; then echo " [PASS] Plugin symlink target exists" else echo " [FAIL] Plugin symlink target does not exist" @@ -32,7 +32,7 @@ fi # Test 2: Verify lib/skills-core.js is in place echo "Test 2: Checking skills-core.js..." -if [ -f "$HOME/.config/opencode/superpowers/lib/skills-core.js" ]; then +if [ -f "$HOME/.config/opencode/autodev/lib/skills-core.js" ]; then echo " [PASS] skills-core.js exists" else echo " [FAIL] skills-core.js not found" @@ -41,7 +41,7 @@ fi # Test 3: Verify skills directory is populated echo "Test 3: Checking skills directory..." -skill_count=$(find "$HOME/.config/opencode/superpowers/skills" -name "SKILL.md" | wc -l) +skill_count=$(find "$HOME/.config/opencode/autodev/skills" -name "SKILL.md" | wc -l) if [ "$skill_count" -gt 0 ]; then echo " [PASS] Found $skill_count skills installed" else @@ -49,18 +49,18 @@ else exit 1 fi -# Test 4: Check using-superpowers skill exists (critical for bootstrap) -echo "Test 4: Checking using-superpowers skill (required for bootstrap)..." -if [ -f "$HOME/.config/opencode/superpowers/skills/using-superpowers/SKILL.md" ]; then - echo " [PASS] using-superpowers skill exists" +# Test 4: Check using-autodev skill exists (critical for bootstrap) +echo "Test 4: Checking using-autodev skill (required for bootstrap)..." +if [ -f "$HOME/.config/opencode/autodev/skills/using-autodev/SKILL.md" ]; then + echo " [PASS] using-autodev skill exists" else - echo " [FAIL] using-superpowers skill not found (required for bootstrap)" + echo " [FAIL] using-autodev skill not found (required for bootstrap)" exit 1 fi # Test 5: Verify plugin JavaScript syntax (basic check) echo "Test 5: Checking plugin JavaScript syntax..." -plugin_file="$HOME/.config/opencode/superpowers/.opencode/plugins/superpowers.js" +plugin_file="$HOME/.config/opencode/autodev/.opencode/plugins/autodev.js" if node --check "$plugin_file" 2>/dev/null; then echo " [PASS] Plugin JavaScript syntax is valid" else diff --git a/tests/opencode/test-priority.sh b/tests/opencode/test-priority.sh index 1c36fa3..770e4f6 100755 --- a/tests/opencode/test-priority.sh +++ b/tests/opencode/test-priority.sh @@ -1,6 +1,6 @@ #!/usr/bin/env bash # Test: Skill Priority Resolution -# Verifies that skills are resolved with correct priority: project > personal > superpowers +# Verifies that skills are resolved with correct priority: project > personal > autodev # NOTE: These tests require OpenCode to be installed and configured set -euo pipefail @@ -17,14 +17,14 @@ trap cleanup_test_env EXIT # Create same skill "priority-test" in all three locations with different markers echo "Setting up priority test fixtures..." -# 1. Create in superpowers location (lowest priority) -mkdir -p "$HOME/.config/opencode/superpowers/skills/priority-test" -cat > "$HOME/.config/opencode/superpowers/skills/priority-test/SKILL.md" <<'EOF' +# 1. Create in autodev location (lowest priority) +mkdir -p "$HOME/.config/opencode/autodev/skills/priority-test" +cat > "$HOME/.config/opencode/autodev/skills/priority-test/SKILL.md" <<'EOF' --- name: priority-test -description: Superpowers version of priority test skill +description: Autonomous Dev Kit version of priority test skill --- -# Priority Test Skill (Superpowers Version) +# Priority Test Skill (Autonomous Dev Kit Version) This is the SUPERPOWERS version of the priority test skill. @@ -65,10 +65,10 @@ echo " Created priority-test skill in all three locations" echo "" echo "Test 1: Verifying test fixtures..." -if [ -f "$HOME/.config/opencode/superpowers/skills/priority-test/SKILL.md" ]; then - echo " [PASS] Superpowers version exists" +if [ -f "$HOME/.config/opencode/autodev/skills/priority-test/SKILL.md" ]; then + echo " [PASS] Autonomous Dev Kit version exists" else - echo " [FAIL] Superpowers version missing" + echo " [FAIL] Autonomous Dev Kit version missing" exit 1 fi @@ -96,9 +96,9 @@ if ! command -v opencode &> /dev/null; then exit 0 fi -# Test 2: Test that personal overrides superpowers +# Test 2: Test that personal overrides autodev echo "" -echo "Test 2: Testing personal > superpowers priority..." +echo "Test 2: Testing personal > autodev priority..." echo " Running from outside project directory..." # Run from HOME (not in project) - should get personal version @@ -112,19 +112,19 @@ output=$(timeout 60s opencode run --print-logs "Use the use_skill tool to load t } if echo "$output" | grep -qi "PRIORITY_MARKER_PERSONAL_VERSION"; then - echo " [PASS] Personal version loaded (overrides superpowers)" + echo " [PASS] Personal version loaded (overrides autodev)" elif echo "$output" | grep -qi "PRIORITY_MARKER_SUPERPOWERS_VERSION"; then - echo " [FAIL] Superpowers version loaded instead of personal" + echo " [FAIL] Autonomous Dev Kit version loaded instead of personal" exit 1 else echo " [WARN] Could not verify priority marker in output" echo " Output snippet:" - echo "$output" | grep -i "priority\|personal\|superpowers" | head -10 + echo "$output" | grep -i "priority\|personal\|autodev" | head -10 fi -# Test 3: Test that project overrides both personal and superpowers +# Test 3: Test that project overrides both personal and autodev echo "" -echo "Test 3: Testing project > personal > superpowers priority..." +echo "Test 3: Testing project > personal > autodev priority..." echo " Running from project directory..." # Run from project directory - should get project version @@ -143,7 +143,7 @@ elif echo "$output" | grep -qi "PRIORITY_MARKER_PERSONAL_VERSION"; then echo " [FAIL] Personal version loaded instead of project" exit 1 elif echo "$output" | grep -qi "PRIORITY_MARKER_SUPERPOWERS_VERSION"; then - echo " [FAIL] Superpowers version loaded instead of project" + echo " [FAIL] Autonomous Dev Kit version loaded instead of project" exit 1 else echo " [WARN] Could not verify priority marker in output" @@ -151,12 +151,12 @@ else echo "$output" | grep -i "priority\|project\|personal" | head -10 fi -# Test 4: Test explicit superpowers: prefix bypasses priority +# Test 4: Test explicit autodev: prefix bypasses priority echo "" -echo "Test 4: Testing superpowers: prefix forces superpowers version..." +echo "Test 4: Testing autodev: prefix forces autodev version..." cd "$TEST_HOME/test-project" -output=$(timeout 60s opencode run --print-logs "Use the use_skill tool to load superpowers:priority-test specifically. Show me the exact content including any PRIORITY_MARKER text." 2>&1) || { +output=$(timeout 60s opencode run --print-logs "Use the use_skill tool to load autodev:priority-test specifically. Show me the exact content including any PRIORITY_MARKER text." 2>&1) || { exit_code=$? if [ $exit_code -eq 124 ]; then echo " [FAIL] OpenCode timed out after 60s" @@ -165,9 +165,9 @@ output=$(timeout 60s opencode run --print-logs "Use the use_skill tool to load s } if echo "$output" | grep -qi "PRIORITY_MARKER_SUPERPOWERS_VERSION"; then - echo " [PASS] superpowers: prefix correctly forces superpowers version" + echo " [PASS] autodev: prefix correctly forces autodev version" elif echo "$output" | grep -qi "PRIORITY_MARKER_PROJECT_VERSION\|PRIORITY_MARKER_PERSONAL_VERSION"; then - echo " [FAIL] superpowers: prefix did not force superpowers version" + echo " [FAIL] autodev: prefix did not force autodev version" exit 1 else echo " [WARN] Could not verify priority marker in output" diff --git a/tests/opencode/test-skills-core.sh b/tests/opencode/test-skills-core.sh index b058d5f..f87b5a7 100755 --- a/tests/opencode/test-skills-core.sh +++ b/tests/opencode/test-skills-core.sh @@ -249,10 +249,10 @@ fi echo "" echo "Test 4: Testing resolveSkillPath..." -# Create skills in personal and superpowers locations for testing +# Create skills in personal and autodev locations for testing mkdir -p "$TEST_HOME/personal-skills/shared-skill" -mkdir -p "$TEST_HOME/superpowers-skills/shared-skill" -mkdir -p "$TEST_HOME/superpowers-skills/unique-skill" +mkdir -p "$TEST_HOME/autodev-skills/shared-skill" +mkdir -p "$TEST_HOME/autodev-skills/unique-skill" cat > "$TEST_HOME/personal-skills/shared-skill/SKILL.md" <<'EOF' --- @@ -262,18 +262,18 @@ description: Personal version # Personal Shared EOF -cat > "$TEST_HOME/superpowers-skills/shared-skill/SKILL.md" <<'EOF' +cat > "$TEST_HOME/autodev-skills/shared-skill/SKILL.md" <<'EOF' --- name: shared-skill -description: Superpowers version +description: Autonomous Dev Kit version --- -# Superpowers Shared +# Autonomous Dev Kit Shared EOF -cat > "$TEST_HOME/superpowers-skills/unique-skill/SKILL.md" <<'EOF' +cat > "$TEST_HOME/autodev-skills/unique-skill/SKILL.md" <<'EOF' --- name: unique-skill -description: Only in superpowers +description: Only in autodev --- # Unique EOF @@ -282,11 +282,11 @@ result=$(node -e " const fs = require('fs'); const path = require('path'); -function resolveSkillPath(skillName, superpowersDir, personalDir) { - const forceSuperpowers = skillName.startsWith('superpowers:'); - const actualSkillName = forceSuperpowers ? skillName.replace(/^superpowers:/, '') : skillName; +function resolveSkillPath(skillName, autodevDir, personalDir) { + const forceAutodev = skillName.startsWith('autodev:'); + const actualSkillName = forceAutodev ? skillName.replace(/^autodev:/, '') : skillName; - if (!forceSuperpowers && personalDir) { + if (!forceAutodev && personalDir) { const personalPath = path.join(personalDir, actualSkillName); const personalSkillFile = path.join(personalPath, 'SKILL.md'); if (fs.existsSync(personalSkillFile)) { @@ -298,13 +298,13 @@ function resolveSkillPath(skillName, superpowersDir, personalDir) { } } - if (superpowersDir) { - const superpowersPath = path.join(superpowersDir, actualSkillName); - const superpowersSkillFile = path.join(superpowersPath, 'SKILL.md'); - if (fs.existsSync(superpowersSkillFile)) { + if (autodevDir) { + const autodevPath = path.join(autodevDir, actualSkillName); + const autodevSkillFile = path.join(autodevPath, 'SKILL.md'); + if (fs.existsSync(autodevSkillFile)) { return { - skillFile: superpowersSkillFile, - sourceType: 'superpowers', + skillFile: autodevSkillFile, + sourceType: 'autodev', skillPath: actualSkillName }; } @@ -313,45 +313,45 @@ function resolveSkillPath(skillName, superpowersDir, personalDir) { return null; } -const superpowersDir = '$TEST_HOME/superpowers-skills'; +const autodevDir = '$TEST_HOME/autodev-skills'; const personalDir = '$TEST_HOME/personal-skills'; // Test 1: Shared skill should resolve to personal -const shared = resolveSkillPath('shared-skill', superpowersDir, personalDir); +const shared = resolveSkillPath('shared-skill', autodevDir, personalDir); console.log('SHARED:', JSON.stringify(shared)); -// Test 2: superpowers: prefix should force superpowers -const forced = resolveSkillPath('superpowers:shared-skill', superpowersDir, personalDir); +// Test 2: autodev: prefix should force autodev +const forced = resolveSkillPath('autodev:shared-skill', autodevDir, personalDir); console.log('FORCED:', JSON.stringify(forced)); -// Test 3: Unique skill should resolve to superpowers -const unique = resolveSkillPath('unique-skill', superpowersDir, personalDir); +// Test 3: Unique skill should resolve to autodev +const unique = resolveSkillPath('unique-skill', autodevDir, personalDir); console.log('UNIQUE:', JSON.stringify(unique)); // Test 4: Non-existent skill -const notfound = resolveSkillPath('not-a-skill', superpowersDir, personalDir); +const notfound = resolveSkillPath('not-a-skill', autodevDir, personalDir); console.log('NOTFOUND:', JSON.stringify(notfound)); " 2>&1) if echo "$result" | grep -q 'SHARED:.*"sourceType":"personal"'; then - echo " [PASS] Personal skills shadow superpowers skills" + echo " [PASS] Personal skills shadow autodev skills" else echo " [FAIL] Personal skills not shadowing correctly" echo " Result: $result" exit 1 fi -if echo "$result" | grep -q 'FORCED:.*"sourceType":"superpowers"'; then - echo " [PASS] superpowers: prefix forces superpowers resolution" +if echo "$result" | grep -q 'FORCED:.*"sourceType":"autodev"'; then + echo " [PASS] autodev: prefix forces autodev resolution" else - echo " [FAIL] superpowers: prefix not working" + echo " [FAIL] autodev: prefix not working" exit 1 fi -if echo "$result" | grep -q 'UNIQUE:.*"sourceType":"superpowers"'; then - echo " [PASS] Unique superpowers skills are found" +if echo "$result" | grep -q 'UNIQUE:.*"sourceType":"autodev"'; then + echo " [PASS] Unique autodev skills are found" else - echo " [FAIL] Unique superpowers skills not found" + echo " [FAIL] Unique autodev skills not found" exit 1 fi diff --git a/tests/opencode/test-tools.sh b/tests/opencode/test-tools.sh index e4590fe..2b73006 100755 --- a/tests/opencode/test-tools.sh +++ b/tests/opencode/test-tools.sh @@ -36,8 +36,8 @@ output=$(timeout 60s opencode run --print-logs "Use the find_skills tool to list } # Check for expected patterns in output -if echo "$output" | grep -qi "superpowers:brainstorming\|superpowers:using-superpowers\|Available skills"; then - echo " [PASS] find_skills tool discovered superpowers skills" +if echo "$output" | grep -qi "autodev:brainstorming\|autodev:using-autodev\|Available skills"; then + echo " [PASS] find_skills tool discovered autodev skills" else echo " [FAIL] find_skills did not return expected skills" echo " Output was:" @@ -76,12 +76,12 @@ else exit 1 fi -# Test 3: Test use_skill with superpowers: prefix +# Test 3: Test use_skill with autodev: prefix echo "" -echo "Test 3: Testing use_skill with superpowers: prefix..." -echo " Running opencode with superpowers:brainstorming skill..." +echo "Test 3: Testing use_skill with autodev: prefix..." +echo " Running opencode with autodev:brainstorming skill..." -output=$(timeout 60s opencode run --print-logs "Use the use_skill tool to load superpowers:brainstorming and tell me the first few lines of what you received." 2>&1) || { +output=$(timeout 60s opencode run --print-logs "Use the use_skill tool to load autodev:brainstorming and tell me the first few lines of what you received." 2>&1) || { exit_code=$? if [ $exit_code -eq 124 ]; then echo " [FAIL] OpenCode timed out after 60s" @@ -92,9 +92,9 @@ output=$(timeout 60s opencode run --print-logs "Use the use_skill tool to load s # Check for expected content from brainstorming skill if echo "$output" | grep -qi "brainstorming\|Launching skill\|skill.*loaded"; then - echo " [PASS] use_skill loaded superpowers:brainstorming skill" + echo " [PASS] use_skill loaded autodev:brainstorming skill" else - echo " [FAIL] use_skill did not load superpowers:brainstorming correctly" + echo " [FAIL] use_skill did not load autodev:brainstorming correctly" echo " Output was:" echo "$output" | head -50 exit 1 diff --git a/tests/plan-scope-check.sh b/tests/plan-scope-check.sh index 2e7a223..278d1fc 100755 --- a/tests/plan-scope-check.sh +++ b/tests/plan-scope-check.sh @@ -41,11 +41,12 @@ usage() { # Extract the Scope Manifest section from a plan file. Prints lines from the # `## Scope Manifest` heading through (but not including) the next H2 heading -# at start of line. Empty output if the section is absent. +# or first `### Task` heading at start of line. Empty output if absent. extract_manifest() { awk ' /^## Scope Manifest[[:space:]]*$/ { in_section = 1; print; next } in_section && /^## / { in_section = 0 } + in_section && /^### Task [0-9]+[A-Za-z]*([: ]|$)/ { in_section = 0 } in_section { print } ' "$1" } diff --git a/tests/skill-activation-audit.sh b/tests/skill-activation-audit.sh index ae8809d..9762817 100755 --- a/tests/skill-activation-audit.sh +++ b/tests/skill-activation-audit.sh @@ -1,7 +1,7 @@ #!/usr/bin/env bash # tests/skill-activation-audit.sh -# Reads .claude/superpowers-state/in-progress.jsonl and reports which -# superpowers skills / agents fired during the recorded session(s), +# Reads .claude/autodev-state/in-progress.jsonl and reports which +# autodev skills / agents fired during the recorded session(s), # plus a heuristic check for "expected but not invoked" pipeline gates. # # This is strictly local — it never transmits anything off the machine. @@ -52,9 +52,9 @@ for arg in "$@"; do esac done -# Default: look up from CWD into .claude/superpowers-state/in-progress.jsonl +# Default: look up from CWD into .claude/autodev-state/in-progress.jsonl if [ -z "$STATE_FILE" ]; then - STATE_FILE="${PWD}/.claude/superpowers-state/in-progress.jsonl" + STATE_FILE="${PWD}/.claude/autodev-state/in-progress.jsonl" fi if [ ! -r "$STATE_FILE" ]; then @@ -67,7 +67,7 @@ if [ ! -r "$STATE_FILE" ]; then fi # Pipeline gates we expect for an autonomous run, in order. The pipeline -# is the canonical chain documented in skills/using-superpowers/SKILL.md: +# is the canonical chain documented in skills/using-autodev/SKILL.md: # brainstorming → adversarial-design-review (design) → writing-plans → # adversarial-design-review (plan) → alignment-check → scope-lock → # subagent-driven-development → finishing-a-development-branch → @@ -102,30 +102,32 @@ OPTIONAL_GATES=( # --- Parse JSONL ---------------------------------------------------------- -# Each line is {"ts":"...","tool":"...","detail":"skill=foo args=..."} or -# {"ts":"...","tool":"Agent","detail":"agent=... desc=\"...\" bg=..."}. +# New rows are compressed: {"ts":"...","ev":"skill","sk":"foo"} or +# {"ts":"...","ev":"agent","ag":"general-purpose"}. Legacy rows used +# {"tool":"...","detail":"skill=foo ..."}; keep reading both during migration. # We tolerate jq missing — fall back to grep if jq isn't installed. extract_skills() { if command -v jq >/dev/null 2>&1; then - # detail is a free-form string; pull `skill=` from it. - jq -r 'select(.tool=="Skill") | .detail' "$STATE_FILE" 2>/dev/null \ - | sed -nE 's/.*skill=([A-Za-z0-9_:-]+).*/\1/p' \ - | sed -E 's/^superpowers://' + jq -r 'if (.ev // "") == "skill" then (.sk // "") elif (.tool // "") == "Skill" then (.detail // "") else empty end' "$STATE_FILE" 2>/dev/null \ + | awk 'NF {print}' \ + | sed -nE '/^skill=/ s/.*skill=([A-Za-z0-9_:-]+).*/\1/p; /^[A-Za-z0-9_:-]+$/ p' \ + | sed -E 's/^autodev://' else - grep -E '"tool":"Skill"' "$STATE_FILE" 2>/dev/null \ - | sed -nE 's/.*skill=([A-Za-z0-9_:-]+).*/\1/p' \ - | sed -E 's/^superpowers://' + grep -E '"ev":"skill"|"tool":"Skill"' "$STATE_FILE" 2>/dev/null \ + | sed -nE 's/.*"sk":"([^"]+)".*/\1/p; s/.*skill=([A-Za-z0-9_:-]+).*/\1/p' \ + | sed -E 's/^autodev://' fi } extract_agents() { if command -v jq >/dev/null 2>&1; then - jq -r 'select(.tool=="Agent" or (.tool | type=="string" and startswith("Task"))) | .detail' "$STATE_FILE" 2>/dev/null \ - | sed -nE 's/.*agent=([A-Za-z0-9_-]+).*/\1/p' + jq -r 'if (.ev // "") == "agent" then (.ag // "") elif (.ev // "") == "task" then (.ag // "") elif (.tool=="Agent" or ((.tool // "") | startswith("Task"))) then (.detail // "") else empty end' "$STATE_FILE" 2>/dev/null \ + | awk 'NF {print}' \ + | sed -nE '/^agent=/ s/.*agent=([A-Za-z0-9_-]+).*/\1/p; /^[A-Za-z0-9_-]+$/ p' else - grep -E '"tool":"(Agent|Task[^"]*)"' "$STATE_FILE" 2>/dev/null \ - | sed -nE 's/.*agent=([A-Za-z0-9_-]+).*/\1/p' + grep -E '"ev":"(agent|task)"|"tool":"(Agent|Task[^"]*)"' "$STATE_FILE" 2>/dev/null \ + | sed -nE 's/.*"ag":"([^"]+)".*/\1/p; s/.*agent=([A-Za-z0-9_-]+).*/\1/p' fi } diff --git a/tests/skill-compression-notes.sh b/tests/skill-compression-notes.sh new file mode 100755 index 0000000..e80c043 --- /dev/null +++ b/tests/skill-compression-notes.sh @@ -0,0 +1,33 @@ +#!/usr/bin/env bash +# Verifies every skill that uses compressed prose advertises the expander skill. + +set -euo pipefail + +REPO_ROOT="$(cd "$(dirname "$0")/.." && pwd)" +cd "$REPO_ROOT" + +failures=0 +note='Condensed format: load `autodev:condensed-pipeline-writing` to expand shorthand.' + +while IFS= read -r file; do + case "$file" in + skills/condensed-pipeline-writing/SKILL.md) + if grep -Fq "$note" "$file"; then + printf 'FAIL: compression skill should not require itself: %s\n' "$file" >&2 + failures=$((failures + 1)) + fi + ;; + *) + if ! grep -Fq "$note" "$file"; then + printf 'FAIL: missing condensed-format note: %s\n' "$file" >&2 + failures=$((failures + 1)) + fi + ;; + esac +done < <(find skills -mindepth 2 -maxdepth 2 -name SKILL.md | sort) + +if [ "$failures" -ne 0 ]; then + exit 1 +fi + +echo "PASS: condensed-format notes are present where required." diff --git a/tests/skill-cross-refs.sh b/tests/skill-cross-refs.sh index e5b8bc0..7aed6f0 100755 --- a/tests/skill-cross-refs.sh +++ b/tests/skill-cross-refs.sh @@ -6,7 +6,7 @@ # # Two classes of references are checked: # 1. Skill / agent references — `/SKILL.md` paths and -# `superpowers:` strings. Verifies the target exists either as +# `autodev:` strings. Verifies the target exists either as # skills//SKILL.md or as agents/.md. # 2. Step references — ` Step N[a-z]?` mentions in prose. # Verifies that the cited skill's SKILL.md contains a heading or @@ -107,19 +107,19 @@ while IFS= read -r f; do fi done < <(printf '%s\n' "$annotated" | grep -E 'skills/[a-z][a-z0-9-]+/SKILL\.md' || true) - # Pattern 3: `superpowers:` mentions — must resolve to a skill OR agent + # Pattern 3: `autodev:` mentions — must resolve to a skill OR agent while IFS=: read -r line_no line; do [ -z "${line_no:-}" ] && continue - # A line may have multiple superpowers: mentions; check each. + # A line may have multiple autodev: mentions; check each. for name in $(printf '%s' "$line" \ - | grep -oE 'superpowers:[a-z][a-z0-9-]+' \ - | sed -E 's|^superpowers:||' | sort -u); do + | grep -oE 'autodev:[a-z][a-z0-9-]+' \ + | sed -E 's|^autodev:||' | sort -u); do if ! is_known_target "$name"; then - printf '%s:%s: "superpowers:%s" — no such skill or agent\n' \ + printf '%s:%s: "autodev:%s" — no such skill or agent\n' \ "$f" "$line_no" "$name" >> "$tmp_failures" fi done - done < <(printf '%s\n' "$annotated" | grep -E 'superpowers:[a-z][a-z0-9-]+' || true) + done < <(printf '%s\n' "$annotated" | grep -E 'autodev:[a-z][a-z0-9-]+' || true) done <<< "$scan_files_list" # --- 2. Step references -------------------------------------------------- diff --git a/tests/skill-triggering/run-test.sh b/tests/skill-triggering/run-test.sh index 553a0e9..203f7ea 100755 --- a/tests/skill-triggering/run-test.sh +++ b/tests/skill-triggering/run-test.sh @@ -19,11 +19,11 @@ fi # Get the directory where this script lives (should be tests/skill-triggering) SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" -# Get the superpowers plugin root (two levels up from tests/skill-triggering) +# Get the autodev plugin root (two levels up from tests/skill-triggering) PLUGIN_DIR="$(cd "$SCRIPT_DIR/../.." && pwd)" TIMESTAMP=$(date +%s) -OUTPUT_DIR="/tmp/superpowers-tests/${TIMESTAMP}/skill-triggering/${SKILL_NAME}" +OUTPUT_DIR="/tmp/autodev-tests/${TIMESTAMP}/skill-triggering/${SKILL_NAME}" mkdir -p "$OUTPUT_DIR" # Read prompt from file diff --git a/tests/subagent-driven-dev/go-fractals/plan.md b/tests/subagent-driven-dev/go-fractals/plan.md index 9875ab5..51adae2 100644 --- a/tests/subagent-driven-dev/go-fractals/plan.md +++ b/tests/subagent-driven-dev/go-fractals/plan.md @@ -1,6 +1,6 @@ # Go Fractals CLI - Implementation Plan -Execute this plan using the `superpowers:subagent-driven-development` skill. +Execute this plan using the `autodev:subagent-driven-development` skill. ## Context @@ -13,7 +13,7 @@ Building a CLI tool that generates ASCII fractals. See `design.md` for full spec Create the Go module and directory structure. **Do:** -- Initialize `go.mod` with module name `github.com/superpowers-test/fractals` +- Initialize `go.mod` with module name `github.com/autodev-test/fractals` - Create directory structure: `cmd/fractals/`, `internal/sierpinski/`, `internal/mandelbrot/`, `internal/cli/` - Create minimal `cmd/fractals/main.go` that prints "fractals cli" - Add `github.com/spf13/cobra` dependency diff --git a/tests/subagent-driven-dev/go-fractals/scaffold.sh b/tests/subagent-driven-dev/go-fractals/scaffold.sh index d11ea74..2363503 100755 --- a/tests/subagent-driven-dev/go-fractals/scaffold.sh +++ b/tests/subagent-driven-dev/go-fractals/scaffold.sh @@ -42,4 +42,4 @@ git commit -m "Initial project setup with design and plan" echo "Scaffolded Go Fractals project at: $TARGET_DIR" echo "" echo "To run the test:" -echo " claude -p \"Execute this plan using superpowers:subagent-driven-development. Plan: $TARGET_DIR/plan.md\" --plugin-dir /path/to/superpowers" +echo " claude -p \"Execute this plan using autodev:subagent-driven-development. Plan: $TARGET_DIR/plan.md\" --plugin-dir /path/to/autodev" diff --git a/tests/subagent-driven-dev/run-test.sh b/tests/subagent-driven-dev/run-test.sh index 02f4aca..0243b1f 100755 --- a/tests/subagent-driven-dev/run-test.sh +++ b/tests/subagent-driven-dev/run-test.sh @@ -4,7 +4,7 @@ # # Example: # ./run-test.sh go-fractals -# ./run-test.sh svelte-todo --plugin-dir /path/to/superpowers +# ./run-test.sh svelte-todo --plugin-dir /path/to/autodev set -e @@ -43,7 +43,7 @@ fi # Create timestamped output directory TIMESTAMP=$(date +%s) -OUTPUT_BASE="/tmp/superpowers-tests/$TIMESTAMP/subagent-driven-development" +OUTPUT_BASE="/tmp/autodev-tests/$TIMESTAMP/subagent-driven-development" OUTPUT_DIR="$OUTPUT_BASE/$TEST_NAME" mkdir -p "$OUTPUT_DIR" @@ -60,7 +60,7 @@ echo "" # Prepare the prompt PLAN_PATH="$OUTPUT_DIR/project/plan.md" -PROMPT="Execute this plan using superpowers:subagent-driven-development. The plan is at: $PLAN_PATH" +PROMPT="Execute this plan using autodev:subagent-driven-development. The plan is at: $PLAN_PATH" # Run Claude with JSON output for token tracking LOG_FILE="$OUTPUT_DIR/claude-output.json" diff --git a/tests/subagent-driven-dev/svelte-todo/plan.md b/tests/subagent-driven-dev/svelte-todo/plan.md index f4e555b..12adf8c 100644 --- a/tests/subagent-driven-dev/svelte-todo/plan.md +++ b/tests/subagent-driven-dev/svelte-todo/plan.md @@ -1,6 +1,6 @@ # Svelte Todo List - Implementation Plan -Execute this plan using the `superpowers:subagent-driven-development` skill. +Execute this plan using the `autodev:subagent-driven-development` skill. ## Context diff --git a/tests/subagent-driven-dev/svelte-todo/scaffold.sh b/tests/subagent-driven-dev/svelte-todo/scaffold.sh index f58129d..e86af8d 100755 --- a/tests/subagent-driven-dev/svelte-todo/scaffold.sh +++ b/tests/subagent-driven-dev/svelte-todo/scaffold.sh @@ -43,4 +43,4 @@ git commit -m "Initial project setup with design and plan" echo "Scaffolded Svelte Todo project at: $TARGET_DIR" echo "" echo "To run the test:" -echo " claude -p \"Execute this plan using superpowers:subagent-driven-development. Plan: $TARGET_DIR/plan.md\" --plugin-dir /path/to/superpowers" +echo " claude -p \"Execute this plan using autodev:subagent-driven-development. Plan: $TARGET_DIR/plan.md\" --plugin-dir /path/to/autodev"