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

Namespace d'outils : Les outils Chorus sont exposés par le serveur MCP connecté sous un préfixe chorus__ sur OpenClaw (par ex. chorus__chorus_admin_verify_task). Les noms simples sont utilisés ci-dessous par souci de lisibilité — préfixez avec chorus__ lors de l'invocation. Voir /chorus pour la règle complète.

Vue d'ensemble

Admin Agent a 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)
• Vérification des Tasks — vérifier ou rouvrir les Tasks 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

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, des tasks ou du changement de code agrégé final d'une Idea, obtenez un VERDICT indépendant avant d'approuver/vérifier/livrer. Sur OpenClaw, il n'y a pas de hook PostToolUse pour vous le rappeler — invoquez la review vous-même, en ligne.

1. Préféré — créez un sous-agent reviewer. Utilisez l'outil OpenClaw sessions_spawn pour créer un sous-agent dont la task lui dit d'invoquer le skill /proposal-reviewer (pour les proposals), le skill /task-reviewer (pour les tasks), ou le skill /code-reviewer (la porte de vérification finale au moment du livrage 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) — tous fournis avec ce plugin — contre l'entité. Attendez-le (interrogez l'outil subagents ou utilisez sessions_yield — ne le détachez PAS ; vous devez avoir le VERDICT avant de continuer). Le sous-agent hérite des skills du plugin, donc le skill reviewer est disponible pour lui ; il poste un commentaire VERDICT avec des résultats détaillés. Exemple de task prompt : Run the /proposal-reviewer skill to review proposalUuid <uuid>; post your VERDICT comment when done.
2. Lisez le VERDICT. Une fois que le reviewer 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 validés et vérifiez (tasks).
   • VERDICT: PASS WITH NOTES — Petites notes non bloquantes. Approuvez/vérifiez quand même. Les notes sont informatives.
   • VERDICT: FAIL — BLOCKERs trouvés. Rejetez (proposals) ou rouvrez (tasks). Pour un FAIL de passerelle de code-review, ne rouvrez pas les tasks vérifiées — à la place, corrigez via le workflow quick-dev (/quick-dev) : chorus_create_tasks avec proposalUuid défini sur la proposal approuvée actuelle pour que les tasks de correction s'y attachent, puis exécutez → vérifiez et relancez la passerelle. Corrigez les BLOCKERs spécifiques listés dans le commentaire avant de resoumettez.
3. Pas de nouveau commentaire VERDICT? Le sous-agent a épuisé son budget de tours avant de poster. Relancez-le 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 aussi à poster, revoyez manuellement (étape 5).
4. Suivi des rounds. Comptez les commentaires VERDICT existants avant de lancer. Après 3 rounds de FAIL sur le même item, arrêtez la boucle et escaladez vers une review humaine.
5. Secours — reviewez-le vous-même (pas de sessions_spawn sur l'hôte). Si le lancement est indisponible (désactivé par politique, ou le lancement échoue), effectuez la review vous-même comme un passage focalisé et en lecture seule en utilisant les checklists de qualité dans les workflows ci-dessous : lisez l'entité, ses commentaires et les documents/code pertinents, exécutez les commandes de test/build en lecture seule le cas échéant, et ne modifiez RIEN. Enregistrez alors votre VERDICT via chorus_add_comment se terminant par une ligne VERDICT: (PASS / PASS WITH NOTES / FAIL), en classifiant chaque résultat comme BLOCKER ou NOTE. Les skills /proposal-reviewer, /task-reviewer et /code-reviewer sont les checklists autoritaires 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 a besoin de 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 les vérifications de tasks.

Workflow A : Proposal Review

A1 : Lire la Proposal

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

chorus_get_proposal est par défaut section: "basic" — métadonnées de la proposal plus un index léger des brouillons (uuid, type/titre, contentLength, nombre AC, arêtes de dépendance) sans contenu de document ou descriptions complètes de tasks. Pour une review, vous avez besoin des corps, donc passez section: "full" pour obtenir tout à la fois (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, tech design), brouillons 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
• [ ] Aucun cas limite ou considération de sécurité manquants

Tasks :

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

Vue d'ensemble :

• [ ] La Proposal s'aligne avec la(les) idée(s) originale(s)
• [ ] Pas de dérive de scope 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 : Review Indépendante

Obtenez un VERDICT selon la Stratégie de Review ci-dessus — lancez un sous-agent via sessions_spawn et faites-le exécuter le skill /proposal-reviewer (attendez-le), sinon reviewez vous-même comme un passage en lecture seule et postez le VERDICT. 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 tasks ou référencer des documents.

Une fois approuvée :

• Les brouillons de documents deviennent de vrais Documents
• Les brouillons de tasks deviennent de vraies Tasks (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 des 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 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 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 revient au statut draft pour que le PM puisse réviser et resoumettez.

Workflow B : Vérification de Task

B1 : Revue de 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 Rapports de Travail

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

B2.5 : Review Indépendante

Obtenez un VERDICT selon la Stratégie de Review ci-dessus — lancez un sous-agent via sessions_spawn et faites-le exécuter le skill /task-reviewer (attendez-le), sinon reviewez vous-même comme un passage en lecture seule et postez le VERDICT. Une fois qu'il est terminé, lisez son VERDICT :

• VERDICT: PASS ou PASS WITH NOTES → allez à B3 (marquer AC) et B4 (vérifier).
• VERDICT: FAIL → allez à B4 et rouvrez la task. Ne marquez PAS AC comme validé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 validés) :

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 developers.

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

Conseils

• Reviewez à fond — Ne visez pas d'approbation automatique des proposals ; vérifiez la qualité
• Donnez des commentaires exploitables — Lors du rejet, expliquez précisément 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 tasks qui ne sont plus pertinentes
• Débloquez l'équipe — Priorité aux reviews de proposals pour maintenir le flux du travail PM et Developer
• Utilisez la suppression avec parcimonie — Préférez la fermeture à la suppression ; la fermeture préserve l'historique
• Documentez les décisions — Utilisez les commentaires pour expliquer les raisons d'approbation/rejet
• Vérifiez entre les vagues — En exécution séquentielle par vagues, 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 du travail ultérieurement
2. Commentaires exploitables — 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 seulement l'impression subjective
4. Discipline du scope — Fermez ce qui n'est plus nécessaire, ne laissez pas les items orphelins s'accumuler
5. Débloquez les autres — Vos reviews 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 /chorus
• Pour l'élaboration d'Idea (avant les proposals), voir /idea
• Pour la création de Proposal (ce que vous reviewez), voir /proposal
• Pour le workflow Developer (ce que vous vérifiez), voir /develop