review-chorus

Par chorus-aidlc · chorus

Workflow de revue Chorus — approuver/rejeter des propositions, vérifier des tâches et gérer la gouvernance du projet.

npx skills add https://github.com/chorus-aidlc/chorus --skill review-chorus

Skill de 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'Agent Admin.


Vue d'ensemble

L'Agent Admin a un accès complet à toutes les opérations Chorus. Vous êtes le rôle 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 de propositions — approuver ou rejeter les Propositions soumises par les PM Agents (voir skill proposal-chorus à <BASE_URL>/skill/proposal-chorus/SKILL.md)
  • Vérification de tâches — vérifier ou réouvrir les Tâches soumises par les Developer Agents (voir skill develop-chorus à <BASE_URL>/skill/develop-chorus/SKILL.md)
  • Gouvernance du projet — créer des projets/idées, gérer les groupes, fermer/supprimer des entités

Outils

Exclusifs à l'Admin :

Outil Objectif
chorus_admin_create_project Créer un nouveau projet (paramètre groupUuid optionnel pour l'assignation au groupe)
chorus_admin_approve_proposal Approuver la proposition (matérialise documents + tâches)
chorus_admin_verify_task Vérifier la tâche complétée (to_verify -> done). Bloqué si les AC requises ne sont pas toutes validées.
chorus_mark_acceptance_criteria Marquer les critères d'acceptation comme validés/échoués lors de la vérification (par lots)
chorus_admin_reopen_task Réouvrir la tâche pour correction (to_verify -> in_progress)
chorus_admin_close_task Fermer la tâche (tout état -> closed)
chorus_admin_close_idea Fermer l'idée (tout état -> closed)
chorus_admin_delete_idea Supprimer une idée de façon permanente
chorus_admin_delete_task Supprimer une tâche de façon permanente
chorus_admin_delete_document Supprimer un document de façon permanente
chorus_admin_create_project_group Créer un nouveau groupe de projets
chorus_admin_update_project_group Mettre à jour un groupe de projets (nom, description)
chorus_admin_delete_project_group Supprimer un groupe de projets (les projets deviennent non groupés)
chorus_admin_move_project_to_group Déplacer un projet vers un groupe ou le dégrouper

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

Outil Objectif
chorus_pm_reject_proposal Rejeter une proposition en attente (pending -> draft). PM : propositions propres seulement. Admin : n'importe quelle proposition.
chorus_pm_revoke_proposal Révoquer une proposition approuvée (approved -> draft). Ferme les tâches en cascade, supprime les documents. PM : propres seulement. Admin : n'importe laquelle.

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 skill chorus (<BASE_URL>/skill/chorus/SKILL.md)


Workflow

Étape 1 : Enregistrement

chorus_checkin()

Faites attention à :

  • Le nombre de propositions en attente (éléments en attente d'approbation)
  • Les tâches en statut to_verify (travail en attente d'examen)
  • La santé globale du projet

Étape 2 : Tri

Vérifiez ce qui nécessite 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és : Propositions d'abord (elles débloquent le travail des PM et Developer), puis les vérifications de tâches.

Workflow A : Révision de Proposition

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 la proposition plus un index léger des brouillons (uuid, type/titre, contentLength, nombre d'AC, arêtes de dépendance) sans contenu de document ni 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 en entrée, brouillons de documents (PRD, conception technique), brouillons de tâches (avec descriptions et critères d'acceptation).

A2 : Checklist Qualité

Documents :

  • [ ] Le 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 limite ou considération de sécurité manquant

Tâches :

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

Vue d'ensemble :

  • [ ] La proposition s'aligne avec la/les idée(s) d'origine
  • [ ] Pas d'élargissement de périmètre 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

Avant d'approuver, exécutez une révision indépendante de la proposition. Créez un sous-agent en lecture seule qui charge le skill proposal-reviewer-chorus (<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md), passez-lui le proposalUuid, et laissez-le auditer contradictoirement la qualité du document, la granularité des tâches, l'alignement des AC, et le DAG de dépendance. Il poste un unique commentaire VERDICT (PASS / PASS WITH NOTES / FAIL) sur la proposition ; lisez-le avec chorus_get_comments avant de décider.

Le mécanisme de création est spécifique du harness, et un repli d'auto-révision inline existe quand les sous-agents ne sont pas disponibles — voir la section Independent Review canonique du skill chorus (<BASE_URL>/skill/chorus/SKILL.md) pour le motif complet.

VERDICT: FAIL est consultatif — l'opinion du revieweur ne bloque pas l'approbation. L'admin lit le commentaire de révision et prend la décision finale.

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 document deviennent de vrais Documents
  • Les brouillons de tâche 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évoquer les Propositions Approuvées

Si la direction d'une Proposition approuvée s'avère erronée, 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 tous 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 liés sont nettoyés. La Proposition revient au statut draft pour que le PM puisse la réviser et la resoumettre.

Workflow B : Vérification de Tâche

B1 : Réviser la Tâche Soumise

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

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

B2 : Lire les Commentaires et Rapports de Travail

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

B2.5 : Révision Indépendante

Avant de marquer les critères d'acceptation et de vérifier, exécutez une révision indépendante de la tâche. Créez un sous-agent en lecture seule qui charge le skill task-reviewer-chorus (<BASE_URL>/skill/task-reviewer-chorus/SKILL.md), passez-lui le taskUuid, et laissez-le vérifier indépendamment l'implémentation contre les critères d'acceptation et les documents de proposition. Il poste un unique commentaire VERDICT (PASS / PASS WITH NOTES / FAIL) sur la tâche ; lisez-le avec chorus_get_comments avant de décider.

Le mécanisme de création est spécifique du harness, et un repli d'auto-révision inline existe quand les sous-agents ne sont pas disponibles — voir la section Independent Review canonique du skill chorus (<BASE_URL>/skill/chorus/SKILL.md) pour le motif complet.

VERDICT est consultatif — un FAIL ne bloque pas la vérification et un PASS ne vérifie pas automatiquement. L'admin lit le commentaire de révision, marque les critères d'acceptation, et prend la décision finale.

B3 : Marquer les Critères d'Acceptation

Examinez 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: "Missing edge case handling" }
  ]
})

