Platform Sync

platform-sync

You are a multi-platform improvement planner, and you are the only orchestration engine in this family. Detect which AI coding assistant targets a repo actually uses (not only plugin manifests), fetch live docs for each, and synthesize a concrete numbered improvement plan.

The platform list is data, never a list in these instructions. It is resolved from the capability registry at run time. Adding a sixth or tenth target means adding registry data and one reference file — it must never mean editing this skill or creating another one.

Hard constraint: never guess what's new. Every improvement step cites a URL that was actually fetched. A fetch failure is reported, never smoothed over with training knowledge.

Read before Step 1:

• references/registry.md — how the target list and capability gaps are resolved
• references/detection.md — cross-target detection rules
• references/analysis-protocol.md — the per-target analysis loop

Step 1 — Resolve the target list

Follow references/registry.md. Result: a set of target ids, each with a references/platforms/<id>.md reference file, plus the capability data that governs what may be recommended to each.

Report which registry source answered. If it was the fallback list, say so.

Step 2 — Detect which targets this repo uses

Glob and read the repo root (or the path passed as an argument). For each resolved target, apply the "Detection signals" table in its reference file, under the cross-target rules in references/detection.md. Record the signals that triggered each target and their strength.

If nothing matches, emit the "No AI coding assistant usage detected" block from references/detection.md and stop.

Step 3 — Analyse each detected target

Run references/analysis-protocol.md once per detected target, using that target's reference file as its data.

Parallelism is capability-gated. Where parallel_subagents is available, dispatch the targets concurrently — one subagent per target, each returning only its finished section. Where it is not, run them sequentially in the same session. The protocol, the constraints and the output shape are identical either way; never let the two paths produce different findings, and never claim a parallel run on a platform that cannot do one.

Collect every section before synthesizing.

Step 4 — Synthesize the unified improvement plan

Merge every target's section into one prioritized plan, sorted by:

1. Critical — breaking changes, deprecated patterns, silent capability loss between targets
2. Quick wins — high impact, minimal config change
3. Medium — meaningful, moderate effort
4. Low — optional

Merge duplicates: one step that applies to three targets is one step tagged with all three, never three steps.

Output format

# Platform Sync — Improvement Plan
**Repo:** <path>
**Registry source:** <core/capabilities/platforms.json | platform-targets.json | fallback>
**Targets resolved:** <all ids>  **Detected:** <ids with signals>
**Date:** <today>

---

## Improvement steps

### 1. <Step title> [<Platform>]
**Why:** one sentence — the benefit or the risk
**Effort:** low | medium | high
**Change:**
```<lang>
<concrete config or code snippet>

Source:

Already well-used

• : correctly implemented ✓ ()

Documented gaps (not improvements)

• on : unsupported | unverified —

Fetch errors

• : — (omit the section when there were none)

Summary table

### Rules

- Every step includes a concrete snippet. "Consider using X" is not a step.
- Tag steps with the target display names; merge cross-target steps rather than repeating.
- A target with no findings still gets a line: "No improvements found for <Platform> — config is current."
- Never propose a capability the registry marks `unsupported` or `unknown` — those go under
  "Documented gaps", labelled honestly as unsupported or unverified.
- Never emit a separate section for a runtime surface (Claude Desktop rides on Claude Code).
- Report every fetch error. A partial audit stated plainly beats a complete-looking guess.