with one click
my-router
// Context-aware router that detects work type and dispatches to the right skill. Ships with a minimal default routing table; extend it in your fork with your own skill entries.
// Context-aware router that detects work type and dispatches to the right skill. Ships with a minimal default routing table; extend it in your fork with your own skill entries.
Review loop for staged changes. Detects content type, prepares a review request for Codex (Terminal-relay manual default, opt-in Auto-terminal codex-exec subprocess, or IDE plugin), categorizes feedback, revises, and iterates. Works for code, papers, proposals, or any text-based output.
Review loop for staged changes. Detects content type, prepares a review request for Codex (Terminal-relay manual default, opt-in Auto-terminal codex-exec subprocess, or IDE plugin), categorizes feedback, revises, and iterates. Works for code, papers, proposals, or any text-based output.
| name | my-router |
| description | Context-aware router that detects work type and dispatches to the right skill. Ships with a minimal default routing table; extend it in your fork with your own skill entries. |
A routing layer that sits between the outer workflow (e.g., superpowers brainstorm/plan/execute/verify) and domain skills. The router reads the working directory, file types, and user prompt to decide which skill to invoke, so the user does not need to remember skill names.
In this repo's shipped form, the routing table has concrete entries for the four shipped skills (implement-review, ci-mockup-figure, readme-polish, plus my-router itself). It is also designed as a pattern you extend: add entries for your own skills (whether local to your fork of this repo or local to a consuming project) and the router will dispatch to them.
The router decides this. Not all tasks need superpowers' full ceremony.
| Task shape | Route | Why |
|---|---|---|
| Clear, scoped task with an obvious skill match (e.g., "review staged changes") | Direct dispatch ā router picks the domain skill and runs it immediately | Brainstorming and planning add no value when the task is already well-defined |
| Open-ended, multi-step, or ambiguous task (e.g., "build a new feature", "restructure the paper") | Superpowers first ā brainstorm ā plan ā execute (router dispatches during execute) ā verify | These benefit from thinking before doing |
| Quick edit or fix (e.g., "fix the typo on line 42", "rename this variable") | Neither ā just do it directly | No routing or workflow needed |
| Effort signal words in prompt (e.g., "extensively", "deep", "thorough", "in-depth", "carefully", "comprehensive") | Superpowers + extended thinking ā enable extended thinking (Alt+T) and route through superpowers regardless of task shape | The user is explicitly asking for more deliberation |
The rule: if the domain skill is obvious and the scope is clear, skip superpowers and dispatch directly. If the task needs exploration or planning, let superpowers run the outer loop and the router dispatches during execution. If the user signals they want deep effort, always use superpowers with extended thinking enabled.
When superpowers is active, it handles workflow phases: brainstorm ā plan ā execute ā verify. The router activates during the execute phase and dispatches to the right domain skill.
When superpowers is not active (direct dispatch or quick task), the router works standalone.
At dispatch time, the router checks three signals in order:
The user's prompt often contains the clearest signal. The shipped routing table includes keyword entries for implement-review, ci-mockup-figure, and readme-polish. Extend it in your fork with entries for your own skills.
See references/routing-table.md for the current table and the extension template.
If prompt keywords are ambiguous, inspect the files being worked on. The shipped router recognizes staged git changes ā implement-review, HTML mockup files for dashboards/timelines ā ci-mockup-figure, and a top-level README.md flagged for polish ā readme-polish. Add your own file-type rules when you add new skills.
Some projects declare their type in AGENTS.local.md or via directory naming conventions (e.g., a proposals/ or papers/ directory, or a submodule pointing at a shared editorial repo). Use these hints to pick content-aware behavior when relevant to your skills.
skills/ (project-local) for any skill that is a more specific variant of the matched skill. If a local variant exists, use it instead of any pack-deployed or bootstrapped copy.In consuming project repos, skills can be project-local, pack-deployed, or bootstrapped from shared config. When dispatching, look for each skill in this order:
skills/<name>/SKILL.md: project-local (highest priority). Projects can add their own skills here..claude/skills/<name>/SKILL.md: pack-deployed by anywhere-agents pack install. The .claude/ prefix is a historical Claude Code convention; the SKILL.md contents are agent-agnostic..agent-config/repo/skills/<name>/SKILL.md: bootstrapped from the shared config repo./skills output.If a project-local skill matches the task better than a pack-deployed or bootstrapped skill, prefer the project-local one. The router itself follows this same lookup order.
To add a new skill to the router's dispatch table:
skills/<your-skill>/ (in your fork of this repo, or in a consuming project's own skills/)references/routing-table.md with keywords, file types, and directory hints.claude/commands/<your-skill>.md pointer file so Claude Code can invoke it directlyThe router will pick up the new entry on the next session.
When review is needed after a domain skill finishes:
implement-review with the appropriate lens (code, paper, proposal, general)See implement-review/SKILL.md for the review loop protocol.
User says: "Review this"
ā Router detects: staged changes exist ā dispatches to implement-review; content-type lens (code, paper, proposal, general) selected based on staged files.
User says: "Build the feature and review it"
ā Router detects: code context ā superpowers handles the build, then router dispatches to implement-review with code lens.
User says: "Make an HTML mockup for the method figure"
ā Router detects: keyword "mockup" ā dispatches to ci-mockup-figure.
User says: "Polish the README with modern patterns"
ā Router detects: keyword "polish README" ā dispatches to readme-polish.
User says: (anything else, shipped router has no rule)
ā Router falls through to superpowers or general agent behavior. Add more rules by editing references/routing-table.md.