Harness Router
Natural language entry point to all harness skills. Classifies intent by scope/domain, confirms routing with reasoning, dispatches to the appropriate skill.
When to Use
- When the user invokes
/harness with a natural language description
- When the user is unsure which harness skill to use
- NOT when the user already knows the specific skill (e.g.,
/harness:tdd)
- NOT for non-harness tasks (general coding, file operations, etc.)
Process
Iron Law
The router confirms before dispatching. Never silently route. Always present the chosen skill, scope classification, and reasoning — then wait for confirmation.
Phase 1: CLASSIFY — Parse Intent and Search
Check for empty input. Show usage help and stop:
Usage: /harness <describe what you want to do>
Examples:
/harness fix the button spacing on the settings page
/harness we need a notification system
/harness this page is slow
/harness redesign how the sidebar filters work
/harness clean up my code
I'll figure out the right skill and process level for you.
Search the skill catalog. Call search_skills({ query: "<user's intent>" }) to get ranked matches.
Classify scope into one of four tiers:
| Scope |
Signal Words |
Description |
| quick-fix |
fix, tweak, adjust, update, change X to Y, correct |
Small targeted change, no design decisions |
| guided-change |
redesign, refactor, improve, rework |
Moderate scope, clear architecture |
| full-exploration |
build, create, add system for, we need, design |
Ambiguous scope, design decisions needed |
| diagnostic |
broken, slow, failing, debug, review, analyze |
Something broken or needs analysis |
Additional signals: single file → lower ceremony; multiple systems → higher ceremony; error messages → diagnostic.
Map scope to entry skill:
| Scope |
Primary Skill |
Alternates |
| quick-fix |
harness-tdd |
harness-refactoring if structural |
| guided-change |
harness-planning |
harness-architecture-advisor if tradeoffs involved |
| full-exploration |
harness-brainstorming |
— |
| diagnostic |
harness-debugging |
harness-code-review for reviews, harness-perf for performance |
If search_skills results strongly favor a different skill, prefer search results. Scope classification is the fallback when search is ambiguous.
Assess confidence:
- High: Top result clearly dominates and aligns with scope classification
- Low: Top 2-3 results close in score, or scope classification conflicts with search results
Phase 2: CONFIRM — Present Decision with Reasoning
High confidence:
This looks like a [scope-level] — [reasoning].
I'll route to `harness:[skill]` because [why this skill fits].
Proceed? (y / n / suggest another)
Wait for confirmation.
Low confidence (multiple candidates):
This could be a few things:
1. `harness:[skill-1]` — [description]
2. `harness:[skill-2]` — [description]
3. `harness:[skill-3]` — [description]
Which fits best? (1 / 2 / 3)
Wait for the user to choose.
User rejects: If they name a skill, confirm and dispatch. If they re-phrase, re-run CLASSIFY. Do not loop more than twice — after two misses, list all available skills and let the user pick.
Phase 3: DISPATCH — Invoke Selected Skill
- Pass original intent as context so the user does not repeat themselves.
- Invoke via
run_skill: run_skill({ skill: "<selected-skill>", path: "<project-root>" }) with original intent as argument context.
- Hand off cleanly. Once invoked, the router's job is done. The dispatched skill owns all subsequent interaction.
Examples
Quick Fix: "fix the button spacing on the settings page"
quick-fix — single component, clear target → harness-tdd
Guided Change: "redesign how the sidebar filters work"
guided-change — moderate scope, some decisions → harness-planning or harness-architecture-advisor
Full Exploration: "we need a notification system"
full-exploration — ambiguous scope, multiple approaches → harness-brainstorming
Diagnostic: "this page is slow"
diagnostic — performance symptom → harness-perf
Ambiguous: "clean up my code"
Could be refactoring, dead code, or architecture cleanup → Present candidates: harness-refactoring, harness-codebase-cleanup, harness-cleanup-dead-code
Harness Integration
search_skills — Phase 1: matches intent against the skill catalog. Returns ranked results.run_skill — Phase 3: dispatches to selected skill with project path and original intent.harness validate — Not used by the router. Validation is the dispatched skill's responsibility.
Success Criteria
- Quick-fix intents route to
harness-tdd, full-exploration to harness-brainstorming, diagnostics to appropriate diagnostic skill
- Ambiguous intents present top 2-3 candidates for user choice
- Confirmation always includes scope classification, chosen skill, and one-line reasoning
- User can reject and re-phrase or pick a different skill
- Dispatched skill receives original intent as context
search_skills MCP tool is used for matching — no custom scoring code/harness with no arguments shows usage help
Rationalizations to Reject
| Rationalization |
Reality |
| "The intent is obvious, I can skip confirmation" |
The Iron Law requires confirmation before every dispatch. Even obvious intents benefit from the user seeing scope classification. |
| "I should suggest downstream skills the dispatched skill will chain into" |
Each skill owns its own transitions. Surfacing the full chain adds noise and duplicates logic in the dispatched skill. |
| "Search results don't match well, so I'll guess based on keywords" |
If search_skills returns poor results, present top candidates and let the user choose. Guessing silently is worse than admitting ambiguity. |
| "The user rejected twice, I should keep trying" |
After two misses, list available skills and let the user pick directly. Do not loop indefinitely. |
Gates
- No silent dispatch. Every routing decision must be confirmed before the skill is invoked.
- No bypassing search_skills. The skill catalog search must be used. Do not hardcode intent-to-skill mappings.
- No downstream chaining. The router dispatches to exactly one skill. Do not pre-load or suggest follow-on skills.
- No more than two re-classification attempts. After two rejections, show the full list.
Escalation
search_skills returns no results: Skills index may be stale. Suggest harness update-skills-index to regenerate, then retry.- Intent spans multiple skills: Ask: "This involves both [skill A] and [skill B]. Which should we start with?" Do not dispatch to multiple skills.
- Intent outside harness catalog: Say so plainly: "This doesn't match any harness skill. Handle directly, or re-describe if you think a skill should apply."
1---2name: harness-router3description: Harness Router4---5# Harness Router67> Natural language entry point to all harness skills. Classifies intent by scope/domain, confirms routing with reasoning, dispatches to the appropriate skill.89## When to Use1011- When the user invokes `/harness` with a natural language description12- When the user is unsure which harness skill to use13- NOT when the user already knows the specific skill (e.g., `/harness:tdd`)14- NOT for non-harness tasks (general coding, file operations, etc.)1516## Process1718### Iron Law1920**The router confirms before dispatching.** Never silently route. Always present the chosen skill, scope classification, and reasoning — then wait for confirmation.2122---2324### Phase 1: CLASSIFY — Parse Intent and Search25261. **Check for empty input.** Show usage help and stop:2728 ```29 Usage: /harness <describe what you want to do>30 Examples:31 /harness fix the button spacing on the settings page32 /harness we need a notification system33 /harness this page is slow34 /harness redesign how the sidebar filters work35 /harness clean up my code36 I'll figure out the right skill and process level for you.37 ```38392. **Search the skill catalog.** Call `search_skills({ query: "<user's intent>" })` to get ranked matches.40413. **Classify scope** into one of four tiers:4243 | Scope | Signal Words | Description |44 | -------------------- | -------------------------------------------------- | ------------------------------------------ |45 | **quick-fix** | fix, tweak, adjust, update, change X to Y, correct | Small targeted change, no design decisions |46 | **guided-change** | redesign, refactor, improve, rework | Moderate scope, clear architecture |47 | **full-exploration** | build, create, add system for, we need, design | Ambiguous scope, design decisions needed |48 | **diagnostic** | broken, slow, failing, debug, review, analyze | Something broken or needs analysis |4950 Additional signals: single file → lower ceremony; multiple systems → higher ceremony; error messages → diagnostic.51524. **Map scope to entry skill:**5354 | Scope | Primary Skill | Alternates |55 | ---------------- | ----------------------- | ----------------------------------------------------------------- |56 | quick-fix | `harness-tdd` | `harness-refactoring` if structural |57 | guided-change | `harness-planning` | `harness-architecture-advisor` if tradeoffs involved |58 | full-exploration | `harness-brainstorming` | — |59 | diagnostic | `harness-debugging` | `harness-code-review` for reviews, `harness-perf` for performance |6061 If `search_skills` results strongly favor a different skill, prefer search results. Scope classification is the fallback when search is ambiguous.62635. **Assess confidence:**64 - **High:** Top result clearly dominates and aligns with scope classification65 - **Low:** Top 2-3 results close in score, or scope classification conflicts with search results6667---6869### Phase 2: CONFIRM — Present Decision with Reasoning7071**High confidence:**7273```74This looks like a [scope-level] — [reasoning].75I'll route to `harness:[skill]` because [why this skill fits].76Proceed? (y / n / suggest another)77```7879Wait for confirmation.8081**Low confidence (multiple candidates):**8283```84This could be a few things:851. `harness:[skill-1]` — [description]862. `harness:[skill-2]` — [description]873. `harness:[skill-3]` — [description]88Which fits best? (1 / 2 / 3)89```9091Wait for the user to choose.9293**User rejects:** If they name a skill, confirm and dispatch. If they re-phrase, re-run CLASSIFY. Do not loop more than twice — after two misses, list all available skills and let the user pick.9495---9697### Phase 3: DISPATCH — Invoke Selected Skill98991. **Pass original intent as context** so the user does not repeat themselves.1002. **Invoke via `run_skill`:** `run_skill({ skill: "<selected-skill>", path: "<project-root>" })` with original intent as argument context.1013. **Hand off cleanly.** Once invoked, the router's job is done. The dispatched skill owns all subsequent interaction.102103---104105## Examples106107**Quick Fix:** "fix the button spacing on the settings page"108quick-fix — single component, clear target → `harness-tdd`109110**Guided Change:** "redesign how the sidebar filters work"111guided-change — moderate scope, some decisions → `harness-planning` or `harness-architecture-advisor`112113**Full Exploration:** "we need a notification system"114full-exploration — ambiguous scope, multiple approaches → `harness-brainstorming`115116**Diagnostic:** "this page is slow"117diagnostic — performance symptom → `harness-perf`118119**Ambiguous:** "clean up my code"120Could be refactoring, dead code, or architecture cleanup → Present candidates: `harness-refactoring`, `harness-codebase-cleanup`, `harness-cleanup-dead-code`121122## Harness Integration123124- **`search_skills`** — Phase 1: matches intent against the skill catalog. Returns ranked results.125- **`run_skill`** — Phase 3: dispatches to selected skill with project path and original intent.126- **`harness validate`** — Not used by the router. Validation is the dispatched skill's responsibility.127128## Success Criteria129130- Quick-fix intents route to `harness-tdd`, full-exploration to `harness-brainstorming`, diagnostics to appropriate diagnostic skill131- Ambiguous intents present top 2-3 candidates for user choice132- Confirmation always includes scope classification, chosen skill, and one-line reasoning133- User can reject and re-phrase or pick a different skill134- Dispatched skill receives original intent as context135- `search_skills` MCP tool is used for matching — no custom scoring code136- `/harness` with no arguments shows usage help137138## Rationalizations to Reject139140| Rationalization | Reality |141| ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |142| "The intent is obvious, I can skip confirmation" | The Iron Law requires confirmation before every dispatch. Even obvious intents benefit from the user seeing scope classification. |143| "I should suggest downstream skills the dispatched skill will chain into" | Each skill owns its own transitions. Surfacing the full chain adds noise and duplicates logic in the dispatched skill. |144| "Search results don't match well, so I'll guess based on keywords" | If `search_skills` returns poor results, present top candidates and let the user choose. Guessing silently is worse than admitting ambiguity. |145| "The user rejected twice, I should keep trying" | After two misses, list available skills and let the user pick directly. Do not loop indefinitely. |146147## Gates148149- **No silent dispatch.** Every routing decision must be confirmed before the skill is invoked.150- **No bypassing search_skills.** The skill catalog search must be used. Do not hardcode intent-to-skill mappings.151- **No downstream chaining.** The router dispatches to exactly one skill. Do not pre-load or suggest follow-on skills.152- **No more than two re-classification attempts.** After two rejections, show the full list.153154## Escalation155156- **`search_skills` returns no results:** Skills index may be stale. Suggest `harness update-skills-index` to regenerate, then retry.157- **Intent spans multiple skills:** Ask: "This involves both [skill A] and [skill B]. Which should we start with?" Do not dispatch to multiple skills.158- **Intent outside harness catalog:** Say so plainly: "This doesn't match any harness skill. Handle directly, or re-describe if you think a skill should apply."
Intense-Visions