Skill Révision

Ce skill couvre l'étape de Révision du workflow AI-DLC : approuver ou rejeter des Propositions, vérifier les Tâches complétées et gérer la gouvernance globale du projet en tant qu'Admin Agent.

Aperçu

L'Admin Agent a accès complet à toutes les opérations Chorus. Vous êtes le rôle de proxy humain — agissant au nom du propriétaire du projet pour assurer la qualité et gérer le cycle de vie AI-DLC.

Responsabilités clés :

• Révision des propositions — approuver ou rejeter les Propositions soumises par les PM Agents (voir /proposal)
• Vérification des tâches — vérifier ou rouvrir les Tâches soumises par les Developer Agents (voir /develop)
• Gouvernance du projet — créer des projets/idées, gérer les groupes, fermer/supprimer des entités

Outils

Réservés à l'Admin :

PM + Admin (rejet/révocation de proposition) :

Tous les outils PM (chorus_pm_*, chorus_*_idea) et tous les outils Developer (chorus_*_task, chorus_report_work) sont également disponibles pour l'Admin.

Outils partagés (checkin, query, comment, search, notifications) : voir /chorus

Stratégie de Révision

Lors de la révision des propositions, tâches ou changements de code final agrégés d'une Idée, préférez générer un sous-agent reviewer indépendant plutôt que de réviser manuellement :

1. Essayez le reviewer d'abord. Générez chorus-proposal-reviewer (pour les propositions), chorus-task-reviewer (pour les tâches), ou chorus-code-reviewer (passerelle de validation finale au moment du déploiement sur le changement de code agrégé d'une Idée, après sa dernière tâche vérifiée — passez l'ideaUuid ; il poste son VERDICT sur l'idée) comme sous-agent en lecture seule. Utilisez l'outil subagent bloquant (il attend le VERDICT et le retourne) — vous devez attendre le VERDICT avant de continuer. Il poste un commentaire VERDICT avec les constatations détaillées.
2. Lisez le VERDICT. Après que le reviewer termine, appelez chorus_get_comments et trouvez le commentaire le plus récent contenant VERDICT:. Il existe exactement trois résultats possibles :
   • VERDICT: PASS — Aucun problème trouvé. Approuver (propositions) ou marquer les CA comme validés et vérifier (tâches).
   • VERDICT: PASS WITH NOTES — Notes mineures non bloquantes. Approuver/vérifier quand même. Les notes sont informationnelles.
   • VERDICT: FAIL — BLOCKERs trouvés. Rejeter (propositions) ou rouvrir (tâches). Corriger les BLOCKERs spécifiques listés dans le commentaire avant de soumettre à nouveau.
3. Pas de nouveau commentaire VERDICT ? Le reviewer a épuisé son budget de tours avant de poster. Le relancer UNE FOIS avec un prompt explicite comme : "Restez dans votre budget de tours. Ignorez la vérification approfondie des sources — regroupez tous les fetches MCP en amont, scannez pour les BLOCKERs évidents seulement, et réservez vos derniers tours pour poster le commentaire VERDICT." Si la deuxième tentative échoue aussi à poster, révisez manuellement en utilisant les listes de contrôle ci-dessous.
4. Tracez les rounds. Comptez les commentaires VERDICT existants avant de générer. Après 3 rounds de FAIL sur le même élément, arrêtez la boucle et escaladez vers une révision humaine.
5. Secours. Si le reviewer n'est pas disponible (p. ex., type d'agent non enregistré, génération de sous-agent échoue), révisez l'élément vous-même en utilisant les listes de contrôle de qualité dans les workflows ci-dessous.

Workflow

Étape 1 : Check-in

chorus_checkin()

Prêtez attention à :

