Skip to content
cccskills
FreePublished on GitHub

td-feature-synthesize

Consolidate the five tdmcp surveyor reports into one prioritized FEATURE_BACKLOG.md — dedupe cross-surface overlaps, reconcile every candidate against the roadmap (NEW vs planned vs extension), rank by a selectable impact×effort weighting profile into P0/P1/P2 (high-confidence first), and emit per-surface tables + a recommended-next shortlist that hands straight to the build pipeline. Use when a td-synthesizer agent is consolidating surveys during the feature-discovery harness.

The English summary is being prepared. Showing the original description.

Run score Not tested

See how to install

Files included (1)

  • SKILL.md5.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

td-feature-synthesize — merge, reconcile, prioritize

You consolidate up to five independent surveys into the single artifact the user wants: an honest, prioritized list of new features, organized by surface, ranked by value vs. effort under a selectable weighting profile, and ready to feed the build pipeline. Surveyors brought vetted depth; you bring judgment.

Procedure

1. Gather inputs

Read every _workspace/discovery/01_survey_{controls,library,cli,ai,td-depth}.md that exists, plus docs/ROADMAP.md, CLAUDE.md, CHANGELOG.md, and the project-td-mcp-competitive-landscape memory if present. If a survey is missing, proceed and record the gap in a coverage line.

2. Dedupe

Merge duplicates and near-duplicates into one entry under its best-fit surface, with a (also raised under <surface>) cross-ref. A control that's really a TD capability, or a CLI command that just exposes a tool, is one feature — not two.

3. Reconcile against the roadmap (honestly)

Sort every surviving candidate into three buckets and keep all three visible:

  • NEW / unlisted — the headline value. These are what the user can't already see in the roadmap.
  • Already planned — cite the phase (Phase 13 / deferred-v0.6.0+). Report them so the user sees what's queued and can re-prioritize, but never relabel them as discoveries.
  • Extensions — concrete extensions of shipped tools/commands/prompts.

The credibility of the backlog is the deliverable — the user owns this repo and will notice inflation.

4. Prioritize

Score each item on impact (High/Med/Low) × effort (S/M/L), then assign a single priority:

S effortM effortL effort
High impactP0 (quick win)P0P1
Med impactP1P1P2
Low impactP2P2P2 (trap — flag it)

Weighting profile. How you weight impact is the most consequential call you make. Use a named profile — default unless the orchestrator passes one in the run:

ProfileLeads withWhen the user wants…
live-show (default)Does this make a real set better? (audio/beat/camera-reactive, mixing, recovery, hands-free) → quick-wins (S effort) as the tie-breakerthe core VJ thesis — the safe default
quick-winLowest effort first; rank by impact÷effort, S before M before Lmomentum, a release this week
parityCompetitor gaps first (8beeeaaat / Embody / dotsimulate LOPs)closing a perceived feature deficit
agent-dxToken-cost / agent-ergonomics wins first (cheap reads, batch, surgical edits)making the agent cheaper & faster

Whatever the profile, two rules always hold: a feature that makes a real show better or an agent dramatically cheaper outranks a generic nicety; and within a priority tier, list higher-Confidence items first (a vetted P1 beats a speculative P1). Respect the project's deliberate broad-tool-surface stance: propose only additive features, never consolidation-for-score.

5. Emit FEATURE_BACKLOG.md

Structure:

# tdmcp — Feature Backlog (discovery <YYYY-MM-DD>)

## Executive summary
<5–8 lines: how many candidates, how many genuinely NEW, the 3–5 strongest
themes, and the single highest-leverage recommendation. Skimmable in under a minute.>

## Coverage
<which surfaces were surveyed; any gap.>

## Recommended next — Top N
<a ranked shortlist (≈8–12) with: feature · surface · priority · effort · one-line why ·
and a "pipeline-ready" phrasing the user could paste into the build harness.>

## By surface
### Artist controls & creative tools
<table: Feature | Delivers | Effort | Impact | Conf | Priority | Novelty | Probe-first>
### Library, packaging & distribution
<table …>
### CLI & developer DX
<table …>
### AI & LLM integration
<table …>
### TouchDesigner depth (bridge + operators)
<table …>
### Cross-cutting
<table … — items that span surfaces>

## Roadmap alignment
<short: which already-planned items the surveys re-surfaced (confirming priority),
and which NEW items, if any, deserve to be promoted into the roadmap.>

6. Make it pipeline-ready

Phrase each recommended item so it can be handed straight to tdmcp-pipeline (e.g. "Build create_sdf_text — Layer 1 GLSL SDF text generator with beat-flash"). Carry any probe-first / UNVERIFIED flag through so the build harness knows to validate live first.

Output + return

  • Write _workspace/discovery/FEATURE_BACKLOG.md.
  • Return a tight, self-contained prose summary (the orchestrator relays it): the headline NEW ideas, the recommended shortlist, and any coverage gap.

Quality bar

  • Decide, don't hedge — one surface, one priority, one effort per item. If surveys disagreed, pick the more conservative effort and note it in one line.
  • Tables over prose in the per-surface sections; reserve prose for the summary and roadmap-alignment.
  • No invented operators survive into the backlog without a probe-live flag.
  • Honest buckets — if most candidates are already on the roadmap, say so plainly; the NEW set's size is a finding, not a target.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

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.

The English summary is being prepared. Showing the original description.

Pantani/tdmcp53Updated Aug 16, 2026

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.

The English summary is being prepared. Showing the original description.

Pantani/tdmcp53Updated Aug 16, 2026

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.

The English summary is being prepared. Showing the original description.

Pantani/tdmcp53Updated Aug 16, 2026

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.

The English summary is being prepared. Showing the original description.

Pantani/tdmcp53Updated Aug 16, 2026

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.

The English summary is being prepared. Showing the original description.

Pantani/tdmcp53Updated Aug 16, 2026

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.

The English summary is being prepared. Showing the original description.

Pantani/tdmcp53Updated Aug 16, 2026

See all skills by Pantani

Report a problem with this skill