From 87de8f429663e6c3788e15ee4c8fae584ae9d89e Mon Sep 17 00:00:00 2001 From: dyoshikawa Date: Thu, 6 Aug 2026 00:07:03 -0700 Subject: [PATCH 1/2] docs: note the stale global files HERMES_HOME leaves behind Setting HERMES_HOME after having generated global files with an earlier version leaves the files at the old default location untouched, because --delete only reaches the profile root Rulesync currently resolves. Co-Authored-By: Claude Fable 5 --- docs/reference/supported-tools.md | 7 +++++++ src/generated/docs-content.ts | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/reference/supported-tools.md b/docs/reference/supported-tools.md index fcd279dcc..858d6b4a1 100644 --- a/docs/reference/supported-tools.md +++ b/docs/reference/supported-tools.md @@ -71,6 +71,13 @@ platform default: `~/.hermes` everywhere except Windows, where it is the profile, it also takes precedence over `--output-roots` in global scope. Project-scoped paths remain rooted in the project. +If you set `HERMES_HOME` after having generated global files with an earlier +Rulesync version, the files written under the old default location (`~/.hermes/` +on macOS and Linux) are left behind: `--delete` only reaches the profile root +Rulesync currently resolves, so it no longer sees them. Remove them by hand once +you are sure Hermes no longer reads that directory. `--global --delete` orphan +removal now operates entirely under `$HERMES_HOME`. + Project plugins are registered by adding their names to `$HERMES_HOME/config.yaml`, but Rulesync does not persist Hermes's global project-plugin trust gate. Run Hermes from a trusted project root with diff --git a/src/generated/docs-content.ts b/src/generated/docs-content.ts index a15d26676..7a17f4e16 100644 --- a/src/generated/docs-content.ts +++ b/src/generated/docs-content.ts @@ -42,7 +42,7 @@ export const DOCS_CONTENT: Record = { "reference/mcp-server": '# Rulesync MCP Server\n\nRulesync provides an MCP (Model Context Protocol) server that enables AI agents to manage your Rulesync files. This allows AI agents to discover, read, create, update, and delete files dynamically.\n\n> [!NOTE]\n> The MCP server exposes the only one tool to minimize your agent\'s token usage. Approximately less than 1k tokens for the tool definition.\n\n## Supported Features and Operations\n\nThe single `rulesyncTool` multiplexes by `feature` and `operation`:\n\n- `rule`, `command`, `subagent`, `skill`: `list`, `get`, `put`, `delete`\n- `ignore`, `mcp`, `permissions`, `hooks`: `get`, `put`, `delete`\n- `generate`: `run`\n- `import`: `run`\n- `convert`: `run`\n\nThe `permissions` feature operates on `.rulesync/permissions.jsonc` and the `hooks` feature operates on `.rulesync/hooks.jsonc`. Both accept a `content` string (valid JSONC) on `put`.\n\n### `skill` other files\n\nA skill directory may contain files other than `SKILL.md`. They are passed as `otherFiles`, where each entry has:\n\n| Field | Type | Required | Description |\n| ---------- | --------------------- | -------- | ------------------------------------------------------------------------------ |\n| `name` | `string` | Yes | Path of the file relative to the skill directory (e.g. `references/logo.png`). |\n| `body` | `string` | Yes | File content, encoded according to `encoding`. |\n| `encoding` | `"utf-8" \\| "base64"` | No | Defaults to `"utf-8"`. Use `"base64"` for binary files such as images. |\n\nOn `get`, every returned entry carries an explicit `encoding`: `"utf-8"` when the file content survives a UTF-8 round trip unchanged, and `"base64"` otherwise. On `put`, the declared `encoding` is trusted and the decoded bytes are written verbatim, so binary files round-trip byte for byte.\n\nWhen feeding entries returned by `get` back into `put`, keep their `encoding` field. Dropping it makes a `"base64"` body be stored as literal text and corrupts the file.\n\nA `"base64"` body must be canonical base64 (the standard or the URL-safe alphabet, padding optional); otherwise `put` fails with `Invalid base64 body for other file `. The 1MB skill size limit is evaluated against the decoded byte length of each other file.\n\n### `convert` / `run` options\n\nWhen invoking `feature: "convert"` with `operation: "run"`, pass `convertOptions` with the following shape:\n\n| Option | Type | Required | Description |\n| ---------- | ---------- | -------- | ---------------------------------------------------------------------------------- |\n| `from` | `string` | Yes | Source tool name (e.g. `"claudecode"`). Must be a valid `ToolTarget`. |\n| `to` | `string[]` | Yes | One or more destination tool names. Must not be empty and must not include `from`. |\n| `features` | `string[]` | No | Features to convert (e.g. `["rules", "commands"]`). Defaults to `["*"]`. |\n| `global` | `boolean` | No | Convert global (user-scope) configurations. Defaults to `false`. |\n| `dryRun` | `boolean` | No | Preview changes without writing files. Defaults to `false`. |\n\n## Usage\n\n### Starting the MCP Server\n\n```bash\nrulesync mcp\n```\n\nThis starts an MCP server using stdio transport that AI agents can communicate with.\n\n### Configuration\n\nAdd the Rulesync MCP server to your `.rulesync/mcp.jsonc`:\n\n```json\n{\n "$schema": "https://github.com/dyoshikawa/rulesync/releases/latest/download/mcp-schema.json",\n "mcpServers": {\n "rulesync-mcp": {\n "type": "stdio",\n "command": "npx",\n "args": ["-y", "rulesync", "mcp"],\n "env": {}\n }\n }\n}\n```\n', "reference/supported-tools": - '# Supported Tools and Features\n\nRulesync supports both **generation** and **import** for All of the major AI coding tools:\n\n\n\n| Tool | --targets | rules | ignore | mcp | commands | subagents | skills | hooks | permissions | checks |\n| ------------------------- | ------------------ | :---: | :----: | :------: | :------: | :-------: | :----: | :---: | :---------: | :----: |\n| AGENTS.md | agentsmd | ✅ | | | 🎮 | 🎮 | 🎮 | | | |\n| AgentsSkills | agentsskills | | | | | | ✅ 🌏 | | | |\n| Amp | amp | ✅ 🌏 | | ✅ 🌏 | | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 |\n| Claude Code | claudecode | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Claude Code plugin | claudecode-plugin | | | ✅ | ✅ | ✅ | ✅ | ✅ | | |\n| Codex CLI | codexcli | ✅ 🌏 | | ✅ 🌏 🔧 | 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| GitHub Copilot | copilot | ✅ 🌏 | | ✅ | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| GitHub Copilot CLI | copilotcli | ✅ 🌏 | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | |\n| Goose | goose | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | ✅ 🌏 | 🌏 | |\n| Hermes Agent | hermesagent | ✅ | ✅ | 🌏 🔧 | 🌏 | ✅ 🌏 | 🌏 | 🌏 | 🌏 | ✅ |\n| Grok CLI | grokcli | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Cursor | cursor | ✅ | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ |\n| deepagents-cli | deepagents | ✅ 🌏 | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | 🌏 | | |\n| Factory Droid | factorydroid | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| OpenCode | opencode | ✅ 🌏 | | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Cline | cline | ✅ 🌏 | ✅ | 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ | |\n| Kilo Code | kilo | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Kimi Code | kimi-code | ✅ 🌏 | | ✅ 🌏 🔧 | | ✅ 🌏 | ✅ 🌏 | 🌏 | 🌏 | |\n| Roo Code | roo | ✅ 🌏 | ✅ | ✅ | ✅ 🌏 | ✅ | ✅ 🌏 | | | |\n| Zoo Code | zoocode | ✅ 🌏 | ✅ | ✅ | ✅ 🌏 | ✅ | ✅ 🌏 | | | |\n| Rovodev (Atlassian) | rovodev | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | ✅ |\n| Takt | takt | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 |\n| Vibe Code | vibe | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Qwen Code | qwencode | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Reasonix | reasonix | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Kiro ⚠️ | kiro | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ | ✅ | ✅ | ✅ | ✅ | |\n| Kiro CLI | kiro-cli | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | ✅ | |\n| Kiro IDE | kiro-ide | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| Google Antigravity IDE | antigravity-ide | ✅ 🌏 | | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| Google Antigravity CLI | antigravity-cli | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | 🌏 | |\n| Google Antigravity plugin | antigravity-plugin | ✅ | | ✅ 🔧 | | ✅ | ✅ | ✅ | | |\n| JetBrains AI Assistant | aiassistant | ✅ | ✅ | ✅ 🌏 | | | ✅ | | | |\n| JetBrains Junie | junie | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | 🌏 | 🌏 | |\n| AugmentCode | augmentcode | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Devin Desktop | devin | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Warp | warp | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | | 🌏 | |\n| Replit | replit | ✅ | | | | | ✅ 🌏 | | | |\n| Pi Coding Agent | pi | ✅ 🌏 | | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | | |\n| Zed | zed | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | | ✅ 🌏 | | ✅ 🌏 | |\n\n\n\n- ✅: Supports project mode\n- 🌏: Supports global mode\n- 🎮: Supports simulated commands/subagents/skills (Project mode only)\n- 🔧: Supports MCP tool config (`enabledTools`/`disabledTools`)\n- ⚠️: Deprecated — still supported, but see the note below\n\n## Hermes Agent compatibility\n\nThe `hermesagent` target is validated against Hermes Agent v0.19.0 (release\n`v2026.7.20`). The supported contract covers project rules, ignore patterns,\nsubagents, and checks, plus global MCP servers, commands, subagents, skills,\nhooks, and permissions. Generation, `--check`, and import round-trips are\ncovered for both advertised scopes.\n\nRulesync honors Hermes profiles through `HERMES_HOME`. When it is set, its value\nis the profile root itself: global configuration is read and written directly\nunder `$HERMES_HOME` (`config.yaml`, `skills/`, `plugins/`, and `rulesync/`),\nwithout appending `.hermes`. When it is unset, Rulesync follows Hermes\'s own\nplatform default: `~/.hermes` everywhere except Windows, where it is\n`%LOCALAPPDATA%\\hermes`. Because `HERMES_HOME` names where Hermes itself reads\nthe profile, it also takes precedence over `--output-roots` in global scope.\nProject-scoped paths remain rooted in the project.\n\nProject plugins are registered by adding their names to\n`$HERMES_HOME/config.yaml`, but Rulesync does not persist Hermes\'s global\nproject-plugin trust gate. Run Hermes from a trusted project root with\n`HERMES_ENABLE_PROJECT_PLUGINS=true` for an explicit, session-scoped opt-in. A\nfuture Hermes release that changes its loaders, schemas, or plugin API requires\na new compatibility validation.\n\n## Deprecation notes\n\n- **Google Antigravity (`antigravity-ide` / `antigravity-cli`)** — Antigravity 2.0 splits into two products: the desktop **`antigravity-ide`** and the **`antigravity-cli`** (`agy`). As of Antigravity 2.0 the IDE reads its global MCP config and skills from the shared `~/.gemini/config/` tree — `~/.gemini/config/mcp_config.json` and `~/.gemini/config/skills/`, matching the current [MCP](https://antigravity.google/docs/mcp) and [Skills](https://antigravity.google/docs/skills) docs. The `antigravity-cli` global MCP config also lives in the shared `~/.gemini/config/mcp_config.json`, while the CLI keeps its own global skills tree at `~/.gemini/antigravity-cli/skills/`. Both targets also intentionally **share** the global rule file `~/.gemini/GEMINI.md` and the global hooks file `~/.gemini/config/hooks.json` — enabling both targets in `--global` mode writes those shared files once. For project-scope rules, **both `antigravity-ide` and `antigravity-cli`** emit the root rule as a plain cross-tool **`AGENTS.md`** at the project root (the Gemini-lineage discovery order is `AGENTS.md`, `CONTEXT.md`, `GEMINI.md`; the IDE has read `AGENTS.md` since v1.20.3) and non-root rules under `.agents/rules/` (the IDE adds trigger frontmatter to non-root rules; the CLI keeps them as plain markdown). For **commands (workflows)**, both targets share the project `.agents/workflows/` directory (invoked as `/workflow-name`); in `--global` mode the IDE writes to `~/.gemini/antigravity/global_workflows/` while the CLI keeps its own `~/.gemini/antigravity-cli/global_workflows/` tree (mirroring the CLI\'s global skills tree).\n- **Kiro (`kiro`)** — Kiro ships as two products with diverging config formats: the **Kiro IDE** reads Markdown subagents (`.kiro/agents/*.md`) and structured JSON hooks (`.kiro/hooks/*.json`, format `{ "version": "v1", "hooks": [ ... ] }`), while the **Kiro CLI** reads JSON agent-config subagents (`.kiro/agents/*.json`) and agent hooks in `.kiro/agents/default.json`. A single target cannot emit both faithfully, so `kiro` is split into **`kiro-cli`** and **`kiro-ide`**. The legacy `kiro` target is kept as a **deprecated alias** (its current mixed output is unchanged for backward compatibility). Shared surfaces (steering rules with `inclusion`, `.kiro/settings/mcp.json`, `.kiro/prompts/` commands, `.kiro/skills/`, `.kiroignore`, permissions) are identical between the two; they differ in **subagents** (`.md` vs `.json`) and **hooks**. Kiro IDE **hooks** are emitted as a single `.kiro/hooks/rulesync.json` (whose `hooks` array holds every generated hook) in both project (`.kiro/hooks/`) and global (`~/.kiro/hooks/`) scope, mapping canonical lifecycle events to the IDE\'s PascalCase triggers (`SessionStart`, `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, `Stop`) and supporting both `agent` (prompt) and `command` actions; the Kiro CLI continues to emit agent hooks in `.kiro/agents/default.json`, including `cacheTtl` ⇄ `cache_ttl_seconds`. Global **skills** (`~/.kiro/skills/`), global **ignore** (`~/.kiro/settings/kiroignore`), and global Kiro IDE **subagents** (`~/.kiro/agents/`) are also supported, as are global Kiro CLI **commands** (`~/.kiro/prompts/`) and **subagents** (`~/.kiro/agents/`). Kiro\'s shared MCP file preserves per-server `disabledTools`.\n', + '# Supported Tools and Features\n\nRulesync supports both **generation** and **import** for All of the major AI coding tools:\n\n\n\n| Tool | --targets | rules | ignore | mcp | commands | subagents | skills | hooks | permissions | checks |\n| ------------------------- | ------------------ | :---: | :----: | :------: | :------: | :-------: | :----: | :---: | :---------: | :----: |\n| AGENTS.md | agentsmd | ✅ | | | 🎮 | 🎮 | 🎮 | | | |\n| AgentsSkills | agentsskills | | | | | | ✅ 🌏 | | | |\n| Amp | amp | ✅ 🌏 | | ✅ 🌏 | | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 |\n| Claude Code | claudecode | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Claude Code plugin | claudecode-plugin | | | ✅ | ✅ | ✅ | ✅ | ✅ | | |\n| Codex CLI | codexcli | ✅ 🌏 | | ✅ 🌏 🔧 | 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| GitHub Copilot | copilot | ✅ 🌏 | | ✅ | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| GitHub Copilot CLI | copilotcli | ✅ 🌏 | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | |\n| Goose | goose | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | ✅ 🌏 | 🌏 | |\n| Hermes Agent | hermesagent | ✅ | ✅ | 🌏 🔧 | 🌏 | ✅ 🌏 | 🌏 | 🌏 | 🌏 | ✅ |\n| Grok CLI | grokcli | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Cursor | cursor | ✅ | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ |\n| deepagents-cli | deepagents | ✅ 🌏 | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | 🌏 | | |\n| Factory Droid | factorydroid | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| OpenCode | opencode | ✅ 🌏 | | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Cline | cline | ✅ 🌏 | ✅ | 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ | |\n| Kilo Code | kilo | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Kimi Code | kimi-code | ✅ 🌏 | | ✅ 🌏 🔧 | | ✅ 🌏 | ✅ 🌏 | 🌏 | 🌏 | |\n| Roo Code | roo | ✅ 🌏 | ✅ | ✅ | ✅ 🌏 | ✅ | ✅ 🌏 | | | |\n| Zoo Code | zoocode | ✅ 🌏 | ✅ | ✅ | ✅ 🌏 | ✅ | ✅ 🌏 | | | |\n| Rovodev (Atlassian) | rovodev | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | ✅ |\n| Takt | takt | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 |\n| Vibe Code | vibe | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Qwen Code | qwencode | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Reasonix | reasonix | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Kiro ⚠️ | kiro | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ | ✅ | ✅ | ✅ | ✅ | |\n| Kiro CLI | kiro-cli | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | ✅ | |\n| Kiro IDE | kiro-ide | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| Google Antigravity IDE | antigravity-ide | ✅ 🌏 | | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| Google Antigravity CLI | antigravity-cli | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | 🌏 | |\n| Google Antigravity plugin | antigravity-plugin | ✅ | | ✅ 🔧 | | ✅ | ✅ | ✅ | | |\n| JetBrains AI Assistant | aiassistant | ✅ | ✅ | ✅ 🌏 | | | ✅ | | | |\n| JetBrains Junie | junie | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | 🌏 | 🌏 | |\n| AugmentCode | augmentcode | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Devin Desktop | devin | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Warp | warp | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | | 🌏 | |\n| Replit | replit | ✅ | | | | | ✅ 🌏 | | | |\n| Pi Coding Agent | pi | ✅ 🌏 | | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | | |\n| Zed | zed | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | | ✅ 🌏 | | ✅ 🌏 | |\n\n\n\n- ✅: Supports project mode\n- 🌏: Supports global mode\n- 🎮: Supports simulated commands/subagents/skills (Project mode only)\n- 🔧: Supports MCP tool config (`enabledTools`/`disabledTools`)\n- ⚠️: Deprecated — still supported, but see the note below\n\n## Hermes Agent compatibility\n\nThe `hermesagent` target is validated against Hermes Agent v0.19.0 (release\n`v2026.7.20`). The supported contract covers project rules, ignore patterns,\nsubagents, and checks, plus global MCP servers, commands, subagents, skills,\nhooks, and permissions. Generation, `--check`, and import round-trips are\ncovered for both advertised scopes.\n\nRulesync honors Hermes profiles through `HERMES_HOME`. When it is set, its value\nis the profile root itself: global configuration is read and written directly\nunder `$HERMES_HOME` (`config.yaml`, `skills/`, `plugins/`, and `rulesync/`),\nwithout appending `.hermes`. When it is unset, Rulesync follows Hermes\'s own\nplatform default: `~/.hermes` everywhere except Windows, where it is\n`%LOCALAPPDATA%\\hermes`. Because `HERMES_HOME` names where Hermes itself reads\nthe profile, it also takes precedence over `--output-roots` in global scope.\nProject-scoped paths remain rooted in the project.\n\nIf you set `HERMES_HOME` after having generated global files with an earlier\nRulesync version, the files written under the old default location (`~/.hermes/`\non macOS and Linux) are left behind: `--delete` only reaches the profile root\nRulesync currently resolves, so it no longer sees them. Remove them by hand once\nyou are sure Hermes no longer reads that directory. `--global --delete` orphan\nremoval now operates entirely under `$HERMES_HOME`.\n\nProject plugins are registered by adding their names to\n`$HERMES_HOME/config.yaml`, but Rulesync does not persist Hermes\'s global\nproject-plugin trust gate. Run Hermes from a trusted project root with\n`HERMES_ENABLE_PROJECT_PLUGINS=true` for an explicit, session-scoped opt-in. A\nfuture Hermes release that changes its loaders, schemas, or plugin API requires\na new compatibility validation.\n\n## Deprecation notes\n\n- **Google Antigravity (`antigravity-ide` / `antigravity-cli`)** — Antigravity 2.0 splits into two products: the desktop **`antigravity-ide`** and the **`antigravity-cli`** (`agy`). As of Antigravity 2.0 the IDE reads its global MCP config and skills from the shared `~/.gemini/config/` tree — `~/.gemini/config/mcp_config.json` and `~/.gemini/config/skills/`, matching the current [MCP](https://antigravity.google/docs/mcp) and [Skills](https://antigravity.google/docs/skills) docs. The `antigravity-cli` global MCP config also lives in the shared `~/.gemini/config/mcp_config.json`, while the CLI keeps its own global skills tree at `~/.gemini/antigravity-cli/skills/`. Both targets also intentionally **share** the global rule file `~/.gemini/GEMINI.md` and the global hooks file `~/.gemini/config/hooks.json` — enabling both targets in `--global` mode writes those shared files once. For project-scope rules, **both `antigravity-ide` and `antigravity-cli`** emit the root rule as a plain cross-tool **`AGENTS.md`** at the project root (the Gemini-lineage discovery order is `AGENTS.md`, `CONTEXT.md`, `GEMINI.md`; the IDE has read `AGENTS.md` since v1.20.3) and non-root rules under `.agents/rules/` (the IDE adds trigger frontmatter to non-root rules; the CLI keeps them as plain markdown). For **commands (workflows)**, both targets share the project `.agents/workflows/` directory (invoked as `/workflow-name`); in `--global` mode the IDE writes to `~/.gemini/antigravity/global_workflows/` while the CLI keeps its own `~/.gemini/antigravity-cli/global_workflows/` tree (mirroring the CLI\'s global skills tree).\n- **Kiro (`kiro`)** — Kiro ships as two products with diverging config formats: the **Kiro IDE** reads Markdown subagents (`.kiro/agents/*.md`) and structured JSON hooks (`.kiro/hooks/*.json`, format `{ "version": "v1", "hooks": [ ... ] }`), while the **Kiro CLI** reads JSON agent-config subagents (`.kiro/agents/*.json`) and agent hooks in `.kiro/agents/default.json`. A single target cannot emit both faithfully, so `kiro` is split into **`kiro-cli`** and **`kiro-ide`**. The legacy `kiro` target is kept as a **deprecated alias** (its current mixed output is unchanged for backward compatibility). Shared surfaces (steering rules with `inclusion`, `.kiro/settings/mcp.json`, `.kiro/prompts/` commands, `.kiro/skills/`, `.kiroignore`, permissions) are identical between the two; they differ in **subagents** (`.md` vs `.json`) and **hooks**. Kiro IDE **hooks** are emitted as a single `.kiro/hooks/rulesync.json` (whose `hooks` array holds every generated hook) in both project (`.kiro/hooks/`) and global (`~/.kiro/hooks/`) scope, mapping canonical lifecycle events to the IDE\'s PascalCase triggers (`SessionStart`, `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, `Stop`) and supporting both `agent` (prompt) and `command` actions; the Kiro CLI continues to emit agent hooks in `.kiro/agents/default.json`, including `cacheTtl` ⇄ `cache_ttl_seconds`. Global **skills** (`~/.kiro/skills/`), global **ignore** (`~/.kiro/settings/kiroignore`), and global Kiro IDE **subagents** (`~/.kiro/agents/`) are also supported, as are global Kiro CLI **commands** (`~/.kiro/prompts/`) and **subagents** (`~/.kiro/agents/`). Kiro\'s shared MCP file preserves per-server `disabledTools`.\n', "tools/takt": "# Takt\n\n[Takt](https://github.com/nrslib/takt) is a faceted-prompting AI coding workflow tool. Rulesync generates plain-Markdown facet files into Takt's `.takt/facets/` layout (or `~/.takt/facets/` in global mode).\n\n## Output mapping\n\nEach rulesync feature maps onto a dedicated Takt facet directory. The target directory is fixed per feature, except that **rules** may opt into Takt's fifth facet — `output-contracts` — via the `takt.facet` override (see below).\n\n| Rulesync feature | Takt facet directory |\n| ---------------- | --------------------------------------------------------------------------------------- |\n| `rules` | `.takt/facets/policies/` (default) or `.takt/facets/output-contracts/` via `takt.facet` |\n| `commands` | `.takt/facets/instructions/` |\n| `subagents` | `.takt/facets/personas/` |\n| `skills` | `.takt/facets/knowledge/` |\n\nTakt-specific frontmatter knobs:\n\n```yaml\n---\ntakt:\n name: my-renamed-stem # rename the emitted filename stem\n extends: base # emit a leading {extends:base} facet-inheritance directive\n facet: output-contracts # \"policies\" (default) or \"output-contracts\"\n---\n```\n\n- `takt.name` is **optional**; the source filename stem is used by default. Unsafe values (path separators, `..` segments, etc.) raise a hard validation error at `generate` time.\n- `takt.facet` is **optional** and defaults to `policies`. Setting it to `output-contracts` redirects the rule to Takt's output-structure / report-template facet, which has no dedicated rulesync feature. Both `policies` and `output-contracts` support `{extends:...}` inheritance. The other facets (`instructions`, `personas`, `knowledge`) are owned by the commands, subagents, and skills features and are not selectable via `takt.facet`.\n- Like `takt.name` and `takt.extends`, `takt.facet` is a generate-side authoring control. Because Takt facet files are plain Markdown with no frontmatter, the facet selection cannot be recovered on import (see [Importing](#importing-existing-takt-files-into-rulesync) below).\n\nOutput files are **plain Markdown** — the source frontmatter is dropped entirely and the body is written verbatim:\n\n```\n.rulesync/rules/style.md → .takt/facets/policies/style.md\n.rulesync/rules/review-format.md → .takt/facets/output-contracts/review-format.md (with takt.facet: output-contracts)\n.rulesync/commands/review.md → .takt/facets/instructions/review.md\n.rulesync/subagents/coder.md → .takt/facets/personas/coder.md\n.rulesync/skills/oncall/SKILL.md → .takt/facets/knowledge/oncall.md\n```\n\n## MCP (partial — transport allowlist only)\n\nTakt has no project- or global-level registry of MCP server _definitions_: the concrete `mcp_servers` map (`command`/`args`/`env` or `type`/`url`/`headers`) is declared **per workflow step** inside individual workflow YAML files, and Takt's `config.yaml` loader rejects unknown top-level keys. The one MCP knob `config.yaml` does expose is the **default-deny transport allowlist** `workflow_mcp_servers: { stdio, sse, http }`; until a transport is enabled there, every workflow-defined MCP server using it is refused.\n\nRulesync therefore emits **only** this allowlist into the shared `.takt/config.yaml` (project) / `~/.takt/config.yaml` (global), turning on exactly the transports the servers in `.rulesync/mcp.jsonc` use (`local`/`stdio` → `stdio`, `sse` → `sse`, `http`/`streamable-http`/`ws` → `http`). The merge is in place, so the active provider, provider profiles, and all other config keys are preserved; the file is never deleted.\n\n**Lossiness:** the per-server names, commands, env, URLs, and headers are not representable in `config.yaml` and are intentionally not written — you still declare the concrete servers in your workflow YAML steps; Rulesync only opens the transport gate that permits them. Because of this, reverse import cannot reconstruct server definitions and yields an empty `mcpServers` map.\n\n## Checks — quality gates\n\n`.rulesync/checks/*.md` become TAKT **quality gates** in the `workflow_overrides` block of the shared `config.yaml`. A check's body is a string gate — a completion directive TAKT injects into the agent step prompt — unless the check's `takt` frontmatter block names a `command`, which makes it a command gate TAKT runs after the step, failing the gate on a non-zero exit.\n\n**A command gate runs unconditionally.** TAKT's default-deny `workflow_command_gates.custom_scripts` policy applies to gates declared in workflow YAML, not to gates coming from `workflow_overrides`, so a `takt.command` in a check is executed after every step it applies to with no further gating. Read the frontmatter of any check you obtain with `rulesync fetch` before generating.\n\n**Lossiness:** TAKT gates carry no severity or tool allowlist, so a check's `severity` and `tools` fields are not written and do not come back on import.\n\n`quality_gates_edit_only` in a check's `takt` block applies to the whole block, and reaches only the gates with no `steps` / `personas` scope — TAKT runs a scoped gate whether or not the step may edit files.\n\nThe block is owned by the checks feature: it is rewritten from `.rulesync/checks/` on every generate, and retracted when checks remain but none target TAKT. Emptying `.rulesync/checks/` altogether leaves the gates in place — the feature has no source to generate from — so delete them by hand in that case. See [file formats](../reference/file-formats.md) for the frontmatter reference.\n\n## Scope\n\nBoth project mode (`.takt/facets/...`, `.takt/config.yaml`) and global mode (`~/.takt/facets/...`, `~/.takt/config.yaml`) are supported.\n\n## Importing existing TAKT files into rulesync\n\nImporting the **facet** features (rules, commands, subagents, skills) is **not supported**. TAKT facet files are plain Markdown with no frontmatter, so the original skill / command / subagent metadata cannot be recovered. Attempting to import a TAKT skill raises a clear error rather than silently producing a stub that round-trips badly.\n\nThe `config.yaml` features do import: `rulesync import --targets takt --features checks` reads the quality gates back into `.rulesync/checks/`, and `--features permissions` reads the permission mode and the Takt-specific override keys. MCP is the exception noted above — the allowlist carries no server definitions to reconstruct.\n", }; From f5f9911dbd580c2784946b1aff2a818d50cfda3f Mon Sep 17 00:00:00 2001 From: dyoshikawa Date: Thu, 6 Aug 2026 00:10:06 -0700 Subject: [PATCH 2/2] docs: make the Hermes migration note version- and platform-accurate Address review: the stranding happens whenever the resolved profile root changes, not only on an upgrade, and Windows moved too (before v16.2.0 its global files went to ~/.hermes rather than %LOCALAPPDATA%\hermes). Dropped the redundant closing sentence. Co-Authored-By: Claude Fable 5 --- docs/reference/supported-tools.md | 14 ++++++++------ src/generated/docs-content.ts | 2 +- 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/docs/reference/supported-tools.md b/docs/reference/supported-tools.md index 858d6b4a1..c39608112 100644 --- a/docs/reference/supported-tools.md +++ b/docs/reference/supported-tools.md @@ -71,12 +71,14 @@ platform default: `~/.hermes` everywhere except Windows, where it is the profile, it also takes precedence over `--output-roots` in global scope. Project-scoped paths remain rooted in the project. -If you set `HERMES_HOME` after having generated global files with an earlier -Rulesync version, the files written under the old default location (`~/.hermes/` -on macOS and Linux) are left behind: `--delete` only reaches the profile root -Rulesync currently resolves, so it no longer sees them. Remove them by hand once -you are sure Hermes no longer reads that directory. `--global --delete` orphan -removal now operates entirely under `$HERMES_HOME`. +Changing which profile root Rulesync resolves strands whatever it generated +under the previous one. `--delete` reconciles only the root resolved for the +current run, so files under a root it no longer resolves are invisible to it and +must be removed by hand once you are sure Hermes no longer reads them. This +applies whenever you set or change `HERMES_HOME`, and to two upgrades that moved +the resolved root on their own: before v16.0.0 global files went to `~/.hermes` +even when `HERMES_HOME` was set, and before v16.2.0 they went there on Windows +too, rather than to `%LOCALAPPDATA%\hermes`. Project plugins are registered by adding their names to `$HERMES_HOME/config.yaml`, but Rulesync does not persist Hermes's global diff --git a/src/generated/docs-content.ts b/src/generated/docs-content.ts index 7a17f4e16..4a7ea1349 100644 --- a/src/generated/docs-content.ts +++ b/src/generated/docs-content.ts @@ -42,7 +42,7 @@ export const DOCS_CONTENT: Record = { "reference/mcp-server": '# Rulesync MCP Server\n\nRulesync provides an MCP (Model Context Protocol) server that enables AI agents to manage your Rulesync files. This allows AI agents to discover, read, create, update, and delete files dynamically.\n\n> [!NOTE]\n> The MCP server exposes the only one tool to minimize your agent\'s token usage. Approximately less than 1k tokens for the tool definition.\n\n## Supported Features and Operations\n\nThe single `rulesyncTool` multiplexes by `feature` and `operation`:\n\n- `rule`, `command`, `subagent`, `skill`: `list`, `get`, `put`, `delete`\n- `ignore`, `mcp`, `permissions`, `hooks`: `get`, `put`, `delete`\n- `generate`: `run`\n- `import`: `run`\n- `convert`: `run`\n\nThe `permissions` feature operates on `.rulesync/permissions.jsonc` and the `hooks` feature operates on `.rulesync/hooks.jsonc`. Both accept a `content` string (valid JSONC) on `put`.\n\n### `skill` other files\n\nA skill directory may contain files other than `SKILL.md`. They are passed as `otherFiles`, where each entry has:\n\n| Field | Type | Required | Description |\n| ---------- | --------------------- | -------- | ------------------------------------------------------------------------------ |\n| `name` | `string` | Yes | Path of the file relative to the skill directory (e.g. `references/logo.png`). |\n| `body` | `string` | Yes | File content, encoded according to `encoding`. |\n| `encoding` | `"utf-8" \\| "base64"` | No | Defaults to `"utf-8"`. Use `"base64"` for binary files such as images. |\n\nOn `get`, every returned entry carries an explicit `encoding`: `"utf-8"` when the file content survives a UTF-8 round trip unchanged, and `"base64"` otherwise. On `put`, the declared `encoding` is trusted and the decoded bytes are written verbatim, so binary files round-trip byte for byte.\n\nWhen feeding entries returned by `get` back into `put`, keep their `encoding` field. Dropping it makes a `"base64"` body be stored as literal text and corrupts the file.\n\nA `"base64"` body must be canonical base64 (the standard or the URL-safe alphabet, padding optional); otherwise `put` fails with `Invalid base64 body for other file `. The 1MB skill size limit is evaluated against the decoded byte length of each other file.\n\n### `convert` / `run` options\n\nWhen invoking `feature: "convert"` with `operation: "run"`, pass `convertOptions` with the following shape:\n\n| Option | Type | Required | Description |\n| ---------- | ---------- | -------- | ---------------------------------------------------------------------------------- |\n| `from` | `string` | Yes | Source tool name (e.g. `"claudecode"`). Must be a valid `ToolTarget`. |\n| `to` | `string[]` | Yes | One or more destination tool names. Must not be empty and must not include `from`. |\n| `features` | `string[]` | No | Features to convert (e.g. `["rules", "commands"]`). Defaults to `["*"]`. |\n| `global` | `boolean` | No | Convert global (user-scope) configurations. Defaults to `false`. |\n| `dryRun` | `boolean` | No | Preview changes without writing files. Defaults to `false`. |\n\n## Usage\n\n### Starting the MCP Server\n\n```bash\nrulesync mcp\n```\n\nThis starts an MCP server using stdio transport that AI agents can communicate with.\n\n### Configuration\n\nAdd the Rulesync MCP server to your `.rulesync/mcp.jsonc`:\n\n```json\n{\n "$schema": "https://github.com/dyoshikawa/rulesync/releases/latest/download/mcp-schema.json",\n "mcpServers": {\n "rulesync-mcp": {\n "type": "stdio",\n "command": "npx",\n "args": ["-y", "rulesync", "mcp"],\n "env": {}\n }\n }\n}\n```\n', "reference/supported-tools": - '# Supported Tools and Features\n\nRulesync supports both **generation** and **import** for All of the major AI coding tools:\n\n\n\n| Tool | --targets | rules | ignore | mcp | commands | subagents | skills | hooks | permissions | checks |\n| ------------------------- | ------------------ | :---: | :----: | :------: | :------: | :-------: | :----: | :---: | :---------: | :----: |\n| AGENTS.md | agentsmd | ✅ | | | 🎮 | 🎮 | 🎮 | | | |\n| AgentsSkills | agentsskills | | | | | | ✅ 🌏 | | | |\n| Amp | amp | ✅ 🌏 | | ✅ 🌏 | | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 |\n| Claude Code | claudecode | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Claude Code plugin | claudecode-plugin | | | ✅ | ✅ | ✅ | ✅ | ✅ | | |\n| Codex CLI | codexcli | ✅ 🌏 | | ✅ 🌏 🔧 | 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| GitHub Copilot | copilot | ✅ 🌏 | | ✅ | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| GitHub Copilot CLI | copilotcli | ✅ 🌏 | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | |\n| Goose | goose | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | ✅ 🌏 | 🌏 | |\n| Hermes Agent | hermesagent | ✅ | ✅ | 🌏 🔧 | 🌏 | ✅ 🌏 | 🌏 | 🌏 | 🌏 | ✅ |\n| Grok CLI | grokcli | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Cursor | cursor | ✅ | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ |\n| deepagents-cli | deepagents | ✅ 🌏 | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | 🌏 | | |\n| Factory Droid | factorydroid | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| OpenCode | opencode | ✅ 🌏 | | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Cline | cline | ✅ 🌏 | ✅ | 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ | |\n| Kilo Code | kilo | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Kimi Code | kimi-code | ✅ 🌏 | | ✅ 🌏 🔧 | | ✅ 🌏 | ✅ 🌏 | 🌏 | 🌏 | |\n| Roo Code | roo | ✅ 🌏 | ✅ | ✅ | ✅ 🌏 | ✅ | ✅ 🌏 | | | |\n| Zoo Code | zoocode | ✅ 🌏 | ✅ | ✅ | ✅ 🌏 | ✅ | ✅ 🌏 | | | |\n| Rovodev (Atlassian) | rovodev | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | ✅ |\n| Takt | takt | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 |\n| Vibe Code | vibe | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Qwen Code | qwencode | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Reasonix | reasonix | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Kiro ⚠️ | kiro | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ | ✅ | ✅ | ✅ | ✅ | |\n| Kiro CLI | kiro-cli | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | ✅ | |\n| Kiro IDE | kiro-ide | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| Google Antigravity IDE | antigravity-ide | ✅ 🌏 | | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| Google Antigravity CLI | antigravity-cli | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | 🌏 | |\n| Google Antigravity plugin | antigravity-plugin | ✅ | | ✅ 🔧 | | ✅ | ✅ | ✅ | | |\n| JetBrains AI Assistant | aiassistant | ✅ | ✅ | ✅ 🌏 | | | ✅ | | | |\n| JetBrains Junie | junie | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | 🌏 | 🌏 | |\n| AugmentCode | augmentcode | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Devin Desktop | devin | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Warp | warp | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | | 🌏 | |\n| Replit | replit | ✅ | | | | | ✅ 🌏 | | | |\n| Pi Coding Agent | pi | ✅ 🌏 | | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | | |\n| Zed | zed | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | | ✅ 🌏 | | ✅ 🌏 | |\n\n\n\n- ✅: Supports project mode\n- 🌏: Supports global mode\n- 🎮: Supports simulated commands/subagents/skills (Project mode only)\n- 🔧: Supports MCP tool config (`enabledTools`/`disabledTools`)\n- ⚠️: Deprecated — still supported, but see the note below\n\n## Hermes Agent compatibility\n\nThe `hermesagent` target is validated against Hermes Agent v0.19.0 (release\n`v2026.7.20`). The supported contract covers project rules, ignore patterns,\nsubagents, and checks, plus global MCP servers, commands, subagents, skills,\nhooks, and permissions. Generation, `--check`, and import round-trips are\ncovered for both advertised scopes.\n\nRulesync honors Hermes profiles through `HERMES_HOME`. When it is set, its value\nis the profile root itself: global configuration is read and written directly\nunder `$HERMES_HOME` (`config.yaml`, `skills/`, `plugins/`, and `rulesync/`),\nwithout appending `.hermes`. When it is unset, Rulesync follows Hermes\'s own\nplatform default: `~/.hermes` everywhere except Windows, where it is\n`%LOCALAPPDATA%\\hermes`. Because `HERMES_HOME` names where Hermes itself reads\nthe profile, it also takes precedence over `--output-roots` in global scope.\nProject-scoped paths remain rooted in the project.\n\nIf you set `HERMES_HOME` after having generated global files with an earlier\nRulesync version, the files written under the old default location (`~/.hermes/`\non macOS and Linux) are left behind: `--delete` only reaches the profile root\nRulesync currently resolves, so it no longer sees them. Remove them by hand once\nyou are sure Hermes no longer reads that directory. `--global --delete` orphan\nremoval now operates entirely under `$HERMES_HOME`.\n\nProject plugins are registered by adding their names to\n`$HERMES_HOME/config.yaml`, but Rulesync does not persist Hermes\'s global\nproject-plugin trust gate. Run Hermes from a trusted project root with\n`HERMES_ENABLE_PROJECT_PLUGINS=true` for an explicit, session-scoped opt-in. A\nfuture Hermes release that changes its loaders, schemas, or plugin API requires\na new compatibility validation.\n\n## Deprecation notes\n\n- **Google Antigravity (`antigravity-ide` / `antigravity-cli`)** — Antigravity 2.0 splits into two products: the desktop **`antigravity-ide`** and the **`antigravity-cli`** (`agy`). As of Antigravity 2.0 the IDE reads its global MCP config and skills from the shared `~/.gemini/config/` tree — `~/.gemini/config/mcp_config.json` and `~/.gemini/config/skills/`, matching the current [MCP](https://antigravity.google/docs/mcp) and [Skills](https://antigravity.google/docs/skills) docs. The `antigravity-cli` global MCP config also lives in the shared `~/.gemini/config/mcp_config.json`, while the CLI keeps its own global skills tree at `~/.gemini/antigravity-cli/skills/`. Both targets also intentionally **share** the global rule file `~/.gemini/GEMINI.md` and the global hooks file `~/.gemini/config/hooks.json` — enabling both targets in `--global` mode writes those shared files once. For project-scope rules, **both `antigravity-ide` and `antigravity-cli`** emit the root rule as a plain cross-tool **`AGENTS.md`** at the project root (the Gemini-lineage discovery order is `AGENTS.md`, `CONTEXT.md`, `GEMINI.md`; the IDE has read `AGENTS.md` since v1.20.3) and non-root rules under `.agents/rules/` (the IDE adds trigger frontmatter to non-root rules; the CLI keeps them as plain markdown). For **commands (workflows)**, both targets share the project `.agents/workflows/` directory (invoked as `/workflow-name`); in `--global` mode the IDE writes to `~/.gemini/antigravity/global_workflows/` while the CLI keeps its own `~/.gemini/antigravity-cli/global_workflows/` tree (mirroring the CLI\'s global skills tree).\n- **Kiro (`kiro`)** — Kiro ships as two products with diverging config formats: the **Kiro IDE** reads Markdown subagents (`.kiro/agents/*.md`) and structured JSON hooks (`.kiro/hooks/*.json`, format `{ "version": "v1", "hooks": [ ... ] }`), while the **Kiro CLI** reads JSON agent-config subagents (`.kiro/agents/*.json`) and agent hooks in `.kiro/agents/default.json`. A single target cannot emit both faithfully, so `kiro` is split into **`kiro-cli`** and **`kiro-ide`**. The legacy `kiro` target is kept as a **deprecated alias** (its current mixed output is unchanged for backward compatibility). Shared surfaces (steering rules with `inclusion`, `.kiro/settings/mcp.json`, `.kiro/prompts/` commands, `.kiro/skills/`, `.kiroignore`, permissions) are identical between the two; they differ in **subagents** (`.md` vs `.json`) and **hooks**. Kiro IDE **hooks** are emitted as a single `.kiro/hooks/rulesync.json` (whose `hooks` array holds every generated hook) in both project (`.kiro/hooks/`) and global (`~/.kiro/hooks/`) scope, mapping canonical lifecycle events to the IDE\'s PascalCase triggers (`SessionStart`, `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, `Stop`) and supporting both `agent` (prompt) and `command` actions; the Kiro CLI continues to emit agent hooks in `.kiro/agents/default.json`, including `cacheTtl` ⇄ `cache_ttl_seconds`. Global **skills** (`~/.kiro/skills/`), global **ignore** (`~/.kiro/settings/kiroignore`), and global Kiro IDE **subagents** (`~/.kiro/agents/`) are also supported, as are global Kiro CLI **commands** (`~/.kiro/prompts/`) and **subagents** (`~/.kiro/agents/`). Kiro\'s shared MCP file preserves per-server `disabledTools`.\n', + '# Supported Tools and Features\n\nRulesync supports both **generation** and **import** for All of the major AI coding tools:\n\n\n\n| Tool | --targets | rules | ignore | mcp | commands | subagents | skills | hooks | permissions | checks |\n| ------------------------- | ------------------ | :---: | :----: | :------: | :------: | :-------: | :----: | :---: | :---------: | :----: |\n| AGENTS.md | agentsmd | ✅ | | | 🎮 | 🎮 | 🎮 | | | |\n| AgentsSkills | agentsskills | | | | | | ✅ 🌏 | | | |\n| Amp | amp | ✅ 🌏 | | ✅ 🌏 | | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 |\n| Claude Code | claudecode | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Claude Code plugin | claudecode-plugin | | | ✅ | ✅ | ✅ | ✅ | ✅ | | |\n| Codex CLI | codexcli | ✅ 🌏 | | ✅ 🌏 🔧 | 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| GitHub Copilot | copilot | ✅ 🌏 | | ✅ | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| GitHub Copilot CLI | copilotcli | ✅ 🌏 | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | |\n| Goose | goose | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | ✅ 🌏 | 🌏 | |\n| Hermes Agent | hermesagent | ✅ | ✅ | 🌏 🔧 | 🌏 | ✅ 🌏 | 🌏 | 🌏 | 🌏 | ✅ |\n| Grok CLI | grokcli | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Cursor | cursor | ✅ | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ |\n| deepagents-cli | deepagents | ✅ 🌏 | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | 🌏 | | |\n| Factory Droid | factorydroid | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| OpenCode | opencode | ✅ 🌏 | | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Cline | cline | ✅ 🌏 | ✅ | 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ | |\n| Kilo Code | kilo | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Kimi Code | kimi-code | ✅ 🌏 | | ✅ 🌏 🔧 | | ✅ 🌏 | ✅ 🌏 | 🌏 | 🌏 | |\n| Roo Code | roo | ✅ 🌏 | ✅ | ✅ | ✅ 🌏 | ✅ | ✅ 🌏 | | | |\n| Zoo Code | zoocode | ✅ 🌏 | ✅ | ✅ | ✅ 🌏 | ✅ | ✅ 🌏 | | | |\n| Rovodev (Atlassian) | rovodev | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | ✅ |\n| Takt | takt | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 |\n| Vibe Code | vibe | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Qwen Code | qwencode | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Reasonix | reasonix | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Kiro ⚠️ | kiro | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ | ✅ | ✅ | ✅ | ✅ | |\n| Kiro CLI | kiro-cli | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | ✅ | |\n| Kiro IDE | kiro-ide | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 🔧 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| Google Antigravity IDE | antigravity-ide | ✅ 🌏 | | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ | |\n| Google Antigravity CLI | antigravity-cli | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | 🌏 | |\n| Google Antigravity plugin | antigravity-plugin | ✅ | | ✅ 🔧 | | ✅ | ✅ | ✅ | | |\n| JetBrains AI Assistant | aiassistant | ✅ | ✅ | ✅ 🌏 | | | ✅ | | | |\n| JetBrains Junie | junie | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | 🌏 | 🌏 | |\n| AugmentCode | augmentcode | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Devin Desktop | devin | ✅ 🌏 | ✅ | ✅ 🌏 🔧 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | |\n| Warp | warp | ✅ 🌏 | ✅ | ✅ 🌏 | ✅ 🌏 | | ✅ 🌏 | | 🌏 | |\n| Replit | replit | ✅ | | | | | ✅ 🌏 | | | |\n| Pi Coding Agent | pi | ✅ 🌏 | | | ✅ 🌏 | | ✅ 🌏 | ✅ 🌏 | | |\n| Zed | zed | ✅ 🌏 | ✅ 🌏 | ✅ 🌏 | | | ✅ 🌏 | | ✅ 🌏 | |\n\n\n\n- ✅: Supports project mode\n- 🌏: Supports global mode\n- 🎮: Supports simulated commands/subagents/skills (Project mode only)\n- 🔧: Supports MCP tool config (`enabledTools`/`disabledTools`)\n- ⚠️: Deprecated — still supported, but see the note below\n\n## Hermes Agent compatibility\n\nThe `hermesagent` target is validated against Hermes Agent v0.19.0 (release\n`v2026.7.20`). The supported contract covers project rules, ignore patterns,\nsubagents, and checks, plus global MCP servers, commands, subagents, skills,\nhooks, and permissions. Generation, `--check`, and import round-trips are\ncovered for both advertised scopes.\n\nRulesync honors Hermes profiles through `HERMES_HOME`. When it is set, its value\nis the profile root itself: global configuration is read and written directly\nunder `$HERMES_HOME` (`config.yaml`, `skills/`, `plugins/`, and `rulesync/`),\nwithout appending `.hermes`. When it is unset, Rulesync follows Hermes\'s own\nplatform default: `~/.hermes` everywhere except Windows, where it is\n`%LOCALAPPDATA%\\hermes`. Because `HERMES_HOME` names where Hermes itself reads\nthe profile, it also takes precedence over `--output-roots` in global scope.\nProject-scoped paths remain rooted in the project.\n\nChanging which profile root Rulesync resolves strands whatever it generated\nunder the previous one. `--delete` reconciles only the root resolved for the\ncurrent run, so files under a root it no longer resolves are invisible to it and\nmust be removed by hand once you are sure Hermes no longer reads them. This\napplies whenever you set or change `HERMES_HOME`, and to two upgrades that moved\nthe resolved root on their own: before v16.0.0 global files went to `~/.hermes`\neven when `HERMES_HOME` was set, and before v16.2.0 they went there on Windows\ntoo, rather than to `%LOCALAPPDATA%\\hermes`.\n\nProject plugins are registered by adding their names to\n`$HERMES_HOME/config.yaml`, but Rulesync does not persist Hermes\'s global\nproject-plugin trust gate. Run Hermes from a trusted project root with\n`HERMES_ENABLE_PROJECT_PLUGINS=true` for an explicit, session-scoped opt-in. A\nfuture Hermes release that changes its loaders, schemas, or plugin API requires\na new compatibility validation.\n\n## Deprecation notes\n\n- **Google Antigravity (`antigravity-ide` / `antigravity-cli`)** — Antigravity 2.0 splits into two products: the desktop **`antigravity-ide`** and the **`antigravity-cli`** (`agy`). As of Antigravity 2.0 the IDE reads its global MCP config and skills from the shared `~/.gemini/config/` tree — `~/.gemini/config/mcp_config.json` and `~/.gemini/config/skills/`, matching the current [MCP](https://antigravity.google/docs/mcp) and [Skills](https://antigravity.google/docs/skills) docs. The `antigravity-cli` global MCP config also lives in the shared `~/.gemini/config/mcp_config.json`, while the CLI keeps its own global skills tree at `~/.gemini/antigravity-cli/skills/`. Both targets also intentionally **share** the global rule file `~/.gemini/GEMINI.md` and the global hooks file `~/.gemini/config/hooks.json` — enabling both targets in `--global` mode writes those shared files once. For project-scope rules, **both `antigravity-ide` and `antigravity-cli`** emit the root rule as a plain cross-tool **`AGENTS.md`** at the project root (the Gemini-lineage discovery order is `AGENTS.md`, `CONTEXT.md`, `GEMINI.md`; the IDE has read `AGENTS.md` since v1.20.3) and non-root rules under `.agents/rules/` (the IDE adds trigger frontmatter to non-root rules; the CLI keeps them as plain markdown). For **commands (workflows)**, both targets share the project `.agents/workflows/` directory (invoked as `/workflow-name`); in `--global` mode the IDE writes to `~/.gemini/antigravity/global_workflows/` while the CLI keeps its own `~/.gemini/antigravity-cli/global_workflows/` tree (mirroring the CLI\'s global skills tree).\n- **Kiro (`kiro`)** — Kiro ships as two products with diverging config formats: the **Kiro IDE** reads Markdown subagents (`.kiro/agents/*.md`) and structured JSON hooks (`.kiro/hooks/*.json`, format `{ "version": "v1", "hooks": [ ... ] }`), while the **Kiro CLI** reads JSON agent-config subagents (`.kiro/agents/*.json`) and agent hooks in `.kiro/agents/default.json`. A single target cannot emit both faithfully, so `kiro` is split into **`kiro-cli`** and **`kiro-ide`**. The legacy `kiro` target is kept as a **deprecated alias** (its current mixed output is unchanged for backward compatibility). Shared surfaces (steering rules with `inclusion`, `.kiro/settings/mcp.json`, `.kiro/prompts/` commands, `.kiro/skills/`, `.kiroignore`, permissions) are identical between the two; they differ in **subagents** (`.md` vs `.json`) and **hooks**. Kiro IDE **hooks** are emitted as a single `.kiro/hooks/rulesync.json` (whose `hooks` array holds every generated hook) in both project (`.kiro/hooks/`) and global (`~/.kiro/hooks/`) scope, mapping canonical lifecycle events to the IDE\'s PascalCase triggers (`SessionStart`, `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, `Stop`) and supporting both `agent` (prompt) and `command` actions; the Kiro CLI continues to emit agent hooks in `.kiro/agents/default.json`, including `cacheTtl` ⇄ `cache_ttl_seconds`. Global **skills** (`~/.kiro/skills/`), global **ignore** (`~/.kiro/settings/kiroignore`), and global Kiro IDE **subagents** (`~/.kiro/agents/`) are also supported, as are global Kiro CLI **commands** (`~/.kiro/prompts/`) and **subagents** (`~/.kiro/agents/`). Kiro\'s shared MCP file preserves per-server `disabledTools`.\n', "tools/takt": "# Takt\n\n[Takt](https://github.com/nrslib/takt) is a faceted-prompting AI coding workflow tool. Rulesync generates plain-Markdown facet files into Takt's `.takt/facets/` layout (or `~/.takt/facets/` in global mode).\n\n## Output mapping\n\nEach rulesync feature maps onto a dedicated Takt facet directory. The target directory is fixed per feature, except that **rules** may opt into Takt's fifth facet — `output-contracts` — via the `takt.facet` override (see below).\n\n| Rulesync feature | Takt facet directory |\n| ---------------- | --------------------------------------------------------------------------------------- |\n| `rules` | `.takt/facets/policies/` (default) or `.takt/facets/output-contracts/` via `takt.facet` |\n| `commands` | `.takt/facets/instructions/` |\n| `subagents` | `.takt/facets/personas/` |\n| `skills` | `.takt/facets/knowledge/` |\n\nTakt-specific frontmatter knobs:\n\n```yaml\n---\ntakt:\n name: my-renamed-stem # rename the emitted filename stem\n extends: base # emit a leading {extends:base} facet-inheritance directive\n facet: output-contracts # \"policies\" (default) or \"output-contracts\"\n---\n```\n\n- `takt.name` is **optional**; the source filename stem is used by default. Unsafe values (path separators, `..` segments, etc.) raise a hard validation error at `generate` time.\n- `takt.facet` is **optional** and defaults to `policies`. Setting it to `output-contracts` redirects the rule to Takt's output-structure / report-template facet, which has no dedicated rulesync feature. Both `policies` and `output-contracts` support `{extends:...}` inheritance. The other facets (`instructions`, `personas`, `knowledge`) are owned by the commands, subagents, and skills features and are not selectable via `takt.facet`.\n- Like `takt.name` and `takt.extends`, `takt.facet` is a generate-side authoring control. Because Takt facet files are plain Markdown with no frontmatter, the facet selection cannot be recovered on import (see [Importing](#importing-existing-takt-files-into-rulesync) below).\n\nOutput files are **plain Markdown** — the source frontmatter is dropped entirely and the body is written verbatim:\n\n```\n.rulesync/rules/style.md → .takt/facets/policies/style.md\n.rulesync/rules/review-format.md → .takt/facets/output-contracts/review-format.md (with takt.facet: output-contracts)\n.rulesync/commands/review.md → .takt/facets/instructions/review.md\n.rulesync/subagents/coder.md → .takt/facets/personas/coder.md\n.rulesync/skills/oncall/SKILL.md → .takt/facets/knowledge/oncall.md\n```\n\n## MCP (partial — transport allowlist only)\n\nTakt has no project- or global-level registry of MCP server _definitions_: the concrete `mcp_servers` map (`command`/`args`/`env` or `type`/`url`/`headers`) is declared **per workflow step** inside individual workflow YAML files, and Takt's `config.yaml` loader rejects unknown top-level keys. The one MCP knob `config.yaml` does expose is the **default-deny transport allowlist** `workflow_mcp_servers: { stdio, sse, http }`; until a transport is enabled there, every workflow-defined MCP server using it is refused.\n\nRulesync therefore emits **only** this allowlist into the shared `.takt/config.yaml` (project) / `~/.takt/config.yaml` (global), turning on exactly the transports the servers in `.rulesync/mcp.jsonc` use (`local`/`stdio` → `stdio`, `sse` → `sse`, `http`/`streamable-http`/`ws` → `http`). The merge is in place, so the active provider, provider profiles, and all other config keys are preserved; the file is never deleted.\n\n**Lossiness:** the per-server names, commands, env, URLs, and headers are not representable in `config.yaml` and are intentionally not written — you still declare the concrete servers in your workflow YAML steps; Rulesync only opens the transport gate that permits them. Because of this, reverse import cannot reconstruct server definitions and yields an empty `mcpServers` map.\n\n## Checks — quality gates\n\n`.rulesync/checks/*.md` become TAKT **quality gates** in the `workflow_overrides` block of the shared `config.yaml`. A check's body is a string gate — a completion directive TAKT injects into the agent step prompt — unless the check's `takt` frontmatter block names a `command`, which makes it a command gate TAKT runs after the step, failing the gate on a non-zero exit.\n\n**A command gate runs unconditionally.** TAKT's default-deny `workflow_command_gates.custom_scripts` policy applies to gates declared in workflow YAML, not to gates coming from `workflow_overrides`, so a `takt.command` in a check is executed after every step it applies to with no further gating. Read the frontmatter of any check you obtain with `rulesync fetch` before generating.\n\n**Lossiness:** TAKT gates carry no severity or tool allowlist, so a check's `severity` and `tools` fields are not written and do not come back on import.\n\n`quality_gates_edit_only` in a check's `takt` block applies to the whole block, and reaches only the gates with no `steps` / `personas` scope — TAKT runs a scoped gate whether or not the step may edit files.\n\nThe block is owned by the checks feature: it is rewritten from `.rulesync/checks/` on every generate, and retracted when checks remain but none target TAKT. Emptying `.rulesync/checks/` altogether leaves the gates in place — the feature has no source to generate from — so delete them by hand in that case. See [file formats](../reference/file-formats.md) for the frontmatter reference.\n\n## Scope\n\nBoth project mode (`.takt/facets/...`, `.takt/config.yaml`) and global mode (`~/.takt/facets/...`, `~/.takt/config.yaml`) are supported.\n\n## Importing existing TAKT files into rulesync\n\nImporting the **facet** features (rules, commands, subagents, skills) is **not supported**. TAKT facet files are plain Markdown with no frontmatter, so the original skill / command / subagent metadata cannot be recovered. Attempting to import a TAKT skill raises a clear error rather than silently producing a stub that round-trips badly.\n\nThe `config.yaml` features do import: `rulesync import --targets takt --features checks` reads the quality gates back into `.rulesync/checks/`, and `--features permissions` reads the permission mode and the Takt-specific override keys. MCP is the exception noted above — the allowlist carries no server definitions to reconstruct.\n", };