Run any Skill in Manus with one click

tt-workflow-build

Stars17

Forks1

UpdatedJune 1, 2026 at 21:21

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

mhylle

mhylle/claude-skills-collection

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

SKILL.md

readonly

name

tt-workflow-build

description

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 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.

More from this repository

same repository

design-language

mhylle/claude-skills-collection

Design and manufacture someone's OWN reusable visual design language and save it as durable files — design tokens (css/tokens.css + a W3C design-tokens.json), a DESIGN_LANGUAGE.md contract, and a living multi-page styleguide — that future sessions and other projects read to build UI in one consistent, ownable style. Use this whenever the goal is to create, define, set up, or establish a design language, design system, house style, visual identity, or brand look captured once as files and reused across many UIs or projects; to make apps stop looking templated, generic, or like every other Claude/Anthropic app (the default warm-beige + terracotta + pillowy-card look); or to get tokens plus a contract that tells Claude how to build in that style every time. It is reaction-first — it researches real references, renders live options the user reacts to, and dials each dimension (color, typography, spacing, shape, elevation, motion, imagery, components, patterns, voice) from conventional to experimental. This produc

2026-06-2717

ship-issue

mhylle/claude-skills-collection

One-command issue-to-merge pipeline orchestrator. Drives a GitHub issue through nine stages (preflight, plan, implement, review, ci, cloud_review, deploy, e2e, logs) with two human gates, persisting all run state to files so a crashed or interrupted run resumes losslessly. Triggers on "/ship-issue" with an issue number or URL. User-invoked only.

2026-06-1217

tt-implement-plan

mhylle/claude-skills-collection

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 MC

2026-06-0117

tt-implement-phase

mhylle/claude-skills-collection

Tasktracker-native per-phase executor. Runs a SINGLE phase whose scope and sub-tasks live as tasktracker phase + sub-task rows (NOT in a docs/plans/*.md file). Honours active-task discipline (setActiveTask on phase AND on each sub-task as worked), respects the locked phase body (HTTP 422 on description edit — design notes go to sub-tasks), updates sub-task status via tasktracker_updateTaskStatus as work progresses, logs defects/learnings/frictions through tasktracker insights, and delegates code work to subagents when a subagent-dispatch tool is available — otherwise does the work in-context itself (graceful degradation), never stalling. Used by /tt-implement-plan as the per-phase unit of work; can also be invoked directly with a phase task id. Triggers when /tt-implement-plan delegates a phase, or manually with "/tt-implement-phase <phase-task-id>", "tt implement phase", "execute phase (tasktracker)", "/tt-implement-phase". Prefer this over the plain /implement-phase skill whenever a tasktracker MCP is avail

2026-06-0117

tt-brainstorm

mhylle/claude-skills-collection

Tasktracker-native Socratic brainstorming. Refines a raw idea into a frozen brainstorm document tree stored in tasktracker (NOT in docs/brainstorms/*.md), with every chosen/deferred/rejected option recorded as a decision and an optional one-way promotion into a task tree. Use whenever a user wants to brainstorm, explore, refine, or "think through" an idea AND the work is (or will be) tracked in tasktracker. Triggers on "tt brainstorm", "brainstorm with tasktracker", "brainstorm in tasktracker", "explore this idea (tasktracker)", "/tt-brainstorm", or any brainstorm-style request inside a session that already has a tasktracker active task or project. Prefer this over the plain /brainstorm skill whenever a tasktracker MCP is available — the artifacts integrate with /tt-create-plan and /tt-implement-plan, so picking the file-based variant in a tasktracker project just creates orphan markdown.

2026-06-0117

tt-workflow-audit

mhylle/claude-skills-collection

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 ever

2026-06-0117

name

tt-workflow-build

description

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 Workflow that builds the project — tracking the work in tasktracker, using the build + verify skills.

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

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.