tdmcp-pipeline-0bfc9c — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited tdmcp-pipeline-0bfc9c (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Coordinate the five tdmcp specialists to take feature ideas from spec to a pushed release, following the project's proven workflow: parallel isolated builders + a single-writer integrator + live-validated QA + an autonomous release.
| Stage | Mode | Why |
|---|---|---|
| Design | sub-agent (fan-out if many features) | the architect is an isolated one-shot producer; specs land in _workspace/ |
| Build | sub-agent (fan-out, parallel) | builders are fully isolated by design (new files only, no inter-comms) — the textbook sub-agent case |
| Integrate → QA → Release | agent team | producer↔reviewer feedback loops (QA ↔ builder-fixer/integrator) and the release gate need live messaging |
Why this split: builders must NOT touch shared files so they can run concurrently; that isolation removes any need for build-time team comms. The integrate/QA/release trio, by contrast, lives on a tight fix-and-re-verify loop, which is exactly what an agent team is for.
| Agent | Type | Skill | Output |
|---|---|---|---|
td-architect | custom | td-feature-design | _workspace/01_design_<feature>.md |
td-builder (×N) | custom | td-feature-build | new tool + test files; _workspace/02_build_<feature>.md |
td-integrator | custom | td-feature-integrate | wired index.ts/agent.ts; _workspace/03_integrate.md |
td-qa | custom | td-feature-qa | _workspace/04_qa_<batch>.md (PASS/FAIL/UNVERIFIED) |
td-releaser | custom | td-feature-release | CHANGELOG + version bump + commit/tag/push; _workspace/05_release.md |
All Agent / TeamCreate calls use model: "opus".
_workspace/ exists._workspace/ to _workspace_<YYYYMMDD_HHMMSS>/, then Phase 1.docs/ROADMAP.md._workspace/ and write the feature list to _workspace/00_input/features.md.Spawn one td-architect per feature (or one for the whole small batch) via Agent, subagent_type: "td-architect", model: "opus", run_in_background: true for parallelism. Each writes _workspace/01_design_<feature>.md. Wait for all, then read the specs and resolve any flagged overlaps/contention before building.
Spawn N td-builder sub-agents in a single message (run_in_background: true), one per spec. Each prompt includes its spec path and the hard rule: new files only, never edit shared registries/CLI/docs. Each returns green-in-isolation files (vitest + biome) and a build note. Size N to the batch; keep it to a manageable parallel set (~3–5 at a time for a large batch, then a second wave).
Form the team and run the convergence loop:
TeamCreate(team_name: "tdmcp-delivery", members: [{ name: "integrator", agent_type: "td-integrator", model: "opus" }, { name: "qa", agent_type: "td-qa", model: "opus" }, { name: "builder-fixer", agent_type: "td-builder", model: "opus" }, { name: "releaser", agent_type: "td-releaser", model: "opus" }]) (builder-fixer closes QA's fix requests on handler/schema/test bugs without re-spawning.)
TaskCreate the pipeline with dependencies:integrator)qa, depends on integrate) — not one big pass at the endbuilder-fixer/integrator, depends on QA findings)releaser, depends on QA = PASS for everything shipping)SendMessage: QA sends file:line + fix to the owner the instant a defect is found; boundary bugs go to both sides; QA re-validates after each fix (cap ~2–3 rounds/feature).TaskGet, intervenes if a member stalls._workspace/05_release.md exists (or that release was intentionally held).TeamDelete. Preserve _workspace/ for audit.[leader] → architect(s) ─ specs → builders (parallel) ─ files+notes →
┌─ TeamCreate(integrator, qa, builder-fixer, releaser) ─┐
│ integrator wires → qa validates (live if bridge up) │
│ ↑ fix requests (SendMessage) ↓ │
│ builder-fixer / integrator patch → qa re-checks │
│ qa PASS → releaser cuts + pushes │
└───────────────────────────────────────────────────────┘
↓
_workspace/0*_*.md + pushed tag| Situation | Strategy |
|---|---|
| One builder fails in isolation | Ship the rest; route its spec to builder-fixer in Phase 4 (or re-spawn). Don't block the batch. |
| Build breaks on integrate | Integrator bisects, wires the rest, sends the offender a precise fix; team continues. |
| QA finds a boundary bug | SendMessage to both producer and consumer; re-validate after fix; cap ~2–3 rounds, else report blocker. |
| Bridge offline | QA runs offline gates, marks live checks UNVERIFIED-pending; release may still ship (note it) — never fail the pipeline for a missing TD. |
| QA = FAIL on a feature | Releaser holds it for next cycle; ships only PASS features; report what was held. |
| Concurrent agent's WIP breaks compile project-wide | Validate the slice in isolation (vitest run <file>); wait for their tree to go green before the full build/release. |
Normal: user asks to build the cue-sequencer feature → Phase 1 lists 1 feature → architect writes the spec → 1 builder produces a green tool+test → team forms → integrator wires + builds green → QA validates live (preview + post-cook errors clean) = PASS → releaser bumps minor, writes CHANGELOG, commits/tags/pushes → report names the new version.
Error: in a 4-feature batch, builder-3's tool cooks to a TD error caught by QA (a Level TOP gain no-op) → QA SendMessages builder-fixer with file:line + use brightness1 → fix re-validates PASS → the other 3 already PASS → releaser ships all 4. If builder-3 can't be fixed in 3 rounds, releaser ships the 3 PASS features and the report holds builder-3 for next cycle.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.