Coding router

Coding Router

Route repo work to the smallest reliable source read, edit, check, or skill. Make "no extra skill needed" the default success path.

Rule

Default route: micro-loop.

Do not load another skill when a direct source read, answer, narrow edit, and focused check is enough. A specialized skill is justified only when it prevents a specific failure mode: stale repo setup, unclear behavior, unreproduced failure, unsafe workspace operation, weak completion claim, PR review drift, cleanup exhaustion drift, durable tracking drift, or authorized delegation/parallel work.

Pick one controlling route for the next move. Use gates only for the specific risk that appeared, then return to source/read/edit/check quickly.

Micro-Loop

Use this for tiny safe edits, direct code questions, narrow source reads, and routine source/test/docs/config/workflow changes when no gate risk applies.

1. Inspect the smallest relevant source, docs, tests, logs, diffs, or command output.
2. Answer or make the narrow edit.
3. Run the smallest useful check when behavior, public or caller contract, config, workflow, or generated output changed.
4. Use verify-before-done only before completion, readiness, passing, reviewed, safe, or mergeable claims.

If the task still fits the micro-loop, do not route to another skill.

Choose One Controller

Situation	Controller
Unfamiliar repo, stale repo context, or unknown repo instructions/commands that matter now	repo-onboarding
Unclear behavior, interface, or public or caller contract after cheap repo evidence	clarify-scope
Bug, failing command, build/CI failure, regression, flake, crash, or unexplained error	diagnose-loop
Behavior change, new user-visible or caller-visible path, or regression check needed	tdd-slice
Cleanup discovery, continued cleanup, explicit human-reviewability cleanup, behavior-preserving refactor with structure or testability risk, duplicated logic, module-boundary or caller-interface cleanup, or obsolete-code removal	codebase-cleanup
Branch, commit, working tree, or PR-ready diff needs semantic correctness review	pre-pr-review
Creating or changing coding-agent skills	author-skills
Multi-step approved work truly needs a written plan or handoff	slice-plan
User explicitly wants plan doc + GitHub issues + issue-by-issue execution with an explicit checkpoint policy	issue-driven-execution

Do not use slice-plan for one behavior, one bug, a tiny edit, or a plan that can stay in the chat.

Use pre-pr-review for review requests before opening, updating, or merging a PR. Do not route those straight to verify-before-done; review finds diff-introduced issues, while verification calibrates final claims.

Use Gates Only When Needed

Risk	Gate
Overlapping dirty tracked paths, relevant untracked protected paths, staging, destructive operation, branch/worktree action, dependency install, formatter/generator/migration, generated output, or cleanup could affect workspace state	workspace-safety
Final completion, readiness, passing, reviewed, safe, or mergeable claim	verify-before-done
Durable issue/PR recordkeeping, accepted scope/status record updates, or long-lived GitHub record state that must be written or updated	github-tracking
Explicit user request for subagents, approved plan delegation, or clearly independent review/exploration with enough scope	subagent-workflow
Approved parallel implementation or real workspace isolation needs separate branches/worktrees	worktree-isolation

Do not use github-tracking for generic live GitHub triage, PR publishing, CI debugging, or review-comment resolution when a GitHub-specific plugin skill or direct tool flow owns that job.

Do not use subagent-workflow merely because parallelism seems useful. Delegation needs authorization, clear scope, and parent integration.

Reroute

• If evidence shows the chosen route is wrong, switch routes and name the reason; avoid oscillating.
• If a review turns into fixes, PR tracking, merge, planning, cleanup, or unclear next-route work, return here and choose the next controller.
• If a refactor uncovers a bug, route to diagnose-loop.
• If cleanup changes behavior, route to tdd-slice.
• If a gate expands into the main job, return here instead of letting the gate become the workflow.
• If the selected skill is not installed or available, do not simulate it. Use the closest installed route only if it prevents the same failure mode; otherwise stay in the micro-loop and name the missing skill as unavailable.
• If no specialized route prevents a failure mode, stay in the micro-loop.

Evidence

Use docs, plans, summaries, and issues as maps. Current behavior comes from source, tests, fixtures, logs, diffs, commands, CI/check output, and live tracker state when relevant.

Stop Or Ask

Ask only when the missing answer changes behavior, public or caller contract, data/state, security, dependency/config behavior, cost, reversibility, external state, or destructive scope.

Stop before broad rewrites, new dependencies, migrations, generated-output churn, destructive commands, irreversible external actions, or publishing unless the user approved the route and scope.

Finish

For nontrivial work, end with changed files/behavior, checks or evidence, diff-review result, remaining uncertainty, and the next useful action. For tiny micro-loop work, keep the report short.