本文へ移動
cccskills
無料GitHub で公開

td-feature-qa

Quality-assure integrated tdmcp features: run the four PR gates + recipe/bridge tests, cross-boundary coherence checks (tool schema↔CLI↔docs↔registry, operator↔createable, bridge↔client), and live TouchDesigner validation (preview + post-cook error check) when the bridge is reachable. Use when validating/QA-ing/testing tdmcp tools, checking a feature actually cooks in TD, verifying CLI matches a tool, or gating a release.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md4.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

td-feature-qa — verify it works, not just exists

Most defects here live at boundaries, and a tool that returns success can still cook to errors or a black frame. So: read both sides of every boundary together, and check errors after the network cooks, not just the create_* return flag. Run incrementally — validate each feature as it lands so an early boundary bug doesn't propagate.

Gates + suites — always run (offline, no TD needed)

  • npm run typecheck · npm run build · npm test
  • biome via ./node_modules/.bin/biome check . (NOT npm run lint — RTK proxy gives a false ESLint parse error)
  • npm run validate:recipes · npm run test:bridge (python3 -m unittest discover -s td/tests)

Cross-boundary checks — open both sides

BoundaryLeft (producer)Right (consumer)Compare
Tool ↔ CLItool's Zod inputSchemacommand in src/cli/agent.tsevery param reachable from CLI; types/defaults align; name maps to the right handler
Tool ↔ registryregister… exportlayer*/index.ts + tools/index.tsactually registered + aggregated, not just written
Tool ↔ docslive registrygenerated docs/reference/tools.mdregenerates and includes the new tool
…Impl ↔ testreal return / isError shapemsw test assertionstest exercises the actual shape, not a cast-away generic
Code ↔ TDoperator types createdwhat this build can createoptype exists + is createable (dir(td) suffix-match over-counts; ~22 names not createable; KB lags ~14 ops)
Bridge ↔ clienttd/ endpoint/payloadtouchDesignerClient.ts + validators.ts enveloperesponse shape matches the Zod validator

Live TD validation — when the bridge is up

Policy: offline gates always; live when available. Call get_td_info first.

  • Bridge up: build the feature through the agent CLI against the live bridge, capture get_preview, and check get_td_node_errors after it cooks.
  • Bridge offline: run offline gates, mark live validation UNVERIFIED — pending bridge in the report. Do not fail the pipeline for a missing TD.

Live gotchas to rule out before declaring a bug:

  • Silent failures: a Level TOP has no gain (it's brightness1); no cross-container wires (Select TOP).
  • Paused timeline: time-dependent chains (motion / frame-diff / feedback / beat) read 0 when op('/').time.play is false — check it before concluding a reactive chain is dead.
  • Staleness: a connected mcp__tdmcp__* runs the old build until restarted; editing td/ doesn't reload the running bridge (reload_bridge / restart) — suspect stale modules before "fixing" correct code.
  • GLSL: needs out vec4 fragColor + a self-supplied time uniform.
  • Device sources can hang TD on a macOS permission modal — validate the synthetic/file source first.

Output

A report at _workspace/04_qa_<feature|batch>.md with three explicit buckets — PASS, FAIL (file:line + concrete fix + owning agent), UNVERIFIED (what wasn't checked + why, e.g. bridge offline). Never silently skip a check; list it as UNVERIFIED.

Fix loop

  • Send each defect immediately to its owner (td-builder for handler/schema/test, td-integrator for wiring/CLI/docs); boundary bugs go to both. Re-validate after each fix.
  • Cap at ~2–3 rounds per feature; if still failing, report a blocker with full findings instead of looping.
  • If a gate fails due to a concurrent agent's unrelated in-flight WIP, say so and validate your slice in isolation (vitest run <yourfile>).

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

Use when a hybrid memory system that provides persistent, searchable knowledge management for AI agents (Architecture, Patterns, Decisions).

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

Reference for how BDB structures autonomous software engineering work — the seven-node dispatcher graph (Architect, TechLead, UI/UX, Engineering, Media/EventTech, Reviewer, Shipping) that /startcycle-graph actually runs. Use when you need the high-level lifecycle framing without inventing your own process.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

Tools are how AI agents interact with the world. A well-designed tool is the difference between an agent that works and one that hallucinates, fails silently, or costs 10x more tokens than necessary. This skill covers tool design from schema to error handling.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

Harness patterns for coding agents — memory, permissions, context engineering, delegation, skills, hooks, bootstrap.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

agenttrail: live map of a multi-agent build in the browser: which plan component is being worked on, by which agent or harness, what is done and what is stuck. Use when a multi-agent pipeline starts (/startcycle, /startcycle-graph, /teamwork-preview) or after a plan-canvas approve, when the user asks to see what the agents are doing ("live map", "build board", "who is running now"), or by yourself whenever a multi-agent run is under way — no user prompt needed.

日本語の概要は準備中です。原文の説明を表示しています。

hybridlabor-api/aos62026年10月12日 更新

hybridlabor-api のスキルをすべて見る

このスキルの問題を報告する