tdmcp Roadmap-to-1.0 Campaign
SkillDev toolsDrive the ENTIRE tdmcp roadmap-to-1.0 to completion as a resumable, wave-by-wave campaign — Milestone 4 (generative-AI bridge wave), Milestone 5 (mixer scene arming), and the v1.0 consolidation gates G1–G6 — routing each class of work to the right existing sub-harness. Use whenever the user wants to "implement everything / all the milestones / the whole roadmap / finish the road to 1.0", run the next milestone, close the consolidation gates, or build a long autonomous campaign across M4/M5/G1–G6. ALSO use for every follow-up: continue/resume the roadmap campaign, run the next wave, re-run a failed wave, fold in QA results, check campaign status, re-prioritize, or scope to one milestone/gate. This is the CAMPAIGN layer ABOVE tdmcp-pipeline / tdmcp-feature-lead / tdmcp-backlog-campaign — it sequences across MULTIPLE sub-harnesses (tools, mixer, coverage, docs, bridge, recipes, submission), which the generic backlog-campaign does not. For a SINGLE feature use tdmcp-pipeline; for one tool-shaped backlog file use tdmcp-backlog-campaign. Simple questions can be answered directly.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the tdmcp Roadmap-to-1.0 Campaign skill
What this skill tells your AI
The instructions your AI receives, as published by pantani/tdmcp in .claude/skills/tdmcp-roadmap-campaign/SKILL.md and read by ahel’s review.
Drives _workspace/campaign_roadmap_v1/ROADMAP_1.0_BACKLOG.md to completion,
gated by _workspace/campaign_roadmap_v1/ledger.json (idempotent, resumable,
merge-safe). This is orchestration only — it never writes product code
itself; it routes each ledger item to the existing specialist sub-harness and
records the outcome back into the ledger.
Why this exists (vs tdmcp-backlog-campaign)
tdmcp-backlog-campaign drives a tool-shaped backlog through one pipeline
(design→build→integrate→QA→release). The road to 1.0 is not uniform: it mixes
new tools (M4), a policy-bounded mixer slice (M5), a coverage CI gate (G2), a
bridge exec→REST sweep (G4), docs/governance (G1/G5/G6 prep), and live-validated
recipes (G3). Each needs a different specialist. This skill is the thin router
that sequences them and keeps one ledger of truth.
Confirmed campaign policy (2026-06-21)
- Release: commit + push, NO tag/bump. Everything lands in CHANGELOG
[Unreleased]. Cutting the version is a manual user step — never tag autonomously ([[no-premature-release-tag]]). - Blocked items (GPU/CUDA, live-TD, external service): build offline +
quarantine. Implement, pass the offline gates, set
liveto the rightUNVERIFIED-pending-*marker, keep going. Quarantine never blocks the campaign. - Checkpoint: after Wave 1 only, then autonomous to the end. On repeat failure: retry once → quarantine-and-continue (note it in the wave report).
Routing table (ledger route → sub-harness)
route | Sub-harness | Agents |
|---|---|---|
docs | tdmcp-docs-roadmap-update | roadmap-docs-editor, docs-cookbook-sync, docs-roadmap-qa |
tools | tdmcp-feature-lead | tdmcp-tool-builder ×N + single-writer integration |
mixer | tdmcp-pipeline | mixer-scene-contract-architect, soundcraft-ui24r-adapter-architect, mixer-policy-safety-qa |
coverage | tdmcp-test-coverage | tdmcp-coverage-writer, tdmcp-coverage-qa |
bridge | tdmcp-bridge-endpoint | tdmcp-bridge-engineer (sequential — bridge slices share files) |
recipes | tdmcp-pipeline | td-architect, td-builder, td-qa (needs live TD) |
submission | tdmcp-submission | submission-architect, submission-qa |
| planning | — | tdmcp-backlog-planner (wave computation + ledger transitions) |
Workflow
Phase 0 — Context check (resume vs fresh)
- Read
ledger.json. If absent, the harness isn't initialized — (re)generate it fromROADMAP_1.0_BACKLOG.mdanddocs/ROADMAP.md, then stop and report. - Reconcile against the tree first — a prior session or a merged PR may have
already shipped a ledger item. For each
pendingitem, cheaply verify it's genuinely undone (grep for the tool/file/gate) before assigning it. Flip already-done items toshippedwith anevent: reconciledhistory row. - Determine the next ready wave: lowest wave number with
pending, non-blockeditems whosedepends_onare allshipped. Honor thecheckpoint_after_wavegate.
Phase 1 — Plan the wave (tdmcp-backlog-planner)
Spawn tdmcp-backlog-planner (opus) with the ledger + backlog. It returns: the
exact item set for this wave, their routes, dependency-safe ordering, and the
proposed ledger status transitions. Write its report to
_workspace/campaign_roadmap_v1/wave_<n>_planner_report.md.
Phase 2 — Execute the wave (route to sub-harnesses)
For each item, invoke its route sub-harness with a precise spec. Within a wave:
- Parallelize independent items across routes (docs ∥ coverage ∥ tools).
- Serialize same-file routes — all
bridgeitems run sequentially (they sharetd-client/td/files); withintools, builders are parallel but the integrator is the single writer of shared registries. - Blocked/needs-hardware items: build to the offline boundary, then mark
livequarantined per policy — do not wait on hardware.
Every sub-harness already runs its own gates; this skill does not re-implement
them. Record per-item QA (typecheck/build/biome/vitest/recipes/bridge) into the
ledger qa block, exactly like the project_rag campaign.
Phase 3 — Gate, commit, record
- Run the four PR gates + recipe + bridge tests at the wave boundary
(
npm run typecheck && npm run build && npm run lint && npm test,npm run validate:recipes,npm run test:bridge). - Commit + push the wave on its own branch (
feature/roadmap-<wave-theme>). No tag, no version bump — CHANGELOG[Unreleased]only. - Update the ledger: flip items
pending → shipped(orquarantined), stampqa,commit, and ahistoryrow. Writewave_<n>_report.md.
Phase 4 — Loop or checkpoint
- If the just-finished wave is the
checkpoint_after_wave→ stop and report; wait for the user before the next wave. - Otherwise advance to the next ready wave (Phase 0 → 3) until no
pendingnon-blocked item remains.
Phase 5 — Hand-back
When only quarantine items remain, report campaign complete (offline scope)
and enumerate what the user must do to actually tag 1.0: provide GPU/TOX
components or a reachable TD for the UNVERIFIED-pending-* live validations,
run the bench/hardware M5 spikes, submit to the Connectors Directory, and — only
on the user's word — cut the tagged 1.0 minor (closing G1).
Error handling
- A sub-harness that fails a gate: retry once with the failure fed back. On
second failure, mark the item
quarantinedwith the reason, leave the rest of the wave intact, and note it in the wave report — never delete partial work. - Conflicting tree state vs ledger: trust the tree, reconcile the ledger, note the drift. Never silently overwrite shipped work.
- The ledger is the single source of truth and must stay valid JSON after every transition; write it atomically (full rewrite), never partial.
Test scenarios
- Happy path: fresh ledger → Phase 0 picks Wave 1 → planner assigns 4 docs items → docs sub-harness ships all four → gates green → commit no-tag → checkpoint stop with a Wave-1 report.
- Resume after merge: a follow-up run finds
g2_coverage_ci_gatealready landed on main → reconcile toshipped(event: reconciled) → skip it → plan the remainder of Wave 2. - Blocked item: Wave 4
m4_drive_streamdiffusionbuilds offline, gates green, but no GPU → ship withlive: UNVERIFIED-pending-gpu, campaign continues. - Repeat failure: a tool fails its gate twice → quarantined with reason, wave proceeds with the rest, report flags the gap.
Signals
- GitHub stars
- 41
- Forks
- 9
- Last commit
- Aug 2026
Advanced
- Catalog kind
- skill
- Gateway key
tdmcp-roadmap-campaign- Source
- github.com/pantani/tdmcp