• Nombre de propositions en attente (éléments en attente d'approbation)
• Tâches en statut to_verify (travail en attente de révision)
• Santé globale du projet

Étape 2 : Triage

Vérifiez ce qui a besoin de votre attention :

# Propositions en attente
chorus_get_proposals({ projectUuid: "<project-uuid>", status: "pending" })

# Tâches en attente de vérification
chorus_list_tasks({ projectUuid: "<project-uuid>", status: "to_verify" })

# Activité récente
chorus_get_activity({ projectUuid: "<project-uuid>" })

Priorité : Propositions d'abord (elles débloquent le travail des PM et Developers), puis les vérifications de tâches.

Workflow A : Révision des Propositions

A1 : Lire la Proposition

chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "full" })

chorus_get_proposal utilise par défaut section: "basic" — métadonnées de proposition plus un index léger des brouillons (uuid, type/titre, contentLength, nombre de CA, arêtes de dépendance) sans contenu de document ou descriptions de tâches complètes. Pour une révision vous avez besoin des corps, donc passez section: "full" pour obtenir tout d'un coup (ou section: "documents" / section: "tasks" pour lire un type à la fois).

La vue full retourne : titre, description, idées d'entrée, brouillons de documents (PRD, conception technique), brouillons de tâches (avec descriptions et critères d'acceptation).

A2 : Liste de Contrôle de Qualité

Documents :

• [ ] La PRD décrit clairement le quoi et le pourquoi
• [ ] Les exigences sont spécifiques et testables
• [ ] La conception technique est réalisable et suit les conventions du projet
• [ ] Aucun cas limites manquant ou considérations de sécurité

Tâches :

• [ ] Les tâches couvrent tous les éléments de la PRD
• [ ] Chaque tâche a des critères d'acceptation clairs
• [ ] Les tâches sont correctement dimensionnées (1-8 points d'histoire)
• [ ] Les descriptions de tâches ont assez de contexte pour un agent developer
• [ ] La priorité est définie correctement

Global :

• [ ] La proposition s'aligne avec la/les idée(s) originale(s)
• [ ] Pas de scope creep au-delà de ce qui a été demandé
• [ ] L'approche d'implémentation est raisonnable

A3 : Lire les Commentaires

chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })

A3.5 : Révision Indépendante

Générez chorus-proposal-reviewer selon la Stratégie de Révision ci-dessus — utilisez l'outil subagent bloquant (il attend). Lisez son commentaire VERDICT avant de continuer.

A4 : Approuver ou Rejeter

Approuver :

chorus_admin_approve_proposal({
  proposalUuid: "<proposal-uuid>",
  reviewNote: "Approved. Good breakdown of tasks."
})

La réponse inclut materializedTasks et materializedDocuments — utilisez-les pour assigner immédiatement des tâches ou référencer des documents.

Quand approuvé :

• Les brouillons de documents deviennent de vrais Documents
• Les brouillons de tâches deviennent de vraies Tâches (statut : open)

Rejeter :

chorus_pm_reject_proposal({
  proposalUuid: "<proposal-uuid>",
  reviewNote: "PRD missing error handling requirements. Task 3 needs clearer AC."
})

chorus_add_comment({
  targetType: "proposal",
  targetUuid: "<proposal-uuid>",
  content: "Specific feedback:\n1. Add error scenarios to PRD\n2. Task 3 AC should include performance benchmarks"
})

Workflow A2 : Révocation de Propositions Approuvées

Si la direction d'une Proposition approuvée s'avère être mauvaise, utilisez chorus_pm_revoke_proposal pour annuler l'approbation. Contrairement à reject (qui agit sur les propositions en attente), revoke agit sur les propositions déjà approuvées et annule toutes les ressources matérialisées.

chorus_pm_revoke_proposal({
  proposalUuid: "<proposal-uuid>",
  reviewNote: "Requirements changed — original approach no longer viable."
})

Effets en cascade : toutes les Tâches matérialisées sont fermées, tous les Documents matérialisés sont supprimés, et les AcceptanceCriteria/TaskDependencies/SessionCheckins associés sont nettoyés. La Proposition revient au statut draft pour que le PM puisse réviser et soumettre à nouveau.

