Initiate 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.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.