Compétence Quick Dev

Ignorez le pipeline AI-DLC complet (Idée → Élaboration → Proposition → Approbation) et créez des tâches directement. Idéal pour les petits travaux bien définis. L'objectif est que les agents enregistrent autonomiquement leur travail de développement et vérifient l'achèvement des tâches à travers des critères d'acceptation structurés.

Vue d'ensemble

Le flux AI-DLC standard garantit la qualité par la planification structurée, mais ajoute une surcharge qui ralentit les petites tâches. Quick Dev offre une alternative légère :

vérifier autorisation task:admin explicite → créer/réclamer → implémenter → auto-vérification AC → soumettre → révision tâche indépendante → vérifier ou transférer

Utilisez Quick Dev quand :

• Corrections de bugs avec étapes de reproduction claires
• Petites fonctionnalités (< 2 story points)
• Correctifs post-livraison et colmatage de lacunes après achèvement des tâches d'une proposition
• Tâches de prototype ou exploratoires
• Hotfixes urgents qui ne peuvent pas attendre l'examen de la proposition

N'utilisez PAS Quick Dev quand :

• La fonctionnalité nécessite un PRD ou un document de conception technique
• Plusieurs tâches interdépendantes nécessitent une planification en amont
• Une élaboration des parties prenantes est nécessaire pour clarifier les exigences
• Le travail impacte l'architecture ou les composants partagés de manière significative

Pour les travaux complexes, utilisez les compétences idea et proposal à la place (skill_view("chorus:idea"), skill_view("chorus:proposal")).

Pré-vol : Vérification des permissions

Appelez chorus_checkin et inspectez les permissions effectives de l'agent actif. Définissez canVerifyTask à true seulement quand chorus_checkin().agent.permissions.task contient explicitement "admin" (la permission task:admin).

Ne déduisez jamais l'autorité de vérification du nom de l'agent, de la persona, du label preset/role, de la propriété de la tâche ou de la disponibilité des outils. Ne demandez pas si vous devez auto-vérifier : la permission explicite détermine le chemin terminal.

Outils

Flux de travail

Étape 1 : Créer une Quick Task

acceptanceCriteriaItems est obligatoire — chorus_create_tasks rejette toute tâche sans au moins un critère non vide (et rejette tout le lot si une tâche en manque). Ceux-ci sont aussi la base de l'auto-vérification à l'étape 6. Écrivez des critères spécifiques et testables que vous pouvez vérifier objectivement après le développement. Les AC vagues comme « fonctionne correctement » contredisent l'objectif ; préférez « retourne 200 sur GET /api/foo avec un token valide ».

chorus_create_tasks({
  projectUuid: "<project-uuid>",
  tasks: [{
    title: "Fix login redirect loop on Safari",
    description: "Safari loses session cookie after redirect...",
    priority: "high",
    storyPoints: 1,
    acceptanceCriteriaItems: [
      { description: "Login works on Safari 17+", required: true },
      { description: "Existing Chrome/Firefox behavior unchanged", required: true }
    ]
  }]
})

proposalUuid est optionnel :

• Omettez-le pour les quick tasks autonomes (corrections de bugs, hotfixes, travail exploratoire)
• Passez-le pour attacher la tâche à une proposition existante — utile pour le colmatage, les correctifs de suivi, ou la continuation du travail après la livraison des tâches initiales d'une proposition

Étape 2 : Réclamer la tâche

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

Étape 3 : Modifier les détails (si nécessaire)

Utilisez chorus_update_task pour affiner la tâche après création. Les tâches ont toujours des AC (la création les exige), mais mettez-les à jour quand votre compréhension change pendant le développement. Passer acceptanceCriteriaItems remplace les critères de la tâche par l'ensemble non vide fourni ; omettez le champ pour les laisser inchangés (il ne peut pas être utilisé pour effacer les AC).

chorus_update_task({
  taskUuid: "<task-uuid>",
  description: "Updated with more details...",
  acceptanceCriteriaItems: [
    { description: "Login works on Safari 17+", required: true },
    { description: "Added CSRF token handling", required: true }
  ],
  addDependsOn: ["<other-task-uuid>"]
})

Étape 4 : Commencer à travailler

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

Workers (enfants delegate_task créés avec une session Team-Lead) : passez sessionUuid pour l'attribution :

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

Étape 5 : Signaler la progression

chorus_report_work({
  taskUuid: "<task-uuid>",
  report: "Fixed Safari cookie issue:\n- Root cause: SameSite=Strict incompatible with redirect\n- Changed to SameSite=Lax\n- Commit: abc1234",
  sessionUuid: "<session-uuid>"
})

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

chorus_report_criteria_self_check({
  taskUuid: "<task-uuid>",
  criteria: [
    { uuid: "<ac-uuid-1>", devStatus: "passed", devEvidence: "Tested on Safari 17.2" },
    { uuid: "<ac-uuid-2>", devStatus: "passed", devEvidence: "Chrome/Firefox regression tests pass" }
  ]
})

