---
name: docs-and-memory
description: Update project documentation or capture durable engineering context after code, architecture, setup, or recurring guidance changes.
---

# Docs And Memory

Keep durable guidance accurate, scoped, and reviewable. Prefer checked-in documentation for team facts and Codex memory for stable personal context; neither should contain secrets or ephemeral logs.

## Documentation updates

Identify the audience and source of truth. Read the implementation, configuration, and current docs before editing. Update the smallest set of documents needed for changed behavior, setup, public interfaces, operational procedures, or architecture decisions.

Commands must be runnable on the stated platform. Examples must use placeholders for secret values and clearly distinguish required from optional configuration. Remove or revise stale claims instead of appending contradictory notes.

Use `AGENTS.md` for recurring instructions that should affect future Codex work. Put repository-wide guidance at the root and narrow exceptions in the closest applicable subtree. Keep the root concise and point to maintained references when detail is conditional.

## Durable context

Capture only facts likely to remain useful: repository conventions, verified commands, architectural constraints, recurring failure causes, and explicit user preferences. Record the evidence and scope. Do not promote a one-off workaround into a universal rule.

Never derive memory by parsing Codex transcript files; that format is not a stable interface. Do not store credentials, personal data, copied private content, raw tool output, or speculative conclusions. If a fact is team-relevant, prefer a reviewed repository document over private memory.

## Verification

Check links, referenced paths, command names, versions, and examples. For generated docs, identify the generator and avoid hand-editing output. Summarize the documentation changed and the implementation evidence used.