mhylle/claude-skills-collection/tt-workflow-build

tt-workflow-build

<!-- contents: generated by tests/skill_structure.py --write; edit headings, not this block -->

Contents

• Step 1 — Ensure a project (the one hard precondition)
• Step 2 — Start the parallel build
• Non-negotiables
• References

Reference files (open one when a step points to it):

• references/build-workflow-protocol.md: Building the build workflow — construction detail
• references/workflow-tasktracker-contract.md: Workflow ↔ TaskTracker Contract

<!-- /contents -->

A thin trigger, not a hand-rolled orchestrator. When invoked, do exactly two things — then drive to done:

1. Ensure a tasktracker project exists.
2. Start the parallel build — dependency waves of worktree agents, through the Workflow tool when you have it and parallel Agent calls when you don't — tracking the work in tasktracker, using the build + verify skills.

Do NOT stall. No "is this parallel yet?", no asking the user sequential-or-parallel, no handing back, no switching to /tt-implement-plan. Invoking this skill is the decision to build in parallel. Get a project → start the build → run it to done autonomously, pausing only at genuine human gates (e.g. deploy).

Step 1 — Ensure a project (the one hard precondition)

A build needs a tasktracker project to build into and track against. We need one, so:

• If a project already exists — the argument-hint slug/id, the session's active project, or a clear match from tasktracker_listProjects — use it. (Normally /brainstorm → /tt-create-plan already produced a planned project with requirements + a phased, dependency-graphed task tree — that's the ideal input.)
• If none exists — create one. Prefer running /tt-create-plan (it yields the requirements + phased tasks the build consumes); at minimum tasktracker_createProject.

Never reach Step 2 without a project. That's the only thing this skill guarantees before starting the build.

Step 2 — Start the parallel build

Pick the engine from your tool list (the contract's "Tool availability" section):

• `Workflow` is in your tool list — declared to you directly, or among the deferred tools (load it with ToolSearch select:Workflow) → each wave is one Workflow run whose script fans the wave's slices out as worktree agents.
• It isn't — Workflow is opt-in, so this is the common case → each wave is one message holding one Agent call per slice, with subagent_type: "general-purpose" and isolation: "worktree", the same slice prompt the workflow script would send, and the same SLICE_RESULT asked for as JSON. Wait for every completion notification of the wave before integrating.

Either way the parent does the rest the same way: integrate each returned slice, gate it, track it in tasktracker, select the next wave, loop until done. Read `references/build-workflow-protocol.md` (and the contract it points to) and follow it — slice schema, slice prompt, wave construction for both engines, integration, gates — but treat it as construction detail, not a decision gate that can stop you.

Non-negotiables

• Get a project, then start the build — autonomously. Never ask the user to pick a mode, never hand back, never abandon to /tt-implement-plan / /tt-workflow-run.
• Parallel work runs in parallel, engaged as early as the dependency graph allows — through Workflow when it is in your tool list, otherwise through parallel Agent calls. A missing Workflow tool changes the engine, not the plan. The only sequential work is the irreducible bridge — the one-time git init + scaffold + first commit a fresh repo needs before any worktree can branch, or a lone dependent leaf — done inline by the parent as part of the build (it makes the next parallel wave possible). Never run ready, independent slices one after another.
• Parent owns every tasktracker write (parallel agents share one MCP identity and cannot write — contract R1); agents return schema results only.
• The tool list decides, not `ToolSearch` — a tool declared to you directly never appears in ToolSearch, so a miss there proves nothing.

References

• references/build-workflow-protocol.md — how the parent constructs the build (slice-result schema, slice prompt, the Workflow and Agent wave, git-apply integration, per-slice gates, PARTIAL/BLOCKED handling, wave loop, resume). Follow it; it is NOT a stall gate.
• references/workflow-tasktracker-contract.md — the shared tt-workflow-* contract: tool availability (check the tool list; Agent fallback when Workflow is absent), parent-owns-writes, worktree isolation + integration intents (R6), no wall-clock/RNG in scripts, quality gates, prod safety, canonical skeleton. Read it before building.