Project Context Loader

Every fresh conversation about an ongoing project starts with the same five-to-ten-minute re-explanation. The repo's structure, the technical constraints, the decisions already locked in, the stakeholders and what they care about, the next milestone. Multiply that across three projects and four sessions a day and the time loss is substantial. A one-page context file eliminates it.

The skill ingests whatever the user has — a 20-page brief, a Notion doc, a rambling Slack thread, a verbal description — and extracts six layers. Project Identity (name, one-line description, your role, current phase). Objectives and Success Criteria (force-ranked, with what's explicitly out of scope). Constraints and Boundaries (timeline, budget, tech, brand, compliance). Key Decisions Made (so Claude doesn't suggest things you've already rejected). Stakeholder Map. Working Files and References. Then it compresses — a 20-page brief becomes a 1-page context file; anything longer than two pages means you haven't distilled enough.

Lightweight mode exists for the common case where the full structure is overkill. A side project, a weekend build, a solo experiment — those don't need a stakeholder map or a working files layer. The skill trims to fit. Ten lines for a weekend project is fine. Forcing the full template would mean nobody uses the file, which is worse than no file at all.

The Decisions Log inside the context file is the highest-value section. Decisions already locked in prevent Claude from re-litigating settled questions or suggesting approaches you've already rejected. Open questions are equally important — unresolved items prevent Claude from making assumptions you didn't authorise. The most common context-file failure mode is documenting what's decided and not documenting what's still uncertain; the skill insists on both.

Updates are first-class. Phase transitions — discovery to build, build to launch — are automatic update triggers because everything changes at those moments. Routine updates accept quick brain-dumps ("update context: moved to dev phase, deadline is now July 15") without requiring a full re-interview. When a project completes, the file gets archived with a final status note and a two-or-three-sentence lessons-learned section. The archive matters — the next similar project starts faster because the lessons from this one are written down.

One file per project, never combined. Cross-project context creates confusion and is the single most common reason context files stop being trusted. Save to the project directory or a central contexts/ folder, load at session start, and the conversation begins with Claude already knowing what it took the last person an hour to explain.