cross-ecosystem-synergy-detection

Files (1)

• SKILL.md

SKILL.md (first lines)

# cross-ecosystem-synergy-detection — Multi-Ecosystem Automatic Synergy Discovery

Automatically discovers cross-invocable pairs in environments with multiple installed plugins and cross-CLI tools, and derives a synergy ranking table.

## Activation Triggers

1. **Multi-ecosystem component environment specified**: "multiple plugins/cross-CLI installed", "synergy with other components", "cross-ecosystem", "run together"
2. **New component added/removed**: "component install", "add/remove component"
3. **Synergy check phrasing**: "are they working in isolation?", "can they be integrated?", "environment check", "combination effect"
4. **Registry change detected** (optional): If a user-maintained `LOCAL_SKILL_REGISTRY.md` is present, Step 7 runs when a new project/skill is registered. The registry is not auto-created — absent file → Step 7 reports `[NOT-CONFIGURED]` and skips its body (see Step 7-1 outcome table).

**Exception**: Single-component environments (1 or fewer installed → no meaningful activation)

### Natural Language Triggers (General user phrasing — activates without internal vocabulary)

| Example phrasing | Intent |
|---|---|
| "Do my installed tools work well together?" | Check synergy of installed plugins/skills |
| "Would using this and that together be better?" | Explore cross-invocation possibilities |
| "I have multiple plugins installed in Claude — am I using them well?" | Diagnose installation ecosystem utilization |
| "My tools seem to be working in isolation" | Detect namespace/cwd fragmentation |
| "I just installed something new — check for conflicts with existing setup" | Check after adding new component |
| "I have multiple installs but not sure if I'm using them right" | Diagnose installation ecosystem utilization |
| "Wouldn't this and that work better together?" | Explore cross-invocation possibilities |
| "My tools feel disconnected and inconvenient" | Detect namespace/cwd fragmentation |
| "Wouldn't combining these plugins be more powerful?" | Explore component combination synergies |
| "I feel like there's synergy here — find it" | Automatic cross-invocation pair discovery |
| "Do my harnesses have synergy with each other?" | **Step 3-b standalone** — harness-level scan |
| "Can I transplant a governance pattern from another project?" | **Step 3-b standalone** |
| "Could I bring that project's gate over here?" | **Step 3-b standalone** |
| "하네스끼리 시너지" · "거버넌스 패턴 이식" · "다른 프로젝트 게이트 가져올 수 있나" | **Step 3-b standalone** |
| "이 하네스에 시너지 몰아줘" · "focus the synergy on this one" · "이거 하나 집중해서 강화" | **focus mode** — Step 3-b **+ Step 3-c by default** |
| "밖에도 이런 거 있나" · "더 강화할 방법 있어?" · "is there prior art that would make this stronger?" | **Step 3-c** |

> **Step 3-b fires standalone.** The last four rows call that step alone; they do not require the full
> door-④ pass. A request about *harnesses* is not a request about *installed plugins*.

## Processing Steps (7-step)

### Step 1. Installation Inventory Direct Inspection

```bash
cat ~/.claude/plugins/installed_plugins.json
```

**Schema (measured 2026-08-11, `version: 2`)** — read this before writing any parser:

```
{"version": 2,
 "plugins": {                       # DICT, not a list
   "<plugin>@<marketplace>": [      # value is a LIST of entries
     {"gitCommitSha": …, "installPath": …, "installedAt": …,
      "lastUpdated": …, "scope": …, "version": …}
   ]}}
```

The plugin **name is the dict key**, not an entry field — `entry.get('name')` is always `None`,
and iterating `for pl in data['plugins']` yields **key strings**, not entry dicts.
`gitCommitSha` is **optional** (measured: present on 5 of 11 installs) — see Step 5 drift.

Additional checks:
- `~/.claude/settings.json` `enabledPlugins` (actually active assets)
- Check `installed_plugins.json` ↔ `enabledPlugins` consistency (catch drift)

### Step 2. Asset Matrix Extraction per Component

```bash
for T in skills agents commands .mcp.json hooks; do
  if [ -e "$IP/$T" ]; then echo "PRESENT $T"; ls "$IP/$T"; else echo "ABSENT  $T"; fi
done
```

Extract each asset's frontmatter `description` + `allowed-tools` + `model`. Merge `plugin.json keywords`.

**`ABSENT` is a state, not a zero.** Most plugins ship only a subset (measured on `fh-meta`:
`skills`/`agents` present, `commands`/`.mcp.json`/`hooks` absent). Carry `ABSENT` through to
the matrix — an absent asset class must not be counted as "0 assets found", which would read as
an inspected-and-empty component.

### Step 3. Cross-Invocation Possible Pair Matrix Derivation

Call mechanism compatibility:
- **Skill**: Can be called directly as `{component-name}:{skill-name}`
- **Agent**: Can be called directly as `{component-name}:{agent-name}` via subagent_type
- **Hook**: Auto-triggered (no direct cross-component calls)
- **MCP**: Per-tool calls (namespace separated)

### Step 3-b. Harness-level pattern-transplant scan (conditional default)

**Condition**: 2+ mapped field-harness tracks exist. 🟥 **Establish the count by running
`bash scripts/mapped_tracks.sh` — never by listing `tracks/` from the session's cwd.** The mapping
signal is the *presence* of `tracks/<name>/`, and that signal cannot reach a worktree: `tracks/**` is
gitignored, and at least one mapped track is an **empty directory** git could not carry even if it
were not. Measured 2026-08-22, one run: **main checkout 11 · worktree 1** — a cwd listing does not
return a smaller count, it returns a structurally blind one, and `skipped(<2 mapped tracks)` is a
*pass* value, so the blind run closes green. The script resolves the hub root through
`git rev-parse --git-common-dir` (the `EVIDENCE_ROOT` pattern this repo already sanctions in
`templates/.git-hooks/pre-commit`) so both standpoints answer alike.
🟥 **`status=UNMEASURED` (exit 3) is NOT a skip** — it means the count could not be taken, which is a
different value from "fewer than two". Close it as `external-error` (non-pass); never as
`skipped(<2 mapped tracks)`. Underscore-prefixed meta dirs (`_meta`/`_audit`/`_contrib`/`_chamber`)
do not count — the test is a **leading** underscore, so a track like `the_bible` is counted.
Otherwise skip with one line.

Steps 1–3 look at **installed plugins/skills**. This step looks one layer up: the **governance
mechanisms of the mapped field harnesses themselves** — verification axes, verdict enums, gate exit
codes, persona systems — and finds pairs where one harness's mechanism is transplantable into another.

- Read each mapped track's **canon** (`CLAUDE.md` / `README.md`), not its code. Field-harness
  vocabulary must not be normalized into general concepts — that is this repo's habitual failure.
- Emit **transplantable pairs only**: the two must share the *same problem shape*. Merely overlapping
  subject matter is excluded.
- 🟥 Declare the read depth. "Read the top ~150 lines of CLAUDE.md" is a different claim from "read the
  file"; say which, and mark anything not opened as **unverified**, never as absent.
- Store under its **own section** in the Step 6 result file, separate from the skill/agent pair table —
  the two layers answer different questions and merging them hides which one produced a finding.

> **Boundary with Step 7**: Step 7 (proactive) may *trigger* Step 3-b; it does not replace its scan.
> Step 7 decides *when to offer*, Step 3-b decides *what to read and which transplant pairs come out*.

From chrono-meta/forge-harness, MIT.

More from chrono-meta/forge-harness