Source profileQuality 88/100

davekilleen/Dex/.claude/plugins/compound-engineering/skills/compound-docs/SKILL.md

compound-docs

Capture solved problems as categorized documentation with YAML frontmatter for fast lookup

Source repository stars
456
Declared platforms
0
Static risk flags
1
Last source update
2026-08-04
Source checked
2026-08-04

Decision brief

What it does—and where it fits

Purpose: Automatically document solved problems to build searchable institutional knowledge with category-based organization (enum-validated problem types).

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/davekilleen/Dex --skill ".claude/plugins/compound-engineering/skills/compound-docs"
    Safe inspection promptEditorial

    Inspect the Agent Skill "compound-docs" from https://github.com/davekilleen/Dex/blob/2aa1a433a3c8879dfe320902a976197dda3a2484/.claude/plugins/compound-engineering/skills/compound-docs/SKILL.md at commit 2aa1a433a3c8879dfe320902a976197dda3a2484. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      7-Step Process

      Auto-invoke after phrases:

      "that worked""it's fixed""working now"
    2. 02

      Step 1: Detect Confirmation

      Auto-invoke after phrases:

      "that worked""it's fixed""working now"
    3. 03

      Step 2: Gather Context

      Extract from conversation history:

      Module name: Which module or component had the problemSymptom: Observable error/behavior (exact error messages)Investigation attempts: What didn't work and why
    4. 04

      Step 3: Check Existing Docs

      Search docs/solutions/ for similar issues:

      Search docs/solutions/ for similar issues:
    5. 05

      Step 4: Generate Filename

      Format: [sanitized-symptom]-[module]-[YYYYMMDD].md

      LowercaseReplace spaces with hyphensRemove special characters except hyphens

    Permission review

    Static risk signals and limitations

    Writes files

    medium · line 166

    The documentation asks the agent to create, modify, or delete local files.

    *Create documentation file:**

    Writes files

    medium · line 174

    The documentation asks the agent to create, modify, or delete local files.

    # Create directory if needed

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score88/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars456SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    davekilleen/Dex
    Skill path
    .claude/plugins/compound-engineering/skills/compound-docs/SKILL.md
    Commit
    2aa1a433a3c8879dfe320902a976197dda3a2484
    License
    NOASSERTION
    Collected
    2026-08-04
    Default branch
    main
    View the original SKILL.md

    compound-docs Skill

    Purpose: Automatically document solved problems to build searchable institutional knowledge with category-based organization (enum-validated problem types).

    Overview

    This skill captures problem solutions immediately after confirmation, creating structured documentation that serves as a searchable knowledge base for future sessions.

    Organization: Single-file architecture - each problem documented as one markdown file in its symptom category directory (e.g., docs/solutions/performance-issues/n-plus-one-briefs.md). Files use YAML frontmatter for metadata and searchability.


    <critical_sequence name="documentation-capture" enforce_order="strict">

    7-Step Process

    Auto-invoke after phrases:

    • "that worked"
    • "it's fixed"
    • "working now"
    • "problem solved"
    • "that did it"

    OR manual: /doc-fix command

    Non-trivial problems only:

    • Multiple investigation attempts needed
    • Tricky debugging that took time
    • Non-obvious solution
    • Future sessions would benefit

    Skip documentation for:

    • Simple typos
    • Obvious syntax errors
    • Trivial fixes immediately corrected

    Extract from conversation history:

    Required information:

    • Module name: Which module or component had the problem
    • Symptom: Observable error/behavior (exact error messages)
    • Investigation attempts: What didn't work and why
    • Root cause: Technical explanation of actual problem
    • Solution: What fixed it (code/config changes)
    • Prevention: How to avoid in future

    Environment details:

    • Rails version
    • Stage (0-6 or post-implementation)
    • OS version
    • File/line references

    BLOCKING REQUIREMENT: If critical context is missing (module name, exact error, stage, or resolution steps), ask user and WAIT for response before proceeding to Step 3:

    I need a few details to document this properly:
    
    1. Which module had this issue? [ModuleName]
    2. What was the exact error message or symptom?
    3. What stage were you in? (0-6 or post-implementation)
    
    [Continue after user provides details]
    

    Search docs/solutions/ for similar issues:

    # Search by error message keywords
    grep -r "exact error phrase" docs/solutions/
    
    # Search by symptom category
    ls docs/solutions/[category]/
    

    IF similar issue found:

    THEN present decision options:

    Found similar issue: docs/solutions/[path]
    
    What's next?
    1. Create new doc with cross-reference (recommended)
    2. Update existing doc (only if same root cause)
    3. Other
    
    Choose (1-3): _
    

    WAIT for user response, then execute chosen action.

    ELSE (no similar issue found):

    Proceed directly to Step 4 (no user interaction needed).

    Format: [sanitized-symptom]-[module]-[YYYYMMDD].md

    Sanitization rules:

    • Lowercase
    • Replace spaces with hyphens
    • Remove special characters except hyphens
    • Truncate to reasonable length (< 80 chars)

    Examples:

    • missing-include-BriefSystem-20251110.md
    • parameter-not-saving-state-EmailProcessing-20251110.md
    • webview-crash-on-resize-Assistant-20251110.md

    CRITICAL: All docs require validated YAML frontmatter with enum validation.

    <validation_gate name="yaml-schema" blocking="true">

    Validate against schema: Load schema.yaml and classify the problem against the enum values defined in yaml-schema.md. Ensure all required fields are present and match allowed values exactly.

    BLOCK if validation fails:

    ❌ YAML validation failed
    
    Errors:
    - problem_type: must be one of schema enums, got "compilation_error"
    - severity: must be one of [critical, high, medium, low], got "invalid"
    - symptoms: must be array with 1-5 items, got string
    
    Please provide corrected values.
    

    GATE ENFORCEMENT: Do NOT proceed to Step 6 (Create Documentation) until YAML frontmatter passes all validation rules defined in schema.yaml.

    </validation_gate>

    Determine category from problem_type: Use the category mapping defined in yaml-schema.md (lines 49-61).

    Create documentation file:

    PROBLEM_TYPE="[from validated YAML]"
    CATEGORY="[mapped from problem_type]"
    FILENAME="[generated-filename].md"
    DOC_PATH="docs/solutions/${CATEGORY}/${FILENAME}"
    
    # Create directory if needed
    mkdir -p "docs/solutions/${CATEGORY}"
    
    # Write documentation using template from assets/resolution-template.md
    # (Content populated with Step 2 context and validated YAML frontmatter)
    

    Result:

    • Single file in category directory
    • Enum validation ensures consistent categorization

    Create documentation: Populate the structure from assets/resolution-template.md with context gathered in Step 2 and validated YAML frontmatter from Step 5.

    If similar issues found in Step 3:

    Update existing doc:

    # Add Related Issues link to similar doc
    echo "- See also: [$FILENAME]($REAL_FILE)" >> [similar-doc.md]
    

    Update new doc: Already includes cross-reference from Step 6.

    Update patterns if applicable:

    If this represents a common pattern (3+ similar issues):

    # Add to docs/solutions/patterns/common-solutions.md
    cat >> docs/solutions/patterns/common-solutions.md << 'EOF'
    
    ## [Pattern Name]
    
    **Common symptom:** [Description]
    **Root cause:** [Technical explanation]
    **Solution pattern:** [General approach]
    
    **Examples:**
    - [Link to doc 1]
    - [Link to doc 2]
    - [Link to doc 3]
    EOF
    

    Critical Pattern Detection (Optional Proactive Suggestion):

    If this issue has automatic indicators suggesting it might be critical:

    • Severity: critical in YAML
    • Affects multiple modules OR foundational stage (Stage 2 or 3)
    • Non-obvious solution

    Then in the decision menu (Step 8), add a note:

    💡 This might be worth adding to Required Reading (Option 2)
    

    But NEVER auto-promote. User decides via decision menu (Option 2).

    Template for critical pattern addition:

    When user selects Option 2 (Add to Required Reading), use the template from assets/critical-pattern-template.md to structure the pattern entry. Number it sequentially based on existing patterns in docs/solutions/patterns/critical-patterns.md.

    </critical_sequence>


    <decision_gate name="post-documentation" wait_for_user="true">

    Decision Menu After Capture

    After successful documentation, present options and WAIT for user response:

    ✓ Solution documented
    
    File created:
    - docs/solutions/[category]/[filename].md
    
    What's next?
    1. Continue workflow (recommended)
    2. Add to Required Reading - Promote to critical patterns (critical-patterns.md)
    3. Link related issues - Connect to similar problems
    4. Add to existing skill - Add to a learning skill (e.g., hotwire-native)
    5. Create new skill - Extract into new learning skill
    6. View documentation - See what was captured
    7. Other
    

    Handle responses:

    Option 1: Continue workflow

    • Return to calling skill/workflow
    • Documentation is complete

    Option 2: Add to Required Reading ⭐ PRIMARY PATH FOR CRITICAL PATTERNS

    User selects this when:

    • System made this mistake multiple times across different modules
    • Solution is non-obvious but must be followed every time
    • Foundational requirement (Rails, Rails API, threading, etc.)

    Action:

    1. Extract pattern from the documentation
    2. Format as ❌ WRONG vs ✅ CORRECT with code examples
    3. Add to docs/solutions/patterns/critical-patterns.md
    4. Add cross-reference back to this doc
    5. Confirm: "✓ Added to Required Reading. All subagents will see this pattern before code generation."

    Option 3: Link related issues

    • Prompt: "Which doc to link? (provide filename or describe)"
    • Search docs/solutions/ for the doc
    • Add cross-reference to both docs
    • Confirm: "✓ Cross-reference added"

    Option 4: Add to existing skill

    User selects this when the documented solution relates to an existing learning skill:

    Action:

    1. Prompt: "Which skill? (hotwire-native, etc.)"
    2. Determine which reference file to update (resources.md, patterns.md, or examples.md)
    3. Add link and brief description to appropriate section
    4. Confirm: "✓ Added to [skill-name] skill in [file]"

    Example: For Hotwire Native Tailwind variants solution:

    • Add to hotwire-native/references/resources.md under "Project-Specific Resources"
    • Add to hotwire-native/references/examples.md with link to solution doc

    Option 5: Create new skill

    User selects this when the solution represents the start of a new learning domain:

    Action:

    1. Prompt: "What should the new skill be called? (e.g., stripe-billing, email-processing)"
    2. Run python3 .claude/skills/anthropic-skill-creator/scripts/init_skill.py [skill-name]
    3. Create initial reference files with this solution as first example
    4. Confirm: "✓ Created new [skill-name] skill with this solution as first example"

    Option 6: View documentation

    • Display the created documentation
    • Present decision menu again

    Option 7: Other

    • Ask what they'd like to do

    </decision_gate>


    <integration_protocol>

    Integration Points

    Invoked by:

    • /compound command (primary interface)
    • Manual invocation in conversation after solution confirmed
    • Can be triggered by detecting confirmation phrases like "that worked", "it's fixed", etc.

    Invokes:

    • None (terminal skill - does not delegate to other skills)

    Handoff expectations: All context needed for documentation should be present in conversation history before invocation.

    </integration_protocol>


    <success_criteria>

    Success Criteria

    Documentation is successful when ALL of the following are true:

    • ✅ YAML frontmatter validated (all required fields, correct formats)
    • ✅ File created in docs/solutions/[category]/[filename].md
    • ✅ Enum values match schema.yaml exactly
    • ✅ Code examples included in solution section
    • ✅ Cross-references added if related issues found
    • ✅ User presented with decision menu and action confirmed

    </success_criteria>


    Error Handling

    Missing context:

    • Ask user for missing details
    • Don't proceed until critical info provided

    YAML validation failure:

    • Show specific errors
    • Present retry with corrected values
    • BLOCK until valid

    Similar issue ambiguity:

    • Present multiple matches
    • Let user choose: new doc, update existing, or link as duplicate

    Module not in modules documentation:

    • Warn but don't block
    • Proceed with documentation
    • Suggest: "Add [Module] to modules documentation if not there"

    Execution Guidelines

    MUST do:

    • Validate YAML frontmatter (BLOCK if invalid per Step 5 validation gate)
    • Extract exact error messages from conversation
    • Include code examples in solution section
    • Create directories before writing files (mkdir -p)
    • Ask user and WAIT if critical context missing

    MUST NOT do:

    • Skip YAML validation (validation gate is blocking)
    • Use vague descriptions (not searchable)
    • Omit code examples or cross-references

    Quality Guidelines

    Good documentation has:

    • ✅ Exact error messages (copy-paste from output)
    • ✅ Specific file:line references
    • ✅ Observable symptoms (what you saw, not interpretations)
    • ✅ Failed attempts documented (helps avoid wrong paths)
    • ✅ Technical explanation (not just "what" but "why")
    • ✅ Code examples (before/after if applicable)
    • ✅ Prevention guidance (how to catch early)
    • ✅ Cross-references (related issues)

    Avoid:

    • ❌ Vague descriptions ("something was wrong")
    • ❌ Missing technical details ("fixed the code")
    • ❌ No context (which version? which file?)
    • ❌ Just code dumps (explain why it works)
    • ❌ No prevention guidance
    • ❌ No cross-references

    Example Scenario

    User: "That worked! The N+1 query is fixed."

    Skill activates:

    1. Detect confirmation: "That worked!" triggers auto-invoke
    2. Gather context:
      • Module: Brief System
      • Symptom: Brief generation taking >5 seconds, N+1 query when loading email threads
      • Failed attempts: Added pagination (didn't help), checked background job performance
      • Solution: Added eager loading with includes(:emails) on Brief model
      • Root cause: Missing eager loading causing separate database query per email thread
    3. Check existing: No similar issue found
    4. Generate filename: n-plus-one-brief-generation-BriefSystem-20251110.md
    5. Validate YAML:
      module: Brief System
      date: 2025-11-10
      problem_type: performance_issue
      component: rails_model
      symptoms:
        - "N+1 query when loading email threads"
        - "Brief generation taking >5 seconds"
      root_cause: missing_include
      severity: high
      tags: [n-plus-one, eager-loading, performance]
      
      ✅ Valid
    6. Create documentation:
      • docs/solutions/performance-issues/n-plus-one-brief-generation-BriefSystem-20251110.md
    7. Cross-reference: None needed (no similar issues)

    Output:

    ✓ Solution documented
    
    File created:
    - docs/solutions/performance-issues/n-plus-one-brief-generation-BriefSystem-20251110.md
    
    What's next?
    1. Continue workflow (recommended)
    2. Add to Required Reading - Promote to critical patterns (critical-patterns.md)
    3. Link related issues - Connect to similar problems
    4. Add to existing skill - Add to a learning skill (e.g., hotwire-native)
    5. Create new skill - Extract into new learning skill
    6. View documentation - See what was captured
    7. Other
    

    Future Enhancements

    Not in Phase 7 scope, but potential:

    • Search by date range
    • Filter by severity
    • Tag-based search interface
    • Metrics (most common issues, resolution time)
    • Export to shareable format (community knowledge sharing)
    • Import community solutions

    Alternatives

    Compare before choosing

    Computed 9823,781

    alirezarezvani/claude-skills

    quality-manager-qms-iso13485

    ISO 13485 Quality Management System implementation and maintenance for medical device organizations. Provides QMS design, documentation control, internal auditing, CAPA management, and certification support. Use when working with medical device quality systems, preparing for ISO 13485 audits, managing regulatory compliance documentation, setting up corrective actions, or building audit preparation programs. Useful for quality management, audit preparation, regulatory compliance, medical device d

    Computed 9810,895

    huggingface/skills

    huggingface-zerogpu

    AI demos and GPU compute with Gradio Spaces and Hugging Face Spaces ZeroGPU. Use when writing or reviewing code that uses `@spaces.GPU`, configuring `python_version` or `requirements.txt` for a ZeroGPU Space, or handling ZeroGPU-specific code constraints — pickle-based process isolation, `gr.State` semantics across the worker boundary, no `torch.compile` (use AoTI instead), CUDA wheel-only builds (no `nvcc` at build or runtime), large vs xlarge sizing, and dynamic duration callables. Make sure t

    Computed 9732,606

    K-Dense-AI/scientific-agent-skills

    biopython

    Comprehensive molecular biology toolkit. Use for sequence manipulation, file parsing (FASTA/GenBank/PDB), phylogenetics, and programmatic NCBI/PubMed access (Bio.Entrez). Best for batch processing, custom bioinformatics pipelines, BLAST automation. For quick lookups use gget; for multi-service integration use bioservices.

    Computed 9732,606

    K-Dense-AI/scientific-agent-skills

    esm

    Use when working directly with the `esm` Python SDK, ESM3 or ESMC model IDs, Forge/Biohub inference clients, or ESMFold2 folding workflows.