From vibe-keystone
Bootstrap a CLAUDE.md from the 626Labs project-CLAUDE pattern, with tenant-aware adaptation. Interviews the user for org / decision surface / voice rules / persona before drafting, so the produced file reflects THEIR conventions — not 626Labs defaults baked in. The keystone is the load-bearing structural file — every agent decision in the repo rests on it. Use when starting in a new repo without a CLAUDE.md, or when the existing one is stale. Trigger phrases include "set up CLAUDE.md", "create the keystone", "bootstrap claude md", "claude md for this repo", "/keystone".
How this skill is triggered — by the user, by Claude, or both
Slash command
/vibe-keystone:keystoneThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are an agent in a 626Labs-owned (or 626Labs-style) repository. Your task is to produce a `CLAUDE.md` for this repo following the 626Labs project-CLAUDE pattern. Read this entire skill before writing anything.
You are an agent in a 626Labs-owned (or 626Labs-style) repository. Your task is to produce a CLAUDE.md for this repo following the 626Labs project-CLAUDE pattern. Read this entire skill before writing anything.
The keystone is the load-bearing structural file: every decision the agent makes in the repo rests on it. Get it right.
Before producing the file, inventory the repo:
git status and git log --oneline -20 — branch state + recent rhythmls -la — top-level layoutpackage.json, pyproject.toml, Cargo.toml, or whatever defines the stackREADME.md and any top-level *.md files.claude/, .husky/, .github/workflows/, scripts/, docs/, .ai/Makefile, Dockerfile, GitHub Actions, etc.CLAUDE.md already exists, read it before overwriting. Do not blindly replace.Identify the repo type:
Before a CLAUDE.md is meaningful, you need to know whose conventions it should encode. This skill ships with 626Labs defaults baked in (Dashboard MCP for decisions, 626Labs voice rules, brand tokens, Architect persona inheritance) — but those should only land when the user is actually 626Labs. For any other tenant, ask first.
Ask the user in one round (concise — single message back). Group the questions and let them skip ones that don't apply:
Whose repo is this — 626Labs, another organization, an individual project?
If 626Labs: the defaults apply (Dashboard MCP, brand voice, Architect persona). Skip to question 4.
If another tenant, follow up:
~/.claude/CLAUDE.md defining a persona, an org HANDBOOK.md, a CONTRIBUTING.md, a VALUES.md / principles doc, a brand voice guide, a style guide, an architecture doc. Name the paths and I'll read them before drafting — your priorities, voice rules, and conventions should fold into the produced file.mcp__626Labs__manage_decisions log — 626Labs Dashboard MCP (default for 626Labs repos)decisions.md (or similar) file in the repo~/.claude/CLAUDE.md define a persona this repo should reference (e.g., 626Labs's "The Architect")? If yes, the produced CLAUDE.md will say "inherits {name}, no need to re-establish.".claude/agents/? — list them, or "propose new ones based on the repo type."If CLAUDE.md already exists, also ask: keep the existing persona/voice/structure and refresh the rest, or rewrite section-by-section?
After the user answers, read any tenant docs they named before drafting. Tenant priorities, voice rules, and decision-log conventions should fold into the produced CLAUDE.md instead of inheriting 626Labs defaults that don't apply.
Carry these answers downstream as adaptations:
| Section | 626Labs default | Other tenant — substitute |
|---|---|---|
| Tech Stack & Voice (content-bearing repos) | 626Labs voice rules + brand tokens (cyan, magenta, navy, Space Grotesk, etc.) | Pull from tenant brand/voice docs. If no docs, propose a minimal voice block and ask the user to confirm. |
| Design system reference | ~/.claude/skills/626labs-design/ | Tenant's equivalent if any; otherwise drop the section. |
| Decisions log | mcp__626Labs__manage_decisions log | Whatever the user named in Q2. If "none," drop the section or point at commit/PR conventions. |
| Persona inheritance note | The Architect (or whatever 626Labs has) | Tenant's persona name, or "no persona" framing. |
Produce a CLAUDE.md with these sections. Drop sections marked CONDITIONAL when they don't apply.
If the user said inherit from global:
# {Repo Name}
> **Persona:** This repo inherits {global persona name from Step 1} from `~/.claude/CLAUDE.md`. No need to re-establish — just adds project context below.
If the user said override (writing/thesis case):
> **Persona override:** In this repo, you operate as {Project Persona} — not the global one. {Persona} supersedes for {scope}; global process habits (gather context, log decisions, assess blast radius) still apply to project work (commits, file moves, MCP calls).
If the user said no persona at all, drop the blockquote entirely. Just the # {Repo Name} title.
For a code-only repo:
## Tech Stack
- **Language/Framework:** {actual}
- **Build:** {actual}
- **Deploy:** {actual}
- **Testing:** {actual}
For any public-facing / content-bearing repo, add a Voice section.
If 626Labs-owned (Step 1 Q1):
## Tech Stack & Voice
- **Stack:** {as above}
- **Brand:** Cyan `#17d4fa` + magenta `#f22f89`, always paired. Navy `#0f1f31` field. Space Grotesk display, Inter body, JetBrains Mono code/meta (uppercase + 0.12em tracking on small labels).
- **Voice:** Builder-to-builder, second person, sentence case. No "empower / leverage / seamlessly / unlock / unleash." Em-dashes welcome. No emoji in UI copy or marketing surfaces. Tagline: *Imagine Something Else.*
If another tenant: pull voice rules + brand tokens from any tenant docs the user named in Step 1. Match the tenant's existing brand voice rather than inventing one. If no tenant voice docs exist, write a minimal block and ask the user to confirm or extend:
## Tech Stack & Voice
- **Stack:** {as above}
- **Voice:** {tenant-provided voice rules, OR — if none — a minimal "builder-to-builder, second person, no corporate speak" placeholder for the user to extend}
- **Brand:** {tenant-provided tokens, OR — if none — note "no brand tokens established"}
If 626Labs-owned:
## Design system
Canonical brand spec lives at `~/.claude/skills/626labs-design/` (globally available — same skill across every 626 Labs repo). Use `colors_and_type.css` as the token source and `ui_kits/` as the pattern reference. Local `Design/` (or wherever this repo keeps brand artifacts) is for repo-specific references only.
If another tenant with their own design skill / system docs: point at their canonical brand spec the same way.
If no tenant design system exists: drop this section entirely. Don't fabricate a reference.
A markdown table with paths and one-line purposes. One row per major directory or load-bearing file. Anyone should find anything in 5 seconds.
## What's where
| Path | What it is |
|---|---|
| `src/` | {one line} |
| `scripts/` | {one line} |
| ... |
This is the operational center of gravity. Pick what applies:
Use sub-headings under one parent section. Be concrete — name the actual files, scripts, workflows, and triggers.
## Common tasks
| You want to… | Path / command |
|---|---|
| {task} | {how} |
5–10 rows covering the most frequent operations.
## Conventions
- **Commits:** Conventional commits ({list types — for thesis repos use academic-flavored: draft / revise / cite / respond / meta / chore})
- **Style:** {brief, stack-specific}
- **File rules:** {what's read-only, what's generated, what's the canonical source}
The shape adapts to the user's answer in Step 1 Q2.
If 626Labs Dashboard MCP:
## Decisions log
Significant decisions log to the **626Labs Dashboard** via MCP (`mcp__626Labs__manage_decisions log`). Tag with the bound project ID. The bar: *would future-you (or someone asking "why this approach?") want to know this in 3–6 months?*
Especially:
- {category 1, repo-specific}
- {category 2}
- {3–5 categories total}
Skip the routine: {what doesn't get logged}.
If unbound (no 626Labs project): tag with the repo name in the description and set `projectId: null`.
If a different MCP / tool: swap the tool name and any binding mechanics. Same shape, same bar.
If a decisions.md file:
## Decisions log
Significant decisions land in `decisions.md` (or `docs/decisions/` for ADR-style). Each entry: date, title, context, decision, consequences. The bar: *would future-you want to know this in 3–6 months?*
Categories worth logging: {repo-specific list}. Skip the routine.
If an external tracker (Linear / Jira / Notion / GitHub Issues): point at the tracker, link to the project/board, name the labels or convention used to mark "decision" entries.
If "none": drop this section entirely. Don't fabricate a decision-log surface that doesn't exist. Optionally add a one-line note in the Conventions section: "Significant decisions are captured in commit messages and PR descriptions; no separate decision log."
3–5+ explicit, repo-specific guardrails. Each one names the failure mode and (where useful) the right alternative.
## What NOT to do
- **Don't {specific thing}** — {why, or what to do instead}
- ...
Examples to draw from when identifying don'ts: don't hand-edit generated files (and the right edit point), don't bypass the build pipeline, don't commit secrets, don't force-push to main, don't fabricate citations (thesis), don't write to read-only directories.
## References
- Architecture details: {path}
- Modular rules: `.claude/rules/`
- Specialized agents: `.claude/agents/` (see `agents/README.md`)
- Session hooks: `.claude/hooks/`
- CI/CD: `{path}`
CLAUDE.md at repo root#, ##, ###)Verify:
After the CLAUDE.md lands, propose:
.claude/agents/ candidates that would serve recurring tasks in this repo (code-reviewer, security-auditor, copy-reviewer, visual-asset-reviewer, citation-checker, devils-advocate, story-editor, etc. — pick what fits).claude/rules/ files for specialized guidance that doesn't fit in CLAUDE.md.claude/hooks/ for automation that closes a feedback loop (template-edit drift checks, type-check-after-edit, etc.)Each suggestion is a proposal. The user decides what gets built.
Code platform:
Marketing / content site:
Long-form writing / thesis:
Infrastructure / mixed:
.claude/agents/, .claude/rules/, or .claude/hooks/. Propose them; let the user decide.Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub estevanhernandez-stack-ed/vibe-keystone --plugin vibe-keystone