Développer une Skill

Cette skill couvre l'étape de Développement du workflow AI-DLC : réclamer des Tâches, effectuer le travail, signaler la progression et soumettre pour vérification.

Aperçu

Les Agents Développeurs prennent les Tâches créées par les Agents PM (via des propositions) et les transforment en code fonctionnel. Chaque tâche suit :

claim --> in_progress --> report work --> self-check AC --> submit for verify --> Admin review

Outils

Cycle de vie des tâches :

Outil	Objectif
`chorus_claim_task`	Réclamer une tâche ouverte (open -> assigned)
`chorus_release_task`	Libérer une tâche réclamée (assigned -> open)
`chorus_update_task`	Mettre à jour le statut de la tâche (in_progress / to_verify)
`chorus_submit_for_verify`	Soumettre la tâche pour vérification admin avec résumé

Signalement du travail :

Outil	Objectif
`chorus_report_work`	Signaler la progression ou la réalisation (écrit un commentaire + enregistre l'activité, avec mise à jour de statut optionnelle)

Critères d'acceptation :

Outil	Objectif
`chorus_report_criteria_self_check`	Signaler les résultats d'auto-vérification (réussi/échoué + preuve optionnelle) sur les critères d'acceptation structurés

Outils partagés (checkin, query, comment, search, notifications) : voir la skill chorus (<BASE_URL>/skill/chorus/SKILL.md)

Workflow

Étape 1 : Vérification initiale

chorus_checkin()

Vérifiez votre persona, vos assignations actuelles et les comptages de travail en attente.

Étape 2 : Trouver du travail

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

Ou vérifiez vos assignations existantes :

chorus_get_my_assignments()

Étape 3 : Réclamer une tâche

chorus_get_task({ taskUuid: "<task-uuid>" })  # Vérifiez d'abord
chorus_claim_task({ taskUuid: "<task-uuid>" })

Vérifiez : la description, les critères d'acceptation, la priorité, les story points, la proposition/les documents associés.

Étape 4 : Rassembler le contexte

Chaque tâche et proposition inclut un champ commentCount — utilisez-le pour décider quelles entités ont des discussions qui valent la peine d'être lues.

Lisez la tâche et identifiez les dépendances :
```
chorus_get_task({ taskUuid: "<task-uuid>" })
```
Portez attention à dependsOn (tâches en amont) et commentCount.
Lisez les commentaires de la tâche (contient les rapports de travail précédents, la progression, les retours) :
```
chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
```
Examinrez les tâches de dépendance en amont — votre travail s'appuie probablement sur le leur :
```
chorus_get_task({ taskUuid: "<dependency-task-uuid>" })
chorus_get_comments({ targetType: "task", targetUuid: "<dependency-task-uuid>" })
```
Recherchez : fichiers créés, contrats d'API, interfaces, compromis.
Lisez la proposition d'origine pour comprendre l'intention de conception :
```
chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "documents" })
```
(chorus_get_proposal est par défaut section: "basic" — juste les métadonnées + un index de brouillon. Passez section: "documents" pour les docs de conception, ou section: "full" pour les docs + les brouillons de tâches.)
Lisez les documents du projet (PRD, design technique, ADR) :
```
chorus_get_documents({ projectUuid: "<project-uuid>" })
```

Étape 5 : Commencer le travail

Marquez la tâche comme en cours :

chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })

Application des dépendances : Si cette tâche a des dépendances non résolues (les tâches dependsOn ne sont pas en done ou closed), l'appel sera rejeté avec des informations de blocage détaillées. Utilisez chorus_get_unblocked_tasks pour trouver les tâches sur lesquelles vous pouvez commencer maintenant.

Étape 6 : Signaler la progression

Signalez régulièrement avec chorus_report_work. Considérez l'inclusion de :

Ce qui a été réalisé
Les fichiers créés ou modifiés
Les commits et PR Git
Le statut actuel / le travail restant
Les blocages ou les questions

chorus_report_work({
  taskUuid: "<task-uuid>",
  report: "Progression :\n- Création de src/services/auth.service.ts\n- Commit : abc1234\n- Restant : tests unitaires"
})

Signalez avec mise à jour de statut à la fin :

chorus_report_work({
  taskUuid: "<task-uuid>",
  report: "Toute l'implémentation est complète :\n- Fichiers : ...\n- PR : https://github.com/org/repo/pull/42\n- Tous les tests réussissent",
  status: "to_verify"
})

Étape 7 : Auto-vérifier les critères d'acceptation

Avant de soumettre, vérifiez les critères d'acceptation structurés :

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

# Si task.acceptanceCriteriaItems n'est pas vide :
chorus_report_criteria_self_check({
  taskUuid: "<task-uuid>",
  criteria: [
    { uuid: "<criterion-uuid>", devStatus: "passed", devEvidence: "Les tests unitaires couvrent ceci" },
    { uuid: "<criterion-uuid>", devStatus: "passed", devEvidence: "Vérifié manuellement" }
  ]
})

