--- name: sst-skill-router description: | Per-task router that picks which sub-skills to invoke for a complex multi-step request, sequences them, passes outputs between them, and synthesizes a final result. Discovers available skills via the harness's skill registry; chooses by description, not by hardcoded names. Always ends with an editorial pass on the synthesized output. Distinct from sst-manager (cron-based, multi-project, periodic ops loop) and from sst-chain-driver (single-session driver of one multi-iter chain run); this one runs INSIDE a single user request. user-invocable: true version: 1.1.1 model-floor: sonnet effort-floor: high argument-hint: [high-level task or objective] --- # Skill router Given a complex task, this skill plans the sub-tasks, picks skills to handle each, runs them in sequence, and synthesizes the results. The user calls this once; the skill drives everything to completion. ## Project contract - **Output dir**: `/data/sst-skill-router/` for the synthesized final result. Files as `_.md`. - **Required skills**: discovered dynamically from the harness's skill registry. The router picks based on each skill's `description` field. The chain ALWAYS ends with `sst-editorial-pass` (or the project's proprietary editorial counterpart) for the final synthesis pass. - **Tools required**: harness's `Skill` tool (to invoke sub-skills); `Read` (to load intermediate outputs); `Write` (to save the final synthesis). ## Operating principles - **Plan before invoking.** Before calling any sub-skill, write a plan: what's the task, what sub-tasks does it decompose into, which skill handles each, in what order, with what inputs/outputs. The plan is your contract with yourself; deviations from it require a re-plan, not a quiet ad-hoc detour. - **Pick by description, not by name.** Don't hardcode skill names. Walk the harness's available skills, read each description, choose by fit. This keeps the router portable across projects with different proprietary skill sets. - **Pass concrete inputs.** When you call a sub-skill, give it the actual data it needs (text, file paths, structured inputs), not "the previous result." Keep the contract explicit. - **Always close with sst-editorial-pass.** The final user-facing output goes through `sst-editorial-pass` (or its proprietary counterpart). No exceptions: even short answers benefit from the scope/clarity check. - **Iterate when results are weak.** If a sub-skill returned a thin or off-target result, revise your instructions and re-invoke. Don't accept "close enough" on the first pass and let it propagate downstream. ## Process ### 1. Read the task Restate the task in your own words. Identify: - **Top-level deliverable** (a research report, an edited draft, a published post, a ranked shortlist, ...). - **Implicit sub-deliverables** (does the report require new research, or does it work from existing inputs? does the post need fact-checking? does the shortlist need new candidates first?). - **Constraints** (length target, audience, tone, must-include / must-not-include, deadlines). If anything is genuinely ambiguous and would produce wildly different plans, ask once before planning. ### 2. Plan the chain Write a plan in this shape (in your scratchpad; save to `/data/sst-skill-router/_.plan.md`): ```markdown # Plan — **Task**: **Final deliverable**: ## Sub-tasks 1. — skill: `` — input: — expected output: 2. — skill: `` — input: — expected output: 3. ... N. Synthesis + sst-editorial-pass — input: — expected output: ``` ### 3. Discover available skills Read the harness's skill registry (the list it surfaces to you on every invocation). Match each sub-task to the best-fit skill by description. Prefer: - **Proprietary counterparts** when present in the project's `.claude/skills/` (they hold project-specific facts). - **Transferable skills** otherwise. If the project has both `-X` and `X` available, use `-X`. The proprietary's `transferable: X` frontmatter signals which transferable it inherits, but you don't need to chase that — just pick the most-specific available implementation. ### 4. Execute the chain For each step in your plan: 1. Invoke the chosen skill with the prepared input. 2. Read the skill's output (most skills report a file path as the final line; `Read` it). 3. Verify the output meets the "expected output" you wrote in the plan. If it doesn't: - For minor shortfalls: revise the instructions and re-invoke the same skill (max 2 retries). - For fundamental shortfalls: re-plan from this step. Don't pretend the bad output is fine. 4. Pass the verified output as input to the next step. If a step fails twice in a row, surface the failure to the user with the plan's current state. Don't loop indefinitely. ### 5. Final synthesis + editorial pass After all sub-skills have completed: 1. Synthesize the outputs into the final deliverable's shape (report, draft, list, etc.). This is your direct work, not a sub-skill call. 2. Invoke `sst-editorial-pass` (or the proprietary editorial counterpart) on the synthesis. 3. Save the sst-editorial-pass result to `/data/sst-skill-router/_.md`. ### 6. Report ``` Final deliverable: Plan: Sub-skills run: Total sub-skill invocations: ``` ## Hard rules - **Never invoke yourself recursively.** This skill is the router; it doesn't call other sst-skill-router instances. - **Never invoke `sst-manager` (the ops-loop skill) or `sst-chain-driver` (the multi-iter session driver).** Different concepts; both run outside a single user request. - **Never skip the sst-editorial-pass at the end.** Even when the synthesis feels solid, the pass catches scope drift and unverified claims. - **Never pad the final deliverable to look thorough.** Match the user's request, not your sense of completeness. - **If a sub-skill is missing for a sub-task, ask the user how to proceed.** Don't fake it by inlining the work: that defeats the routing pattern. ## Naming history This skill was originally shipped as `sst-agent-orchestrator` and renamed to `sst-skill-router` in framework Phase 15 to remove the three-way collision between this skill, `sst-chain-driver` (formerly `sst-orchestrator`), and the looser everyday "orchestrator" usage. Behavior is unchanged. Output dir name updated from `data/sst-agent-orchestrator/` to `data/sst-skill-router/`.