initializing-memory

Files (1)

• SKILL.md

SKILL.md (first lines)

# Memory Initialization

Initialize persistent memory into a deeply hierarchical structure of 15-25
small, focused files in `.pi/memory/`.

Run `/init` again after major project changes or when you want to re-analyze.

## Target Output

| Metric              | Target                                   |
| ------------------- | ---------------------------------------- |
| Total files         | 15-25 (aim for ~20)                      |
| Max lines per file  | ~40 (split if larger)                    |
| Hierarchy depth     | 2-3 levels using `/` naming              |
| Nesting requirement | Every file MUST be nested under a parent |

**Anti-patterns:**

- ❌ Only 3-5 large files
- ❌ Flat naming (all files at top level)
- ❌ Mega-files with 10+ sections

## Example Target Structure

```
system/
├── human/
│   ├── identity.md
│   ├── context.md
│   └── prefs/
│       ├── communication.md
│       ├── coding_style.md
│       └── workflow.md
├── project/
│   ├── overview.md
│   ├── architecture.md
│   ├── conventions.md
│   ├── gotchas.md
│   └── tooling/
│       ├── testing.md
│       └── linting.md
└── persona/
    ├── role.md
    └── behavior.md
reference/
├── README.md
└── history/
    └── decisions.md
```

## What to Remember

### 1. Procedures (Rules & Workflows)

- Commit conventions, branching strategy
- Build/test/lint commands and order
- Review process, CI requirements

### 2. Preferences (Style & Conventions)

- Coding style rules (formatting, patterns, anti-patterns)
- Communication preferences (terse vs detailed)
- Tool preferences (which tools, how to use them)

### 3. History & Context

- Key refactors, past bugs, architectural decisions
- Project evolution, deprecated patterns
- Ongoing work and current priorities

## Workflow

### Step 1: Backup existing memory

Use `memory_backup` tool first if memory already has content.

### Step 2: Ask upfront questions (bundle in one message)

1. **Research depth**: Standard (~5-20 tool calls) or deep (~100+)?
2. **Identity**: Which contributor are you? (check git context from /init)
3. **Related repos**: Other repositories you should know about?
4. **Historical sessions**: If prior agent sessions were detected, ask:
   "I found prior Claude Code / Pi / Codex sessions. Should I analyze them
   to learn your preferences and project context?"
5. **Communication**: Terse or detailed responses?
6. **Rules**: Any rules I should always follow?

**Don't ask things you can find by reading files.** Be autonomous during execution.

### Step 3: Research the project

**Standard research:**

- README, AGENTS.md, CLAUDE.md, CONTRIBUTING.md
- Package manifests (package.json, Cargo.toml, pyproject.toml, go.mod)
- Config files (tsconfig, eslint, prettier, etc.)
- `git log --oneline -20` — recent history
- `git log --format="%s" -50 | head -20` — commit conventions
- Explore key directories and understand structure

**Deep research (if chosen):**

- Everything above, plus:
- `git shortlog -sn --all | head -10` — contributors
- `git branch -a` — branching strategy
- `git log --format="%an <%ae>" | sort -u` — deduplicate contributors by email
- Deep dive into architecture, patterns, CI config
- Analyze multiple source directories
- Read key source files to understand patterns
- Cross-reference findings, resolve ambiguities

**Think like a new team member**: What would you want to know on your first day?

### Step 4: Analyze prior sessions (if approved)

If the user approved session history analysis:

**Claude Code sessions** (`~/.claude/projects/`):

From edmundmiller/dotfiles, MIT.

More from edmundmiller/dotfiles