mhylle/skills/tt-workflow-build
skills/tt-workflow-build/SKILL.md
--- name: tt-workflow-build description: Tasktracker-native trigger for a PARALLEL build via the Claude Code Workflow tool. Thin by design — it does two things, then drives to done: (1) ensure a tasktracker project exists (use the existing one, or create one), then (2) start a dynamic `Workflow` that builds it, tracking the work in tasktracker and using the build + verify skills. It does NOT analyze parallelism up front, ask the user to choose a mode, hand back, or fall back to a sequential skil
$ install --global
skillsauthnpx skillsauth add mhylle/claude-skills-collection skills/tt-workflow-buildInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 5, 2026, 6:26 AM166.9s1 file scanned
SKILL.md
- name:
- tt-workflow-build
- description:
- Tasktracker-native trigger for a PARALLEL build via the Claude Code Workflow tool. Thin by design — it does two things, then drives to done: (1) ensure a tasktracker project exists (use the existing one, or create one), then (2) start a dynamic `Workflow` that builds it, tracking the work in tasktracker and using the build + verify skills. It does NOT analyze parallelism up front, ask the user to choose a mode, hand back, or fall back to a sequential skill — get a project, start the workflow, drive autonomously to done (pausing only at real human gates like deploy). Use when the user wants a build driven by the parallel Workflow engine — typically after /tt-brainstorm + /tt-create-plan, or standalone. Triggers on "/tt-workflow-build", "build this with a workflow", "parallel build (tasktracker)", "fan out the build". Prefer /tt-implement-plan or /tt-workflow-run only when the WHOLE job is irreducibly sequential; prefer /tt-workflow-audit for read-only analysis.
- context:
- fork
- user-invocable:
- true
- argument-hint:
- [project-slug-or-id]
tt-workflow-build
A thin trigger, not a hand-rolled orchestrator. When invoked, do exactly two things — then drive to done:
- Ensure a tasktracker project exists.
- Start a dynamic
Workflowthat 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-hintslug/id, the session's active project, or a clear match fromtasktracker_listProjects— use it. (Normally/tt-brainstorm → /tt-create-planalready 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 minimumtasktracker_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
Workflowtool 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-timegit 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 invokeWorkflow/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 sharedtt-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.
Related Skills
mhylle/skills/grumpy-reviewer
tools
VerifiedTrustedCommunity
--- name: grumpy-reviewer description: A single grumpy, nitpicky structural code reviewer that runs as an isolated subagent and treats the code as third-party work submitted by a junior programmer for validation. It cares about exactly one thing — maintainability — judged through separation of concerns, service-oriented design, helper-method extraction, small files, and the rule of 7 (as any grouping nears 7 members, it pushes for sub-groupings). It is deliberately kept OUT of the implementation
14SKILL.mdUpdated Jun 5, 2026
mhylle/skills/tt-workflow-run
development
VerifiedTrustedCommunity
--- name: tt-workflow-run description: 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/fr
14SKILL.mdUpdated May 31, 2026
mhylle/tt-workflow-audit
tools
VerifiedTrustedCommunity
Tasktracker-native project-wide parallel audit using the Claude Code Workflow tool (dynamic workflows). Partitions a repo / backlog / architecture and fans out read-only agents (one per partition) that return schema-checked findings, aggregates them into a deduplicated, ranked risk register, and OPTIONALLY writes fixes back as tasks under a Bug Fix phase — with all tasktracker writes done by the PARENT, never the parallel agents (single global active-task pointer). Journaled and resumable, so a rate-limit or crash mid-audit resumes without re-running completed partitions. Use for large, embarrassingly-parallel, read/analyze-heavy jobs where each unit is self-contained and the output aggregates — audit every file/component for risk, find all architecture drift (scanArchitectureDrift) or duplicate tasks (detectDuplicates/auditDuplicates), per-file tech-debt sweep, test-coverage or security-surface scan across a whole project. Triggers on "/tt-workflow-audit", "audit the whole repo", "parallel audit", "scan every file/component", "find all drift/duplicates", "tech-debt sweep (tasktracker)", or any whole-project analyze-at-scale request inside a session with a tasktracker project. Prefer this over /codebase-audit or /code-quality-audit when the project is tracked in tasktracker AND you want the findings written back as tasks; prefer it over team-* modes when the units don't need to negotiate live (they just report).
14SKILL.mdUpdated May 30, 2026
mhylle/tt-implement-plan
tools
VerifiedTrustedCommunity
Tasktracker-native plan orchestrator. Drives execution of a plan whose phases are stored as tasktracker phase tasks (NOT a docs/plans/*.md file). Honours active-task discipline (setActiveTask before every artifact-producing call, pauseActiveTask before user waits, clearActiveTask on phase done), respects the locked phase body (design notes go to sub-tasks, never to the phase description), logs defects/learnings/frictions through tasktracker insights as they surface, and delegates the actual implementation to /implement-phase. Use whenever the user wants to "implement the plan", "run the plan", or "work through the phases" AND the plan was created with /tt-create-plan (or otherwise lives in tasktracker). Triggers on "tt implement plan", "tt implement", "implement plan (tasktracker)", "/tt-implement-plan", "execute the tasktracker plan", or any plan-execution request inside a session that already has a tasktracker active task or project. Prefer this over the plain /implement-plan skill whenever a tasktracker MCP is available — it correctly handles the locked phase body, requirement linking, insight logging, and lifecycle gating that the file-based variant ignores.
14SKILL.mdUpdated May 27, 2026