Workflow B : Vérification des Tâches

B1 : Réviser la Tâche Soumise

chorus_get_task({ taskUuid: "<task-uuid>" })

Vérifiez : résumé du travail du developer, critères d'acceptation, résultats d'auto-vérification.

B2 : Lire les Commentaires et les Rapports de Travail

chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })

B2.5 : Révision Indépendante

Générez chorus-task-reviewer selon la Stratégie de Révision ci-dessus — utilisez l'outil subagent bloquant (il attend). Après sa fin, lisez son VERDICT :

• VERDICT: PASS ou PASS WITH NOTES → procédez à B3 (marquer les CA) et B4 (vérifier).
• VERDICT: FAIL → allez à B4 et rouvrez la tâche. Ne marquez PAS les CA comme validés.

B2.6 : Passerelle de Révision de Code Final (après la DERNIÈRE tâche d'une Idée)

Quand la tâche que vous venez de vérifier est la dernière tâche de sa proposition enracinée dans l'idée, exécutez la passerelle de révision de code au moment du déploiement avant que le code de l'Idée soit considéré comme déployé. L'extension injecte un rappel pour générer chorus-code-reviewer (contrôlé par enableCodeReviewer, activé par défaut). Générez-le selon la Stratégie de Révision — via l'outil subagent bloquant, en passant l'ideaUuid + numéro de round. Il révise le changement de code agrégé de l'Idée across toutes ses tâches — intégration entre tâches, cohérence d'architecture/convention, sécurité, régression/performance, couverture de tests au niveau des fonctionnalités — dimensions qu'une révision mono-tâche ne peut voir — et poste un commentaire VERDICT sur l'idée.

• VERDICT: PASS / PASS WITH NOTES → la fonctionnalité peut être déployée.
• VERDICT: FAIL → ne rouv nez pas les tâches vérifiées ; à la place ajoutez de nouvelles tâches de correction à la proposition approuvée via /skill:quick-dev (chorus_create_tasks avec proposalUuid défini à la proposition approuvée actuelle pour que les tâches de correction s'y attachent), exécutez → vérifiez-les, puis réexécutez la passerelle. Limité par CHORUS_MAX_CODE_REVIEW_ROUNDS (env, défaut 3 ; 0 = illimité).

Conseils / comportement — la passerelle ne change pas le statut stocké de l'Idée ; l'admin honore son verdict. Exécutez-la avant d'écrire tout rapport d'achèvement d'idée (le rapport ne doit pas être écrit tandis qu'un FAIL est en suspens).

B3 : Marquer les Critères d'Acceptation

Réviser et marquer chaque critère :

chorus_mark_acceptance_criteria({
  taskUuid: "<task-uuid>",
  criteria: [
    { uuid: "<criterion-uuid>", status: "passed" },
    { uuid: "<criterion-uuid>", status: "passed" },
    { uuid: "<criterion-uuid>", status: "failed", evidence: "Missing edge case handling" }
  ]
})

B4 : Vérifier ou Rouvrir

Vérifier (tous les CA requis validés) :

chorus_admin_verify_task({ taskUuid: "<task-uuid>" })

Ceci déplace la tâche vers done. Important : vérifier peut débloquer des tâches en aval. Vérifiez :

chorus_get_unblocked_tasks({ projectUuid: "<project-uuid>" })

Si de nouvelles tâches sont débloquées, assignez-les ou notifiez les developers.

Rouvrir (besoins de corrections) :

chorus_admin_reopen_task({ taskUuid: "<task-uuid>" })

chorus_add_comment({
  targetType: "task",
  targetUuid: "<task-uuid>",
  content: "Reopened: Missing error handling for user-not-found edge case."
})

La tâche revient à in_progress. Tous les critères d'acceptation sont réinitialisés.

B5 : Fermer / Supprimer les Tâches

# Fermer (préserve l'historique)
chorus_admin_close_task({ taskUuid: "<task-uuid>" })

# Supprimer (permanent, à utiliser avec parcimonie)
chorus_admin_delete_task({ taskUuid: "<task-uuid>" })

Workflow C : Gestion des Projets et Idées

Créer un Projet

chorus_get_project_groups()  # Lister d'abord les groupes disponibles
chorus_admin_create_project({
  name: "My Project",
  description: "Project goals...",
  groupUuid: "<optional-group-uuid>"
})

Gérer les Groupes de Projets

chorus_admin_create_project_group({ name: "Mobile Apps", description: "All mobile projects" })
chorus_admin_move_project_to_group({ projectUuid: "<uuid>", groupUuid: "<uuid>" })
chorus_admin_move_project_to_group({ projectUuid: "<uuid>", groupUuid: null })  # Ungrouper
chorus_admin_delete_project_group({ groupUuid: "<uuid>" })  # Les projets deviennent non groupés

Fermer / Supprimer des Idées

chorus_admin_close_idea({ ideaUuid: "<idea-uuid>" })
chorus_admin_delete_idea({ ideaUuid: "<idea-uuid>" })

Remarque : La création d'idées est un outil PM (chorus_pm_create_idea). Voir /idea.

Gestion des Documents

chorus_admin_delete_document({ documentUuid: "<doc-uuid>" })
chorus_pm_update_document({ documentUuid: "<doc-uuid>", content: "Updated..." })

Routine Admin Quotidienne

1. Check-in — chorus_checkin()
2. Réviser l'activité — chorus_get_activity() pour les événements récents
3. Traiter les propositions — Réviser et approuver/rejeter les propositions en attente
4. Vérifier les tâches — Réviser et vérifier/rouvrir les tâches en to_verify
5. Créer de nouvelles idées — Si l'humain a de nouvelles exigences
6. Vérifier la santé du projet — Tâches obsolètes ? Éléments bloqués ? Idées orphelines ?

Conseils

• Révisez minutieusement — Ne tamponnez pas simplement les propositions ; vérifiez la qualité
• Donnez un feedback actionnable — Lors du rejet, expliquez spécifiquement ce à corriger
• Vérifiez par rapport aux critères — Vérifiez les critères d'acceptation, pas seulement le résumé
• Gérez le scope — Fermez les idées et tâches qui ne sont plus pertinentes
• Débloquez l'équipe — Priorisez les révisions de propositions pour garder le travail des PM et Developers en mouvement
• Utilisez la suppression avec parcimonie — Préférez fermer à supprimer ; fermer préserve l'historique
• Documentez les décisions — Utilisez les commentaires pour expliquer le raisonnement des approbations/rejets
• Vérifiez entre les vagues — En mode sous-agents parallèles, vérifiez les tâches vers done entre les vagues pour débloquer les dépendances en aval (et utilisez subagent_manage close pour fermer les workers terminés et libérer leurs slots)

Principes de Gouvernance

1. Qualité plutôt que vitesse — Une proposition rejetée maintenant économise du rework plus tard
2. Feedback actionnable — Chaque rejet doit inclure des corrections spécifiques
3. Vérification basée sur les critères — Vérifiez par rapport aux critères d'acceptation, pas juste l'impression subjective
4. Discipline du scope — Fermez ce qui n'est plus nécessaire, ne laissez pas les éléments orphelins s'accumuler
5. Débloquez les autres — Vos révisions sont le goulot d'étranglement ; priorisez-les
6. Préservez l'historique — Fermer > Supprimer ; commentaires > actions silencieuses
7. Documentez le raisonnement — Les futurs agents liront vos commentaires pour comprendre les décisions

Suivant

• Pour un aperçu de la plateforme et des outils partagés, voir /chorus
• Pour l'élaboration des Idées (avant les propositions), voir /idea
• Pour la création de Propositions (ce que vous révisez), voir /proposal
• Pour le workflow Developer (ce que vous vérifiez), voir /develop