tsh-orchestrating-implementation

Orchestrating Implementation

This skill is the canonical workflow owner for implementation orchestration in the lower-tier orchestrator. It selects the right flow, prepares execution context, routes delegated work, and closes quality gates without writing product code itself.

<principles> <canonical-source-of-truth> This skill is the single canonical source of truth for the implementation-orchestration workflow. Keep flow selection, planning readiness, task routing, todo protocol, execution-plan steps, and review gates here rather than duplicating them in agents or prompts. </canonical-source-of-truth> <never-edits-files-directly> This skill never edits any file directly; it always delegates every file change to the owning specialist. This applies to product code, tests, infrastructure, prompts, and documentation alike — there is no file type the orchestrator may edit itself. It orchestrates delegation, validation, review, and escalation only. </never-edits-files-directly> <read-search-routing-only> The `read` and `search` tools are used only to validate routing and delegation decisions, never to research or solve the task directly. Read just enough to choose the right specialist and pass an accurate handoff; do not gather solution context the owning specialist should gather itself. </read-search-routing-only> <last-resort-stop-or-ask> If no suitable specialist agent exists for a required file change, stop and ask the user instead of self-executing the edit. Self-execution is never the fallback. </last-resort-stop-or-ask> <todo-role> The todo list is the progress-control surface. It is not a context-loss recovery mechanism and must not be treated as one. </todo-role> </principles>

Workflow

Use the checklist below and keep it synchronized with the todo list:

Implementation orchestration progress:
- [ ] Step 0: Create flow-start todos
- [ ] Step 1: Select Quick Flow or Full Flow
- [ ] Step 2: Plan the task order
- [ ] Step 3: Run the selected flow
- [ ] Step 4: Close validation and review gates

Step 0 - Start with todos

• Create todos at the start of the selected flow.
• In Quick Flow, create one todo per orchestration action.
• In Full Flow, create one todo per plan task, per review loop, per [REUSE] UI verification item, and per final gate.
• Consult the todo list before each action.
• Mark the matching todo complete immediately after the action finishes.
• If scope changes, update the execution plan first, then synchronize the todo list.

Step 1 - Assess complexity and recommend a flow

Use the following decision rules before any delegation.

Quick Flow is allowed only when every check below passes:

Check	Quick Flow pass condition
Scope width	Narrow, single-domain change with one clear implementation owner (any domain qualifies — app code, CI/CD, infra/Terraform, Kubernetes/deploy, observability, LLM prompts, E2E, etc.)
Solution clarity	Solution path is obvious from the task, approved plan, or existing context
File impact	Likely to touch 3 files or fewer
Ambiguity	No major ambiguity, contradiction, or unresolved tradeoff
Planning readiness	No missing research gap and no missing plan gap for the work being attempted
UI/Figma involvement	No Figma reference, no [REUSE] UI verification task, and no UI-verification requirement

Full Flow is required when any check below is true:

Trigger	Full Flow condition
Cross-domain work	Work spans multiple domains, multiple agents, or architectural boundaries
Ambiguity	Requirements, constraints, or acceptance criteria are incomplete or unclear
Research gap	Required context is missing or no complete *.research.md exists
Plan gap	No actionable *.plan.md exists for the current task
Larger scope	Likely to touch more than 3 files or requires phased execution
UI/Figma involvement	Any Figma involvement or UI-verification involvement exists

Hard exclusion: any Figma or UI-verification involvement immediately disqualifies Quick Flow. UI-verification involvement is broad: ANY change to rendered UI on a Figma-backed screen — layout, spacing, sizing, width/height caps, flex/grid, alignment, typography, colors, or component structure — counts as UI-verification work, even when no [REUSE] task or Figma URL is currently in hand. In that case, obtain the Figma reference (ask the user if it is missing) and run the UI verification gate. Never reclassify a visual/layout change as a plain "narrow code fix" to skip it.

Repository-documentation requests — when the work only touches repository documentation (README, CHANGELOG, in-repo /docs, or the published documentation site) — are recognized as a first-class documentation work type and routed to tsh-technical-writer via the Execution routing table, never improvised or self-executed.

Use vscode/askQuestions to recommend Quick Flow or Full Flow, give a short reason, and allow the user to override the recommendation.

If the selected execution path would proceed without an approved plan, use vscode/askQuestions to confirm the user wants no-plan execution before delegating any implementation work.

Step 2 - Plan the task order

Produce a task-order plan - the WHAT tasks in WHAT order - before the first delegation, not a binding agent + prompt call sequence.

• Do this immediately after flow selection.
• In Full Flow, do it again after plan approval and before execution starts.
• List every planned task in order, covering each delegation, review, validation checkpoint, and UI verification item.
• Do not bind an agent or prompt to each task here; the agent + prompt per task is implied at execution time by the Execution routing table.
• Share the intended flow on chat with an explicit note that it may change as execution proceeds.
• Keep the task-order plan synchronized with the todo list whenever order or scope changes.

Task-to-Owner Routing

This table is the single source of truth for selecting a delegate agent and prompt for any task, by task type or tag. Both Quick Flow and Full Flow consult this table — it is not duplicated elsewhere in this skill.

Task type or tag	Delegate to	Prompt to use	Notes
app code (plan task)	tsh-plan-implementor	tsh-implement-common-task.prompt.md	DEFAULT route in both Quick Flow and Full Flow for approved, actionable, low-risk plan seams that must be executed exactly as written
app code (complex or no-plan)	tsh-software-engineer	tsh-implement-common-task.prompt.md	EXCEPTION route for complex non-UI work, or for no-plan non-UI execution after the no-plan confirmation gate; choose GPT-5.3-Codex for medium-reasoning precision on complex work, or Gemini 3.5 Flash for fast, low-cost, large-context analysis
UI with Figma	tsh-ui-engineer	tsh-implement-ui-common-task.prompt.md	The internal prompt should be used for Figma-based UI implementation
E2E	tsh-e2e-engineer	tsh-implement-e2e.prompt.md	The internal prompt should be used for end-to-end test work
infra/Terraform	tsh-devops-engineer	tsh-implement-terraform.prompt.md	The internal prompt should be used for Terraform changes
Kubernetes/deploy	tsh-devops-engineer	`tsh-deploy-kubernetes.promp

---

Content truncated.