Skill de Revue Chorus

Ce skill couvre l'étape Review du workflow AI-DLC : approuver ou rejeter les Proposals, vérifier les Tasks complétées, et gérer la gouvernance globale du projet en tant qu'Admin Agent.

Vue d'ensemble

Admin Agent a un 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 :

• Revue de proposal — approuver ou rejeter les Proposals soumises par les PM Agents (voir /chorus-proposal)
• Vérification de task — vérifier ou réouvrir les Tasks soumises par les Developer Agents (voir /chorus-develop)
• Gouvernance de projet — créer des projets/idées, gérer les groupes, fermer/supprimer des entités

Outils

Exclusifs à l'Admin :

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

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

Outils partagés (checkin, query, comment, search, notifications) : voir le doc steering chorus.

Stratégie de Revue

Lors de la revue de proposals, de tasks, ou du changement de code agrégé final d'une Idea, préférez créer un sous-agent reviewer indépendant plutôt que de revue manuelle :

1. Essayez le reviewer en premier. Créez le chorus-proposal-reviewer (pour les proposals), chorus-task-reviewer (pour les tasks), ou chorus-code-reviewer (le gateway final au moment du ship sur le changement de code agrégé d'une Idea, après sa dernière task vérifiée — passez l'ideaUuid ; il poste son VERDICT sur l'idea) en tant que sous-agent lecture seule. Exécutez-le en avant-plan — vous devez attendre le VERDICT avant de continuer. Il poste un commentaire VERDICT avec les résultats détaillés.
2. Lisez le VERDICT. Après que le reviewer se termine, appelez chorus_get_comments et trouvez le commentaire le plus récent contenant VERDICT:. Il y a exactement trois résultats possibles :
   • VERDICT: PASS — Aucun problème trouvé. Approuvez (proposals) ou marquez AC réussi et vérifiez (tasks).
   • VERDICT: PASS WITH NOTES — Notes mineures non-bloquantes. Approuvez/vérifiez quand même. Les notes sont informatives.
   • VERDICT: FAIL — BLOCKERs trouvés. Rejetez (proposals) ou réouvrez (tasks). Corrigez les BLOCKERs spécifiques listés dans le commentaire avant la resoumission.
3. Pas de nouveau commentaire VERDICT? Le reviewer a épuisé son budget de tours avant de poster. Re-créez-le UNE FOIS avec un prompt explicite comme : "Restez dans votre budget de tours. Ignorez la vérification profonde des sources — regroupez tous les fetches MCP à l'avance, parcourez rapidement les BLOCKERs évidents, 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 checklists ci-dessous.
4. Suivez les rounds. Comptez les commentaires VERDICT existants avant la création. Après 3 rounds de FAIL sur le même élément, arrêtez la boucle et escaladez vers une revue humaine.
5. Fallback. Si le reviewer est indisponible (ex. : la création du sous-agent échoue), révisez l'élément vous-même en utilisant les checklists de qualité dans les workflows ci-dessous.

Workflow

Étape 1 : Check In

chorus_checkin()

Prêtez attention à :

• Le nombre de proposals en attente (éléments attendant approbation)
• Les tasks en statut to_verify (travail attendant revue)
• La santé globale du projet

Étape 2 : Triage

Vérifiez ce qui nécessite votre attention :

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

# Tasks attendant vérification
chorus_list_tasks({ projectUuid: "<project-uuid>", status: "to_verify" })

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

Priorité : Proposals d'abord (elles débloquent le travail PM et Developer), puis vérifications de tasks.

Workflow A : Revue de Proposal

A1 : Lire la Proposal

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

chorus_get_proposal par défaut à section: "basic" — métadonnées de proposal plus un index léger des drafts (uuid, type/titre, contentLength, nombre d'AC, arêtes de dépendance) sans contenu de document ou descriptions complètes de tasks. Pour une revue vous avez besoin des corps, donc passez section: "full" pour tout obtenir en une seule fois (ou section: "documents" / section: "tasks" pour lire un type à la fois).

La vue full retourne : titre, description, idées input, drafts de documents (PRD, tech design), drafts de tasks (avec descriptions et critères d'acceptation).

A2 : Checklist de Qualité

Documents :

• [ ] Le PRD décrit clairement le quoi et le pourquoi
• [ ] Les exigences sont spécifiques et testables
• [ ] Le tech design est faisable et suit les conventions du projet
• [ ] Pas de cas limites manquants ou de considérations de sécurité

Tasks :

• [ ] Les tasks couvrent toutes les exigences du PRD
• [ ] Chaque task a des critères d'acceptation clairs
• [ ] Les tasks sont de taille appropriée (1-8 story points)
• [ ] Les descriptions des tasks ont assez de contexte pour un developer agent
• [ ] La priorité est définie correctement

Général :

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

A3 : Lire les Commentaires

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

A3.5 : Revue Indépendante

Créez le chorus-proposal-reviewer selon la Stratégie de Revue ci-dessus — en avant-plan, pas en arrière-plan. Lisez son commentaire VERDICT avant de continuer.

A4 : Approuver ou Rejeter

Approuver :

chorus_admin_approve_proposal({
  proposalUuid: "<proposal-uuid>",
  reviewNote: "Approuvé. Bonne décomposition des tasks."
})

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

Quand approuvé :

• Les drafts de documents deviennent de vrais Documents
• Les drafts de tasks deviennent de vraies Tasks (statut : open)

Rejeter :

chorus_pm_reject_proposal({
  proposalUuid: "<proposal-uuid>",
  reviewNote: "PRD manquant les exigences de gestion d'erreur. Task 3 a besoin d'AC plus clairs."
})

chorus_add_comment({
  targetType: "proposal",
  targetUuid: "<proposal-uuid>",
  content: "Retours spécifiques:\n1. Ajouter les scénarios d'erreur au PRD\n2. Les AC de Task 3 devraient inclure des benchmarks de performance"
})

Workflow A2 : Révocation de Proposals Approuvées

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

chorus_pm_revoke_proposal({
  proposalUuid: "<proposal-uuid>",
  reviewNote: "Les exigences ont changé — l'approche originale n'est plus viable."
})

Effets en cascade : toutes les Tasks 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 Proposal retourne au statut draft pour que le PM puisse réviser et resoumettres.

Workflow B : Vérification de Task

B1 : Reviser la Task Soumise

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

Vérifiez : le résumé de travail du développeur, les critères d'acceptation, les résultats d'auto-contrôle.

B2 : Lire les Commentaires et Rapports de Travail

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

B2.5 : Revue Indépendante

Créez le chorus-task-reviewer selon la Stratégie de Revue ci-dessus — en avant-plan, pas en arrière-plan. Après qu'il se termine, lisez son VERDICT :

• VERDICT: PASS ou PASS WITH NOTES → continuez à B3 (marquer AC) et B4 (vérifier).
• VERDICT: FAIL → passez à B4 et réouvrez la task. Ne marquez PAS les AC comme réussis.

B2.6 : Gateway Code-Review Final (après la DERNIÈRE task d'une Idea vérifiée)

Quand la task que vous venez de vérifier est la dernière task de sa proposal enracinée dans l'idea, exécutez le gateway code-review au moment du ship avant que le code de l'Idea soit considéré comme shipé. Le hook postToolUse injecte un rappel pour créer le chorus-code-reviewer. Créez-le selon la Stratégie de Revue — en avant-plan, passant l'ideaUuid + numéro de round. Il revise le changement de code agrégé de l'Idea à travers toutes ses tasks — intégration inter-tasks, cohérence architecture/convention, sécurité, régression/performance, couverture de test au niveau feature — des dimensions qu'une single-task review ne peut pas voir — et poste un commentaire VERDICT sur l'idea.

• VERDICT: PASS / PASS WITH NOTES → la feature peut être shippée.
• VERDICT: FAIL → ne rouvrez pas les tasks vérifiées ; à la place créez de nouvelles fix tasks à la proposal approuvée via /chorus-quick-dev (chorus_create_tasks avec proposalUuid défini à la proposal approuvée actuelle afin que les fix tasks s'y attachent), exécutez → vérifiez-les, puis re-exécutez le gateway. Borné par maxCodeReviewRounds.

Avis / comportemental — le gateway ne change pas le statut stocké de l'Idea ; l'admin honore son verdict. Exécutez-le avant d'écrire n'importe quel rapport de completion d'idea (le rapport ne doit pas être écrit pendant qu'un FAIL est en cours).

B3 : Marquer les Critères d'Acceptation

Révisez et marquez 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: "Gestion des cas limites manquante" }
  ]
})

