Notre avis
Extrait les connaissances du contexte d'une PR GitHub et enregistre une documentation structurée dans un répertoire de leçons.
Points forts
- Automatise la documentation des commentaires et revues de PR.
- Dédoublonne et classe les connaissances avec des tags et types de problèmes.
- Intègre les fichiers de contexte existants et génère des références croisées.
- Gère les erreurs et demande une intervention manuelle si nécessaire.
Limites
- Nécessite l'interface en ligne de commande GitHub (gh) et une structure de répertoires spécifique.
- Peut manquer des retours précieux si les commentaires ne contiennent pas de mots-clés explicites.
- Dépend de l'existence d'une PR ; sinon demande une saisie manuelle.
Après avoir fusionné une PR pour capturer les apprentissages et décisions afin de les référencer ultérieurement.
Lorsque la PR ne contient aucun commentaire ou contexte pertinent, ou que la création d'une documentation supplémentaire est inutile.
Analyse de sécurité
SûrThe 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.
Aucun point d'attention détecté
Exemples
/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}/) -->
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.