Chorus Quick Dev Skill

Ignorez le pipeline complet AI-DLC (Idée → Élaboration → Proposition → Approbation) et créez les 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 via des critères d'acceptation structurés.

Aperçu

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

[check admin role] → chorus_create_tasks → chorus_claim_task → in_progress → report → self-check AC → submit for verify → [self-verify if admin] → done

Utilisez Quick Dev quand :

• Correction de bugs avec étapes de reproduction claires
• Petites fonctionnalités (< 2 story points)
• Patches post-livraison et colmatage après que les tâches d'une proposition soient terminées
• Tâches de prototypage ou d'exploration
• 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 préalable
• L'élaboration avec les parties prenantes est nécessaire pour clarifier les exigences
• Le travail impacte significativement l'architecture ou les composants partagés

Pour les travaux complexes, utilisez /chorus-idea + /chorus-proposal à la place.

Pré-vol : Vérification d'auto-vérification Admin

Avant de créer les tâches, si chorus_checkin().agent.permissions.task inclut "admin", posez la question à l'utilisateur (une question interactive claire, attendez la réponse) :

« J'ai des privilèges admin. Après le développement, devrais-je vérifier la tâche moi-même, ou la laisser à un autre admin pour vérifier ? »

C'est important car les agents admin peuvent appeler chorus_admin_verify_task pour fermer la boucle autonomiquement. Si l'utilisateur approuve l'auto-vérification, vous pouvez compléter l'ensemble du cycle création → développement → vérification sans intervention humaine. Enregistrez la décision et appliquez-la à l'étape 7.

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 le lot entier si une tâche en manque). Ceux-ci sont aussi la base pour 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. Des AC vagues comme « fonctionne correctement » vont à l'encontre de 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 pour les quick tasks autonomes (corrections de bugs, hotfixes, travaux exploratoires)
• Passez pour attacher la tâche à une proposition existante — utile pour le colmatage, les patches 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 fourni non vide ; 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 le travail

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

Subagents : 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 pour vérification (ou auto-vérifier)

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

Auto-vérification admin : Si vous avez task: ["admin"] dans permissions et que l'utilisateur a approuvé l'auto-vérification dans la vérification de pré-vol, vous pouvez vérifier la tâche vous-même immédiatement après soumission :

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

Cela complète le cycle autonome complet : créer → développer → vérifier → fait.

Intégration de session

Les Quick Tasks fonctionnent avec les subagents Kiro exactement comme les tâches basées sur une proposition :

• Orchestrateur (agent principal) : créer les quick tasks, puis les dispatcher aux subagents par UUID de tâche
• Subagents : passez sessionUuid à chorus_update_task et chorus_report_work pour l'attribution
• Cycle de vie de la session sur l'agent chorus principal est automatisé par ses hooks de cycle de vie

Conseils

• Gardez les Quick Tasks petites — si vous avez besoin de plus de 2-3 tâches, envisagez d'utiliser /chorus-proposal
• Les critères d'acceptation sont obligatoires au moment de la création — chorus_create_tasks rejette les tâches qui en manquent. Ils sont votre contrat d'auto-vérification ; des AC spécifiques et testables permettent la vérification autonome et rendent l'ensemble du flux de travail auto-contenu
• 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 garde le travail associé 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 une proposition
• Les agents admin peuvent exécuter l'ensemble du cycle de vie autonomiquement (créer → développer → auto-vérifier) — mais confirmez toujours avec l'utilisateur d'abord

Suivant

• Pour les détails complets du cycle de vie des tâches, voir /chorus-develop
• Pour la vérification admin, voir /chorus-review
• Pour le flux de planification standard, voir /chorus-idea et /chorus-proposal
• Pour l'aperçu de la plateforme, voir le doc steering chorus.