B4 : Vérifier ou Réouvrir

Vérifier (tous les AC requis réussis) :

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

Cela déplace la task vers done. Important : vérifier peut débloquer les tasks en aval. Vérifiez :

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

Si de nouvelles tasks sont débloquées, assignez-les ou notifiez les développeurs.

Réouvrir (besoins de fixes) :

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

chorus_add_comment({
  targetType: "task",
  targetUuid: "<task-uuid>",
  content: "Réouvert : Gestion d'erreur manquante pour le cas limite user-not-found."
})

La task retourne à in_progress. Tous les critères d'acceptation sont réinitialisés.

B5 : Fermer / Supprimer des Tasks

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

# Supprimer (permanent, utilisez avec prudence)
chorus_admin_delete_task({ taskUuid: "<task-uuid>" })

Workflow C : Gestion de Projet & Idea

Créer un Projet

chorus_get_project_groups()  # Lister les groupes disponibles en premier
chorus_admin_create_project({
  name: "Mon Projet",
  description: "Objectifs du projet...",
  groupUuid: "<optional-group-uuid>"
})

Gérer les Groupes de Projets

chorus_admin_create_project_group({ name: "Applications Mobiles", description: "Tous les projets mobiles" })
chorus_admin_move_project_to_group({ projectUuid: "<uuid>", groupUuid: "<uuid>" })
chorus_admin_move_project_to_group({ projectUuid: "<uuid>", groupUuid: null })  # Dégrouper
chorus_admin_delete_project_group({ groupUuid: "<uuid>" })  # Les projets deviennent non-groupés

