Skip to content

/init-context

Set a project up with the surfaces manifest-dev works from — a glossary, ADR conventions, and the context-file wiring that makes every session use them — seeding them from the project''s own history where there is any. Use when a repository has no CONTEXT.md or decision records,

From plugin
manifest-dev
7092 skills2 agents
Install
$ npx -y skills add doodledood/manifest-dev --skill init-context --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/init-context

Context preview

The summary Claude sees to decide when to auto-load this skill.

Set a project up with the surfaces manifest-dev works from — a glossary, ADR conventions, and the context-file wiring that makes every session use them — seeding them from the project''s own history where there is any. Use when a repository has no CONTEXT.md or decision records,

SKILL.md

init-context.SKILL.md
name: init-context
description: 'Set a project up with the surfaces manifest-dev works from — a glossary, ADR conventions, and the context-file wiring that makes every session use them — seeding them from the project''s own history where there is any. Use when a repository has no CONTEXT.md or decision records, when adopting manifest-dev in an existing codebase, when starting a new project, or when the user asks to initialize project context, bootstrap ADRs, or reconstruct decisions from history.'

Install the project surfaces a repository needs so that every future session — and every teammate, with or without manifest-dev — works from the same vocabulary and the same decision record.

Two things get installed, and only the first is essential:

  • **The wiring** — an ADR conventions file the project owns, a glossary, and a project-context-file section that makes sessions read and maintain both. This runs on every project, including one with no history at all.
  • **A seed** — vocabulary and decision records reconstructed from the project's own history. This runs wherever there is history to read, and it is enrichment on top of the wiring, never a substitute for it.

Aim for a good starting point rather than a complete record. Most of a project's past reasoning is genuinely unrecoverable; a seed that is honest about what it could not recover is worth far more than one that reads complete and isn't.

Flags

`--no-mine` skips the seed and installs the wiring alone. Mining otherwise runs wherever there is history — a project with no commits, no docs and no code simply has nothing to seed from, which needs no flag to express.

Interpret only top-level options as flags; quoted or code-formatted mentions of them are topic text.

What already exists governs

Read before writing, and never overwrite a surface the project already maintains:

  • **`docs/adr/CONVENTIONS.md` exists** → the project has its own ADR convention. It governs. Do not replace it; follow it for anything written this run, and skip the conventions step.
  • **`CONTEXT.md` exists** (or the context named by a root `CONTEXT-MAP.md`) → load it. Mined vocabulary is proposed as additions to it, never as a replacement.
  • **`docs/adr/` holds records but there is no `CONVENTIONS.md`** → the project has an unwritten convention, and the records are the evidence of it. Infer it from them — naming scheme, which sections they carry, how they cross-reference, what the index looks like — and write the conventions file to describe *that*, adapting the shipped default rather than replacing it. Installing the default unchanged here would declare an existing corpus non-conforming, which is both wrong and the fastest way to get the file ignored. Where the corpus is inconsistent, or where following it would leave the index un-rebuildable, say so and let the user choose; never silently pick.
  • **A project context file already carries some of this wiring** → add what is missing and leave the rest alone.

The run

1. **Resolve the project context file.** Its name differs by CLI — `CLAUDE.md`, `AGENTS.md`, or another — so detect it rather than assuming. The detection table and per-CLI resolution order live in `../review-code/references/context-file-adherence.md`; read it and use it.

2. **Install the ADR conventions**, unless `docs/adr/CONVENTIONS.md` already exists. Copy `../figure-out/references/ADR_FORMAT.md` to `docs/adr/CONVENTIONS.md`, changing its opening as follows and nothing else:

  • retitle the heading to `# ADR Conventions`;
  • keep the sentence describing what ADRs are;
  • replace both the self-contained note and the whole `## Precedence` section with one paragraph stating that this file is the project's ADR convention and governs, that everything needed to decide and write is here with no tool or prior knowledge required, and that tooling carrying its own defaults defers to it.

Everything from `## When a decision deserves a record` onward travels verbatim — the file is written to be self-sufficient, and a reader with no tooling must be able to follow it end to end.

Where records already exist, this is not a straight copy: reconcile the default with the practice those records show, per *What already exists governs* above, and surface any divergence you had to resolve.

3. **Seed, unless `--no-mine`.** Load `references/MINING.md` and follow it. It covers what each source can and cannot yield, how a record says so when the reasoning is gone, and why glossary candidates are ratified rather than written.

4. **Wire the project context file.** Add a section carrying three things, and nothing else — the conventions file holds the detail, and this file is read on every session, so every line here is a permanent cost:

  • **The glossary is resident.** Import `CONTEXT.md` where the host supports imports, and state the instruction to read it at session start regardless — a host without imports still gets a trigger, and session start is one. Write it as *the project context file*, not as a specific filename.
  • **When to open the decision records.** Before settling a question the project may already have settled, and when a change contradicts or narrows an existing decision. A pointer with no trigger is how a corpus goes unread.
  • **Writing a record is one act.** The new record, the restatus of everything whose standing it changes, and the index rebuild — in one change, pointing at the conventions file for how.

5. **Report what landed**, per the *Reporting* section of `references/MINING.md`, which specifies what the report must cover. A run that skipped seeding still reports — what was installed, and that nothing was seeded because there was nothing to seed from.

Empty input

Pointed at a repository with no commits, no documentation and no code, install the wiring and stop: the conventions file, a `CONTEXT.md` holding the project name, a one-line purpose and an empty Language section, and the context-file section.

Read more
Ships withmanifest-dev

Loop engineering for Claude Code and other agent CLIs: figure the problem out first, define what done means, then execute and verify every criterion independently.

Get the whole plugin, auto-invoked

Other skills on manifest-dev.