Audit d'org en tâches
La version artisanale prenait une demi-journée : lire un long audit, décider de ce qui va ensemble, écrire chaque tâche avec une priorité et une définition de fait, puis la saisir dans le suivi. Ce skill fait la lecture et la saisie. La décision reste avec la personne.
Étape 1 : demander avant d'agir
Demandez en un seul message et attendez :
- Quelle org (alias CLI) ? Confirmez qu'il ne s'agit pas d'une org de production client sauf si l'engagement autorise les analyses en lecture seule.
- Où vont les tâches ? ClickUp (quelle liste) ou GitHub (quel dépôt). Vérifiez que le serveur MCP correspondant est connecté ; sinon, arrêtez-vous et dites comment le connecter.
- Qui possède les tâches ? Noms des assignés, ou laissez non assigné.
- Y a-t-il quelque chose à exclure ? Certaines constatations sont connues et acceptées. Le dire maintenant évite du bruit plus tard.
Étape 2 : auditer
node audit.js --org <alias> --out ./out
Écrit out/findings.md et out/findings.json. Lecture seule : chaque appel est une requête ou une liste.
Étape 3 : façonner les tâches
node to-tasks.js out/findings.json
Écrit out/tasks.json : une tâche par type et sévérité de constatation, chaque composant affecté en tant qu'élément de checklist, les longs groupes divisés en lots de 25, avec priorité, effort, libellés et critères d'acceptation.
Étape 4 : réviser avec la personne
Affichez la liste de tâches sous forme de tableau : clé, titre, priorité, effort, nombre d'éléments de checklist. Appliquez ensuite le jugement que le script ne peut pas :
- Fusionnez ou divisez lorsque le regroupement ne correspond pas à la façon dont l'équipe travaille.
- Supprimez les constatations que la personne a dit d'exclure à l'Étape 1.
- Remontez tout ce qui semble petit mais ne l'est pas (un utilisateur d'intégration avec Modifier toutes les données est une constatation de sécurité et de contrôle des modifications).
- Réécrivez les critères d'acceptation lorsque l'équipe a sa propre définition de fait.
Ne créez rien tant que la personne n'a pas dit que la liste était correcte.
Étape 5 : créer
Créez chaque tâche approuvée via le serveur MCP connecté, ou pour GitHub avec node create-issues.js --repo owner/name (prévisualisez d'abord avec --dry-run), avec le titre, la description, la priorité, les libellés, la checklist (checklist ClickUp ou liste de tâches GitHub dans le corps) et les critères d'acceptation. Enregistrez l'URL de chaque tâche créée dans out/tasks.json sous url.
Puis rapportez : combien de tâches ont été créées, où, et le temps écoulé de l'Étape 2 à la dernière tâche créée.
Règles
- L'audit n'écrit jamais dans l'org.
- Aucune tâche n'est créée sans approbation de la liste.
- Aucun nom de client dans quoi que ce soit qui quitte le dossier d'engagement.
- Si un appel au système de tâches échoue, arrêtez-vous, signalez ce qui a été créé et ce qui ne l'a pas été, et ne réessayez pas aveuglément.