prime

What this skill does

# Prime

Perform a comprehensive evaluation of the current codebase/project and produce a structured report covering what the project is, where it stands, and what should happen next. This is the skill to use when encountering any project for the first time, resuming work after a break, or needing a full situational assessment before making decisions.

**This skill is read-only. It NEVER modifies files, commits, or pushes.**

## Proactive Triggers

Suggest this skill when:
1. User starts a new session and asks about the project, e.g. "what is this project" or "tell me about this codebase"
2. User is encountering a repository for the first time or resuming work after a break
3. User asks about project health, code quality, or documentation status
4. Before making architectural decisions that require understanding the current state
5. User says "give me an overview" or "assess this project"

## Input

**Arguments:** `$ARGUMENTS`

Optional arguments:
- A specific focus area (e.g., "testing", "deployment readiness", "documentation")
- A path to a subdirectory to scope the analysis

If no arguments are provided, evaluate the entire project from the repository root.

## Instructions

Execute ALL phases below using per-phase dispatch: Phases 1, 3, and 5 run via `context: fork` + `agent: Explore` (read-only analysis, isolated context). Phase 0 (lab notebook) and Phase 6 (recommendations) run inline in the main conversation — they require full prior-phase output visibility. Phase 2 pre-loads git state via dynamic context injection before Claude sees the prompt.

### Phase 0: Lab Notebook (Mandatory First Read)

**Before any other analysis**, check for `LAB_NOTEBOOK.md` at the repository root (and within the scoped path if `$ARGUMENTS` specifies a subdirectory). If it exists, read it in full *before* proceeding to Phase 1.

The lab notebook typically contains the most current and authoritative context for the project — active decisions, open action items, recent experiment results, and current baselines — and often contradicts or supersedes what the README claims. Reading it first prevents Phase 1-5 from producing conclusions that the lab notebook has already invalidated.

Carry forward for use throughout the remaining phases:
- **Decision Log entries** — inform architecture, risk, and recommendation sections
- **Open Action Items** — feed into open work detection and recommended next steps
- **Recent experiment entries (last 3-5)** — reveal what was tried, what worked, what failed
- **Current Baseline measurements** — use these over README descriptions when they conflict

If no `LAB_NOTEBOOK.md` is present, note "Lab Notebook: Absent" and proceed.

### Phase 1: Project Identity

> **Dispatch:** This phase runs via `context: fork` + `agent: Explore`. Fork an isolated Explore subagent for all file scanning and manifest reading in this phase. Return findings to parent for report assembly.

Determine what this project IS.

1. **Read project manifests** -- Check for `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `pom.xml`, `build.gradle`, `Gemfile`, `*.csproj`, `Makefile`, `docker-compose.yml`, or similar. Extract: project name, version, description, language/runtime, declared dependencies.
2. **Read documentation** -- Check for `README.md`, `CLAUDE.md`, `CONTRIBUTING.md`, `docs/`, `wiki/`. Extract: stated purpose, architecture overview, setup instructions.
3. **Scan entry points** -- Identify main entry points (`main.*`, `index.*`, `app.*`, `__main__.py`, `cli.*`, `server.*`). Trace the top-level execution flow.
4. **Identify project type** -- Classify as: library, CLI tool, web application, API service, plugin/extension, monorepo, data pipeline, mobile app, infrastructure-as-code, or other.

**Output for report:** Project name, type, language(s), purpose (1-3 sentences), key dependencies.

### Phase 2: Repository Health

Assess the project's current state and activity.

1. **Git history analysis** (pre-loaded via dynamic context injection — values available before this phase runs):
   - Recent commits: `!`git log --oneline -20``
   - Last commit date: `!`git log --format='%ai' -1``
   - First commit date: `!`git log --format='%ai' --reverse | head -1``
   - Top contributors: `!`git shortlog -sn --no-merges | head -10``
   - Activity last 30 days: `!`git log --since="30 days ago" --oneline | wc -l``

2. **Branch status** (pre-loaded via dynamic context injection):
   - Active branches: `!`git branch -a --sort=-committerdate | head -10``
   - Working tree state: `!`git status -s``

3. **Open work detection** -- Check for: `TODO`, `FIXME`, `HACK`, `XXX` comments across source files. Check for `IMPLEMENTATION_PLAN.md`, `PROGRESS.md`, `RECOMMENDATIONS.md`, open GitHub issues/PRs if `gh` is available.

4. **Lab notebook** -- Check for `LAB_NOTEBOOK.md`. If present, read it thoroughly and extract:
   - **Decision Log:** Active decisions and their rationale — these reflect architectural and operational choices that shape what happens next
   - **Open Action Items:** Pending follow-ups with priority and source entry — these are the project's known TODO list beyond code comments
   - **Recent experiment entries:** Last 3-5 entries with status — reveals what was recently tried, what worked, what failed
   - **Current Baseline:** System state measurements — more current and specific than README descriptions

   The lab notebook is often the richest source of project context. Incorporate its findings throughout the report, not just in this section.

5. **Dependency freshness** -- Check lock files for staleness. Note any pinned versions that might be outdated. Check for security advisory files or `npm audit`/`pip-audit` results if available.

**Output for report:** Repository age, activity level (active/maintained/stale/abandoned), contributor count, working tree status, open work items, lab notebook summary (if present).

### Phase 3: Code Quality & Architecture

> **Dispatch:** This phase runs via `context: fork` + `agent: Explore`. Fork an isolated Explore subagent for all codebase structure analysis, metric collection, and CI/CD inspection. Return findings to parent for report assembly.

Evaluate the codebase structure and quality.

1. **Project structure** -- Map the directory tree (top 3 levels). Identify the architectural pattern: monolith, microservices, plugin architecture, layered, hexagonal, MVC, etc.

2. **Code metrics:**
   - Total source files (by language)
   - Approximate lines of code (use `wc -l` on source files, exclude node_modules, venv, build artifacts)
   - Largest files (potential god classes/modules)
   - Circular dependency indicators

3. **Test coverage:**
   - Test directory presence and structure
   - Test count (if runnable without setup)
   - Coverage configuration (pytest-cov, jest --coverage, etc.)
   - Test-to-source ratio

4. **CI/CD pipeline:**
   - Check `.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`, `Dockerfile`, etc.
   - What does CI run? (lint, test, build, deploy)
   - Are there quality gates? (coverage thresholds, linting enforcement)

5. **Configuration & secrets:**
   - `.env` files (check .gitignore coverage)
   - Config files and their complexity
   - Secret management approach

6. **Code quality signals:**
   - Linter configuration (eslint, ruff, clippy, golangci-lint)
   - Type checking (TypeScript, mypy, pyright)
   - Pre-commit hooks
   - Code formatting enforcement

**Output for report:** Architecture pattern, code size, test coverage status, CI/CD maturity, quality tooling summary.

### Phase 4: Documentation & Developer Experience

Assess how easy it is to understand and work with this project.

1. **Documentation completeness:**
   - README: Does it explain setup, usage, and contribution?
   - API documentation (if applicable)
   - Architecture Decision Records (ADRs)