Initializing Memory

Initializing Memory

The user has requested that you initialize or reorganize your memory state for this project. This skill helps you systematically explore and document a codebase to build effective working memory.

Understanding Your Context

Important: This skill is designed for stateful agents that work with users over extended periods. Your memory is not just a convenience; it's how you get better over time and maintain continuity across sessions.

This command may be run in different scenarios:

• Fresh project: Starting work on a new codebase
• Existing project: User wants you to reorganize or significantly update your understanding
• Deep dive: User wants comprehensive analysis of the project

Before making changes, inspect your current context and understand what already exists.

What to Remember About a Project

1. Procedures (Rules & Workflows)

Explicit rules and workflows that should always be followed:

• "Never commit directly to main - always use feature branches"
• "Always run lint before running tests"
• "Use conventional commits format for all commit messages"
• "Always check for existing tests before adding new ones"

2. Preferences (Style & Conventions)

User and project coding style preferences:

• "Never use try/​catch for control flow"
• "Always add JSDoc comments to exported functions"
• "Prefer functional components over class components"
• "Use early returns instead of nested conditionals"

3. History & Context

Important historical context that informs current decisions:

• "We fixed this exact pagination bug two weeks ago - check PR #234"
• "This monorepo used to have 3 modules before the consolidation"
• "The auth system was refactored in v2.0 - old patterns are deprecated"

Memory Scope Considerations

Consider whether information is:

Project-scoped:

• Build commands, test commands, lint configuration
• Project architecture and key directories
• Team conventions specific to this codebase
• Technology stack and framework choices

User-scoped:

• Personal coding preferences that apply across projects
• Communication style preferences
• General workflow habits

Session/​Task-scoped:

• Current branch or ticket being worked on
• Debugging context for an ongoing investigation
• Temporary notes about a specific task

Recommended Memory Structure

Core Information Categories

Project Overview: Your behavioral guidelines and project purpose

• Technology stack and architecture
• Key directories and their purposes
• Build/​test/​lint commands

Conventions: Project-specific rules and patterns

• Commit message format
• Code style preferences
• PR process and review guidelines

User Preferences: User-specific information

• Communication style preferences
• Cross-project preferences
• Working style and habits

Optional Categories (Create as Needed)

Current Task: Scratchpad for current work item context

• Ticket ID, branch name, PR number
• Relevant links and context
• Current focus area

Decisions: Architectural decisions and their rationale

• Why certain approaches were chosen
• Trade-offs that were considered

Research Depth

You can ask the user if they want a standard or deep research initialization:

Standard initialization (~5-20 tool calls):

• Scan README, package.json/​config files, AGENTS.md, CLAUDE.md
• Review git status and recent commits
• Explore key directories and understand project structure
• Create/​update your memory to contain the essential information

Deep research initialization (~100+ tool calls):

• Everything in standard initialization, plus:
• Use TodoWrite to create a systematic research plan
• Deep dive into git history for patterns, conventions, and context
• Analyze commit message conventions and branching strategy
• Explore multiple directories and understand architecture thoroughly
• Search for and read key source files to understand patterns

What deep research can uncover:

• Contributors & team dynamics: Who works on what areas? Who are the main contributors?
• Coding habits: When do people commit? What's the typical commit size?
• Writing & commit style: How verbose are commit messages? What conventions are followed?
• Code evolution: How has the architecture changed? What major refactors happened?
• Pain points: What areas have lots of bug fixes? What code gets touched frequently?

Research Techniques

File-based research:

• README.md, CONTRIBUTING.md, AGENTS.md, CLAUDE.md
• Package manifests (package.json, Cargo.toml, pyproject.toml, go.mod)
• Config files (.eslintrc, tsconfig.json, .prettierrc)
• CI/​CD configs (.github/​workflows/, .gitlab-ci.yml)

Git-based research (if in a git repo):

• git log --oneline -20 - Recent commit history and patterns
• git branch -a - Branching strategy
• git log --format="%s" -50 | head -20 - Commit message conventions
• git shortlog -sn --all | head -10 - Main contributors
• Recent PRs or merge commits for context on ongoing work

How to Do Thorough Research

Don't just collect data - analyze and cross-reference it.

Shallow research (bad):

• Run commands, copy output
• Take everything at face value
• List facts without understanding

Thorough research (good):

• Cross-reference findings: If two pieces of data seem inconsistent, dig deeper
• Resolve ambiguities: Don't leave questions unanswered
• Read actual content: Don't just list file names - read key files to understand them
• Look for patterns: What do the commit messages tell you about workflow?
• Form hypotheses and verify: "I think this team uses feature branches" → check git branch patterns
• Think like a new team member: What would you want to know on your first day?

Questions to ask yourself during research:

• Does this make sense?
• What's missing?
• What can I infer?
• Am I just listing facts, or do I understand the project?

The goal isn't to produce a report - it's to genuinely understand the project and how to be an effective collaborator.

Recommended Questions to Ask

Bundle these questions together when starting:

1. Research depth: "Standard or deep research (comprehensive, as long as needed)?"
2. Identity: "Which contributor are you?" (You can often infer from git logs)
3. Related repos: "Are there other repositories I should know about?"
4. Communication style: "Terse or detailed responses?"
5. Any specific rules: "Rules I should always follow?"

What NOT to ask:

• Things you can find by reading files ("What's your test framework?")
• Permission for obvious actions - just do them
• Questions one at a time - bundle them

Your Task

1. Ask upfront questions: Bundle the recommended questions above
2. Inspect existing context: See what already exists in AGENTS.md, README, etc.
3. Identify the user: From git logs and their answers
4. Research the project: Explore based on chosen depth. Use TodoWrite for a systematic plan.
5. Document findings: Create notes or update project documentation
6. Reflect and review: Check for completeness and quality
7. Ask user if done: Check if they're satisfied or want you to continue

Reflection Phase

Before finishing, do a reflection step:

1. Completeness check: Did you gather all relevant information?
2. Quality check: Are there gaps or unclear areas?
3. Structure check: Would this information make sense to your future self?

After reflection, summarize what you learned:

"I've completed the initialization. Here's a brief summary of what I set up: [summary]. Should I continue refining, or is this good to proceed?"

Remember: Good memory management is an investment. The effort you put into organizing your knowledge now will pay dividends as you work with this user over time.