Context Layer Optimization for Claude Projects

Calibration: Tier 2, Opus-primary. See repository README for model compatibility.

Rebalances context across Memory, Custom Instructions, knowledge files, and User Preferences in Claude Projects. Produces Memory edit prescriptions, knowledge file trimming recommendations, codification prescriptions for promoting stable patterns to explicit instructions, and cross-layer alignment findings.

Critical Rule: User Confirmation Before Memory Edits

Never execute Memory edits without presenting the full prescription and receiving explicit user confirmation. Memory is persistent and personal — this skill recommends, the user decides.

Confirmation protocol (every engagement):

1. Present the complete optimization prescription: Memory edits (organized Remove → Add → Replace), codification prescriptions (if any), knowledge file trimming recommendations, and context budget impact summary
2. State clearly: "These are my recommendations. I'll make the Memory changes only after you confirm."
3. Wait for explicit user approval before calling memory_user_edits
4. Execute edits in the correct sequence: removals first (highest line numbers first to avoid index shifts), then additions, then replacements
5. Present the final Memory state (via memory_user_edits view) as verification after execution

If the user says "just do it" or "go ahead with everything" — that IS confirmation. Execute. The gate ensures the user has seen the prescription, not to add friction.

If the user wants partial execution — execute only the approved edits. Note which recommendations remain unexecuted.

Critical Rule: Complete File Output

When producing any updated file — Custom Instructions, knowledge files, or any other deliverable — always output the complete file as a single, separately copyable unit. Never output diffs, patches, or partial sections that require manual splicing. The user replaces the old file by copying the complete output.

Reasoning discipline

Before prescribing a Memory optimization, walk through the evidence explicitly. State the observations (specific Memory entries, content types, redundancies, staleness markers), name the placement pattern or principle they match (Memory vs. Custom Instructions vs. knowledge file vs. User Preferences), then apply the rebalancing prescription. Do not compress this sequence into a summary recommendation.

If the optimization scope is unclear (Memory-only? full context-layer rebalance? Codification-focused?), confirm scope with the user before proceeding. Do not proceed on inferred assumptions.

Core Thesis

Optimal Project performance requires the right fact in the right layer:

Misalignment in any direction — orientation buried in a knowledge file, reference material crammed into Memory, behavioral rules in a knowledge file, universal preferences locked inside a single Project's CI — degrades performance. Memory optimization is not a standalone operation; it cascades. When Memory is optimized, knowledge files can be trimmed. When knowledge files are trimmed, context budget is freed. When context budget is freed, Claude has more room for the actual conversation.

When to Use This Skill

Use when:

• User wants to optimize their Memory or review what's in it
• User wants to trim knowledge files or reduce context usage
• User asks whether content belongs in Memory, a knowledge file, or User Preferences
• User asks what should be in Preferences vs. Memory
• User reports context window pressure, truncation, or Claude forgetting instructions in long conversations
• User describes their project as "bloated" in the context of files, memory, or context (not behavior or output)
• A project audit found Knowledge Architecture scoring ≤ 3 and the user has Memory enabled

Do NOT use when:

• User wants a full project architecture audit → recommend rootnode-project-audit if available
• User wants a global account-wide audit → recommend rootnode-global-audit if available
• User wants to evaluate a single prompt → recommend rootnode-prompt-validation if available
• User wants to build a new project from scratch → recommend rootnode-prompt-compilation if available
• User wants to edit a single Memory entry without broader optimization context → assist directly, no skill needed

Stage 1: Project Comprehension

Understand the project holistically before touching any layer. This prevents rote optimization — the skill must know what the project is trying to accomplish before it can judge what every conversation needs.

Assess:

• Mission: What does this project do? What outcome does it serve?
• Phase: Active development, burn-in, mature maintenance, or expansion? The phase determines what Memory needs to emphasize.
• Task profile: What types of conversations happen here? Uniform tasks need less orientation; varied tasks need Memory to anchor the common thread.
• Active constraints: What decisions, limitations, or boundaries affect every conversation? (File count limits, deferred features, architectural principles, deployment targets.) These are prime Memory candidates.
• Volatility: How often does this project's state change? High-volatility facts (current phase, active sprint goals) belong in Memory. Low-volatility facts (design principles, permanent decisions) can live in knowledge files.

Information sources:

• Auto-populated userMemories (visible in system context): identity, projects, current state, preferences
• Manual Memory edits (via memory_user_edits view): user-curated facts
• Custom Instructions (user provides or describes): behavioral architecture
• Knowledge files (user provides key files or describes): reference depth
• User Preferences (if the user provides them or describes their current Preferences content)
• If the user is running this in the project being optimized, all of the above is directly accessible

Do not interrogate. Assess what's available, request only the highest-leverage missing piece, and state what you're assuming about the rest. If the user is in the project being optimized, start immediately with what's accessible.

Stage 2: Context Layer Audit

Map what's in each layer. Identify redundancies, gaps, and misalignments.

2a: Memory Assessment

Evaluate current Memory edits against six criteria. See references/assessment-rubric.md for expanded anchoring examples, common failure patterns, the layer placement decision tree, and the Codification Assessment guide.