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).
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
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
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.
npx skills add https://github.com/davekilleen/Dex --skill ".claude/plugins/compound-engineering/skills/compound-docs"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
- 01
7-Step Process
Auto-invoke after phrases:
"that worked""it's fixed""working now" - 02
Step 1: Detect Confirmation
Auto-invoke after phrases:
"that worked""it's fixed""working now" - 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 - 04
Step 3: Check Existing Docs
Search docs/solutions/ for similar issues:
Search docs/solutions/ for similar issues: - 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
The documentation asks the agent to create, modify, or delete local files.
*Create documentation file:**Writes files
The documentation asks the agent to create, modify, or delete local files.
# Create directory if neededEvidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 88/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 456 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated 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.mdparameter-not-saving-state-EmailProcessing-20251110.mdwebview-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:
criticalin 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:
- Extract pattern from the documentation
- Format as ❌ WRONG vs ✅ CORRECT with code examples
- Add to
docs/solutions/patterns/critical-patterns.md - Add cross-reference back to this doc
- 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:
- Prompt: "Which skill? (hotwire-native, etc.)"
- Determine which reference file to update (resources.md, patterns.md, or examples.md)
- Add link and brief description to appropriate section
- Confirm: "✓ Added to [skill-name] skill in [file]"
Example: For Hotwire Native Tailwind variants solution:
- Add to
hotwire-native/references/resources.mdunder "Project-Specific Resources" - Add to
hotwire-native/references/examples.mdwith link to solution doc
Option 5: Create new skill
User selects this when the solution represents the start of a new learning domain:
Action:
- Prompt: "What should the new skill be called? (e.g., stripe-billing, email-processing)"
- Run
python3 .claude/skills/anthropic-skill-creator/scripts/init_skill.py [skill-name] - Create initial reference files with this solution as first example
- 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:
- Detect confirmation: "That worked!" triggers auto-invoke
- 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
- Check existing: No similar issue found
- Generate filename:
n-plus-one-brief-generation-BriefSystem-20251110.md - Validate YAML:
✅ Validmodule: 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] - Create documentation:
docs/solutions/performance-issues/n-plus-one-brief-generation-BriefSystem-20251110.md
- 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
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
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
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.
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.