Pour les critères obligatoires, préférez continuer à travailler jusqu'à pouvoir auto-vérifier comme passed. N'utilisez failed que pour les critères optionnels qui sont hors du périmètre.

Étape 8 : Soumettre pour vérification

chorus_submit_for_verify({
  taskUuid: "<task-uuid>",
  summary: "Fonctionnalité d'authentification implémentée :\n- Ajout des endpoints login/logout\n- Middleware JWT\n- 95% de couverture de test\n- Tous les AC auto-vérifiés (3/3 réussis)"
})

to_verify ne débloque PAS les tâches en aval — seul done (après vérification admin) le fait.

Examen indépendant : Après chorus_submit_for_verify, effectuez un examen indépendant de la tâche avant qu'elle ne soit vérifiée. Générez un sous-agent en lecture seule qui charge la skill task-reviewer-chorus (<BASE_URL>/skill/task-reviewer-chorus/SKILL.md), passez-lui le taskUuid, et laissez-le poster un seul commentaire VERDICT (PASS / PASS WITH NOTES / FAIL) sur la tâche ; puis lisez-le avec chorus_get_comments et agissez. Le verdict est consultatif (il ne bloque pas la vérification). Le mécanisme de génération est spécifique au harness, et un secours d'auto-examen en ligne existe quand les sous-agents ne sont pas disponibles — voir la section Independent Review canonique dans la skill chorus (<BASE_URL>/skill/chorus/SKILL.md) pour le pattern complet.

Étape 9 : Traiter les retours d'examen

Si réouvert (vérification échouée), tous les critères d'acceptation sont réinitialisés en attente.

Vérifiez les retours :

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

Corrigez les problèmes, signalez les corrections et soumettez à nouveau.

Étape 10 : Tâche complétée

Une fois que l'Admin a vérifié (statut : done), passez à la tâche disponible suivante (retour à l'Étape 2).

Étape 11 : Rapport d'achèvement d'idée (consultatif)

Si la tâche que vous venez d'auto-vérifier était la DERNIÈRE de son Idée (chaque Tâche dans chaque Proposition approuvée est maintenant done/closed) et vous avez document:write, invitez l'utilisateur et appelez chorus_create_report à l'acceptation. La description de l'outil porte le modèle de section. Passer au déclin.

Bonnes pratiques du rapport de travail

Bon rapport (assure la continuité) :

Flux de réinitialisation de mot de passe implémenté :

Fichiers créés/modifiés :
- src/services/auth.service.ts (nouveau)
- src/app/api/auth/reset/route.ts (nouveau)
- tests/auth/reset.test.ts (nouveau)

Git :
- Commit : a1b2c3d "feat: password reset flow"
- PR : https://github.com/org/repo/pull/15

Détails de l'implémentation :
- POST /api/auth/reset-request : envoie un email avec token
- Le token expire après 1 heure, usage unique
- Limitation de débit : 3 requêtes/heure/email
- 12 nouveaux tests, tous réussissent

Critères d'acceptation :
- [x] L'utilisateur peut demander une réinitialisation par email
- [x] Le lien de réinitialisation expire après 1 heure
- [x] La limitation de débit prévient l'abus

Mauvais rapport : Terminé.

Conseils

Lisez d'abord les commentaires de la tâche — ils contiennent les rapports de travail précédents pour la continuité
Vérifiez les dépendances en amont — lisez les tâches dependsOn et leurs commentaires pour les interfaces/API
Lisez la proposition d'origine — comprenez la logique de conception et le DAG des tâches
Utilisez commentCount — ignorez la récupération des commentaires sur les entités avec un comptage de 0
Signalez la progression fréquemment — incluez les chemins de fichiers, les commits et les PR
Écrivez des résumés de soumission détaillés — l'Admin en a besoin pour vérifier
Si bloqué, envisagez d'ajouter un commentaire et de libérer la tâche
Préférez terminer une tâche à la fois : complétez ou libérez avant de réclamer une autre

Quand libérer une tâche

Libérez si :

Vous ne pouvez pas la terminer (connaissances manquantes, blocage)
Une tâche de priorité plus élevée a besoin d'attention
Vous ne terminerez pas dans un délai raisonnable

chorus_release_task({ taskUuid: "<task-uuid>" })
chorus_add_comment({ targetType: "task", targetUuid: "<task-uuid>", content: "Libération : raison..." })

Après soumission pour vérification, un Admin examine en utilisant la skill review-chorus (<BASE_URL>/skill/review-chorus/SKILL.md)
Pour l'aperçu de la plateforme et les outils partagés, voir la skill chorus (<BASE_URL>/skill/chorus/SKILL.md)

develop-chorus