Orchestrating Coding Tasks

Markdown
---
name: orchestrating-coding-tasks
description: Routes coding tasks to the minimal sufficient set of specialist skills (architecture, ui-ux-design, frontend, backend-data, debugging, performance, security, testing-quality) based on actual request scope and project evidence, sequences their execution, adapts when evidence changes the diagnosis, and applies verification proportional to risk. Use when handling any coding task—bug fix, feature, refactor, question, or investigation—in a project with existing code, to decide what to inspect, which specialists apply, and what counts as done.
---

# Orchestrating Coding Tasks

Routes work to specialists based on evidence, not keywords. Scales effort to task risk. Never claims invocation or verification that did not happen.

Selection is evidence-based. "Mentions UI" does not mean activate ui-ux-design; "touches a file" does not mean activate its domain specialist. Activate a skill only when the task requires its specific expertise to diagnose, design, implement, or verify.

Coordination rules:

• debugging establishes what is wrong and why; it hands off a confirmed root cause to the implementation specialist(s). Never let debugging and an implementation specialist run implementation changes in parallel on competing hypotheses.
• architecture and ui-ux-design produce decisions consumed by frontend/backend-data; they precede implementation, not follow it.
• frontend and backend-data run together only when evidence confirms the change genuinely spans both (e.g., a new feature needs a new endpoint AND a new UI). Do not activate both by default for anything that "involves an API."
• security and performance are cross-cutting: they can run alongside any phase but are only activated when their specific evidence/trigger is present, not as a default precaution.
• testing-quality runs last, scoped to what changed plus directly affected integration points — not the full suite by default.

Progress:
- [ ] 1. Parse request: goal, explicit constraints, authorized scope
- [ ] 2. Inspect proportionate evidence (files, errors, logs, git history, tests — only what's needed)
- [ ] 3. Classify: domain(s), complexity, risk level
- [ ] 4. Select specialists: necessary / optional / explicitly excluded, with reasons
- [ ] 5. Sequence: dependencies and hand-off order
- [ ] 6. Check specialist accessibility (see Cross-Platform Behavior)
- [ ] 7. Execute within scope; re-route immediately if evidence contradicts current diagnosis
- [ ] 8. Verify proportionate to risk; report what was actually checked vs. assumed

Scaling rule: Steps 2–5 should take seconds for a trivial, unambiguous, low-risk task. They expand only when complexity, ambiguity, cross-domain impact, or risk is actually present. Do not pad simple tasks with speculative investigation or unnecessary specialist activation to appear thorough.

• If the host platform supports invoking specialist skills (e.g., a skill-loading or sub-agent mechanism), use that actual mechanism and confirm what was loaded.
• If invocation isn't supported, check whether the specialist's full instructions are genuinely reachable in context (e.g., bundled file content actually available to read). If yes, read and apply them.
• If the specialist's instructions are not accessible by any real mechanism, do not claim it was invoked or that its full procedure was followed. State plainly that only general reasoning was used for that domain, and flag this as a limitation when it could materially affect correctness (e.g., security-sensitive work without the security specialist's actual checklist).
• A skill file being a plain portable file does not mean the current runtime can load it. Verify actual accessibility; never assume compatibility.

Routing is a hypothesis, not a commitment. When new evidence contradicts the current diagnosis or required expertise:

1. Stop further changes under the old hypothesis immediately — don't finish a speculative fix "since it's already started."
2. Update the diagnosis explicitly, stating what evidence changed it.
3. Re-select specialists: deactivate ones no longer justified, activate newly justified ones.
4. Resume execution under the corrected routing, then verify the integrated result (not just the new piece in isolation).

Example trigger: a "simple frontend bug" traced to a backend API returning a stale/incorrect data contract → drop speculative frontend-only changes, activate backend-data (and keep debugging as the basis), then verify both the fix and that the frontend correctly consumes the corrected contract.

Always report: what was actually run/verified, what passed/failed, and what could not be verified (e.g., no test runner available) — never imply success without a basis.

1. Changing a button's color in an existing UI

• Selected: none of the eight specialists necessarily required; if the color is specified in design tokens/system, at most frontend for the implementation.
• Excluded: ui-ux-design (no design decision — color is already specified), architecture, debugging, performance, security, backend-data, testing-quality.
• Reasoning: no structural, behavioral, or server impact; a mechanical style edit.
• Order: implement directly.
• Completion: visual confirmation of the color change; confirm no unrelated CSS/markup changes.

2. Fixing a bug whose actual cause is initially unknown

• Selected: debugging first, mandatory.
• Excluded upfront: implementation specialists (frontend/backend-data) until root cause is confirmed; architecture, security, performance only if evidence later implicates them.
• Reasoning: implementing a fix before confirming cause risks a speculative, wrong patch.
• Order: debugging → (re-route to correct domain specialist based on confirmed cause) → testing-quality for the affected area.
• Completion: reproduce before/after if possible, confirm regression coverage for the specific defect.

3. Implementing a persistent feature involving both a frontend and an API

• Selected: architecture (brief, if it introduces new structure/data flow) → backend-data (schema/endpoint/persistence) → frontend (consuming UI) → testing-quality (integration).
• Excluded: ui-ux-design unless new UX/layout decisions are actually needed (not just wiring existing UI to new data); debugging (cause isn't the issue — this is new work); performance/security unless the feature touches sensitive data or known hot paths.
• Reasoning: genuinely cross-domain; sequencing matters because frontend depends on the finalized data contract.
• Order: design → backend-data → frontend → testing-quality.
• Completion: integration test across the full round-trip (create/update/persist/display), plus relevant unit tests on each side.

4. Investigating a performance complaint without an established bottleneck

• Selected: debugging/investigation first to locate the bottleneck using profiling, logs, timing evidence; performance activated once a concrete bottleneck is identified.
• Excluded: jumping straight to performance optimizations without evidence; architecture unless the bottleneck turns out to be structural; frontend/backend-data activated only for whichever layer the evidence implicates.
• Reasoning: "it's slow" is not a diagnosis; optimizing blind risks wasted or harmful changes.
• Order: investigate → confirm bottleneck → activate performance (+ relevant domain specialist) → implement → re-measure.
• Completion: quantified before/after measurement where possible; otherwise explicitly note measurement is unverified.

5. Fixing an authentication or authorization vulnerability

• Selected: security mandatory; backend-data typically (auth logic usually server-side); debugging if the vulnerability's exact mechanism isn't yet confirmed; testing-quality for verification.
• Excluded: ui-ux-design, performance, architecture unless the vulnerability stems from a structural flaw (e.g., trust boundary design).
• Reasoning: security-risk work requires explicit risk-closure verification, not just "it works now."
• Order: confirm vulnerability mechanism → security + backend-data fix → testing-quality with explicit negative/ab