Autoplan

Autoplan

One lazy entry point for the whole catalog. Classify the request, route it, apply defaults, and only stop for decisions that are genuinely the user's. Models and people do not hand-route across dozens of skills; this skill does.

Triggers

The router also fires implicitly. Any concrete request that names no skill routes through the table below instead of defaulting to a bare answer, for example "why is CI failing", "investigate the flaky test", or "redo #1723 properly".

These phrases are grounded in this repo's own Copilot and Claude session history. The dominant real openers are continue, proceed, investigate, fix the X, do it, and handle it, not ceremonial delegation phrases. Continue and proceed are deliberately excluded as hard triggers: they mean resume the in-flight work, so they route to whatever is already running rather than re-classifying from scratch.

Process

Phase 0: Recon the target

Before you classify, establish the target repository's stack. Do not assume the stack of the repo this skill ships from (Python-first). The target may be C#, TypeScript, Go, Rust, or anything else.

Read the target's own signals: CONTRIBUTING*, AGENTS.md/CLAUDE.md, README*, build manifests (*.csproj/*.sln, pyproject.toml, package.json, go.mod, Cargo.toml, pom.xml, build.gradle, build.gradle.kts, settings.gradle, settings.gradle.kts), and the src/, lib/, test//tests/ layout. Derive language, build command, test command, and conventions; carry them into every route. A plan, path, or test command that does not match the detected stack is a recon failure. For large governed repos (SDK, runtime, framework), detect contribution gates (API review, ref-assembly updates, changelog, breaking-change policy) and route public-API work through those gates: land an API proposal and maintainer review before writing the implementation.

Issue already has an in-flight blocking PR. Check for one before routing an autoplan <issue-url> request into a fresh implementation. If an open PR already carries a closing keyword for the issue, do not treat "avoid duplicating that work" and "resolve the issue" as the same goal; they diverge whenever the PR bundles the requested scope with unrelated scope that has not cleared review. Do not infer that divergence from an advisory scope- or size-related label alone (a needs-split-style tag): such a label is routinely assigned purely from commit count or file count, unrelated to whether the PR's content is actually separable, and a long, cohesive PR can carry it too. Before trusting one, check what actually assigns it in the target repository (its CI workflow or label-automation config), not what its name suggests. Forking a PR on the label's presence alone risks creating a duplicate implementation instead of extracting anything, so treat any such label only as a prompt to open the diff and review state, never as evidence on its own. Confirm from the actual diff and review comments that the issue's scope sits in its own reviewed, extractable commits before acting; when it does, extract that slice into its own minimal, mergeable PR rather than filing a follow-up issue and reporting the parent issue as handled while it stays open with no merged artifact. (Learned from the rjmurillo/ai-agents repository's issue #5198, 2026-08-25, where needs-split is assigned purely from commit count and proves nothing about scope; an earlier version of this rule hardcoded that repository's label semantics and pointed plugin consumers at a test file that does not ship with this skill. Also from the same issue: two independently-extracted slices of the same blocking PR can race each other and one PR merging first does not retroactively make the other's extraction wrong, only redundant for the scope both cover; check what the winner actually shipped before re-deriving or discarding the loser's independent findings.)

Phase 1: Classify

Answer two questions before you route. The Phase 0 recon reads come first; this step selects the pipeline, it does not forbid those reads.

Intent family. Match the request against the routing table below. When two families match, prefer the more specific row (a failing CI check on a PR is Session-protocol CI failure, not PR ops).

Size. Pick the smallest honest tier:

When unsure between tiers, start one tier down and escalate on contact with evidence (failing tests, widening diff), not on speculation.

Phase 2: Route

The user naming a skill or command bypasses this table entirely. User Sovereignty wins over any row.

Router boundary (ADR-078). Autoplan is the outer front-door router at the skill layer. It classifies any request that names no skill and routes it to one destination: a skill, a lifecycle command, or an agent chain. When a request is multi-domain or multi-agent execution, autoplan hands off to orchestrator (last row above). Orchestrator is one of the destinations autoplan routes to, not a peer: it owns multi-agent coordination, handoff management, and synthesis, and it never routes back to autoplan. Rule: autoplan routes; orchestrator coordinates specialists.

Phase 3: Execute with defaults

Apply these without asking. Log each application for the final gate.

1. Completeness. Fix every case the bug applies to, not only the reported one. Tests cover positive, negative, and edge in the same change.
2. Run the checks. Tests, lint, and type checks always run before a commit claims completion. Never ask "should I run the tests?".
3. DRY at the knowledge level. Reuse the existing helper, skill, or script before writing a sibling.
4. Bias to action. Internal and reversible: act. Flag what you assumed in the final gate instead of pausing mid-run.
5. Mirrors and gates. Honor repo obligations without prompting: sync generated mirrors, update the per-issue handoff when needed, and keep commits atomic. Session log creation is discontinued.

Classify every decision the run surfaces; never promote silently.

The Sovereignty row is the AGENTS.md Ask First list plus the Autonomy Guardrail. When a Sovereignty decision blocks the whole run, present 2 to 3 options with trade-offs per the Confusion Protocol and wait.

Phase 4: Final gate

Every /autoplan run ends with one summary block, not a narration stream:

1. Route taken and why (one line).
2. Auto-decided items, Mechanical count plus each Taste decision with its one-line rationale.
3. Open Sovereignty questions, if any, with options.
4. Evidence: tests run and their counts, gates passed, artifacts produced.

Verification

A routed run is complete when every box checks:

• The request was classified (intent family and size tier named).
• The route was one table row, a lifecycle chain, or the orchestrator fallback, and it was stated in the final gate.
• Every Mechanical default that fired is counted in the final gate.
• Every Taste decision appears in the final gate with a rationale.
• No Sovereignty decision was auto-decided.
• Evidence (test counts, gate results) is present in the final gate.

Anti-Patterns

• Routing everything to the orchestrator. The fallback row is for the long tail, not a substitute for classification. Two orchestrator fallbacks in a row on classifiable requests means the table needs a row, not more fallback.
• Asking mechanical questions. "Should I run the tests?" is never a question. If one defensible answer exists, act.
• Silent sovereignty. Auto-deciding architecture, ADRs, breaking changes, or security posture because the run had momentum. Stop and ask.
• Narration instead of a gate. Streaming every micro-decision as chat defeats the point; batch them into the Phase 4 summary.

Extension Points

• New routing row. When a new skill lands and requests start missing the table, add one row (intent, route) here and mirror the change in the CLAUDE.md Skill routing section until that section delegates here.
• Tier signals. Size-tier signals may grow project-specific entries (for example, a change that touches the shared agent templates implies Standard or above because of mirror obligations).
• Escape hatches. Route fails mid-run: fall back to Task(subagent_type="orchestrator") with the failure context rather than retrying the same route blind. Two consecutive routing misses on one request: stop, ask which route the user wanted, and log the miss with the reflect skill.