
shrink-doc
by cowwoc
AI Agents that land on their feet
SKILL.md
name: shrink-doc description: Compress documentation while preserving execution equivalence (validation-driven approach)
Validation-Driven Document Compression
Task: Compress the documentation file: {{arg}}
Goal: Reduce document size while preserving execution equivalence using objective validation instead of prescriptive rules.
Workflow
Step 1: Validate Document Type
BEFORE compression, verify this is a Claude-facing document:
ALLOWED (Claude-facing):
.claude/configuration files:.claude/agents/- Agent definitions (prompts for sub-agents).claude/commands/- Slash commands (prompts that expand when invoked).claude/hooks/- Hook scripts (execute on events).claude/settings.json- Claude Code settings
CLAUDE.mdand project instructionsdocs/project/development protocol documentationdocs/code-style/*-claude.mdstyle detection patterns
Why slash commands are Claude-facing: When you invoke /shrink-doc, the
contents of .claude/commands/shrink-doc.md expand into a prompt for Claude
to execute. The file is NOT for users to read - it's a configuration that
defines what Claude does when the command is invoked.
FORBIDDEN (Human-facing):
README.md,changelog.md,CHANGELOG.mddocs/studies/,docs/decisions/,docs/performance/docs/optional-modules/(potentially user-facing)todo.md,docs/code-style/*-human.md
⚠️ SPECIAL HANDLING: CLAUDE.md
When compressing CLAUDE.md, use content reorganization instead of standard compression:
Step 1: Analyze Content Location Before compressing, categorize ALL content into:
| Category | Action |
|---|---|
| Duplicates skills | REMOVE - reference skill instead |
| Main-agent-specific | MOVE to main-agent-specific file |
| Sub-agent-specific | MOVE to sub-agent-specific file |
| Universal (all agents) | KEEP in CLAUDE.md |
Step 2: Check for Duplication
# Check if content already exists in skills
ls .claude/skills/
# Check if procedural content duplicates a skill
grep -l "pattern" .claude/skills/*/SKILL.md
Step 3: Content Categories
Examples are illustrative; specific categories vary by project.
REMOVE (duplicates existing):
- Procedural content that exists in skills
- Content already documented in agent-specific files
MOVE (agent-specific):
- Main-agent-only content (e.g., multi-agent coordination, repository structure)
- Sub-agent-only content (e.g., specific workflow steps only they perform)
KEEP (universal guidance):
- Tone/style, error handling, security policies
- Content that applies equally to ALL agent types
Step 4: Result Structure
CLAUDE.md should be a slim reference document (~200 lines) that:
- Contains ONLY universal guidance for ALL agents
- Instructs agents to read their agent-specific files (e.g., "MAIN AGENT: Read {file}.md")
- References skills for procedural content (not duplicate them)
Hub-and-Spoke Pattern:
CLAUDE.md (universal, ~200 lines)
├── "MAIN AGENT: Read {main-agent-file}.md"
└── "SUB-AGENTS: Read {sub-agent-file}.md"
Agent-specific files contain the detailed content moved out of CLAUDE.md. Create these files if they don't exist. CLAUDE.md becomes a routing document that directs agents to their specialized guidance.
Why This Approach: Standard compression preserves all content in place. CLAUDE.md benefits from reorganization because much content is duplicated elsewhere or is agent-specific. Moving content to appropriate locations reduces redundancy across the entire documentation system.
Validation: After reorganization, verify:
# CLAUDE.md should be ~200-250 lines (not 800+)
wc -l CLAUDE.md
# No procedural duplication with skills
grep -c "Step 1:" CLAUDE.md # Should be minimal
⚠️ SPECIAL HANDLING: Style Documentation Files
When compressing .claude/rules/*.md or docs/code-style/*-claude.md:
Preserve style rule sections (lines starting with ### ). These are intentionally-added
detection patterns and rules. Compression can:
- ✅ Condense explanatory text within sections
- ✅ Shorten verbose rationale paragraphs
- ✅ Combine redundant examples
- ❌ Deleting entire
### Section Nameblocks breaks detection - ❌ Removing detection patterns or code examples breaks detection
Verification Required: After compression, count section headers:
ORIGINAL_SECTIONS=$(grep -c "^### " /tmp/original-{filename})
COMPRESSED_SECTIONS=$(grep -c "^### " /tmp/compressed-{filename}-v${VERSION}.md)
if [ "$COMPRESSED_SECTIONS" -lt "$ORIGINAL_SECTIONS" ]; then
echo "❌ ERROR: Section(s) removed! Original: $ORIGINAL_SECTIONS, Compressed: $COMPRESSED_SECTIONS"
echo " Style rule sections must be preserved. Iterate to restore missing sections."
fi
Why This Protection Exists: Session from 2025-12-19 had documentation update remove intentionally-added "Use 'empty' Not 'blank'" style rule section, causing repeated data loss during subsequent rebases.
If forbidden, respond:
This compression process only applies to Claude-facing documentation.
The file `{{arg}}` appears to be human-facing documentation.
Examples:
- ✅ ALLOWED:
.claude/commands/shrink-doc.md(slash command prompt) - ✅ ALLOWED:
.claude/agents/architect.md(agent prompt) - ❌ FORBIDDEN:
README.md(user-facing project description) - ❌ FORBIDDEN:
changelog.md(user-facing change history)
Step 2: Check for Existing Baseline
Check if baseline exists from prior iteration:
BASELINE="/tmp/original-{{filename}}"
if [ -f "$BASELINE" ]; then
BASELINE_LINES=$(wc -l < "$BASELINE")
CURRENT_LINES=$(wc -l < "{{arg}}")
echo "✅ Found existing baseline: $BASELINE ($BASELINE_LINES lines)"
echo " Current file: $CURRENT_LINES lines"
echo " Scores will compare against original baseline."
fi
If NO baseline exists, optionally check git history for prior compression:
if [ ! -f "$BASELINE" ]; then
RECENT_SHRINK=$(git log --oneline -5 -- {{arg}} 2>/dev/null | grep -iE "compress|shrink|reduction" | head -1)
if [ -n "$RECENT_SHRINK" ]; then
echo "ℹ️ Note: File was previously compressed (commit: $RECENT_SHRINK)"
echo " No baseline preserved. Starting fresh with current version as baseline."
fi
fi
Step 3: Invoke Compression Agent
Use Task tool with subagent_type: "general-purpose" and simple outcome-based prompt:
Agent Prompt Template:
**Document Compression Task**
**File**: {{arg}}
**Goal**: Compress while preserving **perfect execution equivalence** (score = 1.0).
**Compression Target**: ~50% reduction is ideal, but lesser compression is acceptable. Perfect equivalence (1.0) is mandatory; compression amount is secondary.
---
## What is Execution Equivalence?
**Execution Equivalence** means: A reader following the compressed version will achieve the same results as someone following the original.
**Preserve**:
- **YAML frontmatter** (between `---` delimiters) - REQUIRED for slash commands
- **Decision-affecting information**: Claims, requirements, constraints that affect what to do
- **Relationship structure**: Temporal ordering (A before B), conditionals (IF-THEN), prerequisites, exclusions (A ⊥ B), escalations
- **Control flow**: Explicit sequences, blocking checkpoints (STOP, WAIT), branching logic
- **Executable details**: Commands, file paths, thresholds, specific values
**Safe to remove**:
- **Redundancy**: Repeated explanations of same concept
- **Verbose explanations**: Long-winded descriptions that can be condensed
- **Meta-commentary**: Explanatory comments about the document (NOT structural metadata like YAML frontmatter)
- **Non-essential examples**: Examples that don't add new information
- **Elaboration**: Extended justifications or background that don't affect decisions
---
## Compression Approach
**Focus on relationships**:
- Keep explicit relationship statements (Prerequisites, Dependencies, Exclusions, Escalations)
- Preserve temporal ordering (Step A→B)
- Maintain conditional logic (IF-THEN-ELSE)
- Keep constraint declarations (CANNOT coexist, MUST occur after)
**Condense explanations**:
- Remove "Why This Ordering Matters" verbose sections → keep ordering statement
- Remove "Definition" sections that explain obvious terms
- Combine related claims into single statements where possible
- Use high-level principle statements instead of exhaustive enumeration (when appropriate)
---
## Output
Read `{{arg}}`, compress it, and **USE THE WRITE TOOL** to save the compressed version.
**⚠️ CRITICAL**: You MUST actually write the file using the Write tool. Do NOT just describe
or summarize the compressed content - physically create the file.
**Target**: ~50% word reduction while maintaining execution equivalence.
Execute compression:
# Invoke agent
Task tool: general-purpose agent with above prompt
Step 4: Validate with /compare-docs
⚠️ CRITICAL: Before saving compressed version, read and save the ORIGINAL document state to use as baseline for validation.
After agent completes:
-
Save original document (ONLY if baseline doesn't exist):
BASELINE="/tmp/original-{{filename}}" if [ ! -f "$BASELINE" ]; then cp {{arg}} "$BASELINE" echo "✅ Saved baseline: $BASELINE ($(wc -l < "$BASELINE") lines)" else echo "✅ Reusing existing baseline: $BASELINE" fiWhy baseline is preserved: Baseline is kept until user explicitly confirms they're done iterating (see Step 5). This ensures scores always compare against the TRUE original, not intermediate compressed versions.
-
Determine version number and save compressed version:
VERSION_FILE="/tmp/shrink-doc-{{filename}}-version.txt" # Get next version number from persistent counter (survives across sessions) if [ -f "$VERSION_FILE" ]; then LAST_VERSION=$(cat "$VERSION_FILE") VERSION=$((LAST_VERSION + 1)) else # First time: check for existing version files to continue numbering HIGHEST=$(ls /tmp/compressed-{{filename}}-v*.md 2>/dev/null | sed 's/.*-v\([0-9]*\)\.md/\1/' | sort -n | tail -1) if [ -n "$HIGHEST" ]; then VERSION=$((HIGHEST + 1)) else VERSION=1 fi fi # Save version counter for next iteration echo "$VERSION" > "$VERSION_FILE" # Save with version number for rollback capability # Agent output → /tmp/compressed-{{filename}}-v${VERSION}.md echo "📝 Saved as version ${VERSION}: /tmp/compressed-{{filename}}-v${VERSION}.md"Why persistent versioning: Version numbers continue across sessions (v1, v2 in session 1 → v3, v4 in session 2) so older revisions are never overwritten. This enables rollback to any previous version and maintains complete compression history.
-
Verify YAML frontmatter preserved (if compressing slash command):
head -5 /tmp/compressed-{{filename}}-v${VERSION}.md | grep -q "^---$" || echo "⚠️ WARNING: YAML frontmatter missing!" -
Run validation AGAINST ORIGINAL:
# ALWAYS compare against original baseline, NOT current file state /compare-docs /tmp/original-{{filename}} /tmp/compressed-{{filename}}-v${VERSION}.md⚠️ IMPORTANT: The validation score reflects execution equivalence between:
- Document A: Original document state BEFORE /shrink-doc was invoked in this session
- Document B: Newly compressed candidate version
NOT a comparison against any intermediate compressed versions.
-
Parse validation result:
- Extract execution_equivalence_score
- Extract warnings and lost_relationships
- Extract structural_changes
Scoring Context: When reporting the score to the user, explicitly state:
Score {score}/1.0 compares the compressed version against the ORIGINAL document
state from before /shrink-doc was invoked (not against any intermediate versions).
⚠️ CRITICAL REMINDER: On second, third, etc. invocations:
- ✅ REUSE
/tmp/original-{{filename}}from first invocation - ✅ Always compare against original baseline (not intermediate versions)
- The baseline is set ONCE on first invocation and REUSED for all subsequent invocations
Step 5: Decision Logic
Threshold: 1.0
Report Format (for approval):
- What was preserved
- What was removed
- Validation Details (claim/relationship/graph scores)
- Results (original size, compressed size, reduction %, execution equivalence score)
- Version Comparison Table (showing all versions generated in this session)
⚠️ CRITICAL: List execution equivalence score at bottom for easy visibility.
Version Comparison Table Format:
After presenting validation results for ANY version, show comparison table.
Note: Use /cat:render-box skill for table rendering - emojis (✅/❌/✓) require
emoji-aware width calculation for proper column alignment.
╭──────────────┬───────┬──────┬───────────┬───────┬──────────────╮
│ Version │ Lines │ Size │ Reduction │ Score │ Status │
├──────────────┼───────┼──────┼───────────┼───────┼──────────────┤
│ **Original** │ {n} │ {n}K │ baseline │ N/A │ Reference │
│ **V1** │ {n} │ {n}K │ {n}% │ {n} │ {✅/❌/✓} │
│ **V2** │ {n} │ {n}K │ {n}% │ {n} │ {✅/❌/✓} │
╰──────────────┴───────┴──────┴───────────┴───────┴──────────────╯
Status Legend:
- ✅ = Approved (score = 1.0)
- ❌ = Rejected (score < 1.0)
- ✓ applied = Currently applied to original file
Example:
╭──────────────┬───────┬──────┬───────────┬───────┬──────────────╮
│ Version │ Lines │ Size │ Reduction │ Score │ Status │
├──────────────┼───────┼──────┼───────────┼───────┼──────────────┤
│ **Original** │ 1,057 │ 48K │ baseline │ N/A │ Reference │
│ **V1** │ 520 │ 26K │ 51% │ 0.89 │ ❌ rejected │
│ **V2** │ 437 │ 27K │ 59% │ 0.97 │ ✓ applied │
╰──────────────┴───────┴──────┴───────────┴───────┴──────────────╯
If score = 1.0: ✅ APPROVE
Validation passed! Execution equivalence: {score}/1.0
✅ Approved version: /tmp/compressed-{{filename}}-v${VERSION}.md
Writing compressed version to {{arg}}...
→ Overwrite original with approved version
→ Clean up versioned compressions: rm /tmp/compressed-{{filename}}-v*.md
→ KEEP baseline: /tmp/original-{{filename}} preserved for potential future iterations
After applying changes, ASK user:
Changes applied successfully!
Would you like to try again to generate an even better version?
- YES → I'll keep the baseline and iterate with new compression targets
- NO → I'll clean up the baseline (compression complete)
If user says YES (wants to try again):
→ Keep /tmp/original-{{filename}}
→ Future /shrink-doc invocations will reuse this baseline
→ Scores will reflect cumulative compression from true original
→ Go back to Step 3 with user's feedback
If user says NO (done iterating):
→ rm /tmp/original-{{filename}}
→ rm /tmp/shrink-doc-{{filename}}-version.txt
→ Note: Future /shrink-doc on this file will use compressed version as new baseline
If score < 1.0: ❌ ITERATE
Validation requires improvement. Score: {score}/1.0 (threshold: 1.0)
Components:
- Claim preservation: {claim_score}
- Relationship preservation: {relationship_score}
- Graph structure: {graph_score}
**Why < 1.0 requires iteration**:
Scores below 1.0 indicate relationship abstraction or loss that creates
interpretation vulnerabilities. See /compare-docs § Score Interpretation
for detailed vulnerability analysis.
**Common issues at this score range**:
- Abstraction ambiguity (e.g., "ALL of X" → separate statements)
- Lost mutual exclusivity constraints
- Conditional logic flattening (IF-THEN-ELSE → flat list)
- Temporal dependencies implicit rather than explicit
Issues found:
{list warnings from /compare-docs}
Specific relationship losses:
{list lost_relationships with details}
Re-invoking agent with feedback to fix issues...
→ Go to Step 6 (Iteration)
⚠️ CRITICAL: Verify Decision Logic Before Presenting
Before presenting results to user, MANDATORY self-check:
# Self-validation checklist
if [ score == 1.0 ]; then
decision="APPROVE"
elif [ score < 1.0 ]; then
decision="ITERATE"
fi
# Verify no contradictions
if [ stated_decision != expected_decision ]; then
ERROR: "Decision logic error detected"
FIX: "Recalculate thresholds"
fi
Common Mistakes: ❌ WRONG: "Score 0.97, close enough to 1.0" (0.97 < 1.0, must be perfect) ✅ CORRECT: "Score 0.97 < 1.0, iterate to achieve perfect equivalence"
❌ WRONG: "Score 0.99, good enough" (ignores 1.0 threshold) ✅ CORRECT: "Score 0.99 < 1.0, iterate to eliminate any loss"
Prevention: Always verify threshold comparison matches stated score value before presenting.
Step 6: Iteration Loop
If score < 1.0, invoke agent again with specific feedback:
Iteration Prompt Template:
**Document Compression - Revision Attempt {iteration_number}**
**Previous Score**: {score}/1.0 (threshold: 1.0)
**Issues Identified by Validation**:
{warnings from /compare-docs}
**Lost Relationships**:
{for each lost_relationship:}
- **{type}**: {from_claim} → {to_claim}
- Constraint: {constraint}
- Evidence: {evidence}
- Impact: {violation_consequence}
- **Fix**: {specific recommendation}
**Your Task**:
Revise the compressed document to restore the lost relationships while maintaining compression.
**Original**: /tmp/original-{{filename}}
**Previous Attempt**: /tmp/compressed-{{filename}}-v${VERSION}.md
Focus on:
1. Restoring explicit relationship statements identified above
2. Maintaining conditional structure (IF-THEN-ELSE)
3. Preserving mutual exclusivity constraints
4. Keeping escalation/fallback paths
**⚠️ CRITICAL**: USE THE WRITE TOOL to save the revised document to the specified path.
Do NOT just describe or return the content - you MUST physically write the file.
After iteration:
- Save revised version as next version number (v${VERSION+1})
- Re-run /compare-docs validation AGAINST ORIGINAL BASELINE
- Apply decision logic again (Step 5)
🚨 MANDATORY: /compare-docs Required for EVERY Iteration
CRITICAL: You MUST invoke /compare-docs (SlashCommand tool) for EVERY version validation.
There are NO exceptions. Manual validation, estimation, or checklist-based scoring is PROHIBITED.
Why This Is Non-Negotiable:
- Session 7937e222: Agent manually validated v2/v3 with self-created checklist → score 0.97
- Independent re-analysis: Actual score was 0.72 (25% inflation)
- Result: Compression approved that lost critical content
Validation Anti-Patterns (ALL are violations):
❌ WRONG #1: Manual checklist validation
"Let me assess v2 improvements..."
| Category | Original | v2 | Preserved |
| State machine | ✅ | ✅ | 100% |
[creates own checklist, assigns 100% to all]
"Estimated Score: 0.97"
Why wrong: Agent knows what SHOULD be there, confirms it exists (confirmation bias)
❌ WRONG #2: Estimation without /compare-docs
"Good progress on v2. Estimated Score: ~0.88"
Why wrong: No independent extraction, just subjective assessment
❌ WRONG #3: Custom Task prompt with items to verify
Task: "Verify these 6 improvements are present: 1. X, 2. Y..."
Why wrong: Primes validator to confirm checklist, misses other losses
✅ CORRECT: Invoke /compare-docs for EVERY version
# v1 validation
/compare-docs /tmp/original-{filename} /tmp/compressed-{filename}-v1.md
# v2 validation (after iteration)
/compare-docs /tmp/original-{filename} /tmp/compressed-{filename}-v2.md
# v3 validation (after iteration)
/compare-docs /tmp/original-{filename} /tmp/compressed-{filename}-v3.md
Enforcement: Score is ONLY valid if it comes from /compare-docs output. Any score derived from manual assessment, estimation, or targeted validation is INVALID.
Self-Check Before Reporting Score:
- Did I invoke /compare-docs (SlashCommand tool) for this version? YES/NO
- Is the score from /compare-docs output, not my own calculation? YES/NO
- If either is NO → STOP and invoke /compare-docs
Maximum iterations: 3
- If still < 1.0 after 3 attempts, report to user and ask for guidance
- All versions preserved in /tmp for rollback
- User may choose to accept best attempt or abandon compression
Implementation Notes
Agent Type: MUST use subagent_type: "general-purpose"
Validation Tool: Use /compare-docs (SlashCommand tool)
Validation Baseline: On first invocation, save original document to
/tmp/original-{filename} and use this as baseline for ALL subsequent
validation comparisons in the session.
Versioning Scheme: Each compression attempt is saved with incrementing version numbers for rollback capability.
File Operations:
- Read original:
Readtool - Save original baseline:
Writetool to/tmp/original-{filename}(once per session) - Save versioned compressed:
Writetool to/tmp/compressed-{filename}-v1.md,/tmp/compressed-{filename}-v2.md, etc. - Overwrite original:
Writetool to{{arg}}(only after approval) - Cleanup after approval:
rm /tmp/compressed-{filename}-v*.md /tmp/original-{filename}
Rollback Capability:
- If latest version unsatisfactory, previous versions available at
/tmp/compressed-{filename}-v{N}.md - Example: If v3 approved but later found problematic, can review v1 or v2
- Versions automatically cleaned up after successful approval
Iteration State:
- Track iteration count via version numbers
- Provide specific feedback from validation warnings
- ALWAYS validate against original baseline, not previous iteration
Success Criteria
✅ Compression approved when:
- Execution equivalence score = 1.0
✅ Compression quality metrics:
- Word reduction: ~50% (target)
- Execution equivalence: = 1.0
- Claim preservation: = 1.0
- Relationship preservation: = 1.0
- Graph structure: = 1.0
- No critical relationship losses
Edge Cases
Abstraction vs Enumeration: When compressed document uses high-level constraint statements (e.g., "handlers are mutually exclusive") instead of explicit pairwise enumerations, validation may score 0.85-0.94. System will automatically iterate to restore explicit relationships, as abstraction creates interpretation vulnerabilities (see /compare-docs § Score Interpretation).
Score Plateau: If multiple iterations needed but score plateaus (no improvement after 2 attempts, e.g., v1=0.87, v2=0.88, v3=0.89), compression may be hitting fundamental limits. After 3 attempts below 1.0, report best version to user and explain compression challenges encountered.
Multiple Iterations: Each iteration should show improvement. Monitor progression toward 1.0 threshold.
Large Documents: For documents >10KB, consider breaking into logical sections and compressing separately to improve iteration efficiency.
Example Usage
/shrink-doc /workspace/main/.claude/commands/example-command.md
Expected flow:
- Validate document type ✅
- Save original to /tmp/original-example-command.md (baseline) ✅
- Invoke compression agent
- Save to /tmp/compressed-example-command-v1.md (version 1) ✅
- Run /compare-docs /tmp/original-example-command.md /tmp/compressed-example-command-v1.md
- Score 1.0 → Approve v1 and overwrite original ✅
- Cleanup: Remove /tmp/compressed-example-command-v*.md and /tmp/original-example-command.md ✅
If iteration needed:
- v1 score < 1.0 → Save v2, validate against original
- v2 score < 1.0 → Save v3, validate against original
- v3 score = 1.0 → Approve v3, cleanup v1/v1/v3 and original
- v3 score < 1.0 (after max iterations) → Report to user with best version
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
1ヶ月以内に更新
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon

