Skill Review

Ce skill couvre l'étape de 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

L'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 :

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

Tools

Exclusifs à l'Admin :

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

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

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

Stratégie de Review

Lors de la revue de proposals, de tasks, ou du changement de code agrégé final d'une Idea, préférez spawner un sub-agent revieweur indépendant plutôt que de revue manuellement :

1. Essayez d'abord le revieweur. Spawner le sub-agent chorus-proposal-reviewer (proposal), chorus-task-reviewer (task), ou chorus-code-reviewer (la gateway finale de livraison sur le changement de code agrégé d'une Idea, après sa dernière task vérifiée — passez-lui l'ideaUuid ; il poste son VERDICT sur l'idea) via spawn_agent(agent_type=..., ...) et attendez-le avec wait_agent. Vous devez attendre le VERDICT avant de procéder. Il poste un commentaire VERDICT avec des conclusions détaillées.
2. Lisez le VERDICT. Une fois que le revieweur est terminé, 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 comme passé 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 rouvrez (tasks). Pour une FAIL de gateway code-review, ne rouvrez pas les tasks vérifiées — corrigez plutôt via le workflow quick-dev ($quick-dev) : chorus_create_tasks avec proposalUuid défini à la proposal approuvée actuelle afin que les tasks de correction s'y attachent, puis exécutez → vérifiez et re-exécutez la gateway. Corrigez les BLOCKERs spécifiques listés dans le commentaire avant de resoumettez.
3. Pas de nouveau commentaire VERDICT ? Le revieweur a épuisé son budget maxTurns avant de poster. Le respawner UNE FOIS avec un prompt explicite comme : "Stay within your turn budget. Skip deep source verification — batch all MCP fetches up front, skim for obvious BLOCKERs only, and reserve your last few turns to post the VERDICT comment." Si la deuxième tentative échoue également à poster, revoyez manuellement en utilisant les checklists ci-dessous.
4. Suivi des 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 escaladez pour une revue humaine.
5. Fallback. Si le revieweur n'est pas disponible (par exemple, type d'agent non enregistré, spawn du sub-agent échoue), revoyez l'item vous-même en utilisant les checklists de qualité dans les workflows ci-dessous.

Workflow

Étape 1 : Check In

chorus_checkin()

Prêtez attention à :

• Nombre de proposals en attente (items en attente d'approbation)
• Tasks avec le statut to_verify (travail en attente de revue)
• 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>" })

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

Workflow A : Revue de Proposal

A1 : Lire la Proposal

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

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

La vue full retourne : titre, description, idées d'entrée, document drafts (PRD, tech design), task drafts (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 réalisable et suit les conventions du projet
• [ ] Aucuns cas limites ou considérations de sécurité manquants

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 de task ont assez de contexte pour un agent développeur
• [ ] La priorité est définie correctement

Globalement :

• [ ] La proposal s'aligne avec la/les idée(s) originelle(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 : Revue Indépendante

Spawnez chorus-proposal-reviewer selon la Stratégie de Review ci-dessus via spawn_agent + wait_agent. 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 les tasks ou référencer les documents.

Quand approuvée :

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

Si la direction d'une Proposal approuvée s'avère incorrecte, 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 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 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 resoumettez.

Workflow B : Vérification de Task

B1 : Revoyez la Task Soumise

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

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

B2 : Lire les Commentaires et les Rapports de Travail

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

B2.5 : Revue Indépendante

Spawnez chorus-task-reviewer selon la Stratégie de Review ci-dessus via spawn_agent + wait_agent. Une fois qu'il est terminé, lisez son VERDICT :

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

B3 : Marquer les Critères d'Acceptation

Revoyez 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 Rouvrir

Vérifier (tous les AC requis sont 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 développeurs.

Rouvrir (nécessite des 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 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, à utiliser avec parcimonie)
chorus_admin_delete_task({ taskUuid: "<task-uuid>" })

Workflow C : Gestion de Projets et d'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 tool PM (chorus_pm_create_idea). Voir /idea.

Gestion de 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. Revoyez l'activité — chorus_get_activity() pour les événements récents
3. Traitez les proposals — Revoyez et approuvez/rejetez les proposals en attente
4. Vérifiez les tasks — Revoyez et vérifiez/rouvrez les tasks en to_verify
5. Créez de nouvelles idées — Si l'humain a de nouvelles exigences
6. Vérifiez la santé du projet — Des tasks obsolètes ? Des items bloqués ? Des idées orphelines ?

Conseils

• Revoyez soigneusement — N'approuvez pas automatiquement les proposals ; vérifiez la qualité
• Donnez des commentaires actionnables — Lors du rejet, expliquez spécifiquement ce qu'il faut 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 les tasks qui ne sont plus pertinentes
• Débloquez l'équipe — Priorisez les revues de proposal pour que le travail PM et Developer continue
• Utilisez la suppression avec parcimonie — Préférez fermer plutôt que supprimer ; fermer préserve l'historique
• Documentez les décisions — Utilisez les commentaires pour expliquer la raison de l'approbation/rejet
• Vérifiez entre les vagues — Lors de l'exécution de workers en parallèle via spawn_agent, vérifiez 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 économise une révision plus tard
2. Commentaires actionnables — Chaque rejet doit inclure des corrections spécifiques
3. Vérification basée sur les critères — Vérifiez selon 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 orphelins s'accumuler
5. Débloquez les autres — Vos revues 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 tools partagés, voir /chorus
• Pour l'élaboration d'Idea (avant les proposals), voir /idea
• Pour la création de Proposal (ce que vous revoyez), voir /proposal
• Pour le workflow Developer (ce que vous vérifiez), voir /develop