reinit

name	reinit
description	Review available recent code-agent history and tool calls, then update the current repository's durable agent guidance with repeatedly needed facts and user-corrected conventions. Run only when the user explicitly invokes /reinit, $reinit, or names the reinit skill; never invoke automatically.
disable-model-invocation	true
user-invocable	true

Reinit

Refresh the current repository's agent guidance from evidence in recent agent work. Preserve durable knowledge that will prevent repeated discovery or repeated user corrections. Do not turn temporary session state into permanent instructions.

Workflow

1. Establish the repository root and scope all edits to that repository.
2. Review the current session's conversation, then any local agent history available for this repository, starting from the reference locations under "Known local history locations". By default inspect up to the 20 most recent sessions from the last 30 days, excluding the current session's own transcript; widen the window (for example, to 90 days) on a first run when no guidance file exists yet. Do not search unrelated home-directory data, credentials, caches, or other repositories merely to find more history.
3. Record candidate facts that the agent repeatedly had to discover, candidate conventions that affected its decisions, and corrections or preferences explicitly supplied by the user.
4. Read the applicable guidance files before proposing changes. Check AGENTS.md, CLAUDE.md, and their relevant ancestor or nested variants. Follow existing repository conventions for which file is canonical.
5. Verify factual candidates against the current repository using the cheapest authoritative source. Prefer manifests, configuration, existing documentation, and focused file inspection over repeating broad exploratory searches.
6. Apply the retention test below. Discard candidates that do not pass.
7. Update the canonical guidance file in place. Preserve existing content and structure, remove exact duplication, and make the smallest coherent edit.
8. Review the diff for accuracy, durability, scope, sensitive data, contradictions, and unnecessary verbosity.
9. Report which guidance file changed, what durable knowledge was added or corrected, and which tempting candidates were intentionally excluded. If nothing qualifies, make no edit and say so.

Retention test

Add a fact or instruction only when all applicable conditions hold:

• It is relevant to future work in this repository.
• It is unlikely to change between ordinary tasks.
• It is not already stated in the repository's guidance files. User-level configuration and personal agent memory do not count as already stated: they are invisible to other contributors, so a repository-relevant fact or correction recorded only there must still be added to the repository guidance. Purely personal preferences with no repository relevance stay out.
• It is specific enough to change or accelerate agent behavior.
• It is supported by current repository evidence or an explicit user preference.
• It either appeared repeatedly in recent discovery work, or represents a clear user correction or standing preference. One explicit correction is sufficient; incidental one-off behavior is not.

Good candidates commonly include:

• Authoritative build, test, lint, format, generation, and validation commands, including required ordering or working directories.
• Package-manager choice, workspace layout, important entry points, ownership boundaries, and non-obvious architectural relationships.
• Generated or vendored paths that should not be edited, and the source files or commands that regenerate them.
• Stable environment constraints, supported runtimes, or tool requirements that are pinned or enforced by repository configuration.
• Repository-specific coding, testing, naming, error-handling, compatibility, or review conventions that are not reliably inferable from nearby code.
• Standing user preferences that apply to future repository work, such as how to derive commit messages, what historical context to consult, or a consistently requested coding style.
• Recurring traps where the obvious command, directory, or implementation approach is wrong for this repository.

Exclude:

• Current branch, dirty files, uncommitted changes, open task state, temporary paths, timestamps, transient failures, and recent command output.
• Guesses based only on the agent checking something once.
• Facts that are cheap and obvious from the file currently being edited unless agents repeatedly need them to orient themselves.
• Exhaustive directory trees, dependency inventories, file-by-file descriptions, tutorials, or generic software-engineering advice.
• Versions that float frequently unless a manifest or policy pins them and the version materially changes the workflow.
• Secrets, credentials, tokens, private conversation content, personal data, or machine-specific configuration.
• Preferences that applied only to one deliverable or were not expressed as an ongoing convention.

Guidance-file strategy

• Prefer an existing canonical guidance file over creating another one.
• When no guidance file exists, create AGENTS.md at the repository root for portable agent guidance.
• When only CLAUDE.md exists and it is clearly canonical, update it rather than creating duplicate guidance.
• When both exist, respect any delegation or import relationship between them. Put shared repository facts in AGENTS.md when appropriate and Claude-only behavior in CLAUDE.md; do not copy the same paragraphs into both.
• Keep nested guidance scoped to the subtree it governs. Do not promote subsystem-specific rules to the repository root.
• Preserve stronger existing instructions. If new evidence conflicts with them, verify the current repository and revise only when the old guidance is demonstrably stale or the user explicitly superseded it.

Writing rules

• Write short, operational statements under existing headings when possible.
• State the command, path, constraint, or decision directly; omit the story of how it was discovered.
• Prefer a small number of high-value additions over documenting every observation.
• Use exact commands only after verifying them. Mark required working directories and prerequisites.
• Do not add a generated timestamp, session identifier, or /reinit bookkeeping section.
• Do not modify application code, configuration, or unrelated documentation during this workflow.

Known local history locations

These paths are reference points only. Storage layouts change between product versions and platforms, so verify a path exists before reading it and fall back to the visible conversation when it does not.

• Claude Code: ~/.claude/projects/<encoded-cwd>/<session-id>.jsonl, one transcript per session, where <encoded-cwd> is the working-directory path with / replaced by -.
• Codex CLI: ~/.codex/sessions/<YYYY>/<MM>/<DD>/rollout-*.jsonl, stored globally across repositories; filter by the cwd recorded inside each file. ~/.codex/history.jsonl holds user prompts only, without tool calls.
• opencode: ~/.local/share/opencode/opencode.db (SQLite) in newer versions; older versions stored JSON files under ~/.local/share/opencode/storage/session/ and storage/message/.
• Crush: <repo>/.crush/crush.db, a per-repository SQLite database inside the repository itself.
• pi: ~/.pi/agent/sessions/<encoded-cwd>/<timestamp>_<id>.jsonl, one transcript per session, grouped under an encoded working-directory path.

Transcripts can be large. Extract user messages, corrections, and repeated discovery work with targeted filters (grep, jq, or SQL) instead of reading whole files. Only read history belonging to the current repository, and never copy secrets or personal data from transcripts into guidance files.

History limitations

Use only history actually exposed to the current agent. Never claim to have reviewed unavailable sessions or tool calls. If earlier history is unavailable, use the visible conversation and explicitly state the limitation. Do not compensate by treating Git history as agent-session history; Git history may verify a candidate, but it does not reveal which facts agents repeatedly rediscovered or which corrections users made.