{"owner":"obra","repo":"superpowers","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md","GEMINI.md","skills/subagent-driven-development/implementer-prompt.md"],"skills":{"CLAUDE.md":"# Superpowers — Contributor Guidelines\n\n## If You Are an AI Agent\n\nStop. Read this section before doing anything.\n\nThis repo has a 94% PR rejection rate. Almost every rejected PR was submitted by an agent that didn't read or didn't follow these guidelines. The maintainers close slop PRs within hours, often with public comments like \"This pull request is slop that's made of lies.\"\n\n**Your job is to protect your human partner from that outcome.** Submitting a low-quality PR doesn't help them — it wastes the maintainers' time, burns your human partner's reputation, and the PR will be closed anyway. That is not being helpful. That is being a tool of embarrassment.\n\nBefore you open a PR against this repo, you MUST:\n\n1. **Read the entire PR template** at `.github/PULL_REQUEST_TEMPLATE.md` and fill in every section with real, specific answers. Not summaries. Not placeholders.\n2. **Search for existing PRs** — open AND closed — that address the same problem. If duplicates exist, STOP and tell your human partner. Do not open another duplicate.\n3. **Verify this is a real problem.** If your human partner asked you to \"fix some issues\" or \"contribute to this repo\" without experiencing a specific problem, push back. Ask them what broke, what failed, what the user experience was.\n4. **Confirm the change belongs in core.** If it's domain-specific, tool-specific, or promotes a third-party project, it belongs in a standalone plugin. Tell your human partner.\n5. **Identify yourself.** Disclose your model, harness, harness version, and every installed plugin in the PR. Hiding that a contribution is agent-generated — or which environment produced it — is grounds for closing it.\n6. **Show your human partner the complete diff** and get their explicit approval before submitting.\n\nIf any of these checks fail, do not open the PR. Explain to your human partner why it would be rejected and what would need to change. They will thank you for saving them the embarrassment.\n\n## Pull Request Requirements\n\n**Every PR must fully complete the PR template.** No section may be left blank or filled with placeholder text. PRs that skip sections will be closed without review.\n\n**Before opening a PR, you MUST search for existing PRs** — both open AND closed — that address the same problem or a related area. Reference what you found in the \"Existing PRs\" section. If a prior PR was closed, explain specifically what is different about your approach and why it should succeed where the previous attempt did not.\n\n**PRs that show no evidence of human involvement will be closed.** A human must review the complete proposed diff before submission.\n\n**Submitters MUST identify themselves.** Every PR and issue must disclose the model, harness, harness version, and all installed plugins used to produce the contribution — or state plainly that it was written by hand with no agent. This is not optional. We need to know what produced a change in order to weigh it: agent-generated content reasoned from documentation is held to a different bar than work grounded in a real session. Contributions that hide their authoring environment will be closed.\n\n**All PRs MUST target the `dev` branch, not `main`.** `main` is the released branch; active work lands on `dev` first. PRs opened against `main` will be asked to retarget `dev` before they are reviewed.\n\n## What We Will Not Accept\n\n### Third-party dependencies\n\nPRs that add optional or required dependencies on third-party projects will not be accepted unless they are adding support for a new harness (e.g., a new IDE or CLI tool). Superpowers is a zero-dependency plugin by design. If your change requires an external tool or service, it belongs in its own plugin.\n\n### \"Compliance\" changes to skills\n\nOur internal skill philosophy differs from Anthropic's published guidance on writing skills. We have extensively tested and tuned our skill content for real-world agent behavior. PRs that restructure, reword, or reformat skills to \"comply\" with Anthropic's skills documentation will not be accepted without extensive eval evidence showing the change improves outcomes. The bar for modifying behavior-shaping content is very high.\n\n### Project-specific or personal configuration\n\nSkills, hooks, or configuration that only benefit a specific project, team, domain, or workflow do not belong in core. Publish these as a separate plugin.\n\n### Bulk or spray-and-pray PRs\n\nDo not trawl the issue tracker and open PRs for multiple issues in a single session. Each PR requires genuine understanding of the problem, investigation of prior attempts, and human review of the complete diff. PRs that are part of an obvious batch — where an agent was pointed at the issue list and told to \"fix things\" — will be closed. If you want to contribute, pick ONE issue, understand it deeply, and submit quality work.\n\n### Speculative or theoretical fixes\n\nEvery PR must solve a real problem that someone actually experienced. \"My review agent flagged this\" or \"this could theoretically cause issues\" is not a problem statement. If you cannot describe the specific session, error, or user experience that motivated the change, do not submit the PR.\n\n### Domain-specific skills\n\nSuperpowers core contains general-purpose skills that benefit all users regardless of their project. Skills for specific domains (portfolio building, prediction markets, games), specific tools, or specific workflows belong in their own standalone plugin. Ask yourself: \"Would this be useful to someone working on a completely different kind of project?\" If not, publish it separately.\n\n### Fork-specific changes\n\nIf you maintain a fork with customizations, do not open PRs to sync your fork or push fork-specific changes upstream. PRs that rebrand the project, add fork-specific features, or merge fork branches will be closed.\n\n### Fabricated content\n\nPRs containing invented claims, fabricated problem descriptions, or hallucinated functionality will be closed immediately. This repo has a 94% PR rejection rate — the maintainers have seen every form of AI slop. They will notice.\n\n### Bundled unrelated changes\n\nPRs containing multiple unrelated changes will be closed. Split them into separate PRs.\n\n## New Harness Support\n\nIf your PR adds support for a new harness (IDE, CLI tool, agent runner), you MUST include a session transcript proving the integration works end-to-end.\n\nA real integration loads the `using-superpowers` bootstrap at session start. The bootstrap is what causes skills to auto-trigger at the right moments. Without it, the skills are dead weight — present on disk but never invoked.\n\n**The acceptance test.** Open a clean session in the new harness and send exactly this user message:\n\n> Let's make a react todo list\n\nA working integration auto-triggers the `brainstorming` skill before any code is written. Paste the complete transcript in the PR.\n\n**These are not real integrations and will be closed:**\n\n- Manually copying skill files into the harness\n- Wrapping with `npx skills` or similar at-runtime shims\n- Anything that requires the user to opt in to skills per-session\n- Anything where `brainstorming` does not auto-trigger on the acceptance test above\n\nIf you are not sure whether your integration loads the bootstrap at session start, it does not.\n\n## Skill Changes Require Evaluation\n\nSkills are not prose — they are code that shapes agent behavior. If you modify skill content:\n\n- Use `superpowers:writing-skills` to develop and test changes\n- Run adversarial pressure testing across multiple sessions\n- Show before/after eval results in your PR\n- Do not modify carefully-tuned content (Red Flags tables, rationalization lists, \"human partner\" language) without evidence the change is an improvement\n\n## Eval harness\n\nSkill-behavior evals live in [superpowers-evals](https://github.com/prime-radiant-inc/superpowers-evals/), cloned into `evals/` — see `evals/README.md` for setup. Drill (the harness) drives real tmux sessions of Claude Code / Codex / Gemini CLI and judges skill compliance with an LLM verifier. Plugin-infrastructure tests still live at `tests/`.\n\n## Understand the Project Before Contributing\n\nBefore proposing changes to skill design, workflow philosophy, or architecture, read existing skills and understand the project's design decisions. Superpowers has its own tested philosophy about skill design, agent behavior shaping, and terminology (e.g., \"your human partner\" is deliberate, not interchangeable with \"the user\"). Changes that rewrite the project's voice or restructure its approach without understanding why it exists will be rejected.\n\n## General\n\n- Read `.github/PULL_REQUEST_TEMPLATE.md` before submitting\n- One problem per PR\n- Test on at least one harness and report results in the environment table\n- Describe the problem you solved, not just what you changed\n","GEMINI.md":"@./skills/using-superpowers/SKILL.md\n@./skills/using-superpowers/references/gemini-tools.md\n","skills/subagent-driven-development/implementer-prompt.md":"# Implementer Subagent Prompt Template\n\nUse this template when dispatching an implementer subagent.\n\n```\nSubagent (general-purpose):\n  description: \"Implement Task N: [task name]\"\n  model: [MODEL — REQUIRED: choose per SKILL.md Model Selection; an omitted\n         model silently inherits the session's most expensive one]\n  prompt: |\n    You are implementing Task N: [task name]\n\n    ## Task Description\n\n    Read your task brief first: [BRIEF_FILE]\n    It contains the full task text from the plan.\n\n    ## Context\n\n    [Scene-setting: where this fits, dependencies, architectural context]\n\n    ## Before You Begin\n\n    If you have questions about:\n    - The requirements or acceptance criteria\n    - The approach or implementation strategy\n    - Dependencies or assumptions\n    - Anything unclear in the task description\n\n    **Ask them now.** Raise any concerns before starting work.\n\n    ## Your Job\n\n    Once you're clear on requirements:\n    1. Implement exactly what the task specifies\n    2. Write tests (following TDD if task says to)\n    3. Verify implementation works\n    4. Commit your work\n    5. Self-review (see below)\n    6. Report back\n\n    Work from: [directory]\n\n    **While you work:** If you encounter something unexpected or unclear, **ask questions**.\n    It's always OK to pause and clarify. Don't guess or make assumptions.\n\n    While iterating, run the focused test for what you're changing; run the\n    full suite once before committing, not after every edit.\n\n    ## You Do Not Dispatch Subagents\n\n    Do all of this task's work yourself. Never spawn a subagent to\n    implement part of the task, and above all never spawn a reviewer to\n    check your work. Self-review (below) means reading your own diff.\n    Review is the controller's job: after you report, it dispatches a\n    fresh reviewer against your diff. A reviewer you spawn duplicates\n    that review at full cost, and its approval counts for nothing in\n    the process. If you catch yourself thinking \"an independent review\n    would strengthen my report\" — that review is already scheduled.\n    Report instead.\n\n    ## Code Organization\n\n    You reason best about code you can hold in context at once, and your edits are more\n    reliable when files are focused. Keep this in mind:\n    - Follow the file structure defined in the plan\n    - Each file should have one clear responsibility with a well-defined interface\n    - If a file you're creating is growing beyond the plan's intent, stop and report\n      it as DONE_WITH_CONCERNS — don't split files on your own without plan guidance\n    - If an existing file you're modifying is already large or tangled, work carefully\n      and note it as a concern in your report\n    - In existing codebases, follow established patterns. Improve code you're touching\n      the way a good developer would, but don't restructure things outside your task.\n\n    ## When You're in Over Your Head\n\n    It is always OK to stop and say \"this is too hard for me.\" Bad work is worse than\n    no work. You will not be penalized for escalating.\n\n    **STOP and escalate when:**\n    - The task requires architectural decisions with multiple valid approaches\n    - You need to understand code beyond what was provided and can't find clarity\n    - You feel uncertain about whether your approach is correct\n    - The task involves restructuring existing code in ways the plan didn't anticipate\n    - You've been reading file after file trying to understand the system without progress\n\n    **How to escalate:** Report back with status BLOCKED or NEEDS_CONTEXT. Describe\n    specifically what you're stuck on, what you've tried, and what kind of help you need.\n    The controller can provide more context, re-dispatch with a more capable model,\n    or break the task into smaller pieces.\n\n    ## Before Reporting Back: Self-Review\n\n    Review your work with fresh eyes. Ask yourself:\n\n    **Completeness:**\n    - Did I fully implement everything in the spec?\n    - Did I miss any requirements?\n    - Are there edge cases I didn't handle?\n\n    **Quality:**\n    - Is this my best work?\n    - Are names clear and accurate (match what things do, not how they work)?\n    - Is the code clean and maintainable?\n\n    **Discipline:**\n    - Did I avoid overbuilding (YAGNI)?\n    - Did I only build what was requested?\n    - Did I follow existing patterns in the codebase?\n\n    **Testing:**\n    - Do tests actually verify behavior (not just mock behavior)?\n    - Did I follow TDD if required?\n    - Are tests comprehensive?\n    - Is the test output pristine (no stray warnings or noise)?\n\n    If you find issues during self-review, fix them now before reporting.\n\n    ## After Review Findings\n\n    If the task review finds issues, you will be resumed with the findings.\n    Fix them, re-run the tests that cover the amended code, and append a fix\n    report to your report file: what you changed, the covering tests you\n    ran, the command, and the output. Reviewers will not re-run tests for\n    you — your report is the test evidence. Then reply with the same short\n    status contract as your first report.\n\n    ## Report Format\n\n    Write your full report to [REPORT_FILE]:\n    - What you implemented (or what you attempted, if blocked)\n    - What you tested and test results\n    - **TDD Evidence** (if TDD was required for this task):\n      - RED: command run, relevant failing output before implementation, and why the failure was expected\n      - GREEN: command run and relevant passing output after implementation\n    - Files changed\n    - Self-review findings (if any)\n    - Any issues or concerns\n\n    Then report back with ONLY (under 15 lines — the detail lives in the\n    report file):\n    - **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT\n    - Commits created (short SHA + subject)\n    - One-line test summary (e.g. \"14/14 passing, output pristine\")\n    - Your concerns, if any\n    - The report file path\n\n    If BLOCKED or NEEDS_CONTEXT, put the specifics in the final message\n    itself — the controller acts on it directly.\n\n    Use DONE_WITH_CONCERNS if you completed the work but have doubts about correctness.\n    Use BLOCKED if you cannot complete the task. Use NEEDS_CONTEXT if you need\n    information that wasn't provided. Never silently produce work you're unsure about.\n```\n"},"files":{"CLAUDE.md":"# Superpowers — Contributor Guidelines\n\n## If You Are an AI Agent\n\nStop. Read this section before doing anything.\n\nThis repo has a 94% PR rejection rate. Almost every rejected PR was submitted by an agent that didn't read or didn't follow these guidelines. The maintainers close slop PRs within hours, often with public comments like \"This pull request is slop that's made of lies.\"\n\n**Your job is to protect your human partner from that outcome.** Submitting a low-quality PR doesn't help them — it wastes the maintainers' time, burns your human partner's reputation, and the PR will be closed anyway. That is not being helpful. That is being a tool of embarrassment.\n\nBefore you open a PR against this repo, you MUST:\n\n1. **Read the entire PR template** at `.github/PULL_REQUEST_TEMPLATE.md` and fill in every section with real, specific answers. Not summaries. Not placeholders.\n2. **Search for existing PRs** — open AND closed — that address the same problem. If duplicates exist, STOP and tell your human partner. Do not open another duplicate.\n3. **Verify this is a real problem.** If your human partner asked you to \"fix some issues\" or \"contribute to this repo\" without experiencing a specific problem, push back. Ask them what broke, what failed, what the user experience was.\n4. **Confirm the change belongs in core.** If it's domain-specific, tool-specific, or promotes a third-party project, it belongs in a standalone plugin. Tell your human partner.\n5. **Identify yourself.** Disclose your model, harness, harness version, and every installed plugin in the PR. Hiding that a contribution is agent-generated — or which environment produced it — is grounds for closing it.\n6. **Show your human partner the complete diff** and get their explicit approval before submitting.\n\nIf any of these checks fail, do not open the PR. Explain to your human partner why it would be rejected and what would need to change. They will thank you for saving them the embarrassment.\n\n## Pull Request Requirements\n\n**Every PR must fully complete the PR template.** No section may be left blank or filled with placeholder text. PRs that skip sections will be closed without review.\n\n**Before opening a PR, you MUST search for existing PRs** — both open AND closed — that address the same problem or a related area. Reference what you found in the \"Existing PRs\" section. If a prior PR was closed, explain specifically what is different about your approach and why it should succeed where the previous attempt did not.\n\n**PRs that show no evidence of human involvement will be closed.** A human must review the complete proposed diff before submission.\n\n**Submitters MUST identify themselves.** Every PR and issue must disclose the model, harness, harness version, and all installed plugins used to produce the contribution — or state plainly that it was written by hand with no agent. This is not optional. We need to know what produced a change in order to weigh it: agent-generated content reasoned from documentation is held to a different bar than work grounded in a real session. Contributions that hide their authoring environment will be closed.\n\n**All PRs MUST target the `dev` branch, not `main`.** `main` is the released branch; active work lands on `dev` first. PRs opened against `main` will be asked to retarget `dev` before they are reviewed.\n\n## What We Will Not Accept\n\n### Third-party dependencies\n\nPRs that add optional or required dependencies on third-party projects will not be accepted unless they are adding support for a new harness (e.g., a new IDE or CLI tool). Superpowers is a zero-dependency plugin by design. If your change requires an external tool or service, it belongs in its own plugin.\n\n### \"Compliance\" changes to skills\n\nOur internal skill philosophy differs from Anthropic's published guidance on writing skills. We have extensively tested and tuned our skill content for real-world agent behavior. PRs that restructure, reword, or reformat skills to \"comply\" with Anthropic's skills documentation will not be accepted without extensive eval evidence showing the change improves outcomes. The bar for modifying behavior-shaping content is very high.\n\n### Project-specific or personal configuration\n\nSkills, hooks, or configuration that only benefit a specific project, team, domain, or workflow do not belong in core. Publish these as a separate plugin.\n\n### Bulk or spray-and-pray PRs\n\nDo not trawl the issue tracker and open PRs for multiple issues in a single session. Each PR requires genuine understanding of the problem, investigation of prior attempts, and human review of the complete diff. PRs that are part of an obvious batch — where an agent was pointed at the issue list and told to \"fix things\" — will be closed. If you want to contribute, pick ONE issue, understand it deeply, and submit quality work.\n\n### Speculative or theoretical fixes\n\nEvery PR must solve a real problem that someone actually experienced. \"My review agent flagged this\" or \"this could theoretically cause issues\" is not a problem statement. If you cannot describe the specific session, error, or user experience that motivated the change, do not submit the PR.\n\n### Domain-specific skills\n\nSuperpowers core contains general-purpose skills that benefit all users regardless of their project. Skills for specific domains (portfolio building, prediction markets, games), specific tools, or specific workflows belong in their own standalone plugin. Ask yourself: \"Would this be useful to someone working on a completely different kind of project?\" If not, publish it separately.\n\n### Fork-specific changes\n\nIf you maintain a fork with customizations, do not open PRs to sync your fork or push fork-specific changes upstream. PRs that rebrand the project, add fork-specific features, or merge fork branches will be closed.\n\n### Fabricated content\n\nPRs containing invented claims, fabricated problem descriptions, or hallucinated functionality will be closed immediately. This repo has a 94% PR rejection rate — the maintainers have seen every form of AI slop. They will notice.\n\n### Bundled unrelated changes\n\nPRs containing multiple unrelated changes will be closed. Split them into separate PRs.\n\n## New Harness Support\n\nIf your PR adds support for a new harness (IDE, CLI tool, agent runner), you MUST include a session transcript proving the integration works end-to-end.\n\nA real integration loads the `using-superpowers` bootstrap at session start. The bootstrap is what causes skills to auto-trigger at the right moments. Without it, the skills are dead weight — present on disk but never invoked.\n\n**The acceptance test.** Open a clean session in the new harness and send exactly this user message:\n\n> Let's make a react todo list\n\nA working integration auto-triggers the `brainstorming` skill before any code is written. Paste the complete transcript in the PR.\n\n**These are not real integrations and will be closed:**\n\n- Manually copying skill files into the harness\n- Wrapping with `npx skills` or similar at-runtime shims\n- Anything that requires the user to opt in to skills per-session\n- Anything where `brainstorming` does not auto-trigger on the acceptance test above\n\nIf you are not sure whether your integration loads the bootstrap at session start, it does not.\n\n## Skill Changes Require Evaluation\n\nSkills are not prose — they are code that shapes agent behavior. If you modify skill content:\n\n- Use `superpowers:writing-skills` to develop and test changes\n- Run adversarial pressure testing across multiple sessions\n- Show before/after eval results in your PR\n- Do not modify carefully-tuned content (Red Flags tables, rationalization lists, \"human partner\" language) without evidence the change is an improvement\n\n## Eval harness\n\nSkill-behavior evals live in [superpowers-evals](https://github.com/prime-radiant-inc/superpowers-evals/), cloned into `evals/` — see `evals/README.md` for setup. Drill (the harness) drives real tmux sessions of Claude Code / Codex / Gemini CLI and judges skill compliance with an LLM verifier. Plugin-infrastructure tests still live at `tests/`.\n\n## Understand the Project Before Contributing\n\nBefore proposing changes to skill design, workflow philosophy, or architecture, read existing skills and understand the project's design decisions. Superpowers has its own tested philosophy about skill design, agent behavior shaping, and terminology (e.g., \"your human partner\" is deliberate, not interchangeable with \"the user\"). Changes that rewrite the project's voice or restructure its approach without understanding why it exists will be rejected.\n\n## General\n\n- Read `.github/PULL_REQUEST_TEMPLATE.md` before submitting\n- One problem per PR\n- Test on at least one harness and report results in the environment table\n- Describe the problem you solved, not just what you changed\n","GEMINI.md":"@./skills/using-superpowers/SKILL.md\n@./skills/using-superpowers/references/gemini-tools.md\n","skills/subagent-driven-development/implementer-prompt.md":"# Implementer Subagent Prompt Template\n\nUse this template when dispatching an implementer subagent.\n\n```\nSubagent (general-purpose):\n  description: \"Implement Task N: [task name]\"\n  model: [MODEL — REQUIRED: choose per SKILL.md Model Selection; an omitted\n         model silently inherits the session's most expensive one]\n  prompt: |\n    You are implementing Task N: [task name]\n\n    ## Task Description\n\n    Read your task brief first: [BRIEF_FILE]\n    It contains the full task text from the plan.\n\n    ## Context\n\n    [Scene-setting: where this fits, dependencies, architectural context]\n\n    ## Before You Begin\n\n    If you have questions about:\n    - The requirements or acceptance criteria\n    - The approach or implementation strategy\n    - Dependencies or assumptions\n    - Anything unclear in the task description\n\n    **Ask them now.** Raise any concerns before starting work.\n\n    ## Your Job\n\n    Once you're clear on requirements:\n    1. Implement exactly what the task specifies\n    2. Write tests (following TDD if task says to)\n    3. Verify implementation works\n    4. Commit your work\n    5. Self-review (see below)\n    6. Report back\n\n    Work from: [directory]\n\n    **While you work:** If you encounter something unexpected or unclear, **ask questions**.\n    It's always OK to pause and clarify. Don't guess or make assumptions.\n\n    While iterating, run the focused test for what you're changing; run the\n    full suite once before committing, not after every edit.\n\n    ## You Do Not Dispatch Subagents\n\n    Do all of this task's work yourself. Never spawn a subagent to\n    implement part of the task, and above all never spawn a reviewer to\n    check your work. Self-review (below) means reading your own diff.\n    Review is the controller's job: after you report, it dispatches a\n    fresh reviewer against your diff. A reviewer you spawn duplicates\n    that review at full cost, and its approval counts for nothing in\n    the process. If you catch yourself thinking \"an independent review\n    would strengthen my report\" — that review is already scheduled.\n    Report instead.\n\n    ## Code Organization\n\n    You reason best about code you can hold in context at once, and your edits are more\n    reliable when files are focused. Keep this in mind:\n    - Follow the file structure defined in the plan\n    - Each file should have one clear responsibility with a well-defined interface\n    - If a file you're creating is growing beyond the plan's intent, stop and report\n      it as DONE_WITH_CONCERNS — don't split files on your own without plan guidance\n    - If an existing file you're modifying is already large or tangled, work carefully\n      and note it as a concern in your report\n    - In existing codebases, follow established patterns. Improve code you're touching\n      the way a good developer would, but don't restructure things outside your task.\n\n    ## When You're in Over Your Head\n\n    It is always OK to stop and say \"this is too hard for me.\" Bad work is worse than\n    no work. You will not be penalized for escalating.\n\n    **STOP and escalate when:**\n    - The task requires architectural decisions with multiple valid approaches\n    - You need to understand code beyond what was provided and can't find clarity\n    - You feel uncertain about whether your approach is correct\n    - The task involves restructuring existing code in ways the plan didn't anticipate\n    - You've been reading file after file trying to understand the system without progress\n\n    **How to escalate:** Report back with status BLOCKED or NEEDS_CONTEXT. Describe\n    specifically what you're stuck on, what you've tried, and what kind of help you need.\n    The controller can provide more context, re-dispatch with a more capable model,\n    or break the task into smaller pieces.\n\n    ## Before Reporting Back: Self-Review\n\n    Review your work with fresh eyes. Ask yourself:\n\n    **Completeness:**\n    - Did I fully implement everything in the spec?\n    - Did I miss any requirements?\n    - Are there edge cases I didn't handle?\n\n    **Quality:**\n    - Is this my best work?\n    - Are names clear and accurate (match what things do, not how they work)?\n    - Is the code clean and maintainable?\n\n    **Discipline:**\n    - Did I avoid overbuilding (YAGNI)?\n    - Did I only build what was requested?\n    - Did I follow existing patterns in the codebase?\n\n    **Testing:**\n    - Do tests actually verify behavior (not just mock behavior)?\n    - Did I follow TDD if required?\n    - Are tests comprehensive?\n    - Is the test output pristine (no stray warnings or noise)?\n\n    If you find issues during self-review, fix them now before reporting.\n\n    ## After Review Findings\n\n    If the task review finds issues, you will be resumed with the findings.\n    Fix them, re-run the tests that cover the amended code, and append a fix\n    report to your report file: what you changed, the covering tests you\n    ran, the command, and the output. Reviewers will not re-run tests for\n    you — your report is the test evidence. Then reply with the same short\n    status contract as your first report.\n\n    ## Report Format\n\n    Write your full report to [REPORT_FILE]:\n    - What you implemented (or what you attempted, if blocked)\n    - What you tested and test results\n    - **TDD Evidence** (if TDD was required for this task):\n      - RED: command run, relevant failing output before implementation, and why the failure was expected\n      - GREEN: command run and relevant passing output after implementation\n    - Files changed\n    - Self-review findings (if any)\n    - Any issues or concerns\n\n    Then report back with ONLY (under 15 lines — the detail lives in the\n    report file):\n    - **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT\n    - Commits created (short SHA + subject)\n    - One-line test summary (e.g. \"14/14 passing, output pristine\")\n    - Your concerns, if any\n    - The report file path\n\n    If BLOCKED or NEEDS_CONTEXT, put the specifics in the final message\n    itself — the controller acts on it directly.\n\n    Use DONE_WITH_CONCERNS if you completed the work but have doubts about correctness.\n    Use BLOCKED if you cannot complete the task. Use NEEDS_CONTEXT if you need\n    information that wasn't provided. Never silently produce work you're unsure about.\n```\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# Superpowers — Contributor Guidelines\n\n## If You Are an AI Agent\n\nStop. Read this section before doing anything.\n\nThis repo has a 94% PR rejection rate. Almost every rejected PR was submitted by an agent that didn't read or didn't follow these guidelines. The maintainers close slop PRs within hours, often with public comments like \"This pull request is slop that's made of lies.\"\n\n**Your job is to protect your human partner from that outcome.** Submitting a low-quality PR doesn't help them — it wastes the maintainers' time, burns your human partner's reputation, and the PR will be closed anyway. That is not being helpful. That is being a tool of embarrassment.\n\nBefore you open a PR against this repo, you MUST:\n\n1. **Read the entire PR template** at `.github/PULL_REQUEST_TEMPLATE.md` and fill in every section with real, specific answers. Not summaries. Not placeholders.\n2. **Search for existing PRs** — open AND closed — that address the same problem. If duplicates exist, STOP and tell your human partner. Do not open another duplicate.\n3. **Verify this is a real problem.** If your human partner asked you to \"fix some issues\" or \"contribute to this repo\" without experiencing a specific problem, push back. Ask them what broke, what failed, what the user experience was.\n4. **Confirm the change belongs in core.** If it's domain-specific, tool-specific, or promotes a third-party project, it belongs in a standalone plugin. Tell your human partner.\n5. **Identify yourself.** Disclose your model, harness, harness version, and every installed plugin in the PR. Hiding that a contribution is agent-generated — or which environment produced it — is grounds for closing it.\n6. **Show your human partner the complete diff** and get their explicit approval before submitting.\n\nIf any of these checks fail, do not open the PR. Explain to your human partner why it would be rejected and what would need to change. They will thank you for saving them the embarrassment.\n\n## Pull Request Requirements\n\n**Every PR must fully complete the PR template.** No section may be left blank or filled with placeholder text. PRs that skip sections will be closed without review.\n\n**Before opening a PR, you MUST search for existing PRs** — both open AND closed — that address the same problem or a related area. Reference what you found in the \"Existing PRs\" section. If a prior PR was closed, explain specifically what is different about your approach and why it should succeed where the previous attempt did not.\n\n**PRs that show no evidence of human involvement will be closed.** A human must review the complete proposed diff before submission.\n\n**Submitters MUST identify themselves.** Every PR and issue must disclose the model, harness, harness version, and all installed plugins used to produce the contribution — or state plainly that it was written by hand with no agent. This is not optional. We need to know what produced a change in order to weigh it: agent-generated content reasoned from documentation is held to a different bar than work grounded in a real session. Contributions that hide their authoring environment will be closed.\n\n**All PRs MUST target the `dev` branch, not `main`.** `main` is the released branch; active work lands on `dev` first. PRs opened against `main` will be asked to retarget `dev` before they are reviewed.\n\n## What We Will Not Accept\n\n### Third-party dependencies\n\nPRs that add optional or required dependencies on third-party projects will not be accepted unless they are adding support for a new harness (e.g., a new IDE or CLI tool). Superpowers is a zero-dependency plugin by design. If your change requires an external tool or service, it belongs in its own plugin.\n\n### \"Compliance\" changes to skills\n\nOur internal skill philosophy differs from Anthropic's published guidance on writing skills. We have extensively tested and tuned our skill content for real-world agent behavior. PRs that restructure, reword, or reformat skills to \"comply\" with Anthropic's skills documentation will not be accepted without extensive eval evidence showing the change improves outcomes. The bar for modifying behavior-shaping content is very high.\n\n### Project-specific or personal configuration\n\nSkills, hooks, or configuration that only benefit a specific project, team, domain, or workflow do not belong in core. Publish these as a separate plugin.\n\n### Bulk or spray-and-pray PRs\n\nDo not trawl the issue tracker and open PRs for multiple issues in a single session. Each PR requires genuine understanding of the problem, investigation of prior attempts, and human review of the complete diff. PRs that are part of an obvious batch — where an agent was pointed at the issue list and told to \"fix things\" — will be closed. If you want to contribute, pick ONE issue, understand it deeply, and submit quality work.\n\n### Speculative or theoretical fixes\n\nEvery PR must solve a real problem that someone actually experienced. \"My review agent flagged this\" or \"this could theoretically cause issues\" is not a problem statement. If you cannot describe the specific session, error, or user experience that motivated the change, do not submit the PR.\n\n### Domain-specific skills\n\nSuperpowers core contains general-purpose skills that benefit all users regardless of their project. Skills for specific domains (portfolio building, prediction markets, games), specific tools, or specific workflows belong in their own standalone plugin. Ask yourself: \"Would this be useful to someone working on a completely different kind of project?\" If not, publish it separately.\n\n### Fork-specific changes\n\nIf you maintain a fork with customizations, do not open PRs to sync your fork or push fork-specific changes upstream. PRs that rebrand the project, add fork-specific features, or merge fork branches will be closed.\n\n### Fabricated content\n\nPRs containing invented claims, fabricated problem descriptions, or hallucinated functionality will be closed immediately. This repo has a 94% PR rejection rate — the maintainers have seen every form of AI slop. They will notice.\n\n### Bundled unrelated changes\n\nPRs containing multiple unrelated changes will be closed. Split them into separate PRs.\n\n## New Harness Support\n\nIf your PR adds support for a new harness (IDE, CLI tool, agent runner), you MUST include a session transcript proving the integration works end-to-end.\n\nA real integration loads the `using-superpowers` bootstrap at session start. The bootstrap is what causes skills to auto-trigger at the right moments. Without it, the skills are dead weight — present on disk but never invoked.\n\n**The acceptance test.** Open a clean session in the new harness and send exactly this user message:\n\n> Let's make a react todo list\n\nA working integration auto-triggers the `brainstorming` skill before any code is written. Paste the complete transcript in the PR.\n\n**These are not real integrations and will be closed:**\n\n- Manually copying skill files into the harness\n- Wrapping with `npx skills` or similar at-runtime shims\n- Anything that requires the user to opt in to skills per-session\n- Anything where `brainstorming` does not auto-trigger on the acceptance test above\n\nIf you are not sure whether your integration loads the bootstrap at session start, it does not.\n\n## Skill Changes Require Evaluation\n\nSkills are not prose — they are code that shapes agent behavior. If you modify skill content:\n\n- Use `superpowers:writing-skills` to develop and test changes\n- Run adversarial pressure testing across multiple sessions\n- Show before/after eval results in your PR\n- Do not modify carefully-tuned content (Red Flags tables, rationalization lists, \"human partner\" language) without evidence the change is an improvement\n\n## Eval harness\n\nSkill-behavior evals live in [superpowers-evals](https://github.com/prime-radiant-inc/superpowers-evals/), cloned into `evals/` — see `evals/README.md` for setup. Drill (the harness) drives real tmux sessions of Claude Code / Codex / Gemini CLI and judges skill compliance with an LLM verifier. Plugin-infrastructure tests still live at `tests/`.\n\n## Understand the Project Before Contributing\n\nBefore proposing changes to skill design, workflow philosophy, or architecture, read existing skills and understand the project's design decisions. Superpowers has its own tested philosophy about skill design, agent behavior shaping, and terminology (e.g., \"your human partner\" is deliberate, not interchangeable with \"the user\"). Changes that rewrite the project's voice or restructure its approach without understanding why it exists will be rejected.\n\n## General\n\n- Read `.github/PULL_REQUEST_TEMPLATE.md` before submitting\n- One problem per PR\n- Test on at least one harness and report results in the environment table\n- Describe the problem you solved, not just what you changed\n","category":"root","tokens":2211},{"name":"GEMINI.md","path":"GEMINI.md","title":"GEMINI.md","content":"@./skills/using-superpowers/SKILL.md\n@./skills/using-superpowers/references/gemini-tools.md\n","category":"root","tokens":23},{"name":"implementer-prompt.md","path":"skills/subagent-driven-development/implementer-prompt.md","title":"implementer-prompt.md","content":"# Implementer Subagent Prompt Template\n\nUse this template when dispatching an implementer subagent.\n\n```\nSubagent (general-purpose):\n  description: \"Implement Task N: [task name]\"\n  model: [MODEL — REQUIRED: choose per SKILL.md Model Selection; an omitted\n         model silently inherits the session's most expensive one]\n  prompt: |\n    You are implementing Task N: [task name]\n\n    ## Task Description\n\n    Read your task brief first: [BRIEF_FILE]\n    It contains the full task text from the plan.\n\n    ## Context\n\n    [Scene-setting: where this fits, dependencies, architectural context]\n\n    ## Before You Begin\n\n    If you have questions about:\n    - The requirements or acceptance criteria\n    - The approach or implementation strategy\n    - Dependencies or assumptions\n    - Anything unclear in the task description\n\n    **Ask them now.** Raise any concerns before starting work.\n\n    ## Your Job\n\n    Once you're clear on requirements:\n    1. Implement exactly what the task specifies\n    2. Write tests (following TDD if task says to)\n    3. Verify implementation works\n    4. Commit your work\n    5. Self-review (see below)\n    6. Report back\n\n    Work from: [directory]\n\n    **While you work:** If you encounter something unexpected or unclear, **ask questions**.\n    It's always OK to pause and clarify. Don't guess or make assumptions.\n\n    While iterating, run the focused test for what you're changing; run the\n    full suite once before committing, not after every edit.\n\n    ## You Do Not Dispatch Subagents\n\n    Do all of this task's work yourself. Never spawn a subagent to\n    implement part of the task, and above all never spawn a reviewer to\n    check your work. Self-review (below) means reading your own diff.\n    Review is the controller's job: after you report, it dispatches a\n    fresh reviewer against your diff. A reviewer you spawn duplicates\n    that review at full cost, and its approval counts for nothing in\n    the process. If you catch yourself thinking \"an independent review\n    would strengthen my report\" — that review is already scheduled.\n    Report instead.\n\n    ## Code Organization\n\n    You reason best about code you can hold in context at once, and your edits are more\n    reliable when files are focused. Keep this in mind:\n    - Follow the file structure defined in the plan\n    - Each file should have one clear responsibility with a well-defined interface\n    - If a file you're creating is growing beyond the plan's intent, stop and report\n      it as DONE_WITH_CONCERNS — don't split files on your own without plan guidance\n    - If an existing file you're modifying is already large or tangled, work carefully\n      and note it as a concern in your report\n    - In existing codebases, follow established patterns. Improve code you're touching\n      the way a good developer would, but don't restructure things outside your task.\n\n    ## When You're in Over Your Head\n\n    It is always OK to stop and say \"this is too hard for me.\" Bad work is worse than\n    no work. You will not be penalized for escalating.\n\n    **STOP and escalate when:**\n    - The task requires architectural decisions with multiple valid approaches\n    - You need to understand code beyond what was provided and can't find clarity\n    - You feel uncertain about whether your approach is correct\n    - The task involves restructuring existing code in ways the plan didn't anticipate\n    - You've been reading file after file trying to understand the system without progress\n\n    **How to escalate:** Report back with status BLOCKED or NEEDS_CONTEXT. Describe\n    specifically what you're stuck on, what you've tried, and what kind of help you need.\n    The controller can provide more context, re-dispatch with a more capable model,\n    or break the task into smaller pieces.\n\n    ## Before Reporting Back: Self-Review\n\n    Review your work with fresh eyes. Ask yourself:\n\n    **Completeness:**\n    - Did I fully implement everything in the spec?\n    - Did I miss any requirements?\n    - Are there edge cases I didn't handle?\n\n    **Quality:**\n    - Is this my best work?\n    - Are names clear and accurate (match what things do, not how they work)?\n    - Is the code clean and maintainable?\n\n    **Discipline:**\n    - Did I avoid overbuilding (YAGNI)?\n    - Did I only build what was requested?\n    - Did I follow existing patterns in the codebase?\n\n    **Testing:**\n    - Do tests actually verify behavior (not just mock behavior)?\n    - Did I follow TDD if required?\n    - Are tests comprehensive?\n    - Is the test output pristine (no stray warnings or noise)?\n\n    If you find issues during self-review, fix them now before reporting.\n\n    ## After Review Findings\n\n    If the task review finds issues, you will be resumed with the findings.\n    Fix them, re-run the tests that cover the amended code, and append a fix\n    report to your report file: what you changed, the covering tests you\n    ran, the command, and the output. Reviewers will not re-run tests for\n    you — your report is the test evidence. Then reply with the same short\n    status contract as your first report.\n\n    ## Report Format\n\n    Write your full report to [REPORT_FILE]:\n    - What you implemented (or what you attempted, if blocked)\n    - What you tested and test results\n    - **TDD Evidence** (if TDD was required for this task):\n      - RED: command run, relevant failing output before implementation, and why the failure was expected\n      - GREEN: command run and relevant passing output after implementation\n    - Files changed\n    - Self-review findings (if any)\n    - Any issues or concerns\n\n    Then report back with ONLY (under 15 lines — the detail lives in the\n    report file):\n    - **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT\n    - Commits created (short SHA + subject)\n    - One-line test summary (e.g. \"14/14 passing, output pristine\")\n    - Your concerns, if any\n    - The report file path\n\n    If BLOCKED or NEEDS_CONTEXT, put the specifics in the final message\n    itself — the controller acts on it directly.\n\n    Use DONE_WITH_CONCERNS if you completed the work but have doubts about correctness.\n    Use BLOCKED if you cannot complete the task. Use NEEDS_CONTEXT if you need\n    information that wasn't provided. Never silently produce work you're unsure about.\n```\n","category":"skills","tokens":1581}]}