{"owner":"JetBrains","repo":"intellij-community","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":2469,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"intellij-community":{"command":"npx","args":["-y","@modelcontextprotocol/server-intellij-community"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"<!-- Generated by community/.ai/render-guides.mjs; edit community/.ai/* -->\n\n**Critical:** These guidelines MUST be followed at all times.\n\n## Project Invariants\n\n- A module or plugin directory can hold its own AGENTS or CLAUDE instructions. Follow them when they are present.\n- `*.iml` files are the source of truth. They generate the `BUILD.bazel` files.\n- Register a new or edited JPS module `.iml` with `bun build/jps-module.mjs register <path-to-iml> --fix-iml-eof`, then run `./build/jpsModelToBazelCommunityOnly.cmd`. Never edit `.idea/modules.xml` by hand. The command keeps `modules.xml` in canonical order.\n- User-visible strings belong in `*.properties` for localization.\n\n## Language\n\n- Read [Code Style](./.agents/skills/code-style/SKILL.md) before writing or reviewing Kotlin or Java.\n- Read [Rust Code Style](./.agents/skills/rust-code-style/SKILL.md) before writing or reviewing Rust.\n\n## Writing\n\nWrite every user-visible artifact in [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/), and keep it short. This covers a comment, KDoc, a commit message, documentation, a spec, and a report to the user. Use the active voice and a simple tense, state one topic per sentence, write positively, and use no noun cluster longer than three words. The five that catch most of the damage here:\n\n- Keep a sentence at or under 25 words.\n- Make an aside its own sentence. Do not put it between dashes.\n- Keep the articles. Write \"the session\", not \"session\".\n- One term per concept. Never introduce a synonym for a term the area already defines.\n- Say what you left out and why. Do not pad a report to look complete.\n\nEach kind of text has one home. Rationale and evidence for a change go in the commit message, not in a code comment. Document a declaration in KDoc on it, not in a `README.md`.\n\n## Workspace Isolation\n\nDo not create a Git worktree or a clone, and do not install a workspace manager, on your own initiative. Read [Workspace Isolation](./.ai/workspace-isolation.md) before any workspace-isolation action. It also covers the explicit-request exception.\n\n## Module-specific rules\n\nRead the referenced rules before you edit or review a file under these roots. They override the general guidance here.\n\n- **Product DSL** (`platform/build-scripts/product-dsl/`): follow its `AGENTS.md`.\n- **IJ Proxy MCP server** (`build/mcp-servers/ij-proxy/`):\n  - Tests: run `bun run build` and `bun test`.\n  - Bazel: do not run a Bazel build or test here.\n- **Eel / IJent** (`platform/eel*/`, `platform/ijent/`): read `platform/eel/AGENTS.md` first.\n- **PyCharm** (`./python`): start a PY-NNNNN issue at `./python/.ai/index.md`.\n\n## Mandatory Rules\n\n### After Code Changes\n\n- **Run the affected tests:** `./tools/bt.cmd --module <module> --filter <FQN>`, or `node --test <file>` for a `*.test.mjs` file. An FQN is required. Always name the test module. When bt refuses the module, run the `tests.cmd` command that it prints. Neither runner needs a separate `bazel build` step. A module rule can override the runner. Skip this when the plugin has no tests. See [TESTING](./.agents/skills/testing/SKILL.md).\n- **Bazel compilation without tests:** to verify compilation only, run `bazel build <target>` for the affected modules. Skip this when you changed only `.js`, `.mjs`, `.md`, `.txt`, or `.json` files.\n- After you change a Bazel or Starlark source (`BUILD`, `BUILD.bazel`, `MODULE.bazel`, `WORKSPACE`, `WORKSPACE.bazel`, or `*.bzl`), run `bazel run //:format.check`. If it reports a diff, run `bazel run //:format`, inspect the changes, and run the check again.\n- After you change an `*.iml`, a `BUILD.bazel`, or a `.idea/` file, run `./build/jpsModelToBazelCommunityOnly.cmd`.\n\n### After Writing Code\n\n- Use `lint_files` to check the files for warnings when ijproxy or JetBrains MCP is available. Fix every warning that belongs to your changes. You can ignore an unrelated warning.\n\n## Repository-wide rules\n\nKeep IDE-serialized `.iml` files in canonical form. Do not:\n\n- add a comment\n- auto-format\n- normalize the structure or the whitespace\n- add a trailing newline at the end of the file\n- remove an empty tag\n- reorder an element or an attribute\n\n## Tools\n\nNever use the `code-search` skill. The search tools below replace it. Recipes, the Windows rules, and the full tool inventory: [Tools Reference](./.ai/tools.md).\n\n### Search & navigation (ijproxy preferred)\n\nUse `search_symbol` for a class, a method, or a field. Use `search_file` to find a file by glob. Use `search_text` and `search_regex` for a string, a comment, or another match that is not a symbol.\n\nThese are `mcp__ijproxy__<name>`. Look them up in the harness deferred-tool catalog before you use a shell or a non-ijproxy fallback.\n\n### IDE-backed semantic tools\n\nAvailable through ijproxy or JetBrains MCP: `lint_files`, `get_symbol_info`, `rename`, `reformat_file`, the threading and lock checks, and the project, VCS and run-configuration tools. Prefer a real refactoring over a manual search and replace.\n\n### Tooling rules\n\n- Prefer ijproxy for a content or symbol **search** and for a semantic operation. Fall back to JetBrains MCP, then to `./tools/fd.cmd` (files) and `./tools/rg.cmd` (text and regex), only when ijproxy is unavailable. Pass `-H` to see a dot-directory such as `.agents/`.\n- Do not shell out for a file **search**, inside the repo or outside it. This is enforced: the `Glob` and `Grep` tools are denied, and so are the `grep` and `find` commands in every pipeline position.\n- Prefer a spelling the allowlist knows, because a novel one asks for a prompt. Add a new entry to `.ai/tool-permissions.json`, never to a harness allowlist.\n- Shell is allowed where this guide documents it, and for git, build, and test. Prefer `git_status` when that tool is available. Outside the working copy it is task-scoped: read what this repo's tooling produced, or what the user or a skill named, and never survey the machine.\n\n### Skills\n\nThe harness can list skill *names* only, without a description. When a task looks like something a skill covers, read the index for what each name does before you improvise:\n\n- Skill index: [`.agents/skills/INDEX.md`](./.agents/skills/INDEX.md)\n\n## Individual Preferences\n\n**Local Preferences:** @./.ai/local.md\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"<!-- Generated by community/.ai/render-guides.mjs; edit community/.ai/* -->\n\n**Critical:** These guidelines MUST be followed at all times.\n\n## Project Invariants\n\n- A module or plugin directory can hold its own AGENTS or CLAUDE instructions. Follow them when they are present.\n- `*.iml` files are the source of truth. They generate the `BUILD.bazel` files.\n- Register a new or edited JPS module `.iml` with `bun build/jps-module.mjs register <path-to-iml> --fix-iml-eof`, then run `./build/jpsModelToBazelCommunityOnly.cmd`. Never edit `.idea/modules.xml` by hand. The command keeps `modules.xml` in canonical order.\n- User-visible strings belong in `*.properties` for localization.\n\n## Language\n\n- Read [Code Style](./.agents/skills/code-style/SKILL.md) before writing or reviewing Kotlin or Java.\n- Read [Rust Code Style](./.agents/skills/rust-code-style/SKILL.md) before writing or reviewing Rust.\n\n## Writing\n\nWrite every user-visible artifact in [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/), and keep it short. This covers a comment, KDoc, a commit message, documentation, a spec, and a report to the user. Use the active voice and a simple tense, state one topic per sentence, write positively, and use no noun cluster longer than three words. The five that catch most of the damage here:\n\n- Keep a sentence at or under 25 words.\n- Make an aside its own sentence. Do not put it between dashes.\n- Keep the articles. Write \"the session\", not \"session\".\n- One term per concept. Never introduce a synonym for a term the area already defines.\n- Say what you left out and why. Do not pad a report to look complete.\n\nEach kind of text has one home. Rationale and evidence for a change go in the commit message, not in a code comment. Document a declaration in KDoc on it, not in a `README.md`.\n\n## Workspace Isolation\n\nDo not create a Git worktree or a clone, and do not install a workspace manager, on your own initiative. Read [Workspace Isolation](./.ai/workspace-isolation.md) before any workspace-isolation action. It also covers the explicit-request exception.\n\n## Module-specific rules\n\nRead the referenced rules before you edit or review a file under these roots. They override the general guidance here.\n\n- **Product DSL** (`platform/build-scripts/product-dsl/`): follow its `AGENTS.md`.\n- **IJ Proxy MCP server** (`build/mcp-servers/ij-proxy/`):\n  - Tests: run `bun run build` and `bun test`.\n  - Bazel: do not run a Bazel build or test here.\n- **Eel / IJent** (`platform/eel*/`, `platform/ijent/`): read `platform/eel/AGENTS.md` first.\n- **PyCharm** (`./python`): start a PY-NNNNN issue at `./python/.ai/index.md`.\n\n## Mandatory Rules\n\n### After Code Changes\n\n- **Run the affected tests:** `./tools/bt.cmd --module <module> --filter <FQN>`, or `node --test <file>` for a `*.test.mjs` file. An FQN is required. Always name the test module. When bt refuses the module, run the `tests.cmd` command that it prints. Neither runner needs a separate `bazel build` step. A module rule can override the runner. Skip this when the plugin has no tests. See [TESTING](./.agents/skills/testing/SKILL.md).\n- **Bazel compilation without tests:** to verify compilation only, run `bazel build <target>` for the affected modules. Skip this when you changed only `.js`, `.mjs`, `.md`, `.txt`, or `.json` files.\n- After you change a Bazel or Starlark source (`BUILD`, `BUILD.bazel`, `MODULE.bazel`, `WORKSPACE`, `WORKSPACE.bazel`, or `*.bzl`), run `bazel run //:format.check`. If it reports a diff, run `bazel run //:format`, inspect the changes, and run the check again.\n- After you change an `*.iml`, a `BUILD.bazel`, or a `.idea/` file, run `./build/jpsModelToBazelCommunityOnly.cmd`.\n\n### After Writing Code\n\n- Use `lint_files` to check the files for warnings when ijproxy or JetBrains MCP is available. Fix every warning that belongs to your changes. You can ignore an unrelated warning.\n\n## Repository-wide rules\n\nKeep IDE-serialized `.iml` files in canonical form. Do not:\n\n- add a comment\n- auto-format\n- normalize the structure or the whitespace\n- add a trailing newline at the end of the file\n- remove an empty tag\n- reorder an element or an attribute\n\n## Tools\n\nNever use the `code-search` skill. The search tools below replace it. Recipes, the Windows rules, and the full tool inventory: [Tools Reference](./.ai/tools.md).\n\n### Search & navigation (ijproxy preferred)\n\nUse `search_symbol` for a class, a method, or a field. Use `search_file` to find a file by glob. Use `search_text` and `search_regex` for a string, a comment, or another match that is not a symbol.\n\nThese are `mcp__ijproxy__<name>`. Look them up in the harness deferred-tool catalog before you use a shell or a non-ijproxy fallback.\n\n### IDE-backed semantic tools\n\nAvailable through ijproxy or JetBrains MCP: `lint_files`, `get_symbol_info`, `rename`, `reformat_file`, the threading and lock checks, and the project, VCS and run-configuration tools. Prefer a real refactoring over a manual search and replace.\n\n### Tooling rules\n\n- Prefer ijproxy for a content or symbol **search** and for a semantic operation. Fall back to JetBrains MCP, then to `./tools/fd.cmd` (files) and `./tools/rg.cmd` (text and regex), only when ijproxy is unavailable. Pass `-H` to see a dot-directory such as `.agents/`.\n- Do not shell out for a file **search**, inside the repo or outside it. This is enforced: the `Glob` and `Grep` tools are denied, and so are the `grep` and `find` commands in every pipeline position.\n- Prefer a spelling the allowlist knows, because a novel one asks for a prompt. Add a new entry to `.ai/tool-permissions.json`, never to a harness allowlist.\n- Shell is allowed where this guide documents it, and for git, build, and test. Prefer `git_status` when that tool is available. Outside the working copy it is task-scoped: read what this repo's tooling produced, or what the user or a skill named, and never survey the machine.\n\n### Skills\n\nThe harness can list skill *names* only, without a description. When a task looks like something a skill covers, read the index for what each name does before you improvise:\n\n- Skill index: [`.agents/skills/INDEX.md`](./.agents/skills/INDEX.md)\n\n## Individual Preferences\n\n**Local Preferences:** @./.ai/local.md\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"<!-- Generated by community/.ai/render-guides.mjs; edit community/.ai/* -->\n\n**Critical:** These guidelines MUST be followed at all times.\n\n## Project Invariants\n\n- A module or plugin directory can hold its own AGENTS or CLAUDE instructions. Follow them when they are present.\n- `*.iml` files are the source of truth. They generate the `BUILD.bazel` files.\n- Register a new or edited JPS module `.iml` with `bun build/jps-module.mjs register <path-to-iml> --fix-iml-eof`, then run `./build/jpsModelToBazelCommunityOnly.cmd`. Never edit `.idea/modules.xml` by hand. The command keeps `modules.xml` in canonical order.\n- User-visible strings belong in `*.properties` for localization.\n\n## Language\n\n- Read [Code Style](./.agents/skills/code-style/SKILL.md) before writing or reviewing Kotlin or Java.\n- Read [Rust Code Style](./.agents/skills/rust-code-style/SKILL.md) before writing or reviewing Rust.\n\n## Writing\n\nWrite every user-visible artifact in [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/), and keep it short. This covers a comment, KDoc, a commit message, documentation, a spec, and a report to the user. Use the active voice and a simple tense, state one topic per sentence, write positively, and use no noun cluster longer than three words. The five that catch most of the damage here:\n\n- Keep a sentence at or under 25 words.\n- Make an aside its own sentence. Do not put it between dashes.\n- Keep the articles. Write \"the session\", not \"session\".\n- One term per concept. Never introduce a synonym for a term the area already defines.\n- Say what you left out and why. Do not pad a report to look complete.\n\nEach kind of text has one home. Rationale and evidence for a change go in the commit message, not in a code comment. Document a declaration in KDoc on it, not in a `README.md`.\n\n## Workspace Isolation\n\nDo not create a Git worktree or a clone, and do not install a workspace manager, on your own initiative. Read [Workspace Isolation](./.ai/workspace-isolation.md) before any workspace-isolation action. It also covers the explicit-request exception.\n\n## Module-specific rules\n\nRead the referenced rules before you edit or review a file under these roots. They override the general guidance here.\n\n- **Product DSL** (`platform/build-scripts/product-dsl/`): follow its `AGENTS.md`.\n- **IJ Proxy MCP server** (`build/mcp-servers/ij-proxy/`):\n  - Tests: run `bun run build` and `bun test`.\n  - Bazel: do not run a Bazel build or test here.\n- **Eel / IJent** (`platform/eel*/`, `platform/ijent/`): read `platform/eel/AGENTS.md` first.\n- **PyCharm** (`./python`): start a PY-NNNNN issue at `./python/.ai/index.md`.\n\n## Mandatory Rules\n\n### After Code Changes\n\n- **Run the affected tests:** `./tools/bt.cmd --module <module> --filter <FQN>`, or `node --test <file>` for a `*.test.mjs` file. An FQN is required. Always name the test module. When bt refuses the module, run the `tests.cmd` command that it prints. Neither runner needs a separate `bazel build` step. A module rule can override the runner. Skip this when the plugin has no tests. See [TESTING](./.agents/skills/testing/SKILL.md).\n- **Bazel compilation without tests:** to verify compilation only, run `bazel build <target>` for the affected modules. Skip this when you changed only `.js`, `.mjs`, `.md`, `.txt`, or `.json` files.\n- After you change a Bazel or Starlark source (`BUILD`, `BUILD.bazel`, `MODULE.bazel`, `WORKSPACE`, `WORKSPACE.bazel`, or `*.bzl`), run `bazel run //:format.check`. If it reports a diff, run `bazel run //:format`, inspect the changes, and run the check again.\n- After you change an `*.iml`, a `BUILD.bazel`, or a `.idea/` file, run `./build/jpsModelToBazelCommunityOnly.cmd`.\n\n### After Writing Code\n\n- Use `lint_files` to check the files for warnings when ijproxy or JetBrains MCP is available. Fix every warning that belongs to your changes. You can ignore an unrelated warning.\n\n## Repository-wide rules\n\nKeep IDE-serialized `.iml` files in canonical form. Do not:\n\n- add a comment\n- auto-format\n- normalize the structure or the whitespace\n- add a trailing newline at the end of the file\n- remove an empty tag\n- reorder an element or an attribute\n\n## Tools\n\nNever use the `code-search` skill. The search tools below replace it. Recipes, the Windows rules, and the full tool inventory: [Tools Reference](./.ai/tools.md).\n\n### Search & navigation (ijproxy preferred)\n\nUse `search_symbol` for a class, a method, or a field. Use `search_file` to find a file by glob. Use `search_text` and `search_regex` for a string, a comment, or another match that is not a symbol.\n\nThese are `mcp__ijproxy__<name>`. Look them up in the harness deferred-tool catalog before you use a shell or a non-ijproxy fallback.\n\n### IDE-backed semantic tools\n\nAvailable through ijproxy or JetBrains MCP: `lint_files`, `get_symbol_info`, `rename`, `reformat_file`, the threading and lock checks, and the project, VCS and run-configuration tools. Prefer a real refactoring over a manual search and replace.\n\n### Tooling rules\n\n- Prefer ijproxy for a content or symbol **search** and for a semantic operation. Fall back to JetBrains MCP, then to `./tools/fd.cmd` (files) and `./tools/rg.cmd` (text and regex), only when ijproxy is unavailable. Pass `-H` to see a dot-directory such as `.agents/`.\n- Do not shell out for a file **search**, inside the repo or outside it. This is enforced: the `Glob` and `Grep` tools are denied, and so are the `grep` and `find` commands in every pipeline position.\n- Prefer a spelling the allowlist knows, because a novel one asks for a prompt. Add a new entry to `.ai/tool-permissions.json`, never to a harness allowlist.\n- Shell is allowed where this guide documents it, and for git, build, and test. Prefer `git_status` when that tool is available. Outside the working copy it is task-scoped: read what this repo's tooling produced, or what the user or a skill named, and never survey the machine.\n\n### Skills\n\nThe harness can list skill *names* only, without a description. When a task looks like something a skill covers, read the index for what each name does before you improvise:\n\n- Skill index: [`.agents/skills/INDEX.md`](./.agents/skills/INDEX.md)\n\n## Individual Preferences\n\n**Local Preferences:** @./.ai/local.md\n","isInternal":false,"tokens":1569,"sizeBytes":6258},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":207},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":193},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":186}],"systemPromptSnippet":"<yakaai_skills repo=\"JetBrains/intellij-community\">\n<!-- File: AGENTS.md (Tokens: ~1569 | Category: root-instruction) -->\n<!-- Generated by community/.ai/render-guides.mjs; edit community/.ai/* -->\n\n**Critical:** These guidelines MUST be followed at all times.\n\n## Project Invariants\n\n- A module or plugin directory can hold its own AGENTS or CLAUDE instructions. Follow them when they are present.\n- `*.iml` files are the source of truth. They generate the `BUILD.bazel` files.\n- Register a new or edited JPS module `.iml` with `bun build/jps-module.mjs register <path-to-iml> --fix-iml-eof`, then run `./build/jpsModelToBazelCommunityOnly.cmd`. Never edit `.idea/modules.xml` by hand. The command keeps `modules.xml` in canonical order.\n- User-visible strings belong in `*.properties` for localization.\n\n## Language\n\n- Read [Code Style](./.agents/skills/code-style/SKILL.md) before writing or reviewing Kotlin or Java.\n- Read [Rust Code Style](./.agents/skills/rust-code-style/SKILL.md) before writing or reviewing Rust.\n\n## Writing\n\nWrite every user-visible artifact in [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/), and keep it short. This covers a comment, KDoc, a commit message, documentation, a spec, and a report to the user. Use the active voice and a simple tense, state one topic per sentence, write positively, and use no noun cluster longer than three words. The five that catch most of the damage here:\n\n- Keep a sentence at or under 25 words.\n- Make an aside its own sentence. Do not put it between dashes.\n- Keep the articles. Write \"the session\", not \"session\".\n- One term per concept. Never introduce a synonym for a term the area already defines.\n- Say what you left out and why. Do not pad a report to look complete.\n\nEach kind of text has one home. Rationale and evidence for a change go in the commit message, not in a code comment. Document a declaration in KDoc on it, not in a `README.md`.\n\n## Workspace Isolation\n\nDo not create a Git worktree or a clone, and do not install a workspace manager, on your own initiative. Read [Workspace Isolation](./.ai/workspace-isolation.md) before any workspace-isolation action. It also covers the explicit-request exception.\n\n## Module-specific rules\n\nRead the referenced rules before you edit or review a file under these roots. They override the general guidance here.\n\n- **Product DSL** (`platform/build-scripts/product-dsl/`): follow its `AGENTS.md`.\n- **IJ Proxy MCP server** (`build/mcp-servers/ij-proxy/`):\n  - Tests: run `bun run build` and `bun test`.\n  - Bazel: do not run a Bazel build or test here.\n- **Eel / IJent** (`platform/eel*/`, `platform/ijent/`): read `platform/eel/AGENTS.md` first.\n- **PyCharm** (`./python`): start a PY-NNNNN issue at `./python/.ai/index.md`.\n\n## Mandatory Rules\n\n### After Code Changes\n\n- **Run the affected tests:** `./tools/bt.cmd --module <module> --filter <FQN>`, or `node --test <file>` for a `*.test.mjs` file. An FQN is required. Always name the test module. When bt refuses the module, run the `tests.cmd` command that it prints. Neither runner needs a separate `bazel build` step. A module rule can override the runner. Skip this when the plugin has no tests. See [TESTING](./.agents/skills/testing/SKILL.md).\n- **Bazel compilation without tests:** to verify compilation only, run `bazel build <target>` for the affected modules. Skip this when you changed only `.js`, `.mjs`, `.md`, `.txt`, or `.json` files.\n- After you change a Bazel or Starlark source (`BUILD`, `BUILD.bazel`, `MODULE.bazel`, `WORKSPACE`, `WORKSPACE.bazel`, or `*.bzl`), run `bazel run //:format.check`. If it reports a diff, run `bazel run //:format`, inspect the changes, and run the check again.\n- After you change an `*.iml`, a `BUILD.bazel`, or a `.idea/` file, run `./build/jpsModelToBazelCommunityOnly.cmd`.\n\n### After Writing Code\n\n- Use `lint_files` to check the files for warnings when ijproxy or JetBrains MCP is available. Fix every warning that belongs to your changes. You can ignore an unrelated warning.\n\n## Repository-wide rules\n\nKeep IDE-serialized `.iml` files in canonical form. Do not:\n\n- add a comment\n- auto-format\n- normalize the structure or the whitespace\n- add a trailing newline at the end of the file\n- remove an empty tag\n- reorder an element or an attribute\n\n## Tools\n\nNever use the `code-search` skill. The search tools below replace it. Recipes, the Windows rules, and the full tool inventory: [Tools Reference](./.ai/tools.md).\n\n### Search & navigation (ijproxy preferred)\n\nUse `search_symbol` for a class, a method, or a field. Use `search_file` to find a file by glob. Use `search_text` and `search_regex` for a string, a comment, or another match that is not a symbol.\n\nThese are `mcp__ijproxy__<name>`. Look them up in the harness deferred-tool catalog before you use a shell or a non-ijproxy fallback.\n\n### IDE-backed semantic tools\n\nAvailable through ijproxy or JetBrains MCP: `lint_files`, `get_symbol_info`, `rename`, `reformat_file`, the threading and lock checks, and the project, VCS and run-configuration tools. Prefer a real refactoring over a manual search and replace.\n\n### Tooling rules\n\n- Prefer ijproxy for a content or symbol **search** and for a semantic operation. Fall back to JetBrains MCP, then to `./tools/fd.cmd` (files) and `./tools/rg.cmd` (text and regex), only when ijproxy is unavailable. Pass `-H` to see a dot-directory such as `.agents/`.\n- Do not shell out for a file **search**, inside the repo or outside it. This is enforced: the `Glob` and `Grep` tools are denied, and so are the `grep` and `find` commands in every pipeline position.\n- Prefer a spelling the allowlist knows, because a novel one asks for a prompt. Add a new entry to `.ai/tool-permissions.json`, never to a harness allowlist.\n- Shell is allowed where this guide documents it, and for git, build, and test. Prefer `git_status` when that tool is available. Outside the working copy it is task-scoped: read what this repo's tooling produced, or what the user or a skill named, and never survey the machine.\n\n### Skills\n\nThe harness can list skill *names* only, without a description. When a task looks like something a skill covers, read the index for what each name does before you improvise:\n\n- Skill index: [`.agents/skills/INDEX.md`](./.agents/skills/INDEX.md)\n\n## Individual Preferences\n\n**Local Preferences:** @./.ai/local.md\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/JetBrains/intellij-community/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}