A complete workflow for implementing a requirement when a product manager provides a prototype project and development happens in a separate target project. It covers exploration, design, coding, testing, release, and review with human approval points.
A small workflow for turning a one-line backend request into a mini plan, an API contract, and an impact analysis. It is intended for changes that do not alter the database and should take no more than eight hours.
A lightweight workflow for small frontend requests described in one sentence, such as adding a filter or changing button text. It expands the request into a short plan and checks whether the work is still small enough for this process.
A lightweight workflow for a small, one-sentence request that changes both the front end and back end. It writes a short requirements document and interface contract, then checks the complete request-to-database path before expanding the work.
A workflow for building only the backend of one project from a working reference project. It studies the reference project's real browser requests and backend structure, then applies the needed behavior to the target project.
A front-end workflow for implementing a feature in a target project by studying a working reference project first. The reference project is treated as read-only, and its visible behaviour and interface expectations are documented before coding.
A routing workflow for development tasks. It asks what kind of work was requested, whether requirements or a prototype exist, and whether the work covers the front end, back end, or both, then selects a more specific workflow.
A development workflow for implementing documented requirements in a target project. It surveys the project, checks for reusable code, designs the change, validates one complete slice, then coordinates the remaining implementation and self-checks.
A release-and-review workflow for a completed feature. It prepares material for product-manager acceptance, guides deployment, checks the feature after release, and records lessons for future work.
A requirements-discovery workflow for examining a working prototype and turning its behaviour into plain business documents. It keeps the prototype read-only and uses back-and-forth questions to clarify unclear points.
Use when facing 3+ independent failures that can be investigated without shared state or dependencies - dispatches multiple Claude agents to investigate and fix independent problems concurrently.
Use when partner provides a complete implementation plan to execute in controlled batches with review checkpoints - loads plan, reviews critically, executes tasks in batches, reports for review between batches.
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
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.
A measured workflow for improving software performance: establish a benchmark, profile the system to find bottlenecks, change one variable, and benchmark again. A bottleneck is the part limiting speed, throughput, memory use, or another target measure.
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.
A step-by-step workflow for changing code structure without changing what the software does. It requires tests around the code, small commits, and passing tests after each change.
Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches superpowers:code-reviewer subagent to review implementation against plan or requirements before proceeding.
Use when errors occur deep in execution and you need to trace back to find the original trigger - systematically traces bugs backward through call stack, adding instrumentation when needed, to identify source of invalid data or incorrect behavior.
Use when you've developed a broadly useful skill and want to contribute it upstream via pull request - guides process of branching, committing, pushing, and creating PR to contribute skills back to upstream repository.
Use when executing implementation plans with independent tasks in the current session - dispatches fresh subagent for each task with code review between tasks, enabling fast iteration with quality gates.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding before attempting solutions.
Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first.
Use when writing or changing tests, adding mocks, or tempted to add test-only methods to production code - prevents testing mock behavior, production pollution with test-only methods, and mocking without understanding dependencies.