--- name: configure-editor-schema description: Wire an existing JSON Schema into VS Code, Cursor, and/or Zed so it provides validation and IntelliSense for matching JSON or YAML files. --- # Editor Schema Configurator Associate an existing JSON Schema with a file-match glob in one or more editors (VS Code, Cursor, Zed) for both JSON and YAML files. Authoring the schema itself is **out of scope** — the schema must already exist on disk or be reachable at an HTTPS URL. Use the arguments supplied in the user's invocation. ## Step 1: Parse Inputs Extract these inputs from the user's invocation. Collect anything missing in Step 2. - **Schema source**: a local file path (absolute or project-relative) OR an HTTPS URL. - **File type**: `json` or `yaml` — which file type the schema validates. - **File-match glob(s)**: one or more glob patterns matching the config files that should use this schema (e.g., `**/myconfig.json`, `.foo/*.yaml`). - **Editor(s)**: any combination of VS Code, Cursor, Zed. - **Scope**: `user` (default) or `project`. If the schema source is ambiguous (e.g., the user said "the schema for X" without giving a path), treat it as missing. ## Step 2: Collect Missing Inputs Use the active client's user-question mechanism to fill gaps. One question per missing input. Suggested prompts: - **Schema source**: "Where is the schema? Provide an absolute path, a project-relative path, or an HTTPS URL." - **File type**: "Is this schema for JSON files or YAML files?" (options: `json`, `yaml`) - **Glob(s)**: "Which files should this schema apply to? Provide one or more glob patterns." - **Editors**: "Which editors should I configure?" (options: `VS Code`, `Cursor`, `Zed`, plus combinations — allow multi-select) - **Scope**: "User-level (applies across all your projects) or project-level (committed to this repo)?" Default: user. Confirm the resolved inputs back to the user in one short summary before writing anything. ## Step 3: Resolve Settings File Paths For each chosen editor and scope, determine the absolute path of the settings file. Consult `references/editor-settings.md` for the per-OS path table and project-level conventions. Use `uname` or known environment context to detect the OS. On Linux, prefer `$XDG_CONFIG_HOME` when set, falling back to `~/.config`. If a settings file or its parent directory does not exist, create them: - `mkdir -p ` - `Write` an empty `{}` if the file is missing. ## Step 4: Read Existing Settings and Detect Conflicts For each target settings file: 1. Read the file with the `Read` tool. 2. Locate the relevant schemas section based on editor + file type. See `references/editor-settings.md` for the exact shape per editor. 3. Detect conflicts: - **VS Code/Cursor JSON** (`json.schemas` array): conflict = an existing entry whose `fileMatch` overlaps with the new glob. - **VS Code/Cursor YAML** (`yaml.schemas` map): conflict = an existing key (schema source) already bound to an overlapping glob, OR a different schema source bound to the same glob. - **Zed JSON / Zed YAML**: same logic, but nested under `lsp.{json|yaml}-language-server.settings.{json|yaml}.schemas`. "Overlap" means the new glob equals or is a string-identical match of an existing one. Don't try to compute true set-overlap — when in doubt, surface the candidate to the user. If conflicts exist, ask about each conflicting entry: "Overwrite the existing mapping `` with ``?" Options: `overwrite`, `skip this editor`, `abort`. ## Step 5: Apply Additive Edits For each settings file: 1. Use the `Edit` tool to make the smallest possible surgical change. **Never** rewrite the whole file with `Write` when settings already exist. 2. Preserve JSONC content — comments, trailing commas, formatting. All three editors permit JSONC in their settings files. 3. Insert into existing structure when the parent keys exist; otherwise create the nested keys. 4. Use the exact shape documented in `references/editor-settings.md`. Two common patterns: - **Empty file (`{}`)**: extend `{}` to include the full required nested structure. - **Existing schemas section**: append to the array (VS Code/Cursor JSON, Zed JSON) or add a new key (VS Code/Cursor YAML, Zed YAML). After editing, re-read the file once to confirm the change parses as valid JSONC (look for matching braces and the new entry being present). ## Step 6: Report Results Return a short summary: - For each editor configured: the settings file path and a one-line description of what was added. - If YAML was configured for VS Code or Cursor, surface the prerequisite: **the Red Hat YAML extension (`redhat.vscode-yaml`) must be installed**, otherwise `yaml.schemas` does nothing. The skill does not probe for it. - If a file or directory was created, mention that. - If the user chose to skip an editor due to a conflict, mention that too. ## Edge Cases - **HTTPS schema URL with YAML**: works in all three editors. - **Zed paths**: `./` resolves to the worktree root, `~/` to the home directory. For user-level Zed config, prefer absolute paths or `~/` over `./` — `./` may resolve unpredictably. - **Multi-root workspaces**: out of scope. Treat the current working directory as the single workspace root for project-scope edits. - **OS support**: Linux and macOS only. Windows is not supported. ## Additional Resources - **`references/editor-settings.md`** — Per-OS settings paths, exact settings shapes for every editor+file-type combination, JSONC notes, and the Red Hat YAML extension prerequisite.