Fermer / Supprimer des Ideas

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

Note : Créer des ideas est un outil PM (chorus_pm_create_idea). Voir /chorus-idea.

Gestion de Documents

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

Routine Admin Quotidienne

1. Check in — chorus_checkin()
2. Revoir l'activité — chorus_get_activity() pour les événements récents
3. Traiter les proposals — Reviser et approuver/rejeter les proposals en attente
4. Vérifier les tasks — Reviser et vérifier/réouvrir les tasks en to_verify
5. Créer de nouvelles ideas — Si le humain a de nouvelles exigences
6. Vérifier la santé du projet — Tasks stagnantes ? Éléments bloqués ? Ideas orphelines ?

Conseils

• Révisez en profondeur — Ne validez pas les proposals à la légère ; vérifiez la qualité
• Donnez un retour actionnable — Quand vous rejetez, expliquez spécifiquement ce qu'il faut corriger
• Vérifiez contre les critères — Vérifiez les critères d'acceptation, pas seulement le résumé
• Gérez le scope — Fermez les ideas et tasks qui ne sont plus pertinentes
• Débloquez l'équipe — Priorisez les revues de proposals pour maintenir le flux de travail PM et Developer

Principes de Gouvernance

1. Qualité plutôt que vitesse — Une proposal rejetée maintenant économise rework plus tard
2. Retour actionnable — Chaque rejet doit inclure des fixes spécifiques
3. Vérification basée sur les critères — Vérifiez contre les critères d'acceptation, pas seulement l'impression subjective
4. Discipline de scope — Fermez ce qui n'est plus nécessaire, ne laissez pas les items orphelines s'accumuler
5. Débloquez les autres — Vos revues sont le goulot ; 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 la vue d'ensemble de la plateforme et les outils partagés, voir le doc steering chorus.
• Pour l'élaboration d'Idea (avant les proposals), voir /chorus-idea
• Pour la création de Proposal (ce que vous révisez), voir /chorus-proposal
• Pour le workflow Developer (ce que vous vérifiez), voir /chorus-develop