Skill1.2k repo starsupdated today
rulesync-feature-research
Rulesync Feature Research maps capabilities across multiple coding-agent platforms including Claude Code, Cursor, Copilot, and others against local implementation details. Use this when documenting feature parity, comparing agent tool support, or tracking which coding assistants support specific rulesync functionality through referenced markdown files for each platform.
Install in Claude Code
Copygit clone --depth 1 https://github.com/dyoshikawa/rulesync /tmp/rulesync-feature-research && cp -r /tmp/rulesync-feature-research/.rulesync/skills/rulesync-feature-research ~/.claude/skills/rulesync-feature-researchThen start a new Claude Code session; the skill loads automatically.
Definition
SKILL.md
# Rulesync Feature Research
## What
Build a reproducible map between a coding-agent client, an upstream feature
surface, and the local rulesync implementation.
| Request target | Read |
| ------------------------- | --------------------------------------------------------------------- |
| `antigravity` | `references/antigravity.md` |
| `augmentcode` | `references/augmentcode.md` |
| `claudecode` | `references/claudecode.md` |
| `cline` | `references/cline.md` |
| `codexcli` | `references/codexcli.md` |
| `copilot` | `references/copilot.md` |
| `copilotcli` | `references/copilotcli.md` |
| `cursor` | `references/cursor.md` |
| `deepagents` | `references/deepagents.md` |
| `factorydroid` | `references/factorydroid.md` |
| `geminicli` | `references/geminicli.md` |
| `goose` | `references/goose.md` |
| `junie` | `references/junie.md` |
| `kilo` | `references/kilo.md` |
| `kiro` | `references/kiro.md` |
| `opencode` | `references/opencode.md` |
| `pi` | `references/pi.md` |
| `qwencode` | `references/qwencode.md` |
| `replit` | `references/replit.md` |
| `roo` | `references/roo.md` |
| `rovodev` | `references/rovodev.md` |
| `takt` | `references/takt.md` |
| `warp` | `references/warp.md` |
| `windsurf` | `references/windsurf.md` |
| `zed` | `references/zed.md` |
| Any other rulesync target | `references/rulesync-source-map.md` + the closest existing client map |
A target without `references/<client>.md` is To be coming, not unsupported.
To add a client map:
1. Create `references/<client>.md` from the closest existing map.
2. Fill `Official Docs` with the client's docs URLs and feature surfaces.
3. Add `Client Anchors` only for behavior not obvious from `rulesync-source-map.md`.
4. Add the client to the request target table.
## Contract
Input:
| Field | Source |
| -------- | ---------------------------------------------------------------------- |
| Client | User prompt or issue text; validate with the rulesync target list |
| Question | Support check, diff, capability surface, issue triage, or new map work |
Reproducibility boundary: same question, official docs, local source tree, and
dry-run command/config.
Collect:
1. Canonical target and feature lists from `references/rulesync-source-map.md`.
2. Rulesync support labels from README, source, processor gates, and dry-run.
3. Official docs from the selected client map.
4. Re-check sentinel rows through official docs/site, then web search if needed;
confirm candidate URLs with Curl or Fetch. Recognized sentinel phrases:
- `No dedicated upstream <feature> surface in map` — upstream has no
dedicated docs surface that this row could point at.
- `No Rulesync-supported <feature> target in map` — no Rulesync adapter is
known to target this feature.
- `Rulesync maps <surface>; verify upstream before expanding behavior` —
Rulesync ships an adapter, but the upstream docs surface is thin or
missing; treat as low confidence until re-verified.
5. Client anchors for surfaces not obvious from naming rules.
6. Dry-run output for generator gates and output roots.
Scope:
- Inspect every rulesync feature for each requested client.
- Do not narrow the investigation by feature or surface.
- Do not explain scope normalization in the final answer.
Dry-run commands:
```bash
pnpm run dev generate --targets <client> --features "*" --dry-run
pnpm run dev generate --targets <client> --features "*" --global --dry-run
pnpm run dev generate --targets "*" --features "*" --dry-run
```
Use client all-feature dry-runs by default. Use the all-target dry-run for
cross-client questions. Dry-run is validation, not the answer.
Output:
1. Start with the result table.
| Feature | Agent surface | Rulesync support | Rulesync surface | Difference |
| ------- | ------------- | ---------------- | ---------------- | ---------- |
Use README-style support labels for Rulesync: `project`, `global`, `simulated`,
`unsupported`.
2. Add a surface table when the feature has sub-surfaces such as hook events,
MCP transports, permission actions, config keys, metadata fields, or output roots.
| Surface | Agent surface | Rulesync map | Difference |
| ------- | ------------- | ------------ | ---------- |
3. End with capability gaps.
Use this section title:
```markdownMore from this repository
create-issueSkill
>-
create-scrap-issueSkill
>-
draft-releaseSkill
Draft a new release of the project.
git-worktree-runnerSkill
>-
playwright-cliSkill
Automate browser interactions, test web pages and work with Playwright tests.
release-dry-runSkill
Dry run for release: summarize changes since last release and suggest version bump.
security-scan-diffSkill
Scan for malicious code in git diff between a tag/commit and HEAD
skill-creatorSkill
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.