Project Context Skill Generator

Purpose

Generate and maintain comprehensive Claude Code skills that preserve project context between chat sessions. This meta-skill teaches Claude HOW to create and maintain other skills.

Goal: Zero context loss. A new session should be able to pick up exactly where the previous one left off.

When to Use This Skill

Explicit Triggers (user requests)

• “create a skill for this project”
• “update the skill” / “update the project skill”
• “save this context”
• “remember this for next session”
• “generate a skill file”

Proactive Triggers (Claude offers automatically)

Offer to create/update a project skill when:

• Session exceeds ~30 minutes of project-specific work
• Significant decisions were made (architecture, tech choices, patterns)
• Complex problems were solved (with solutions worth preserving)
• Technical patterns or gotchas were discovered
• Multi-step implementations were completed
• User asks “what did we do today” or similar wrap-up questions

Proactive prompt: “This session established significant context. Would you like me to create/update the project skill to preserve it?”

Workflow

For the detailed 6-phase generation workflow, refer to Reference/phase-procedures.md.

Quick summary:

1. Analyze → Identify domain and complexity
2. Plan → Determine structure (get user confirmation)
3. Extract → Gather content using zero-context-loss test
4. Build → Create files
5. Verify → Run 25-point checklist
6. Confirm → Present summary to user

Core Principles

1. Single Skill Architecture

• ONE skill per project/domain, not fragments
• All related information stays together
• Progressive disclosure: SKILL.md lean, details in Reference/
• Prevents sync issues between separate skills

2. Snippetizable Content

Every file must be structured so Claude can extract specific answers without loading the entire file:

• Clear headers (H2 major, H3 sub, H4 detail)
• Tables over prose
• Bullet points over paragraphs
• Self-contained sections

3. Zero Context Loss Standard

For each piece of information, ask:

“If a new session started without this, would I lose important context, have to re-explain something, risk re-discovering something the hard way, or make inconsistent decisions?”

If YES to any → Extract it.

4. White-Paper Ready

Technical specifications must be written at handoff quality:

• Include “what it does” + “how it works”
• Use ASCII diagrams for architecture
• Enough detail that someone unfamiliar could maintain it

5. Never Delete, Only Supersede

• Mark old info with [SUPERSEDED: YYYY-MM-DD], don’t delete
• Required sections are required — use “None yet” for empty
• Preserve history for context

Required Skill Structure

Every generated skill MUST have:

.claude/skills/[skill-name]/
├── SKILL.md                    # Entry point (~400 lines max)
├── Reference/
│   ├── skill-maintenance.md    # Update governance (REQUIRED)
│   └── [topic-files].md        # Domain-specific reference files
└── Templates/                  # Optional, if skill tracks entities
    └── [entity]-template.md

SKILL.md Required Sections

Generated SKILL.md files MUST contain these sections in order:

1. YAML Frontmatter

---
name: skill-name-lowercase-hyphens
description: Detailed paragraph describing what the skill covers, when Claude should use it, and specific trigger contexts.
---

2. Mandatory Update Gate

# Mandatory: Read Before ANY Updates

**If you are about to modify ANY file in this skill:**

1. **STOP** — Read `Reference/skill-maintenance.md` in full first
2. **COMPLETE** the Pre-Update Checklist
3. **FOLLOW** the procedure for your update type
4. **COMPLETE** Post-Update Verification
5. **ADD** changelog entry to affected file(s)

**Do not proceed with updates until steps 1-5 are understood.**

3. Quick Reference

At-a-glance summaries using tables and lists:

• Project/domain identity
• Key metrics or status
• Primary entities list
• Capabilities overview

4. Reference File Index

5. Critical Rules

Non-negotiable principles for this domain (numbered, specific, actionable)

6. Changelog

skill-maintenance.md Required Sections

Every generated skill-maintenance.md MUST contain these 11 sections:

1. Update Trigger Protocol — 6-step process before modifications
2. Pre-Update Checklist — 4-step table (identify, search, classify, proceed)
3. Update Classifications — NEW, UPDATE, DUPLICATE, CORRECTION
4. Update Categories & Procedures — 5-10 domain-specific procedures
5. Template Usage — How to use templates for new entities
6. Post-Update Verification — Confirmation format with specific quotes
7. Formatting Standards (Rigid) — Date formats, headers, status flags
8. Content Standards (Flexible) — Writing style, good vs bad examples
9. Cross-File Synchronization — 5-8 sync rules
10. Emergency Procedures — Corruption recovery, conflict resolution
11. Version History — Changelog table

Templates: Templates/maintenance-template.md

Update Classifications

Use these for ALL skill updates:

Standard Marker Flags

Use consistently across all generated skills:

[ACTIVE]                    - Currently in use/progress
[COMPLETED]                 - Finished
[CLOSED]                    - Fully concluded
[PROSPECT]                  - In discussions, not confirmed
[PAUSED]                    - On hold
[CANCELLED]                 - Planned but no longer happening

[BUILT]                     - Implemented and deployed
[PENDING]                   - Scoped but not built
[PLANNED]                   - Discussed but not scoped

[SUPERSEDED: YYYY-MM-DD]    - Replaced by newer info below
[CORRECTED: YYYY-MM-DD]     - Was incorrect, now fixed
[UNCONFIRMED]               - Not yet verified
[ASSUMPTION]                - Based on inference
[RECONSTRUCTED: YYYY-MM-DD] - Rebuilt from history
[NEEDS CLARIFICATION]       - Identified gap requiring input

Verification Checklist Summary

Before delivering any generated skill, verify:

Structure:

• Single skill architecture (not fragmented)
• SKILL.md exists with mandatory update gate
• SKILL.md under 400 lines
• Reference/skill-maintenance.md exists
• skill-maintenance.md has all 11 required sections

Content:

• 5-10 domain-specific update procedures
• 5-8 cross-file sync rules
• All files have changelog at bottom
• No duplicate content across files
• Uncertain info marked with appropriate flags
• Technical specs are white-paper ready

Principles:

• Progressive disclosure (SKILL.md lean, details in Reference/)
• Snippetizable (headers, tables, bullets)
• Zero context loss (all valuable info captured)

Full 25-point checklist: Reference/phase-procedures.md § Verification

Reference File Index

Critical Rules

1. Read before write — Always read existing skill files before modifying
2. One skill per project — Never fragment into multiple skills
3. Required sections are required — Use “None yet”, never delete
4. Verify before delivering — Run checklist, fix all failures first
5. Lead with facts — No narrative, no filler phrases
6. Cross-reference everything — Entity files ↔ technical specs
7. Dates in YYYY-MM-DD — Never MM/DD/YYYY in skill files
8. Mark uncertainty — Use [UNCONFIRMED], [ASSUMPTION] flags

Changelog