Prime

How It Fits

First time:   /prime → /pickup → [work] → /park
Returning:    /pickup → [work] → /park
Stale repo:   /prime --refresh → /pickup → [work] → /park

/prime creates the permanent knowledge layer (expert skills). /pickup loads session-specific context. Different layers of the same system.

Phase 1: Foundation

Establish the current state of the repo and any existing skills.

1a. CLAUDE.md Check

CLAUDE.md exists?
├── No → Run /init to generate it. Read the result as baseline.
├── Yes → Check staleness:
│   ├── Count commits since CLAUDE.md last modified
│   ├── If >10 commits behind → recommend update:
│   │   "CLAUDE.md is N commits stale. Quick refresh before proceeding?"
│   │   If user agrees → re-run /init to update, read result
│   │   If user declines → read existing CLAUDE.md as-is
│   └── If fresh → read as baseline

1b. Existing Skills Check

Scan .claude/skills/ for */SKILL.md files
├── No skills found → fresh setup, proceed to Phase 2
├── Skills found → report what exists:
│   "Found N existing expert skills: {list with descriptions}"
│   For each skill, check staleness:
│     git log --oneline --since="skill-mtime" -- <relevant-paths> | wc -l
│     "{skill-name} covers {paths} — {N} commits since last update"
│   Ask: "Create fresh skills or update existing ones?"

1c. Stack Detection

Identify the technology stack from project files:

Note hybrid stacks (e.g., .NET backend + React frontend).

Phase 2: Deep Analysis

Launch parallel background agents to analyze each architectural layer. Use the Task tool with subagent_type=Explore and run_in_background=true.

Agent assignment based on detected stack. Examples:

Each agent should analyze:

• Key patterns and conventions (with file paths)
• How things are wired together (DI, routing, middleware)
• Non-obvious architectural decisions
• Common gotchas a developer would hit
• Domain vocabulary

Launch 2-4 agents — enough for coverage, not so many they're redundant. While agents run, read key files yourself to build understanding. Synthesize agent results when they complete.

Phase 3: Skill Boundary Proposal (Approval Gate)

Based on analysis, propose expert roles to the user. Present:

Based on the analysis, I recommend N expert skills:

1. {repo}-expert — {what it covers: architecture, domain vocab, key patterns}
2. {repo}-{layer}-expert — {what it covers: specific layer patterns}
3. {repo}-auth-expert — {if auth is complex enough to warrant its own skill}

And 2 context files:
- {repo}-feature-context — loads all experts for feature development
- {repo}-debug-context — loads relevant experts + debugging decision tree

Does this look right, or should I adjust the boundaries?

Guidelines for proposing skills:

• 1 skill = 1 mental model. Each skill should represent a distinct area of expertise that a developer would think of as a unit.
• Minimum 2, maximum 5 expert skills. 1 is too broad, 6+ is fragmented.
• Always propose feature + debug contexts. These are the primary entry points.
• Name pattern: {repo}-expert for main, {repo}-{layer}-expert for specialized.
• Don't create a skill for something Claude already knows well (e.g., generic React patterns). Only for project-specific knowledge.

Wait for user approval before proceeding.

Phase 4: Creation

Write the skill files following progressive disclosure:

SKILL.md Structure (for each expert skill)

---