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

tdmcp-kinect-wall-harp

Orchestrates the dedicated Kinect wall harp implementation team. Use whenever the user asks to build, implement, continue, fix, QA, document, or ship the Kinect wall harp, Kinect v2 wall-depth harp, FreenectTD depth-blob hand tracking, projected wall strings, pluck synth harp, or this feature's Layer 1 tool/recipe/docs. Use this before the generic tdmcp-pipeline for this feature.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md8.0 KB

SKILL.md(原文)

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

tdmcp-kinect-wall-harp - implementation orchestrator

Coordinate the dedicated team for the approved Kinect wall harp prototype. This skill specializes the generic tdmcp pipeline for a physical Kinect v2 + projector wall instrument where FreenectTD depth behavior, manual calibration, two-hand blob tracking, internal audio, and honest live validation all matter.

Execution mode

This repo documents that the current environment runs teams as coordinated sub-agents rather than TeamCreate. Use a hybrid sub-agent workflow:

PhaseModeReason
Planlocal lead or kinect-wall-harp-leadkeep scope tied to the approved spec and wall setup.
Prototype + tool buildparallel sub-agents when write scopes are disjointlive TD prototype and isolated tool file can advance separately.
Integrate/docssingle-writer sub-agentregistries, CLI, recipes, and docs are shared files.
QA/fix loopsub-agent fan-inQA routes precise defects to the owner; live hardware gets PASS / UNVERIFIED accounting.

All spawned agents use the inherited model unless the user explicitly asks for a different one.

Agent roster

AgentRoleSkillsOutput
kinect-wall-harp-leadscope owner and wave captainthis skill_workspace/kinect-wall-harp/00_plan.md
kinect-wall-harp-prototyperlive FreenectTD/Kinect wall prototype and calibration findingstdmcp bridge/tools_workspace/kinect-wall-harp/01_prototype.md
kinect-wall-harp-tool-buildernew Layer 1 tool file + focused unit testtd-feature-build_workspace/kinect-wall-harp/02_build_tool.md
kinect-wall-harp-integratorsingle-writer registry, CLI, recipe, docstd-feature-integrate_workspace/kinect-wall-harp/03_integrate.md
kinect-wall-harp-qaoffline gates, boundary QA, live TD/Kinect validationtd-feature-qa_workspace/kinect-wall-harp/04_qa.md

Use existing tdmcp-bridge-engineer only if implementation proves that a new bridge REST endpoint is necessary. The default plan should avoid a new endpoint and use the existing bridge execution path.

Source of truth

Read these before changing code:

  1. docs/superpowers/specs/2026-06-23-kinect-wall-harp-design.md
  2. CLAUDE.md
  3. Prior live Kinect validation notes from the current workspace/conversation if available: FreenectTD v1.0.1, FreenectTOP, Kinect v2 depth buffer at Render Select index 1, point cloud index 2, IR index 3.
  4. Nearby Layer 1 tools:
    • src/tools/layer1/createBlobReactive.ts
    • src/tools/layer1/createMotionReactive.ts
    • src/tools/layer1/createProjectionMapping.ts
    • audio-reactive or waveform tools under src/tools/layer1/ when present.
  5. Existing recipes that show visual/audio/reactive output patterns.

Workflow

Phase 0 - context check

  1. Read git status --short.
  2. Check _workspace/kinect-wall-harp/.
  3. Decide run mode:
    • no workspace -> fresh run;
    • workspace exists + user says continue/fix/update -> resume only affected phase;
    • workspace exists + new feature direction -> archive the old folder with a timestamp before starting a new one.
  4. Check TouchDesigner bridge with /api/info before any live prototype or QA claim.
  5. Check whether FreenectTOP is registered if the bridge permits live probes.

Phase 1 - plan the wave

Create _workspace/kinect-wall-harp/00_plan.md with:

  • target slice: live prototype, Layer 1 tool, integration, recipe/docs, QA, or all;
  • owner per slice;
  • exact write scopes;
  • expected commands/gates;
  • live hardware assumptions;
  • PASS / UNVERIFIED criteria for real Kinect wall tracking.

Default slice order:

  1. live/synthetic prototype and calibration notes;
  2. synthetic-safe Layer 1 tool;
  3. CLI + optional recipe/docs;
  4. offline QA;
  5. live FreenectTD/Kinect wall QA when hardware and bridge are ready.

Phase 2 - parallel prototype and isolated build

Run in parallel when both are in scope and write scopes are disjoint:

  • kinect-wall-harp-prototyper: use the live bridge to build or validate /project1/kinect_wall_harp, prove the depth-wall mask, and record calibration/hand-channel findings. If bridge is offline, produce a live checklist instead.
  • kinect-wall-harp-tool-builder: create only the new tool file and focused unit test. Do not edit shared files.

Both agents must write their _workspace/kinect-wall-harp/0*_*.md notes.

Phase 3 - single-writer integration

Invoke kinect-wall-harp-integrator after the tool builder reports export names. It owns all shared files:

  • src/tools/layer1/index.ts;
  • src/cli/agent.ts;
  • recipes/kinect_wall_harp.json if the recipe slice is active;
  • docs/cookbook pages if docs are active.

The integrator must run npm run typecheck and npm run build. If docs/recipes changed, also run npm run validate:recipes and the docs generation/build gate that matches the touched files.

