Our review
Extracts knowledge from GitHub PR context and saves structured documentation to a learnings directory.
Strengths
- Automates documentation from PR comments and reviews.
- Deduplicates and classifies knowledge with tags and problem types.
- Integrates with existing context files and generates cross-references.
- Handles errors and prompts for manual input when needed.
Limitations
- Requires GitHub CLI (gh) and a specific directory structure.
- May miss valuable feedback if comments lack explicit keywords.
- Depends on existence of a PR; otherwise asks for manual input.
After completing a pull request to capture learnings and decisions for future reference.
When the PR has no valuable comments or context, or when extra documentation overhead is unnecessary.
Security analysis
SafeThe skill uses only safe, local file operations and gh CLI reads for documentation generation. No destructive or exfiltrating commands are present; all Bash invocations are constrained to reading PR data and writing markdown files within the repository.
No concerns found
Examples
/compound 123/compoundcompound thisname: compound description: | This skill should be used when the user says "/compound", "compound this", "document learnings", "save what we learned", or after completing a PR. Extracts knowledge from PR context and saves to docs/learnings/. allowed-tools:
- Read
- Grep
- Glob
- Bash
- Write
- Edit
- AskUserQuestion
Compound Skill
Extracts knowledge from PR context and saves structured documentation to docs/learnings/.
Workflow
Phase 1: Context Collection
-
Identify PR number/branch
- Use PR number if provided as argument
- Otherwise, find PR from current branch:
gh pr view --json number,body,title - If no PR exists: Prompt user to enter PR number directly or confirm proceeding without PR
-
Extract Plan path
- Find Plan path pattern in PR body:
.dev/specs/{name}/PLAN.md - Regex:
\.dev/specs/[^/]+/PLAN\.md - If no Plan path found: Prompt user to enter spec name directly or select from
.dev/specs/directory listing
- Find Plan path pattern in PR body:
-
Derive Context path
- Extract spec name from Plan path
- Context directory:
.dev/specs/{name}/context/
-
Parallel collection (run following commands simultaneously, skip if files don't exist)
# Context files (treat as empty if not found) cat .dev/specs/{name}/context/learnings.md 2>/dev/null || echo "" cat .dev/specs/{name}/context/decisions.md 2>/dev/null || echo "" cat .dev/specs/{name}/context/issues.md 2>/dev/null || echo "" # PR comments and reviews (collect as JSON for stability) gh pr view {pr_number} --json comments,reviews
Error Handling:
- If no context files exist AND no PR comments → Notify user and request manual input
- At least 1 source required to proceed with document generation
Phase 2: Knowledge Extraction & Classification
2.1 Extract Valuable Feedback from PR Comments
Criteria for valuable feedback:
- Code improvement suggestions
- Bug/issue identification
- Pattern/best practice mentions
- "This would be better" type advice
- Comments left with approval
Filter out:
- Simple questions ("What is this?")
- Confirmation requests ("Is this correct?")
- Approval-only comments ("LGTM", "Approved")
- Bot comments
Extraction keywords:
- "suggest", "recommend", "better", "instead"
- "pattern", "practice", "convention"
- "issue", "bug", "fix"
- "learned", "TIL", "note"
Extracted information:
- author
- body
- file_path (if inline comment)
- created_at
2.2 Analyze Context Files
| File | Purpose | |------|---------| | learnings.md | Direct learnings | | decisions.md | Decision rationale | | issues.md | Out of scope issues (for future reference) |
2.3 Synthesize
- Assess documentation value from collected sources
- Check for duplicates: Search
docs/learnings/ - Classify problem type - Refer to
references/problem-types.md(relative to this skill directory) - Generate tags
Phase 3: Document Generation
-
Generate YAML frontmatter
pr_number: {PR_NUMBER} date: {YYYY-MM-DD} problem_type: {TYPE} tags: [{TAGS}] plan_path: {PLAN_PATH} -
Write document using template
- Template location:
templates/LEARNING_TEMPLATE.md(relative to this skill directory) - Read template and substitute placeholders
- Template location:
-
Determine filename
- Format:
{YYYY-MM-DD}-{short-title}.md - Example:
2024-01-15-api-error-handling.md
- Format:
-
Save
- Path:
docs/learnings/{filename}.md
- Path:
-
Add cross-references (if related documents exist)
- Add new document link to Related section of existing documents
Usage Examples
# Specify PR number
/compound 123
# Use PR from current branch
/compound
Output
Outputs the created document path and summary:
Created: docs/learnings/2024-01-15-api-error-handling.md
Summary:
- Problem Type: error-handling
- Tags: api, typescript, validation
- Sources: learnings.md, 2 PR comments
<!-- TODO: Future extensions --> <!-- - [ ] Session ID based user feedback collection --> <!-- - [ ] CLAUDE.md auto-update suggestions --> <!-- - [ ] Detect existing document UPDATEs --> <!-- - [ ] Auto-categorization by problem_type (docs/solutions/{type}/) -->
API Documentation Generator
Documentation
Automatically generates OpenAPI/Swagger API documentation.
Technical Writer
Documentation
Writes clear technical documentation following top style guides.
Typed Documentation Forms System
Documentation
Add typed comments, documentation, todos, and metadata to Scheme code using `(doc ...)` forms. Doc annotations are authoritative for type inference, extracted by search commands (lf-todo, lf-types), and integrated with the type checker and LSP. Useful for annotating functions, marking deprecations, or tracking localized improvements alongside the code.