# Tt Workflow Build

> tt-workflow-build

- Skill: `mhylle/tt-workflow-build` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add mhylle/tt-workflow-build`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mhylle/tt-workflow-build/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: mhylle (https://skillmd.com/u/mhylle)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/mhylle/tt-workflow-build

---


# tt-workflow-build

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 a dynamic `Workflow`** that builds the project — 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 use the Workflow engine. Get a project → start the workflow → 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 `/tt-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 workflow consumes); at minimum `tasktracker_createProject`.

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

## Step 2 — Start the Workflow

Invoke the **built-in `Workflow` tool** directly. It is a top-level main-loop tool like `Bash`/`Edit`/`Agent` — **NOT an MCP tool**, so it NEVER appears in `ToolSearch`; never look for it there and never read a ToolSearch miss as "unavailable" (see the contract's "Tool availability" section). This skill runs in `context: fork` (the main loop), where the tool is always present — just call it.

The workflow builds the project: fan out the ready, mutually-independent build slices as parallel worktree agents, integrate + gate + track each in the parent, loop waves until done. **Read `references/build-workflow-protocol.md` (and the contract it points to) and follow it when writing the workflow script** — but treat it as construction detail, not a decision gate that can stop you.

## Non-negotiables

- **Get a project, then start the workflow — autonomously.** Never ask the user to pick a mode, never hand back, never abandon to `/tt-implement-plan` / `/tt-workflow-run`.
- **The `Workflow` tool is the engine for ALL parallel work**, engaged as early as the dependency graph allows. 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 running the workflow (it makes the next parallel wave possible). That is **not** a fallback. **No fallback to a non-workflow method for work that could run in parallel.**
- **Parent owns every tasktracker write** (in-run agents share one MCP identity and cannot write — contract R1); agents return schema results only.
- **Built-ins are never in `ToolSearch`** — a miss is meaningless; just invoke `Workflow`/`Agent`.

## References
- `references/build-workflow-protocol.md` — how the parent constructs the build workflow (slice-result schema, 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 + triggering** (built-ins, not ToolSearch), parent-owns-writes, worktree isolation + integration intents (R6), no wall-clock/RNG in scripts, quality gates, prod safety, canonical skeleton. **Read it before building the workflow.**