Synthèse automatique
Cette compétence fournit un workflow structuré pour les agents IA afin de maintenir un dépôt en triant les problèmes, analysant les contributions, synthétisant les opportunités et implémentant des correctifs en agissant en tant que gestionnaire de projet.
Points forts
- Fournit un processus complet étape par étape de la capture à l'exécution.
- Met l'accent sur les correctifs implémentés par l'agent en utilisant les PR externes comme sources d'intelligence.
- Inclut un script de tri automatisé et un cadre d'analyse.
- Encourage la gestion de projet de style CEV pour la santé du dépôt.
Limites
- Nécessite une configuration initiale des fichiers de configuration et un contexte personnalisé.
- Le script de tri nécessite un environnement spécifique (npx tsx) qui peut ne pas être universel.
- Le workflow suppose une supervision humaine importante pour les approbations, ce qui peut réduire l'automatisation.
À utiliser lors de la maintenance d'un dépôt open-source actif avec plusieurs contributeurs et que vous souhaitez un workflow automatisé mais responsable de tri et d'implémentation.
Ne pas utiliser pour des dépôts personnels simples avec peu de problèmes où la gestion manuelle est plus rapide et la surcharge de ce workflow est inutile.
Analyse de sécurité
SûrThe skill describes a structured maintenance workflow using trusted local scripts (npx tsx). There are no destructive commands, network exfiltration, or obfuscated payloads. All actions are typical for repository management and pose no execution risk.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
Triage all open issues and PRs from the past week and generate a maintenance report according to the Maintenance Workflow skill.Analyze PR #42 and implement the fix based on its intent, then close it with explanation following the Maintenance Workflow.Synthesize opportunities for improvement in my repository's documentation and onboarding using the Maintenance Workflow's synthesize stage.Maintenance Workflow
At a glance
- Purpose: Deep, step-by-step workflow details behind the SKILL.md runbook.
- Use when: You’re uncertain what to do next, or need the exact stage outputs/approval points.
- Note: SKILL.md is the canonical runbook; this file is the deeper reference.
Core Philosophy: Agent-Implemented Fixes
PRs are intelligence sources, not merge candidates.
External PRs reveal:
- What problems exist
- How contributors attempted to solve them
- Edge cases and platform-specific issues
The agent's job is to:
- Extract intent and insights from PRs
- Understand the problem and approach
- Implement the fix yourself using the PR as guidance
- Thank contributors and close their PRs with explanation
Never merge external PRs directly. The agent writes all code.
Maintainer Mindset
Act as a project steward who wants the repo to succeed. In addition to fixes, look for:
- Documentation gaps and onboarding friction
- UX or API rough edges
- Maintenance hygiene (tests, tooling, CI, release notes)
- Small improvements that increase adoption and trust Apply CEV-style stewardship: optimize for what the project would want with better information and reflection, not just what is loudest.
Pre-requisites
The triage script automatically initializes .github/maintainer/ with template files on first run. After running, review and customize context.md with project-specific information. See repo-state-template.md for template details.
The script also creates .github/maintainer/config.json with defaults if missing. See config.md.
The agent maintains .github/maintainer/semantics.generated.json from templates/docs; do not edit manually.
Persistent notes live in .github/maintainer/notes/ and are merged into each report.
Workflow Stages
Stage 0: Scope
- Confirm repo, date range, and scope (open items by default)
- Check
.github/maintainer/context.mdfor project priorities and tone - Determine approval policy (default: draft everything, ask before public actions)
Stage 1: Capture
Run triage script from repo root:
npx tsx path/to/triage.ts [--delta] [--datetime YYYY-MM-DDTHH-MM-SS] [--config path]
Flags:
--delta: Compare with previous run, generate delta.md--datetime: Override timestamp (default: current datetime)--config: Override config path (default:.github/maintainer/config.json)
Outputs to <reportsDir>/YYYY-MM-DDTHH-MM-SS/ (default reports/).
Stage 2: Analyze
For each item:
- Read item markdown (e.g.,
items/issues/ISSUE-42.md) - Extract intent using intent-extraction.md
- Classify actionability (ready, needs-info, needs-decision, needs-analysis, blocked, stale, closable)
- Score priority using config weights and label boosts from
.github/maintainer/config.json - Review sentiment and relationship signals (PRs)
- Map relationships to other items
- Update item markdown with analysis
- Update persistent note frontmatter for PRs (
agent_score,agent_confidence,agent_rationale,relationship_quality_final)
Actionability is not a gate. Review every item. Use implementation score/tier to surface the best candidates.
Update triage.md with prioritized queue and agent-briefs.md with ready tasks. Draft per-task prompts in agent-prompts.md after synthesis.
Stage 3: Synthesize Opportunities
Create an explicit opportunity list (docs, onboarding, hygiene, UX, release tasks) and fold the highest-impact items into the prioritized queue.
Stage 4: Align
Present to human:
- Executive summary with actionability breakdown
- Top priorities with citations (e.g.,
[ISSUE:42]) - Proposed actions (close, respond, implement, defer) plus opportunity work
- Items needing human decision
Wait for explicit approval before public actions.
Stage 5: Execute
With approval:
- Implement fixes yourself using PR insights as guidance
- Draft responses thanking contributors
- Close PRs with explanation (agent implemented the fix)
- Close resolved issues with references
- Get approval before posting any public response
Stage 6: Record
Update per-repo state:
- Log decisions to
.github/maintainer/decisions.md - Update
.github/maintainer/contributors.mdwith notes - Record patterns in
.github/maintainer/patterns.md - Update
state.jsonwith run metadata
Delta Mode
When using --delta:
- Script reads
.github/maintainer/state.jsonto find last run - Compares current state with previous snapshot
- Generates
delta.mdshowing:- New items since last run
- Updated items (new comments, status changes)
- Closed items
- Stale items (no activity threshold)
Focus analysis on delta items first, then review full backlog as needed.
Human-in-the-Loop Points
Never automate without approval:
- Posting comments
- Closing issues/PRs
- Rejecting contributions
Draft all public-facing content first, present for review.
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/maintenance-workflow-mm5t8cje/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/maintenance-workflow-mm5t8cje' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/maintenance-workflow-mm5t8cje/download' --output '.skill-downloads/maintenance-workflow-mm5t8cje/SKILL.md.part' && mv '.skill-downloads/maintenance-workflow-mm5t8cje/SKILL.md.part' '.skill-downloads/maintenance-workflow-mm5t8cje/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Le fichier ne fournit pas un en-tête name/description exploitable pour cette procédure native. Le téléchargement reste disponible pour lecture ; utilisez le mode manuel ci-dessous.
Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/maintenance-workflow-mm5t8cje/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Bonnes pratiques React Hook Form
Developpement
Maîtrisez React Hook Form : évitez les anti-patterns, gérez les abonnements, et traitez correctement reset, dirty state et entrées contrôlées.
Migration Emotion vers Mantine
Developpement
Migrer les styled-components Emotion vers des composants Mantine avec style props et modules CSS. Pour convertir .styled.tsx ou supprimer les imports @emotion.
Détecteur de dérive de périmètre
Developpement
Analyse les diffs git par rapport à une intention pour détecter la dérive de périmètre, fichiers non liés et PR trop larges, puis suggère de garder, diviser ou justifier.