# Td Hype Synthesize

> Consolidate the td-trend-scout reports under `_workspace/hype-scout/` into one prioritized HYPE_TOOL_BACKLOG.md — dedupe trends across surfaces, vet each candidate against the real tdmcp codebase (layer fit, operator coverage, bridge work), rank by Hype × Build-Ease, and emit a 'Ready for tdmcp-pipeline' top-5. Use when a td-hype-synthesizer agent is consolidating scouts at the end of the tdmcp-h…

- **Type:** Skill
- **Install:** `agentstack add skill-hybridlabor-api-bdb-dev-optimized-agent-skills-td-hype-synthesize`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [hybridlabor-api](https://agentstack.voostack.com/s/hybridlabor-api)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [hybridlabor-api](https://github.com/hybridlabor-api)
- **Source:** https://github.com/hybridlabor-api/bdb-dev-optimized-agent-skills/tree/main/mcps/tdmcp/.claude/skills/td-hype-synthesize

## Install

```sh
agentstack add skill-hybridlabor-api-bdb-dev-optimized-agent-skills-td-hype-synthesize
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# td-hype-synthesize — synthesis + feasibility vetting + ranking

This skill is loaded by the `td-hype-synthesizer` sub-agent. You produce exactly one file: `_workspace/hype-scout/HYPE_TOOL_BACKLOG.md`. You do not scout new trends.

## Procedure

### Step 1 — Inventory the scouts

List every `_workspace/hype-scout/01_scout_*.md` file:

```bash
ls _workspace/hype-scout/01_scout_*.md
```

Read each file end to end. Note:
- Which surfaces are present and which are missing (`SCOUT MISSING: `).
- Which files are tagged `PARTIAL-DUE-TO-NETWORK` — propagate that into the synthesis header.
- The total candidate count and per-surface tally.

### Step 2 — Build the master candidate table (in memory)

Collect every entry into a working table with columns:

| Field | Source |
|---|---|
| `id` | new sequential (S001…) |
| `name` | scout's tool name |
| `surfaces` | list — usually one, but grow during dedup |
| `summary` | merged "what artists are doing" + "why hyped" |
| `evidence` | union of all citations |
| `scout_hype` | the scout's call (H/M/L) — list if multiple scouts |
| `scout_build_ease` | scout's guess (S/M/L) |
| `scout_coverage` | NOT-COVERED / PARTIAL / COVERED |
| `proposed_layer` | scout's suggestion |
| `proposed_operators` | scout's suggestion |

### Step 3 — Dedupe across surfaces

Two entries collapse into one when they describe the **same TouchDesigner outcome**, even if the scouts framed them differently. Heuristics:

- Same suggested operators → merge.
- Same trend name (case-insensitive, allowing minor wording differences like "StreamDiffusion realtime" vs "Realtime StreamDiffusion bridge") → merge.
- Same "what artists are doing" core (one summary is a subset of another) → merge.

When merging:
- `surfaces` = union.
- `evidence` = union (dedupe by URL).
- `scout_hype` = if all scouts agreed, keep that. If they disagreed, take the **mode** but annotate inline (e.g. `M (showcase: H, tutorials: M)`).
- A trend that appeared in **3+ surfaces** gets a +1 step on Hype (capped at H). Multi-surface confirmation is itself a hype signal.

Do **not** delete dropped entries — keep them in a `## Merge log` appendix at the bottom so the merge is auditable.

### Step 4 — Vet feasibility against the real codebase

For each merged candidate, run targeted greps to lock the **layer, operator coverage, and effort estimate**. Quote what you find so the call is auditable.

| Check | Command |
|---|---|
| Layer 1/2/3 tool already exists? | `grep -rn "create_" src/tools/` |
| Operator in KB? | `grep -irn "" src/knowledge/data/` |
| Recipe already covers it? | `ls recipes/ \| grep -i ` |
| Bridge endpoint exists? | `grep -rn "" src/td-client/touchDesignerClient.ts td/` |
| Roadmap already lists it? | `grep -in "" docs/ROADMAP.md` |

Resolve each candidate to one of:

| Verdict | Meaning | Effort default |
|---|---|---|
| **NEW** (clean) | no existing tool, all operators in KB, no bridge work | S |
| **NEW** (operator gap) | operators exist but not yet wrapped in tdmcp | M |
| **NEW** (bridge needed) | needs a new bridge endpoint (e.g. a new device, persistent state) | L |
| **EXTENSION** | existing tool covers most of it; add a preset/param | S |
| **COVERED** | already shipped — surface as "add cookbook example" |  - |
| **ROADMAP** | already on `docs/ROADMAP.md` for a future phase | note phase |
| **FEASIBILITY-UNCERTAIN** | operator may or may not exist, KB ambiguous | flag for live probe |

Adjust the build-ease score according to the verdict (overwrite scout's guess if vetting disagrees, but log the change).

### Step 5 — Rank with an explicit weighting profile

**Default profile (state it at the top of the output):**

```
score = HYPE_WEIGHT[hype] × BUILD_EASE_WEIGHT[ease]
HYPE_WEIGHT       = { L: 1, M: 2, H: 3 }
BUILD_EASE_WEIGHT = { L: 1, M: 2, S: 3 }
```

So the maximum is H × S = 9, the minimum is L × L = 1. Sort descending. Tie-break by: (1) cross-surface count desc, (2) NEW > EXTENSION > COVERED, (3) Hype desc, (4) name asc.

**Alternative profiles** the user can request (offer them at the end of the file in a "Re-rank knobs" section):

- **Hype-only:** rank by hype, ignore effort.
- **Quick-wins:** filter `ease == S`, then rank by hype.
- **Strategic:** rank L items above S items (long-term bets first).
- **Conservative:** drop everything `FEASIBILITY-UNCERTAIN`.

### Step 6 — Identify force multipliers

A **force multiplier** is one piece of foundational work (a new bridge endpoint, a new operator wrapper, a new prompt) that unlocks 3+ ranked tools. Surface these at the very top of the output, **above** the ranked list, with the dependents listed by id. They often beat any individual tool on ROI.

Example: "Wrap `realsense2TOP` as a Layer 3 tool with depth/color/IR streams + a small Layer 2 helper" might unlock S013 (LiDAR particle scatter), S017 (hand-gesture pointer), S021 (depth-keyed silhouette). Flag as **Force multiplier FM-01**.

### Step 7 — Write the output file

`_workspace/hype-scout/HYPE_TOOL_BACKLOG.md` — this exact structure:

```markdown
# Hype tool backlog — tdmcp

**Run:** 
**Scout coverage:**  (missing: )
**Profile used:** default — Hype × Build-Ease (state weights inline)
**Notes:** any `PARTIAL-DUE-TO-NETWORK` flags, any `SCOUT MISSING` gaps.

---

## Force multipliers

> Foundational work that unlocks 3+ ranked tools.

### FM-01 — 
- **Why:** 
- **What to build:** 
- **Unlocks:** S###, S###, S###
- **Effort:** S / M / L

(...repeat for FM-02 etc., or "None this run.")

---

## Ready for tdmcp-pipeline (top 5)

> Highest-confidence, lowest-friction picks. Hand straight to `tdmcp-pipeline`.

| # | id | Tool | Layer | Hype | Ease | Coverage | Surfaces |
|---|----|------|-------|------|------|----------|----------|
| 1 | S### | `create_` | 1 | H | S | NEW | community-showcase + tutorials |
| 2 | ... |  |  |  |  |  |  |

For each, link to the detailed entry below.

---

## Ranked backlog

| Rank | id | Tool | Layer | Hype | Ease | Coverage | Score |
|------|----|------|-------|------|------|----------|-------|
| 1 | S001 | ... | 1 | H | S | NEW | 9 |
| 2 | ... |  |  |  |  |  |  |

---

## Per-surface breakdowns

### community-showcase
| id | Tool | Hype | Ease | Coverage |
|----|------|------|------|----------|
| ... |  |  |  |  |

### tutorials
...

### generative-ai
...

### hardware-interactive
...

### vfx-aesthetics
...

---

## Candidate details

### S001 — 
- **Summary:** 
- **Surfaces:** community-showcase, tutorials
- **Evidence:** (union of all scout citations, one per line)
  -  — 
- **Hype:** H (showcase: H, tutorials: H)
- **Build-ease:** S — vetted
- **Coverage:** NEW (clean) / NEW (operator gap) / EXTENSION — existing `` / COVERED — existing `` / ROADMAP — phase X.Y / FEASIBILITY-UNCERTAIN — probe live
- **Layer:** 1 / 2 / 3 / bridge-endpoint
- **Suggested operators:** `, , ` (KB confirmed) | (UNVERIFIED — probe live)
- **Tool sketch:** 1-3 sentences, what the tool does end-to-end.
- **Force-multiplier link:** FM-0X (if any)
- **Vet notes:** what grep found / didn't find. Quote paths.

(...all candidates...)

---

## Re-rank knobs

Available alternative profiles (re-invoke synth with the chosen one):
- `--profile=hype-only`
- `--profile=quick-wins`
- `--profile=strategic`
- `--profile=conservative`

---

## Merge log

| New id | Merged from | Reason |
|--------|-------------|--------|
| S001 | scout-community-showcase #3, scout-tutorials #7 | same outcome, same operators |

---

## Follow-up suggestions (not scouted)

> Gaps you noticed during synthesis but were not in any scout. Surface only — do not score; mark for re-scout next run.

- ...
```

## Working principles

- **Quote the grep.** "I checked `grep -rn 'streamdiffusion' src/tools/` — no matches" is auditable; "this is not covered" is not.
- **No silent overwrites.** If your vetting changes a scout's hype or build-ease score, log it in the entry's `Vet notes:`.
- **Tight top-5.** If you can't confidently pick 5, pick 3. Don't dilute.
- **Honest gaps.** A missing scout file is not a synthesis failure; just note it in the header and move on.

## What not to do

- Don't scout new trends. Work only from existing scout files. Surface gaps you noticed under "Follow-up suggestions" without scoring them.
- Don't drop or hide disagreement between scouts. Annotate it.
- Don't pad the ranked list with weak entries to look comprehensive.
- Don't recommend tools that contradict `docs/ROADMAP.md` without flagging the contradiction.

## Re-invocation

If `HYPE_TOOL_BACKLOG.md` already exists:

1. Read it first.
2. Apply only the requested change — re-rank under a new profile, re-vet a single candidate, refresh the top-5, add a new section — preserve numbering and the merge log.
3. Bump the `Run:` date and add a short `## Changes this run` section near the top describing what changed.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [hybridlabor-api](https://github.com/hybridlabor-api)
- **Source:** [hybridlabor-api/bdb-dev-optimized-agent-skills](https://github.com/hybridlabor-api/bdb-dev-optimized-agent-skills)
- **License:** Apache-2.0

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-hybridlabor-api-bdb-dev-optimized-agent-skills-td-hype-synthesize
- Seller: https://agentstack.voostack.com/s/hybridlabor-api
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.