Étape 7 : Soumettre et exécuter l'examen indépendant

chorus_submit_for_verify({
  taskUuid: "<task-uuid>",
  summary: "Fixed Safari login redirect loop. Changed SameSite cookie policy. All AC passed."
})

La soumission n'est pas une vérification finale. Le plugin Chorus Hermes ajoute un rappel au résultat de chorus_submit_for_verify ; agissez en conséquence. Créez le bundle de preuves (diff, log de commit, et sortie de test écrite dans des fichiers sous /tmp/chorus-review/<task-uuid>/ avec terminal), puis exécutez le chorus-task-reviewer requis comme un enfant delegate_task en lecture seule dont le context commence par le marqueur [chorus-reviewer:task] et passe l'UUID de tâche, le chemin du repo, le plafond de rounds (3), et les chemins de preuves. L'exemple complet est dans la compétence review (skill_view("chorus:review"), Review Strategy) et dans skill_view("chorus:develop") étape 8. delegate_task bloque jusqu'à ce que le reviewer finisse ; lisez ensuite le commentaire VERDICT: de THIS round sur la tâche — celui publié après votre dispatch, pas celui d'un ancien round. PASS et PASS WITH NOTES continuent. Sur FAIL, ne vérifiez pas et ne transférez pas : corrigez chaque BLOCKER non résolu, répétez l'auto-vérification et la soumission des AC, puis exécutez une révision de tâche indépendante nouvelle.

Étape 8 : Vérification consciente des permissions

Avec task:admin explicite, après chaque auto-vérification AC requise réussie et révision indépendante sans BLOCKER non résolu, vérifiez et continuez autonomiquement :

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

Sans task:admin explicite, n'appelez pas l'outil admin. Publiez un commentaire riche en preuves sur la tâche avec chorus_add_comment contenant les résultats AC, les preuves de test, le verdict de révision indépendante le plus récent, et l'action exacte demandée. Mentionnez @le responsable humain (préférez chorus_checkin().agent.owner, comme @[Name](user:<ownerUuid>)) pour effectuer la vérification admin, puis terminez le tour actuel.

Ce transfert s'applique dans les sessions CLI interactives et dans les sessions gateway déclenchées par Chorus. Ne posez pas de questions en chat au lieu de commenter, ne sondez pas pour la réponse humaine, et ne vous fiez pas uniquement aux notifications génériques. Quand le humain répond ou vérifie, la plateforme gateway chorus vous réveille dans la session Idea si un suivi est nécessaire.

Intégration de session

Les Quick Tasks fonctionnent avec les workers Hermes delegate_task tout comme les tâches basées sur des propositions (voir skill_view("chorus:develop"), Parallel Workers) :

• Team Lead : créer des quick tasks, créer (ou rouvrir) une session Chorus par worker avec chorus_create_session, puis exécuter les workers avec delegate_task (un enfant, ou un lot tasks=[...]). Chaque enfant a un contexte isolé, donc passez l'UUID de tâche, l'UUID de projet, le chemin du repo, l'UUID de session, et l'instruction de consulter skill_view("chorus:develop") en premier dans son context.
• Workers : checkin avec chorus_session_checkin_task, passez sessionUuid à chorus_update_task et chorus_report_work, checkout avec chorus_session_checkout_task, puis chorus_submit_for_verify
• Cycle de vie de session : delegate_task bloque jusqu'à ce que les workers finissent ; le Team Lead appelle ensuite chorus_close_session pour chaque session worker et exécute le task reviewer par tâche

Conseils

• Gardez les Quick Tasks petites — si vous avez besoin de plus de 2-3 tâches, envisagez d'utiliser la compétence proposal (skill_view("chorus:proposal"))
• Les critères d'acceptation sont obligatoires au moment de la création — chorus_create_tasks rejette les tâches sans eux. Ils sont votre contrat d'auto-vérification ; des AC spécifiques et testables permettent la vérification autonome et rendent tout le flux de travail autonome
• Utilisez chorus_update_task pour affiner les tâches (y compris les AC) après création plutôt que de les supprimer et recréer
• Passez proposalUuid pour attacher les tâches de suivi ou de colmatage à une proposition existante — cela maintient le travail connexe groupé dans le même contexte de projet et DAG
• Les Quick Tasks apparaissent dans la même liste de tâches de projet et DAG que les tâches basées sur des propositions
• Les agents avec task:admin explicite continuent autonomiquement après l'AC et la révision indépendante réussies ; tous les autres utilisent le transfert asynchrone humain riche en preuves

Suivant

• Pour les détails complets du cycle de vie des tâches, voir skill_view("chorus:develop")
• Pour la vérification admin, voir skill_view("chorus:review")
• Pour le flux de planification standard, voir skill_view("chorus:idea") et skill_view("chorus:proposal")
• Pour la vue d'ensemble de la plateforme, voir skill_view("chorus:chorus")