{
  "markdown": "<p align=\"center\">\n  <img src=\"assets/brand/icon.svg\" width=\"120\" alt=\"vibe-keystone mark\">\n  <img alt=\"Vibe Keystone — write a CLAUDE.md that earns every line\" src=\"https://626labs.dev/assets/brand/plugins/vibe-keystone-banner-1500x500.png\" />\n</p>\n\n# Vibe Keystone\n\n**Writes a `CLAUDE.md` that earns every line. Cuts what your agent can already derive; keeps what it would otherwise get wrong.**\n\n[![stable](https://img.shields.io/github/v/tag/estevanhernandez-stack-ed/vibe-Keystone?label=stable&color=17d4fa)](https://github.com/estevanhernandez-stack-ed/vibe-Keystone/tags)\n\nThe keystone is the load-bearing structural file in any repository that uses Claude Code — every agent decision, every dispatched subagent, every commit message rests on it. If your `CLAUDE.md` surface is weak, the architecture standing on it can crumble. You hand a Claude Code session this skill, it asks you a few questions, then writes a `CLAUDE.md` that future agents in that repo will stand on.\n\n## What it does\n\nWhen invoked — typed as `/keystone`, or triggered by phrases like *\"set up CLAUDE.md\"*, *\"bootstrap claude md\"*, *\"create the keystone\"* — the skill:\n\n1. **Inventories the repo.** Git state, layout, stack manifest, existing `.claude/`, workflows. Refuses to write blind. Also works out **what owns any existing `CLAUDE.md`** — a generated file, or one carrying tool-owned regions, is edited at its source, not its output.\n2. **Interviews you for tenant context.** Whose repo, where decisions log, persona inheritance, work mode. Any tenant docs you name get read twice: as a source, and as an exclusion list.\n3. **Gates every line**, then writes what survives.\n4. **Self-checks** against eight criteria, including that every referenced path exists on disk.\n5. **Proposes follow-ups** — nested keystones, skills, agents, rules, hooks. Writes none of them.\n\n## The gate\n\nTwo questions per candidate line. **Both must be yes to cut:**\n\n1. **Derivable?** Could a session get this from `ls`, reading a file, reading the manifest, or `--help`?\n2. **Default correct?** If the line were gone, would the model's default assumption be right?\n\nThe first axis is mechanical, and it is the criterion Claude Code's own `/doctor` applies. The second is judgment, and it exists because thin context does not produce a model that asks — it produces one that quietly substitutes an industry default. Uncertain on the second means keep.\n\nWhat survives: **gotchas, rationale, and non-standard conventions.** A gotcha is an *unknown known* — obvious the moment it is named, invisible until then. If you cannot name the failure mode, it is not a gotcha.\n\nWhat does not: directory layouts, tech-stack lists, architecture overviews, command tables. Your agent can run `ls`.\n\n## What it will not cut\n\nPersona, voice, taste, priorities, brand tokens. That content fails the gate by construction, which is exactly why it is worth writing down — it is the one class of thing an agent cannot reconstruct from your repo.\n\nIt is never deleted for length. It is routed by how often it is needed: always-needed stays inline, situational moves to a skill, and deduplication points at the canonical copy rather than deleting the last one. Inside a persona, identity and procedure are separated — a long persona is often a short identity carrying a lot of restated process.\n\n## Progressive disclosure\n\nNested `CLAUDE.md` files load only while you are working under their directory, so multi-surface repos get a thin root plus per-surface proposals instead of one fat file. Guidance that is procedural and only sometimes needed becomes a proposed skill.\n\nThe root file targets ~50 lines with a ~100 ceiling. The ceiling is soft: a repo with twenty real gotchas correctly produces a longer file. The budget squeezes derivable content and nothing else.\n\n## When it declines\n\nSome repos do not need a keystone yet. When a repo yields no gotchas, no divergent conventions, and no rationale, the skill says so and **writes nothing** rather than emitting a skeleton of empty headings.\n\n## What it does not do\n\n- **Does not write blind.** Inventories first.\n- **Does not overwrite a generated file.** Retargets its template and leaves tool-owned regions alone.\n- **Does not restate the global persona**, or anything else the inherited file already says.\n- **Does not manufacture guardrails.** There is no minimum. \"Don't commit secrets\" is not a gotcha.\n- **Does not auto-create** nested keystones, skills, agents, rules, or hooks. It proposes; you decide.\n- **Does not overwrite an existing `CLAUDE.md`** without showing a diff and confirming.\n- **Does not rightsize files in place** — that is `/doctor`'s job. Keystone regenerates from the repo, so it can surface a trap nobody wrote down; `/doctor` trims the file, so it can only remove what is there. Different inputs, different jobs.\n\n### Using outside your own org\n\nThe defaults are 626Labs-flavored and the interview swaps them out. Name your org, your decision-log surface, your persona, and any docs you already have — a global `CLAUDE.md`, a handbook, a voice guide — and they fold into the produced file instead of 626Labs conventions landing by accident. No tenant docs at all means a minimal block you are asked to confirm, never invented rules.\n\nThe part that generalizes is the gate, the guard, and the discipline. The content comes from your repo and your answers.\n\n## Validated on\n\nFive real keystones across the 626 Labs estate, which surfaced five defects that would otherwise have shipped — including that the skill would silently overwrite generated `CLAUDE.md` files, and that a repo can carry a 205-line `CLAUDE.md` containing nothing about itself.\n\n| Repo | Before | After |\n| --- | --- | --- |\n| `vibe-plugins` | 147 | 46 |\n| `Celestia3` | 205 | 140 (authored — it had no keystone at all) |\n| `vibe-cartographer` | 204 | 152 |\n| `Projects` | 90 | 52 |\n\n## Install\n\n**Stable (recommended) — as a Claude Code plugin via the marketplace:**\n\n```text\n/plugin marketplace add estevanhernandez-stack-ed/vibe-plugins\n/plugin install vibe-keystone@vibe-plugins\n```\n\n**Canary — track this repo's `main`:**\n\n```text\n/plugin install vibe-keystone@estevanhernandez-stack-ed/vibe-Keystone\n```\n\nOnce installed, type `/keystone` in any new repo to invoke. As a marketplace plugin the skill dispatches as `/vibe-keystone:keystone` — slightly more verbose, but auto-updating with the repo.\n\n## Part of the Vibe ecosystem\n\nPart of the **[Vibe Plugins](https://github.com/estevanhernandez-stack-ed/vibe-plugins)** marketplace from [626 Labs](https://626labs.dev) — foundations and process pillars for AI-assisted creation. Keystone is a Foundation — structural: it sets the surface every other plugin's agents stand on.\n\n```text\n/plugin marketplace add estevanhernandez-stack-ed/vibe-plugins\n```\n\n## License\n\nMIT — *Imagine Something Else.* See [`LICENSE`](LICENSE). Copyright (c) 2026 626Labs LLC (Estevan Hernandez).\n\n---\n\n*Built by [Estevan Hernandez](https://github.com/estevanhernandez-stack-ed) at 626 Labs.*\n",
  "bytes": 7025,
  "sha": "b87c8eb719058d30e7e8649ecd6e966f395c7a297197912b2b473b535c4b5f82",
  "repo_slug": "estevanhernandez-stack-ed/vibe-keystone",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_estevanhernandez_stack_ed_vibe_keystone__9fb55244/readme"
}