Agent Skills: tt-workflow-run

Tasktracker-native autonomous build-loop orchestrator. Drives a first-class `workflow_run` end-to-end — create the run (Gate 1 lifecycle completeness + Gate 2 zero-defects-in), then loop while `getNextReadyTask(projectId)` returns a slice — `setActiveTask` → record a pre-slice `scanArchitectureDrift` baseline → delegate the slice to `/tt-implement-phase` (which does the code work, registers the architecture delta in-slice, and auto-logs defects/learnings/frictions) → re-scan drift (Gate 3 architecture-followed) + re-read `getDefectStats` (Gate 2 delta) → read `getTimeSummary` for measured time + classify the slice's layer → `workflow_recordIteration` (appends an immutable by-layer measured-only projection version) → `pauseActiveTask` before any human gate — until the backlog drains, then `workflow_completeRun`. Loose coupling (brainstorm Fork B): the run is pure tasktracker data driven by a thin skill over EXISTING MCP tools + `/tt-implement-phase`; there is NO backend-callable Workflow API and `/loop` is only an optional outer cadence. The skill logs the RUN'S OWN insights too — a "no data" friction when heartbeating was off for a slice (principle #11), a learning on notable patterns, a defect for any new error above baseline. Use whenever the user wants to "run the workflow", "start an autonomous build loop", "drive the backlog to done", "dogfood the run", or "/tt-workflow-run" AND the work is tracked in tasktracker with a passable lifecycle. Triggers on "tt workflow run", "/tt-workflow-run", "start a workflow run", "run the build loop", "autonomous loop (tasktracker)", "drive the next-ready backlog". Prefer this over /tt-implement-plan when you want measured-time projection + per-slice drift/defect gates + a versioned remaining-effort series on top of phase execution; /tt-implement-plan just runs phases in order with no run entity, no projection, no per-slice gate ledger.