alex
f9880638e9
AGENTS.md, CLAUDE.md, copilot-instructions.md, and .cursorrules may contain project knowledge added by other tools or people. Agents now read these files at session start and merge new knowledge into .memory/knowledge.md as the canonical source.
91 lines
2.8 KiB
Markdown
91 lines
2.8 KiB
Markdown
# Bootstrap Project Memory Files
|
|
|
|
RUN { git ls-files; git ls-files --others --exclude-standard; } 2>/dev/null | sort -u
|
|
READ README.md
|
|
|
|
You are bootstrapping `.memory/` files for this project.
|
|
|
|
Your job is to inspect the codebase and create an initial memory baseline in plain
|
|
markdown files. Capture architecture, core modules, conventions, and key decisions
|
|
so future sessions can resume quickly.
|
|
|
|
## Step 1: Create `.memory/` structure
|
|
|
|
Create (if missing):
|
|
|
|
```
|
|
.memory/
|
|
knowledge.md
|
|
decisions.md
|
|
plans/
|
|
research/
|
|
```
|
|
|
|
`.memory/` is tracked in git.
|
|
|
|
## Step 2: Inspect project structure
|
|
|
|
Run `git ls-files` to understand the project layout, then read `README.md` and
|
|
the highest-signal files for architecture and conventions.
|
|
|
|
Also check for existing cross-tool instruction files (`AGENTS.md`, `CLAUDE.md`,
|
|
`.github/copilot-instructions.md`, `.cursorrules`) — they may contain project
|
|
knowledge from other tools or team members that should be incorporated.
|
|
|
|
Identify:
|
|
- What the project does (primary capabilities)
|
|
- Core modules/subsystems and responsibilities
|
|
- Key patterns/conventions (naming, layering, testing, config)
|
|
|
|
## Step 3: Write initial `knowledge.md`
|
|
|
|
Populate `.memory/knowledge.md` with:
|
|
- Project purpose and scope
|
|
- Architecture overview
|
|
- Key modules with file paths
|
|
- Important implementation patterns/conventions
|
|
|
|
Use markdown sections with max 2 heading levels.
|
|
|
|
## Step 4: Seed `decisions.md`
|
|
|
|
Populate `.memory/decisions.md` with any clear, durable decisions found in docs
|
|
or code patterns (for example: stack choices, testing strategy, architectural
|
|
constraints). Include rationale when known.
|
|
|
|
## Step 5: Initialize plans/research folders
|
|
|
|
- If active in-progress work is discoverable, create `.memory/plans/<feature>.md`
|
|
with scope, tasks, and acceptance criteria.
|
|
- If research artifacts are discovered, create `.memory/research/<topic>.md`
|
|
with findings and references.
|
|
|
|
## Step 6: Create/update cross-tool instruction files
|
|
|
|
After `.memory/knowledge.md` is populated, use it as the source of truth to
|
|
create or update all cross-tool instruction files:
|
|
|
|
- `AGENTS.md`
|
|
- `CLAUDE.md`
|
|
- `.github/copilot-instructions.md`
|
|
- `.cursorrules`
|
|
|
|
Each file should include the same core project guidance:
|
|
- project overview and purpose
|
|
- tech stack
|
|
- architecture summary
|
|
- coding conventions/patterns
|
|
- build/test/lint commands
|
|
- project structure overview
|
|
|
|
If any of these files already exist, preserve existing project-specific content
|
|
and merge in new knowledge instead of overwriting wholesale.
|
|
|
|
## Guidelines
|
|
|
|
- Be specific with file paths, APIs, parameters, and behavioral details.
|
|
- Keep sections concise and scannable.
|
|
- Prefer durable knowledge over transient status notes.
|
|
- Add markdown cross-references between related entries (for example,
|
|
knowledge entries linking to decisions).
|