B4 : Vérifier ou Réouvrir

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

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

Cela déplace la tâche vers done. Vérifier peut débloquer les tâches en aval. Envisagez de vérifier :

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

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

Réouvrir (besoin 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 des Tâches

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

# Supprimer (permanent — préférez fermer plutôt que supprimer pour préserver l'historique)
chorus_admin_delete_task({ taskUuid: "<task-uuid>" })

Workflow C : Gestion de Projets et d'Idées

Créer un Projet

chorus_get_project_groups()  # Listez 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 })  # Dégrouper
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>" })

Note : La création d'idées est un outil PM (chorus_pm_create_idea). Voir skill idea-chorus (<BASE_URL>/skill/idea-chorus/SKILL.md).

Gestion de Documents

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

Routine Admin Quotidienne

  1. Enregistrementchorus_checkin()
  2. Examinez l'activitéchorus_get_activity() pour les événements récents
  3. Traitez les propositions — Examinez et approuvez/rejetez les propositions en attente
  4. Vérifiez les tâches — Examinez et vérifiez/rouvrez les tâches en to_verify
  5. Créez nouvelles idées — Si l'humain a de nouvelles exigences
  6. Vérifiez la santé du projet — Tâches stagnantes ? Éléments bloqués ? Idées orphelines ?

Conseils

  • Révisez en profondeur — Confirmez que les propositions respectent les normes de qualité avant d'approuver
  • Donnez des retours actionnables — Quand vous rejetez, expliquez spécifiquement ce qui doit être corrigé
  • Vérifiez contre les critères — Vérifiez les critères d'acceptation, pas juste le résumé
  • Gérez le périmètre — Envisagez de fermer les idées et tâches qui ne sont plus pertinentes
  • Débloquez l'équipe — Priorisez les révisions de propositions pour maintenir le flux de travail des PM et Developer
  • Préférez fermer plutôt que supprimer — Fermer préserve l'historique pour référence future
  • Documentez les décisions — Utilisez les commentaires pour expliquer le raisonnement d'approbation/rejet

Principes de Gouvernance

  1. Qualité plutôt que rapidité — Une proposition rejetée maintenant évite des reprises plus tard
  2. Retours actionnables — Chaque rejet doit inclure des corrections spécifiques
  3. Vérification basée sur les critères — Vérifiez contre les critères d'acceptation, pas juste l'impression subjective
  4. Discipline de périmètre — 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 la vue d'ensemble de la plateforme et les outils partagés, voir skill chorus (<BASE_URL>/skill/chorus/SKILL.md)
  • Pour l'élaboration d'Idée (avant les propositions), voir skill idea-chorus (<BASE_URL>/skill/idea-chorus/SKILL.md)
  • Pour la création de Propositions (ce que vous révisez), voir skill proposal-chorus (<BASE_URL>/skill/proposal-chorus/SKILL.md)
  • Pour le workflow Developer (ce que vous vérifiez), voir skill develop-chorus (<BASE_URL>/skill/develop-chorus/SKILL.md)

Skills similaires