Prime: Load Project Context
Objective
Build understanding of the codebase - either high-level overview or focused deep-dive based on whether a focus area argument is provided.
Usage
/prime- High-level overview (architecture, patterns, structure)/prime "authentication system"- Deep-dive into specific area/prime "API endpoints"- Focus on particular functionality
Decision: Which Mode?
Check if focus area argument was provided:
- Arguments provided → Use FOCUSED mode
- No arguments → Use HIGH-LEVEL mode
HIGH-LEVEL Mode (No Arguments)
Goal: Understand architecture, patterns, and structure with minimal token usage.
Step 1: Directory Structure
Use Bash to show directory tree (2 levels max):
tree -L 2 -I 'node_modules|__pycache__|.git|dist|build|.next|coverage|venv|.venv'
If tree not available, use ls or alternative.
Step 2: Count Files (Optional)
Only if in a git repo:
git ls-files | wc -l
Step 3: Read Minimal Documentation
Read at most 3 files:
- Root README.md (if exists)
- CLAUDE.md or .claude/config (if exists)
- One config file: package.json OR pyproject.toml OR tsconfig.json OR Cargo.toml
DO NOT read:
- Implementation files (src/, lib/, etc.)
- Test files
- Subdirectory READMEs
- Multiple config files
Step 4: Check Git State (If Git Repo)
git status
git log -10 --oneline
Step 5: Internalize Context
Build mental model of the project:
- Purpose and type of application (from README)
- Primary technologies and frameworks (from config)
- Directory structure and organization
- Key directories and their likely purposes (inferred from names)
- Main architectural patterns (if obvious from structure)
DO NOT output this to CLI. Keep context in memory for answering questions.
Step 6: Output Completion
Output only:
Finished priming project.
No detailed report. Context is loaded and ready for use.
FOCUSED Mode (With Argument)
Goal: Deep understanding of a specific area, ignore everything else.
Step 1: Extract Keywords
From the focus area argument, identify key search terms.
Example: "authentication system" → keywords: auth, authentication, login, session, user
Step 2: Find Relevant Files
Use Grep to search for files containing focus keywords:
grep -r "keyword1\|keyword2" --files-with-matches --include="*.py" --include="*.ts" --include="*.js"
Or use Glob for pattern matching:
**/*auth*/**
**/*login*/**
Step 3: Read All Relevant Files
- Read ALL files found in Step 2 that are directly related
- Read imported dependencies if critical to understanding
- Read related documentation
- Go deep into implementation details
No limit on file reading in focused mode.
Step 4: Analyze for Structural Blockers
Internalize understanding (keep in memory, don't output):
- Key functions/classes/components
- Main data structures or types
- Entry points and exports
- Dependencies & integrations
- Patterns & conventions
- Testing approach
Detect structural problems that would block implementation:
Inconsistent Patterns:
- Mixed architectural styles (e.g., some files use MVC, others use different pattern)
- Inconsistent naming conventions across files in the focus area
- Multiple ways of doing the same thing with no clear standard
Unclear Organization:
- Files misplaced (e.g., business logic in UI components, or vice versa)
- Unclear module boundaries or responsibilities
- Circular dependencies or tangled imports
- Missing separation of concerns
Implementation Blockers:
- No clear entry point or hook for the requested feature
- Conflicting patterns that make it unclear which approach to follow
- Missing architectural foundation (e.g., no state management for feature that needs it)
- Unclear how focus area integrates with rest of system
Step 5: Output Result
If structural blockers found:
Output detailed blocker report:
Finished priming. Found structural blockers for "[focus_area]":
**Inconsistent Patterns:**
- [Specific inconsistency with file examples]
- [Another inconsistency]
**Unclear Organization:**
- [Specific organizational issue with file examples]
**Implementation Blockers:**
- [Specific blocker that prevents implementation]
**Recommendation:** [Suggest refactoring or clarification needed before proceeding]
If NO structural blockers found:
Output only:
Finished priming focused on "[focus_area]".
DO NOT output detailed reports to CLI unless blockers are found. Context is loaded and ready for use.
Tips
- High-level mode optimizes for minimal context usage - great for initial orientation
- Focused mode goes deep - use when planning work on a specific feature/area
- Focus arguments should be descriptive: "user authentication flow" not just "auth"
- Can run high-level first, then focused on specific areas as needed