tdmcp-implementation-learning

Files (1)

• SKILL.md

SKILL.md (first lines)

# tdmcp-implementation-learning - post-implementation learning harness

Coordinate a focused study of a completed tdmcp implementation, then turn the
evidence into a prioritized improvement backlog. This harness answers: "What did
this implementation teach us, and what should tdmcp improve next?"

Use it after a feature has already been built, merged, tested in TouchDesigner,
used with hardware, reviewed in a PR, or exercised in a real installation.

## Boundary

This harness studies and routes improvements. It does not own arbitrary feature
implementation.

- Shipped/merged implementation learning:
  `tdmcp-implementation-learning`.
- Chosen new feature build: `tdmcp-pipeline`.
- Broad repo quality or command health: `tdmcp-quality-audit`.
- Known coverage gaps: `tdmcp-test-coverage`.
- Docs, roadmap, or changelog sync: `tdmcp-docs-roadmap-update`.
- Continued Kinect wall harp work: `tdmcp-kinect-wall-harp`.

## Execution mode: sub-agent fan-out -> fan-in

No `TeamCreate`. Use coordinated sub-agents with file handoffs.

- Scope: lead only. Determine target feature, evidence sources, and artifact
  directory.
- Study: sub-agent fan-out. Code, runtime, and quality surfaces can be inspected
  independently.
- Synthesis: one sub-agent. One owner dedupes findings and ranks next actions.
- Handoff: lead only. The user gets a compact decision-ready report.

All agent calls use `model: "opus"` unless the caller has a stricter local
policy.

## Agent roster

- `tdmcp-implementation-learning-lead`:
  `_workspace/implementation-learning/<slug>/00_scope.md` and final handoff.
- `tdmcp-implementation-cartographer`:
  `_workspace/implementation-learning/<slug>/01_map.md`.
- `tdmcp-implementation-runtime-analyst`:
  `_workspace/implementation-learning/<slug>/02_runtime_lessons.md`.
- `tdmcp-implementation-quality-analyst`:
  `_workspace/implementation-learning/<slug>/03_quality_gaps.md`.
- `tdmcp-implementation-synthesizer`:
  `_workspace/implementation-learning/<slug>/04_backlog.md`.

Use a short slug from the implementation name or PR, for example
`kinect-wall-harp`, `ai-party-mixer-scene`, or `pr-114-external-kinect`.

## Workflow

### Phase 0 - context and safety check

1. Read the current repo state with `git status --short --branch`.
2. Read `CLAUDE.md` and any feature-specific harness pointer that already
   exists. Prefer extending or routing through existing harnesses over inventing
   overlapping ones.
3. Identify the implementation being studied from the user's request. If it is
   ambiguous, infer the most recent relevant feature from local context and state
   the assumption.
4. Create `_workspace/implementation-learning/<slug>/`.
5. Write `00_scope.md` with:
   - target implementation and date/context
   - source branches, PRs, docs, specs, tools, scripts, and generated artifacts
   - live/hardware evidence that exists or is missing
   - explicit exclusions
6. Preserve unrelated user changes. Do not revert or clean generated files unless
   the user specifically asks.

### Phase 1 - parallel study

Run the three analyst agents in parallel when their scopes are independent.
Each writes incrementally to its artifact file.

#### Cartographer scope

Map the implementation across code, docs, CLI, tests, recipes, bridge scripts,
runtime helpers, and generated TouchDesigner project structure.

Required output fields:

- shipped surfaces
- data/control flow
- coupling points
- reusable patterns
- duplicated or one-off code that could become a common primitive
- missing ownership boundaries
- follow-up candidates with file references

#### Runtime analyst scope

Study the implementation from the user's real usage path: TouchDesigner bridge,
Kinect/camera/audio/projector setup, diagnostics, calibration, failure modes,
latency, and operator ergonomics.

Required output fields:

- what was actually verified live
- what remains `UNVERIFIED`
- user pain points observed during the implementation
- runtime diagnostics that helped or were missing
- setup steps that should become tool affordances or docs
- hardware assumptions that should be explicit

Do not report hardware or TouchDesigner checks as passing unless they were
actually run.

#### Quality analyst scope

Study the implementation for tests, CI, review feedback, validation gaps,
warnings, script robustness, security, and maintainability.

Required output fields:

- current gates checked
- failing or unverified gates

From hybridlabor-api/aos, Apache-2.0.

More from hybridlabor-api/aos