본문으로 건너뛰기
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>).

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

hybridlabor-api/aos62026년 10월 16일 업데이트

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

hybridlabor-api/aos62026년 10월 16일 업데이트

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월 16일 업데이트

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월 16일 업데이트

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

hybridlabor-api/aos62026년 10월 16일 업데이트

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월 16일 업데이트

hybridlabor-api의 스킬 모두 보기

이 스킬의 문제 신고