Constant BODY 

pub const BODY: &str = "## What repograph is\n\nrepograph is a CLI tool that maintains a registry of local git repositories and exposes their state (branches, status, agent-doc content like CLAUDE.md and AGENTS.md, workspace groupings) as structured JSON for AI agents. It runs locally; no network. The user has registered which repos matter to them via `repograph add` and selected their agent toolchains via `repograph init`. Reach for repograph whenever a request would benefit from cross-repo awareness instead of asking the user to paste paths or context manually.\n\n## When to invoke\n\n- The user asks about cross-repo context: \"what\'s in flight across my projects\", \"show me the state of every repo I have registered\".\n- The user references multiple projects in one turn: \"compare X and Y\", \"the auth changes in repo A affect repo B\".\n- The user asks \"what repos are registered\", \"list my repos\", or \"show me my workspaces\".\n- The user asks to switch to a repo: \"cd into the api repo\", \"open the cli repo for me\", \"switch to <name>\".\n- The user asks for status across projects: \"which repos have uncommitted changes\", \"what\'s dirty right now\".\n- The user wants the agent-doc content for one or more repos pulled into the conversation: \"load the CLAUDE.md for repo X\", \"give me the AGENTS.md for workspace acme\".\n- The user reports something feels off with their setup (\"my agent isn\'t seeing X\"): run `repograph doctor --json` to surface health-check findings before guessing.\n- The user says they\'ve solved something before and wants the prior art \u{2014} \"I did this in another repo\", \"this is already solved somewhere\", \"use repo X as reference\" \u{2014} even when they can\'t name the repo. Run `repograph find \"<description or symbol>\" --json` to locate the reference implementation across every registered repo before re-implementing. This is the cross-repo precedent search; it is distinct from inspecting the current repo (use plain git for that).\n\n## Commands\n\n| Intent                                | Command                       |\n|---------------------------------------|-------------------------------|\n| List registered repos                  | `repograph list --json`       |\n| Show per-repo git status              | `repograph status --json`     |\n| Build full agent context for repos    | `repograph context --json`    |\n| Resolve a repo to a `cd` target       | `repograph switch <name>`     |\n| Find a reference impl across repos    | `repograph find \"<query>\" --json` |\n| Build/refresh the search index        | `repograph index`             |\n| Diagnose registry health              | `repograph doctor --json`     |\n\n`repograph find` searches a local index built by `repograph index`; if a search reports no index, ask the user to run `repograph index` (it is a mutating-ish, potentially slow operation, so don\'t run it unprompted). Each hit carries `repo`, `path`, `line`, `score`, and a `snippet`.\n\nThe `--json` form is the agent-facing surface; always pass it. Every command has a TTY-friendly table form for humans, but agents should consume JSON. `repograph switch <name>` prints exactly `cd <quoted-path>` on stdout; use it to ground filesystem operations to a known repo without rebuilding the path yourself.\n\n## JSON envelope\n\nAll commands write JSON to stdout and diagnostic logs to stderr, so `repograph <cmd> --json 2>/dev/null` always yields clean, parseable JSON \u{2014} never merge stderr into it.\n\nThe richer commands (`context`, `doctor`) carry a top-level `schema_version` integer field; today\'s schema is `1`. The lighter commands (`list`, `status`) currently emit a bare `{ \"repos\": [...] }` with no `schema_version`. Read the field defensively (`.schema_version // null`) rather than assuming it\'s present. Schemas are stable: additive changes (new optional fields) keep `schema_version = 1`; breaking changes bump it.\n\nSalient payload shapes:\n\n- `repograph list --json` \u{2192} `{ \"repos\": [...] }`. Each record: `name`, `path`, `description` (often `null`), `stack` (array, often empty). No `schema_version`.\n- `repograph status --json` \u{2192} `{ \"repos\": [...] }`. Each record: `name`, `path`, `branch`, `upstream`, `ahead`, `behind`, `dirty`, `staged`, `unstaged`, `untracked`, `state` (`\"clean\"`/`\"dirty\"`), `error`. No `schema_version`.\n- `repograph context --json` \u{2192} top-level `schema_version`, `generated_at`, `scope`, `agents`, `warnings`, `repos`. Each repo entry: `name`, `path`, `branch`, `warnings`, and (when present) `agent_docs` \u{2014} an array of `{ agent, files: [...] }` with inlined CLAUDE.md / AGENTS.md content. This is the primary surface for loading context into your reasoning.\n- `repograph doctor --json` \u{2192} `schema_version`, `generated_at`, `checks` (array of findings with `check`, `severity`, `target`, `message`), and a `summary` block (`ok`, `warn`, `error`, `total`).\n\n## Things to avoid\n\n- Do not run mutating commands automatically. This skill is read-only. When the user wants to register a repo, group repos into a workspace, or update an existing entry (`add`, `remove`, `edit`, `workspace \u{2026}`), that is the job of the `repograph-setup` skill \u{2014} defer to it rather than calling those commands here. The registry is the user\'s to manage.\n- Do not assume any specific repo is registered without checking. Prefer `repograph list --json` (or `repograph context --json` for the full surface) over hardcoded names.\n- Do not paste the full `agent_docs` payload back to the user verbatim; it\'s intended as input to your own reasoning. Summarize when you reply.\n- Do not call repograph in a loop. One `repograph context --json` returns every registered repo\'s context in one envelope; iterating per repo is slower and wasteful.\n";

The single canonical instructional body, shared by every per-agent writer.

Owned by repograph-core so the CLI surface is documented in exactly one place. Per-agent writers (see render_artifact) wrap this string in native-format frontmatter or headers but never edit its content.

Content stability: this string is byte-stable for a given crate version. A body update bumps the in-file content for users on re-init; the spliced install layer rewrites only the delimited region.