research-tool-updates

# Research Tool Updates

TARGET = the user's request

Purpose: for every target tool rulesync supports, investigate the tool's recent
releases (official release notes / GitHub releases preferred), compare them
against rulesync's current implementation, and open a per-tool GitHub issue for
any upstream capability rulesync has not yet caught up with. When an issue for
that tool already exists, supplement it with a comment instead of filing a
duplicate.

The matrix bounds the per-tool research, so a full run also scouts **outside**
it: Step 2.5 looks for coding agents rulesync does not target yet and proposes
the strongest ones as new targets, so a tool gaining traction is not missed just
because nobody has added it to the matrix by hand.

## Step 0: Determine Scope

- If `TARGET` is provided, investigate **only that tool**. Accept either the
  display name (e.g., `Claude Code`) or the `--targets` id (e.g., `claudecode`).
  Validate it against the supported tool list from Step 1; if it does not match
  any known tool, stop and report the valid options.
- If `TARGET` is empty, investigate **all** supported target tools.

## Step 1: Enumerate Supported Target Tools

Read the **`Supported Tools and Features`** matrix in `README.md`. This matrix
is the authoritative source of what rulesync supports today. Extract, for each
in-scope tool:

- The display name and the `--targets` identifier.
- The currently supported feature columns (`rules`, `ignore`, `mcp`,
  `commands`, `subagents`, `skills`, `hooks`, `permissions`) and their scope
  markers, using the legend:
  - ✅ project mode, 🌏 global mode, 🎮 simulated (project only),
    🔧 MCP tool config.

Do not hardcode the tool list from memory — re-read the matrix each run so the
skill stays in sync with the README.

Then read `references/new-target-watchlist.md` in the `rulesync-feature-research`
skill. It records products that are not targets yet but were worth re-checking,
each with the condition that would change that. Evaluate every entry in the same
run: promote one whose condition is met to a target proposal (a GitHub issue,
after the duplicate check in Step 4-1) and remove it from the file, retire an
entry that can no longer be met, and leave the rest. Report which entries were
promoted, retired or left in the final report.

## Step 2: Launch One Research Subagent per Target Tool

For each in-scope tool, delegate the investigation to a subagent via the Agent
tool. Run them in parallel, but cap concurrency to roughly **5 at a time** to
avoid overload; launch the next wave as earlier ones finish.

- `subagent_type`: `general-purpose`
- Role framing: "You are researching upstream updates for a single coding-agent
  tool on behalf of rulesync."
- Inputs to pass:
  - The tool display name and `--targets` id.
  - The tool's matrix row (the features rulesync currently supports and their
    scope markers).
- Instructions to include in the subagent prompt:
  - Start from the `rulesync-feature-research` skill. If
    `references/<tool>.md` exists under that skill, use it as the map of the
    tool's official documentation and feature surfaces.
  - Research the tool's **recent releases**. Prefer primary sources: official
    release notes, changelogs, and GitHub releases. Use `WebSearch` and
    `WebFetch`, and confirm candidate URLs against the primary source. Capture
    exact version numbers, dates, and URLs.
  - For each rulesync feature dimension (`rules`, `ignore`, `mcp`, `commands`,
    `subagents`, `skills`, `hooks`, `permissions`), check whether the upstream
    tool has **introduced or changed** a capability that rulesync has **not yet
    followed** — e.g., new config keys, new file locations or naming, a new
    project/global scope, new hook events, new MCP transports, metadata fields,
    format changes, or deprecated surfaces that rulesync still emits.
  - Ground every claim in rulesync's actual implementation. Inspect the
    relevant `src/**` adapters and processor gates (prefer targeted symbol
    and search tools over reading whole files), and validate the generated output
    with a dry-run:

    ```bash
    pnpm run dev generate --targets <id> --features "*" --dry-run
    pnpm run dev generate --targets <id> --features "*" --global --dry-run
    ```

  - Return a structured report. For each gap include: the feature, the upstream
    capability with its source URL and version/date, rulesync's current
    behavior, and a concrete proposed follow-up. If there are no material gaps,
    return exactly `No gaps`.
  - Report only **material capability gaps** — do not list tests, fixtures, or
    refactor chores unless they are required to explain a gap.

## Step 2.5: Discover Coding Agents Rulesync Does Not Support Yet

Run this step only when `TARGET` is empty (a single-tool run has no discovery
scope). It is what keeps the skill from being blind to tools outside the matrix.

Launch **one** additional research subagent, in parallel with the Step 2 waves:

- `subagent_type`: `general-purpose`
- Role framing: "You are scouting coding agents that rulesync does not support
  yet, on behalf of rulesync."
- Inputs to pass:
  - The full list of supported display names and `--targets` ids from Step 1.
  - The candidates already recorded in `references/new-target-watchlist.md` in
    the `rulesync-feature-research` skill — the same file Step 1 reads —
    including the ones under `## Promoted entries` (they must not be
    re-proposed).
- Instructions to include in the subagent prompt:
  - Search the web for coding agents — CLI, IDE extension, or desktop app — that
    are **absent from that supported list**. Favor evidence of traction (GitHub
    stars and their recent growth, npm/PyPI download counts, a funded or
    well-known vendor, coverage in release notes or developer news) or of promise
    (active commits in the last three months, a differentiated capability, a
    published extension/plugin ecosystem).
  - For every candidate, confi