tsh-orchestrating-implementation

Orchestrating Implementation

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

<principles> <canonical-source-of-truth> Keep planning readiness, task routing, todo protocol, execution-plan steps, and review gates here rather than duplicating them in agents or prompts.

This skill is the single owner of route-varying authorization bases, eligibility, and escalation. Execution owners carry the common invariant inline in their own <human-approval-precondition> block; use that inline precondition as the source of truth for the common invariant rather than restating the predicate here as an owners' source of truth. </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: Establish Full Flow and assess planning readiness
- [ ] Step 2: Plan the task order
- [ ] Step 3: Run Full Flow
- [ ] Step 4: Close validation and review gates

Step 0 - Start with todos

• Create todos at the start of Full Flow.
• Create one todo per plan task, per review event, 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 - Establish Full Flow and assess planning readiness

Full Flow is the only implementation-orchestration route for this skill. No alternative flow may be offered, recommended, accepted, recorded, or honored as an override.

Use the following rules before any delegation. Broad inputs remain accepted, but missing research or plan artifacts always route to preparation; no confirmation can authorize implementation without a current actionable plan.

UI-verification scope: 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) and those targets exist in the project — 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.

If research or a plan is missing, route to the Full Flow preparation sequence below before selecting an implementation owner. Do not offer or authorize no-plan implementation.

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 before the first delegation.
• Do it again after Human 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. Full Flow consults this table for every task — 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 for a Human-approved plan revision's actionable, low-risk plan seams that must be executed exactly as written
app code (complex)	tsh-software-engineer	tsh-implement-common-task.prompt.md	EXCEPTION route for complex non-UI work; choose Kimi K2.7 Code or GPT-5.3-Codex for medium-reasoning precision on complex work, or Gemini 3.6 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.prompt.md	The internal prompt should be used for deployment or Kubernetes work
CI/CD	tsh-devops-engineer	tsh-implement-pipeline.prompt.md	The internal prompt should be used for pipeline work
observability	tsh-devops-engineer	tsh-implement-observability.prompt.md	The internal prompt should be used for logging, metrics, or tracing work
LLM prompts	tsh-prompt-engineer	tsh-engineer-prompt.prompt.md	The internal prompt should be used for prompt-engineering tasks
documentation	tsh-technical-writer	tsh-write-documentation.prompt.md	The internal prompt should be used for repository documentation work across all targets — README, CHANGELOG, /docs, and the published documentation site when those targets exist in the project
[REUSE] UI verification	tsh-ui-reviewer	tsh-review-ui.prompt.md	Review each UI item individually; do not batch
[REUSE] other	per the task definition	—	Execute as defined in the task definition; delegate to the matching implementer only when new product code is required

---

Content truncated.