Quick Dev Skill

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

Aperçu

Le flux AI-DLC standard garantit la qualité grâce à 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 :

• Corrections de bugs avec étapes de reproduction claires
• Petites fonctionnalités (< 2 story points)
• Correctifs post-livraison et colmatage de lacunes après que les tâches d'une proposition soient terminées
• Tâches de prototype ou d'exploration
• Correctifs 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 des parties prenantes est nécessaire pour clarifier les exigences
• Le travail impacte l'architecture ou des composants partagés de manière significative

Pour le travail complexe, utilisez /idea + /proposal à la place.

Vérification pré-vol : Auto-vérification admin

Avant de créer des tâches, si chorus_checkin().agent.permissions.task inclut "admin", demandez à l'utilisateur :

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

Cela a de l'importance car les agents admin peuvent appeler chorus_admin_verify_task pour fermer la boucle autonomement. Si l'utilisateur approuve l'auto-vérification, vous pouvez compléter le cycle entier créer → développer → vérifier 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). Ce sont aussi les fondations 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. Des CA 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, correctifs d'urgence, travaux exploratoires)
• Passez-le pour attacher la tâche à une proposition existante — utile pour le colmatage de lacunes, les correctifs de suivi, ou la continuation du travail après que les tâches initiales d'une proposition soient livrées

É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 la création. Les tâches ont toujours des CA (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 CA).

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" })

Sub-agents : passez sessionUuid pour l'attribution :

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

Étape 5 : Rapporter 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érification des 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érification)

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 lors de la vérification pré-vol, vous pouvez vérifier la tâche vous-même immédiatement après la soumission :

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

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

Intégration de session (port Codex)

Les Quick Tasks supportent le même motif de session optionnel que les tâches basées sur les propositions :

• Agent unique : omettez entièrement la session — chorus_update_task / chorus_report_work fonctionnent sans sessionUuid
• Multi-agent via spawn_agent : l'agent principal appelle chorus_create_session avant de générer des workers, passe sessionUuid dans le message initial du worker, et appelle chorus_close_session après le retour du worker
• Pas encore de cycle de vie automatique — Codex supporte les hooks SubagentStart/Stop, mais ce plugin ne les a pas connectés à l'automatisation des sessions ; la gestion des sessions est la responsabilité de l'agent principal (voir la skill $develop pour le motif complet)

Conseils

• Gardez les Quick Tasks petites — si vous avez besoin de plus de 2-3 tâches, envisagez d'utiliser /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 CA spécifiques et testables permettent la vérification autonome et rendent l'ensemble du flux de travail autonome
• Utilisez chorus_update_task pour affiner les tâches (y compris les CA) après la création plutôt que de les supprimer et les recréer
• Passez proposalUuid pour attacher les tâches de suivi ou de colmatage à une proposition existante — cela garde le travail connexe regroupé 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 les propositions
• Les agents admin peuvent exécuter le cycle de vie complet autonomement (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 /develop
• Pour la vérification admin, voir /review
• Pour le flux de planification standard, voir /idea et /proposal
• Pour l'aperçu de la plateforme, voir /chorus