Phase 4 - QA and fix loop

Invoke kinect-wall-harp-qa incrementally:

  1. schema/tool/test shape;
  2. registry and CLI command;
  3. recipe validation if touched;
  4. docs honesty if touched;
  5. synthetic live build when bridge is reachable;
  6. real Kinect/FreenectTD wall-touch validation only when hardware is available.

QA sends precise defects to the owner and re-validates after fixes. Cap repeated fix loops at 2-3 rounds, then report the blocker.

Phase 5 - report and next wave

Report:

  • files changed;
  • commands run and outcomes;
  • PASS / FAIL / UNVERIFIED buckets;
  • whether the prototype is ready for physical calibration;
  • what remains for a polished .tox, MIDI/OSC, or production audio.

Do not tag, release, or push unless the user explicitly asks.

Data flow

approved spec
  -> lead plan
  -> live prototype notes -----+
  -> isolated tool builder ----+-> integrator -> qa -> fixes -> final report

Error handling

SituationStrategy
Bridge offlineBuild/test offline; mark live checks UNVERIFIED pending bridge.
FreenectTD unavailableKeep synthetic fallback green; report plugin install/load state.
Kinect connected but depth not cookingStop live claims; surface raw node errors and next hardware checks.
Two blobs mergeTreat as one blob and document limitation; do not claim two-hand pass.
Shared-file conflictStop shared edits and ask the lead to reconcile.
QA fail after 3 roundsHold failing slice; report evidence and next fix.

Test scenarios

Normal flow

User says "implementar a harpa Kinect." The orchestrator reads the approved spec, creates _workspace/kinect-wall-harp/00_plan.md, runs prototype and tool build slices, integrates the tool and CLI, runs typecheck/build/focused tests, validates synthetic TD output if the bridge is up, and reports live Kinect wall tracking as PASS or UNVERIFIED.

Error flow

The bridge is up but FreenectTOP is not registered. The orchestrator still builds the synthetic-safe tool and docs, QA marks FreenectTD/Kinect checks UNVERIFIED, and the final report names the exact plugin/load step to rerun.

Trigger validation

Should trigger:

  • "implemente a harpa Kinect"
  • "continue o kinect wall harp"
  • "vamos fazer as cordas projetadas com Kinect"
  • "arrume o tracking das maos da harpa"
  • "QA da harpa Kinect"
  • "documenta a feature Kinect wall harp"
  • "faz o Layer 1 tool da harpa de parede"
  • "plucked synth com FreenectTD e depth blobs"

Should not trigger:

  • generic Kinect setup question with no implementation request;
  • unrelated projection mapping feature work;
  • Soundcraft Ui24R mixer scene work;
  • broad backlog campaign across many features;
  • test coverage work not specific to this feature;
  • directory/MCPB submission work.

レビュー

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

同じリポジトリのスキル

概要と使いどころ

Write operator-facing and public documentation plans for AI-Controlled Party mixer/Soundcraft Ui24R scene arming. Use for runbooks, rehearsal checklists, show-day checklists, EN/PT docs updates, demo scripts, safety wording, and follow-up documentation revisions.

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

Pantani/tdmcp502026年8月16日 更新

Authoritative reference for submitting tdmcp to the Anthropic Connectors Directory as a Codex Desktop Extension (MCPB). Use whenever drafting, checking, or fixing the submission — it defines the two submission paths, why tdmcp is a Desktop Extension (never a remote connector), every form field, the rejection-causing gates, and the local-only compliance story. Read this before writing any submission deliverable.

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

Pantani/tdmcp502026年8月16日 更新

Authoritative reference for submitting tdmcp to the Anthropic Connectors Directory as a Claude Desktop Extension (MCPB). Use whenever drafting, checking, or fixing the submission — it defines the two submission paths, why tdmcp is a Desktop Extension (never a remote connector), every form field, the rejection-causing gates, and the local-only compliance story. Read this before writing any submission deliverable.

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

Pantani/tdmcp502026年8月16日 更新

How to migrate the tdmcp Claude Desktop bundle from legacy .dxt to .mcpb (MCP Bundle) and keep it building — covers the manifest schema (verify against the installed packer, never hardcode), the build-mcpb.mjs packer/zip-fallback flow, the npm scripts, and the full .dxt→.mcpb reference sweep across docs and scripts. Use when packaging or migrating the tdmcp desktop bundle.

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

Pantani/tdmcp502026年8月16日 更新

How to migrate the tdmcp Codex Desktop bundle from legacy .dxt to .mcpb (MCP Bundle) and keep it building — covers the manifest schema (verify against the installed packer, never hardcode), the build-mcpb.mjs packer/zip-fallback flow, the npm scripts, and the full .dxt→.mcpb reference sweep across docs and scripts. Use when packaging or migrating the tdmcp desktop bundle.

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

Pantani/tdmcp502026年8月16日 更新

Review, harden, and test the safety policy for AI-Controlled Party mixer/Soundcraft Ui24R scene arming. Use for approval gates, blocked mixer operations, hazardous request handling, venue validation, bypass attempts, QA, risk review, or follow-up safety changes.

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

Pantani/tdmcp502026年8月16日 更新

Pantani のスキルをすべて見る

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