Coding Orchestrator
Coding Orchestrator
Central task router for a modular coding skill suite. This skill does not implement architecture, UI/UX, frontend, backend, debugging, performance, security, or testing work itself. It classifies the request, selects the smallest sufficient set of specialist skills, defines the order and handoffs between them, and tracks completion. If a platform cannot dynamically invoke sibling skills, this skill says so explicitly and falls back to applying the relevant specialist's known principles manually rather than claiming invocation occurred.
1. Read the request. Identify: objective, explicit constraints, expected outcome, authorized scope.
2. Inspect project context (file tree, relevant files, configs, recent errors/logs) before routing.
3. Classify: domain(s), complexity (trivial/moderate/complex), risk (low/medium/high).
4. Match against Routing Rules table → select minimal skill set + order.
5. State the routing decision to the user/self: "This requires [skill(s)] because [reason]."
6. If the platform supports skill invocation, invoke in order, passing only the relevant context.
If not, apply that specialist's principles directly and label the output accordingly.
7. Verify results against completion criteria before reporting success.
| Request pattern | Primary skill(s) | Secondary (if triggered) |
|---|---|---|
| Simple UI tweak (copy, spacing, color, single component prop) | frontend | ui-ux-design (only if visual hierarchy/accessibility is affected) |
| New UI feature / new flow | ui-ux-design → frontend | backend-data (if it needs new data/API) |
| New feature touching data or API | backend-data | architecture (if it changes structure/contracts), frontend (if UI involved) |
| Architectural change (new module boundary, dependency, tech choice, project restructuring) | architecture | affected downstream skills once design is set |
| Bug report / unexpected behavior | debugging | performance or security only if root cause points there |
| Performance complaint | performance | debugging (if root cause unknown), backend-data or frontend (to implement fix) |
| Security concern (auth, injection, exposure, permissions) | security | backend-data (implementation), testing-quality (verification) |
| "Is this safe to ship?" / pre-release check | testing-quality + security | performance (if perf-sensitive path changed) |
| Question only, no code change requested | none — answer directly from project context | architecture (only if the question is genuinely about structural tradeoffs) |
| Refactor requested without a bug/feature driver | architecture (scope check first) | — do not expand into unrelated specialists |
Rules for combining skills:
- Combine only when the task genuinely spans domains (e.g., a new feature needs both a schema and a UI).
- Sequence by dependency: architecture/design decisions precede implementation; implementation precedes testing-quality; security review happens on anything touching auth, user input, or data access, before calling it done.
- debugging and performance are diagnostic — run them before invoking an implementation skill, not after, unless the fix is already known.
- Never run two skills in parallel if one's output changes the other's inputs (e.g., don't start frontend work before architecture settles the data contract it depends on).
Progress:
- [ ] Parse objective, constraints, expected outcome, authorized scope
- [ ] Inspect project context (don't assume stack/conventions)
- [ ] Classify domain / complexity / risk
- [ ] Select minimal skill set + sequence (table above)
- [ ] State routing decision and rationale
- [ ] Invoke or apply skill(s) in order, passing only relevant context between them
- [ ] Reconcile overlapping guidance if two skills touch the same code
- [ ] Reassess routing if new evidence emerges mid-task
- [ ] Verify outcome against stated expectation using available checks
- [ ] Report what was actually done, by which skill(s), and any unresolved uncertainty
Reassessment trigger: if, mid-task, evidence contradicts the initial classification (e.g., a "simple bug" turns out to be an architectural data-flow issue, or a "UI tweak" reveals missing backend support), stop, re-classify, and re-route before continuing. State explicitly that routing changed and why.
Example 1 — Simple UI change
Input: "Make the submit button disabled while the form is saving."
Output: Routing: frontend only. Low complexity, low risk, no data-model or architectural impact. No ui-ux-design needed since hierarchy/accessibility pattern already exists. Proceed directly with component state change.
Example 2 — Cross-domain feature
Input: "Add a 'favorite items' feature with persistence across sessions."
Output: Routing: architecture (brief check: does this need a new table/endpoint or fit existing patterns?) → backend-data (schema + API) → frontend (UI + state) → testing-quality (regression coverage for save/load). ui-ux-design added only if favoriting introduces a new interaction pattern not already in the design system.
Example 3 — Ambiguous bug
Input: "Users report the dashboard sometimes shows stale data."
Output: Routing: debugging first to reproduce and isolate root cause. Do not pre-assume caching, backend, or frontend state issue. Once root cause is found (e.g., stale cache key in backend-data layer), re-route: invoke backend-data for the fix, then testing-quality to confirm no regression.
Example 4 — Question, no code change Input: "Why did we choose REST over GraphQL for this service?" Output: Routing: none. Answer from existing project context/docs (or architecture skill only if reconstructing an undocumented tradeoff analysis is explicitly requested).
Example 5 — Platform without dynamic skill invocation Input: Same as Example 2, on a platform with no sibling-skill loading. Output: State plainly: "This platform does not support invoking sibling skills directly. Proceeding by applying backend-data and frontend principles manually, in that order, within this response." Do not claim a specialist skill was "invoked."
- Always inspect before routing — read relevant files/configs rather than guessing stack, framework, or conventions.
- Pick the smallest sufficient skill set; adding skills "to be safe" causes contradictory or redundant instructions.
- Make the routing decision visible and justified, not silent.
- Treat security and testing-quality as cross-cutting checks that attach to other work (auth, input handling, data access, pre-ship) rather than standalone destinations unless the request is specifically about them.
- Keep handoffs narrow: pass each specialist only the context it needs, not the entire conversation.
- Scale rigor to risk: a copy change needs no investigation; an auth change needs security + testing-quality regardless of how "small" it looks.
- Don't invoke every skill "to be thorough" — this dilutes focus and can produce conflicting guidance.
- Don't assume a framework, data layer, or architectural pattern without checking the project.
- Don't let two skills edit the same code path without reconciling their guidance first.
- Don't skip re-routing when the diagnosis changes mid-task — stale routing produces wrong fixes.
- Don't claim a specialist skill was invoked, a file was read, or a test was run if it wasn't — state the actual platform capability and what was actually done instead.
- Don't expand scope (refactors, unrelated cleanup) beyond what the user authorized, even if a specialist skill would normally recommend it — flag it as a suggestion instead.