Notre avis
Extrait automatiquement les connaissances issues de revues de code et de commentaires de PR pour générer des documents structurés dans docs/learnings/.
Points forts
- Automatise la documentation post-PR en extrayant les retours pertinents
- Intègre des sources multiples (PR, fichiers de contexte existants)
- Gère les doublons et ajoute des références croisées entre documents
Limites
- Nécessite des outils GitHub CLI (gh) et un dépôt Git configuré
- Dépend de la qualité des commentaires de PR pour extraire des informations utiles
- Ne fonctionne qu'avec des PR de la branche courante ou numéro de PR spécifié
Utilisez cette compétence après avoir fusionné une PR ou lorsque vous voulez documenter des apprentissages issus du processus de revue.
Évitez de l'utiliser pour des changements mineurs sans retours significatifs, ou lorsque le projet ne suit pas la structure .dev/specs/{name}/.
Analyse de sécurité
SûrThe skill uses Bash only for local file reads and GitHub CLI operations, with no destructive commands, network exfiltration, or execution of arbitrary code. All actions are confined to the workspace and legitimate PR documentation.
Aucun point d'attention détecté
Exemples
/compound/compound 123compound 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}/) -->
Generateur de Documentation API
Documentation
Genere automatiquement de la documentation API OpenAPI/Swagger.
Rédacteur Technique
Documentation
Rédige de la documentation technique claire selon les meilleurs style guides.
Système de formulaires de documentation typés
Documentation
Utilisez la syntaxe `(doc ...)` pour ajouter des annotations typées, des descriptions, des tâches (todo) et d'autres métadonnées directement dans le code Scheme. Les annotations sont extractibles via des commandes comme lf-todo et lf-types, et s'intègrent au vérificateur de types, où les déclarations de type dans les doc prennent le pas sur l'inférence. Idéal pour documenter les fonctions, marquer des déprécations ou lister des améliorations localisées sans recourir à un système externe.