route_skill

This skill analyzes user requests and routes tasks to oneoff-spec, oneoff-vibe, journal-only, or orchestrator workflows based on complexity.

TypeScript

0

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill matthew-plusprogramming/monorepo --skill route

SKILL.md25.8 KB

Overview

This skill analyzes an incoming request and chooses the right workflow based on complexity, scope, and risk. It defaults to creating lightweight specs (oneoff-spec) unless the change is truly trivial, explicitly overridden, or requires multi-workstream orchestration. The decision includes delegation suggestions, estimated scope, and a clear next action.

How this skill works

The skill inspects the request, checks for any active/incomplete work, and scans the codebase to estimate impacted files and coupling. It applies a set of heuristics (trivial, standard/spec, large/orchestrator, refactor, journal-only), evaluates delegation opportunities, and emits a routing decision with rationale and next steps. Decisions for non-trivial work are persisted to session state and may initialize spec tracking.

When to use it

Routing new change requests to the proper workflow
Deciding whether to skip or require a spec for a task
Determining when to run a multi-workstream orchestrator vs single-workstream work
Choosing refactor workflow for code-quality-only changes
Documenting findings or hotfix rationales with journal-only entries

Best practices

Default to oneoff-spec when unclear — specs are cheap and reduce rework
Use oneoff-vibe only for truly trivial edits or when the user explicitly requests it
Always run the investigation step before orchestrating multi-workstream changes
Prefer delegation: split independent components into parallel subagents where safe
Persist routing decisions for non-trivial work so sessions can be resumed

Example use cases

Fixing a typo in README → oneoff-vibe (truly trivial)
Adding a new API endpoint that touches controller, service, and tests → oneoff-spec with PM interview first
Coordinating a feature that spans services and infra changes → orchestrator with MasterSpec and mandatory /investigate
Refactoring authentication module for maintainability (no behavior changes) → refactor workflow with tests-before-and-after
Recording the root cause and rationale after a hotfix → journal-only investigation or hotfix journal

FAQ

When uncertain, default to oneoff-spec — avoid under-specifying work that may hide edge cases.

Can the user force a quick fix without a spec?

Yes. Honor explicit requests like “just do it” or “skip the spec” by routing to oneoff-vibe and noting the override in the rationale.

When is orchestrator mandatory?

Use orchestrator when the change impacts multiple services, layers, or workstreams (5+ files across subsystems) or when parallel work and dependency orchestration are required; /investigate is mandatory first.

When should I choose journal-only?

Choose journal-only for documenting completed investigations, hotfix rationale, or decisions that don’t need acceptance criteria or planning.