Skill Review

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

Namespace des outils : Les outils Chorus sont exposés par le serveur MCP connecté sous un préfixe mcp__chorus__ sur dsh (par exemple mcp__chorus__chorus_admin_verify_task). Les noms nus sont utilisés ci-dessous pour la lisibilité — ajoutez le préfixe mcp__chorus__ lors de l'appel. Voir chorus pour la règle complète.

Aperçu

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

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

Outils

Exclusifs à 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 chorus

Stratégie de Review

Lors de l'examen des proposals, tasks ou du changement de code agrégé final d'une Idea, obtenez un VERDICT indépendant avant d'approuver/vérifier/livrer. Sur dsh il n'y a pas de hook PostToolUse pour vous le rappeler — invoquez l'examen vous-même, en ligne.

1. Préféré — spawner un sous-agent reviewer (foreground). Utilisez l'outil dsh subagent pour spawner un sous-agent avec run_in_background: false (foreground — l'appel attend et retourne le résultat en ligne ; la décision d'approbation/vérification dépend du verdict). Sa tâche doit lui indiquer d'appeler l'outil skill avec exactement proposal-reviewer-chorus, task-reviewer-chorus, ou code-reviewer-chorus, puis examiner l'entité correspondante. Le résultat faisant autorité est le commentaire Chorus VERDICT: le plus récent. Fixez run_in_background: true (un sous-agent continuable/background dont vous collectez l'avis de règlement plus tard) uniquement quand vous voulez délibérément paralléléiser et n'avez pas besoin du verdict avant votre prochaine étape.

2. Lire le VERDICT. Après que le reviewer complète, 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é. Approuver (proposals) ou marquer AC passé et vérifier (tasks).
   • VERDICT: PASS WITH NOTES — Petites notes non bloquantes. Quand même approuver/vérifier. Les notes sont informatives.
   • VERDICT: FAIL — BLOCKERs trouvés. Rejeter (proposals) ou réouvrir (tasks). Pour un FAIL de code-review gateway, ne réouvrez pas les tasks vérifiées — corrigez plutôt via le workflow quick-dev (quick-dev-chorus) : chorus_create_tasks avec proposalUuid défini à la proposal approuvée actuelle pour que les fix tasks s'y attachent. Groupez les petits BLOCKERs connexes en une seule task cohésive par défaut ; ne split que pour les corrections matériellement grandes ou indépendamment testables. Chaque task de fix doit auto-vérifier ses critères d'acceptation et passer une review task indépendante plus une vérification admin. Re-exécutez le gateway uniquement après que chaque fix task soit avec succès done ; s'il y a une fix task échouée ou annulée, arrêtez et remontez plutôt. Corrigez les BLOCKERs spécifiques listés dans le commentaire avant de renvoyer.

3. Pas de nouveau commentaire VERDICT ? Le sous-agent a épuisé son budget de tours avant de poster. Respawnez-le UNE FOIS avec un prompt explicite comme : "Restez dans votre budget de tours. Sautez la vérification profonde des sources — groupez tous les fetches MCP à l'avance, parcourez-le pour ne trouver que les BLOCKERs évidents, et réservez vos derniers tours pour poster le commentaire VERDICT." Si la deuxième tentative échoue aussi à poster, examinez manuellement (étape 5).

4. Suivre les rounds. Comptez les commentaires VERDICT existants avant de spawner. Après 3 rounds de FAIL sur le même item, arrêtez la boucle et remontez pour une review humaine.

5. Fallback — examinez-le vous-même (pas de subagent sur l'hôte). Si le spawning n'est pas disponible (désactivé par la politique, ou le spawn échoue), effectuez l'examen vous-même comme un passage focalisé, en lecture seule en utilisant les checklists de qualité des workflows ci-dessous : lisez l'entité, ses commentaires et les documents/code pertinents, exécutez les commandes test/build en lecture seule où applicable, et NE MODIFIEZ RIEN. Enregistrez ensuite votre VERDICT via chorus_add_comment se terminant par une ligne VERDICT: (PASS / PASS WITH NOTES / FAIL), classifiant chaque finding comme BLOCKER ou NOTE. Les skills proposal-reviewer-chorus, task-reviewer-chorus, et code-reviewer-chorus sont les checklists faisant autorité pour ce passage manuel — lisez le pertinent et suivez sa procédure.

Workflow

Étape 1 : Check In

chorus_checkin()

Faites attention à :

• Nombre de proposals en attente (items en attente d'approbation)
• Tasks en statut to_verify (travail en attente de review)
• 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 en attente de 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 verifications de tasks.

Workflow A : Proposal Review

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 brouillons (uuid, type/titre, contentLength, compte AC, arêtes de dépendance) sans contenu de document ou descriptions complètes de task. Pour une review vous avez besoin des corps, donc passez section: "full" pour tout obtenir à la fois (ou section: "documents" / section: "tasks" pour lire une sorte à la fois).

La vue full retourne : titre, description, idées d'entrée, brouillons de document (PRD, tech design), brouillons de task (avec descriptions et critères d'acceptation).

A2 : Checklist de Qualité

Documents :

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

Tasks :

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

Global :

• [ ] La proposal s'aligne avec la(les) idée(s) originale(s)
• [ ] Pas de scope creep au-delà de ce qui a été demandé
• [ ] L'approche de mise en œuvre est raisonnable

A3 : Lire les Commentaires

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

A3.5 : Review Indépendante

Obtenez un VERDICT selon la Stratégie de Review ci-dessus — spawner un sous-agent via subagent avec run_in_background: false (foreground — attendez le verdict) et laissez-le appeler l'outil skill avec proposal-reviewer-chorus et le suivre, sinon examinez vous-même comme un passage en lecture seule et postez le VERDICT. Lisez son commentaire VERDICT avant de procéder.

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 tasks ou référencer des documents.

Quand approuvé :

• Les brouillons de document deviennent des Documents réels
• Les brouillons de task deviennent des Tasks réelles (status: 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 Proposals Approuvées

Si la direction d'une Proposal approuvée s'avère 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 revient sur 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 Tasks matérialisées sont fermées, tous les Documents matérialisés sont supprimés, et les AcceptanceCriteria/TaskDependencies/SessionCheckins connexes sont nettoyés. La Proposal revient au statut draft pour que le PM puisse réviser et renvoyer.

Workflow B : Task Verification

B1 : Examiner la Task 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 Work Reports

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

B2.5 : Review Indépendante

Obtenez un VERDICT selon la Stratégie de Review ci-dessus — spawner un sous-agent via subagent avec run_in_background: false (foreground — attendez le verdict) et laissez-le appeler l'outil skill avec task-reviewer-chorus et le suivre, sinon examinez vous-même comme un passage en lecture seule et postez le VERDICT. Après sa complétude, lisez son VERDICT:

• VERDICT: PASS ou PASS WITH NOTES → procédez à B3 (marquer AC) et B4 (vérifier).
• VERDICT: FAIL → passez à B4 et réouvrez la task. NE marquez PAS les AC comme passés.

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 passés) :

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

Cela déplace la task à 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 developers.

Réouvrir (a 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 task revient à 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, 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 })  # 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 : Créer des idées est un outil PM (chorus_pm_create_idea). Voir idea-chorus.

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. Examiner l'activité — chorus_get_activity() pour les événements récents
3. Traiter les proposals — Examiner et approuver/rejeter les proposals en attente
4. Vérifier les tasks — Examiner et vérifier/réouvrir les tasks en to_verify
5. Créer de nouvelles idées — Si l'humain a de nouveaux requirements
6. Vérifier la santé du projet — Tasks obsolètes ? Items bloqués ? Idées orphelines ?

Conseils

• Examiner en détail — Ne validez pas les proposals à la légère ; vérifiez la qualité
• Donner des retours actionnables — Quand rejeter, expliquez spécifiquement ce à corriger
• Vérifier par rapport aux critères — Vérifiez les critères d'acceptation, pas juste le résumé
• Gérer le scope — Fermer les idées et tasks qui ne sont plus pertinentes
• Débloquer l'équipe — Prioriser les reviews de proposal pour maintenir le flux de travail PM et Developer
• Utiliser delete avec parcimonie — Préférer fermer à supprimer ; fermer préserve l'historique
• Documenter les décisions — Utiliser les commentaires pour expliquer le raisonnement d'approbation/rejet
• Vérifier entre les vagues — En exécution de vagues séquentielles, vérifier les tasks à done entre les vagues pour débloquer les dépendances en aval

Principes de Gouvernance

1. Qualité plutôt que vitesse — Une proposal rejetée maintenant épargne le rework plus tard
2. Retours actionnables — Chaque rejet devrait inclure des corrections spécifiques
3. Vérification basée sur les critères — Vérifier par rapport aux critères d'acceptation, pas juste l'impression subjective
4. Discipline du scope — Fermer ce qui n'est plus nécessaire, ne pas laisser les items orphelines s'accumuler
5. Débloquer les autres — Vos reviews sont le goulot ; les prioriser
6. Préserver l'historique — Fermer > Supprimer ; commentaires > actions silencieuses
7. Documenter le raisonnement — Les agents futurs liront vos commentaires pour comprendre les décisions

Suivant

• Pour l'aperçu de la plateforme et les outils partagés, voir chorus
• Pour l'élaboration d'idées (avant les proposals), voir idea-chorus
• Pour la création de proposal (ce que vous examinez), voir proposal-chorus
• Pour le workflow Developer (ce que vous vérifiez), voir develop-chorus