idea

Par chorus-aidlc · chorus

Workflow d'idées Chorus — réclamez des idées, lancez des cycles d'élaboration et préparez la création de propositions.

npx skills add https://github.com/chorus-aidlc/chorus --skill idea

Compétence Idea

Cette compétence couvre l'étape Idéation du workflow AI-DLC : claiming Ideas, lancement de rounds d'élaboration structurés pour clarifier les exigences, et préparation pour la création de Proposal.


Aperçu

Les Ideas sont le point de départ du pipeline AI-DLC. Les humains (ou les agents Admin) créent des Ideas décrivant ce dont ils ont besoin. L'agent PM claim une Idea, lance l'élaboration pour clarifier les exigences, puis passe à /proposal pour créer une Proposal avec des brouillons de document et de tâches.

Cycle de vie du statut Idea (3 états stockés) :

open --> elaborating --> elaborated

Tout progrès post-élaboration (planification, construction, vérification, done) est dérivé de l'état des Proposals et Tasks liées. Aucun agent ne doit définir le statut Idea directement au-delà de l'élaboration -- toutes les transitions sont des effets secondaires du claiming, release, ou complètement de l'élaboration.


Outils

Gestion Idea :

Outil Objectif
chorus_pm_create_idea Créer une nouvelle idea dans un projet (au nom des humains). Le parentUuid optionnel dérive une child idea à partir d'une idea existante du même projet (lignée à parent unique).
chorus_edit_idea Éditer le titre, la description et/ou la lignée parent d'une idea existante. parentUuid : une autre idea du même projet pour réaffecter le parent, null pour détacher au niveau supérieur, omis pour laisser inchangé (vérification de cycle + même projet). Lignée faible à parent unique — un parent affiche un rollup en lecture seule +N derived mais ne bloque jamais le flux d'une idea. Enregistre une activité « editée » et signale la présence.
chorus_claim_idea Claim une idea ouverte (open -> elaborating)
chorus_release_idea Release une idea claimed (elaborating -> open)
chorus_move_idea Déplacer une Idea vers un Project différent. Migre en cascade l'Idea et son intégralité du sous-arbre de lignée (toutes les Ideas descendantes ; la racine déplacée est détachée de tout parent laissé en arrière), toutes les Proposals liées (n'importe quel statut), tous les Documents et Tasks matérialisés, et toutes les Activities associées atomiquement. Les Comments, TaskDependency, AcceptanceCriterion, AgentSession, SessionTaskCheckin, l'historique Notification, et les assignees Task ne sont PAS modifiés. Retourne les comptages moved: { ideas, proposals, documents, tasks, activities }. Requiert idea:write seulement — pas de vérifications au niveau du projet.

Élaboration des exigences :

Outil Objectif
chorus_pm_start_elaboration Générer un round d'élaboration (premier, suivi, ou ajouté après résolution)
chorus_pm_validate_elaboration Marquer l'ensemble de l'élaboration comme complète (requiert idea:admin ; requiert d'abord la confirmation humaine)
chorus_pm_skip_elaboration Ignorer l'élaboration pour les Ideas trivialement claires
chorus_answer_elaboration Soumettre les réponses pour un round d'élaboration (roundUuid optionnel — localise automatiquement le round actif)
chorus_get_elaboration Obtenir l'état d'élaboration complet (rounds, questions, réponses)

Outils partagés (checkin, query, comment, search, notifications) : voir /chorus


Workflow

Étape 1 : Check In

chorus_checkin()

Consultez votre persona, les assignations actuelles, et les comptages de travail en attente.

Étape 2 : Trouver du travail

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

Ou vérifier les assignations existantes :

chorus_get_my_assignments()

Étape 3 : Claim une Idea

Claiming transfère automatiquement l'Idea au statut elaborating :

chorus_claim_idea({ ideaUuid: "<idea-uuid>" })

Étape 4 : Recueillir du contexte

Avant d'élaborer, comprenez la situation complète :

  1. Lire l'idea en détail :

    chorus_get_idea({ ideaUuid: "<idea-uuid>" })
  2. Lire les documents de projet existants (pour le contexte, la pile technologique, les conventions) :

    chorus_get_documents({ projectUuid: "<project-uuid>" })
    chorus_get_document({ documentUuid: "<doc-uuid>" })
  3. Examiner les proposals passées (pour comprendre les modèles et les normes) :

    chorus_get_proposals({ projectUuid: "<project-uuid>", status: "approved" })
  4. Vérifier les tasks existantes (pour éviter la duplication) :

    chorus_list_tasks({ projectUuid: "<project-uuid>" })
  5. Lire les comments sur l'idea pour du contexte supplémentaire :

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

Étape 4.4 : Joindre des références externes

Faire de l'attachement de références externes un réflexe, pas une arrière-pensée. Lors de la collecte de contexte, vous découvrirez souvent des liens externes qui sont la preuve de cette Idea — une issue ou PR précédente, une implémentation de référence, de la documentation officielle, un article ou un blog post. Dès que vous en voyez une, attachez-la comme artefact de référence. Les références sont relues en ligne par chorus_get_idea / chorus_get_proposal / chorus_get_task, elles portent donc le « pourquoi » vers quiconque reprend la proposal ou la task ensuite.

Préférez attacher au moment de la création via le paramètre en ligne references[] sur chorus_pm_create_idea (et plus tard chorus_pm_create_proposal / chorus_create_tasks) plutôt qu'un chorus_add_reference après coup. Attacher à la création signifie que la preuve est présente dès la première lecture ; utilisez chorus_add_reference seulement quand le lien émerge après que l'entité existe déjà.

Choisissez le type qui convient au lien :

type Utiliser pour
docs Documentation officielle — framework / API / référence de bibliothèque
repo Une implémentation de référence ou un dépôt source
issue_pr Un fil issue ou pull-request — précédent, art antérieur, la PR qui livre
paper_blog Un article ou un blog post — contexte ou justification de conception

Exemple — une nouvelle Idea de localisation, attachant la PR précédente et les docs framework en ligne à la création :

chorus_pm_create_idea({
  projectUuid: "<project-uuid>",
  title: "Add Portuguese (pt) locale",
  content: "...",
  references: [
    { type: "issue_pr", url: "https://github.com/org/repo/pull/411",
      title: "PR #411 — prior locale work (precedent to mirror)" },
    { type: "docs", url: "https://next-intl.dev/docs/routing",
      title: "next-intl routing docs (locale registration)" }
  ]
})

Étape 4.5 : Mode Brainstorm (Prélude optionnel)

Si l'Idea est floue et vous auriez du mal à énumérer des questions multi-choix concrètes, proposez à l'utilisateur un prélude de brainstorm avant l'élaboration structurée. Posez une fois via AskUserQuestion (header "Brainstorm", deux options : "Already clear, run structured elaboration" et "Brainstorm first to explore directions").

  • "Already clear": Passez à l'étape 5.
  • "Brainstorm first": Invoquez la compétence /brainstorm. Consultez /brainstorm pour la cadence du dialogue et les règles de synthèse — ne les ré-implémentez PAS ici.

Quand /brainstorm revient, vous possédez la décision de cycle de vie (la compétence brainstorm la laisse intentionnellement à vous) :

  • Si les réponses du round synthétisé couvrent tout → obtenez la confirmation humaine, puis appelez chorus_pm_validate_elaboration pour résoudre l'élaboration. (La résolution nécessite idea:admin — voir l'étape 5.6 si votre clé est pm_agent-preset.)
  • Si des lacunes demeurent → appelez chorus_pm_start_elaboration à nouveau pour ouvrir un Round 2 structuré. Choisissez vous-même la profondeur — ne re-demandez PAS à l'utilisateur.

L'un ou l'autre résultat termine l'étape 4.5 ; passez l'étape 5.

Étape 5 : Élaborer sur l'Idea

Chaque Idea devrait passer par l'élaboration. Ignorer seulement quand les exigences sont complètement sans ambiguïté (par ex., correction de bug avec étapes claires). L'élaboration améliore la qualité de la Proposal et réduit les cycles de rejet.

Ideas simples (ignorer l'élaboration)

Vous pouvez ignorer l'élaboration, mais vous DEVEZ demander la permission de l'utilisateur d'abord via AskUserQuestion avant d'appeler chorus_pm_skip_elaboration. Ne l'ignorez jamais selon votre propre jugement seul.

chorus_pm_skip_elaboration({
  ideaUuid: "<idea-uuid>",
  reason: "Bug fix with clear reproduction steps"
})

Ideas standard/complexes (lancer l'élaboration)

L'élaboration est une boucle, pas une ligne droite. Les étapes 2–5 ci-dessous sont un round. Continuez à boucler vers chorus_pm_start_elaboration (un nouveau round) jusqu'à ce que chaque question ouverte soit réglée, puis résolvez une seule fois à l'étape 6. Vous rentrez dans la boucle chaque fois que :

  • les réponses à un round dérivent de nouvelles questions ou découvrent une contradiction/lacune, ou
  • à la porte de résolution (étape 5d / étape 6) l'humain soulève une nouvelle préoccupation ou correction.

Chaque nouveau round est juste un autre appel chorus_pm_start_elaboration — il n'y a pas de flag « follow-up » distinct, et vous ne résolvez pas jusqu'à ce que la boucle soit vraiment terminée. Le plafond de rounds est 10.

  1. Déterminer la profondeur en fonction de la complexité de l'idea :

    • "minimal" — 2-4 questions (petites features, améliorations mineures)
    • "standard" — 5-10 questions (features nouvelles typiques)
    • "comprehensive" — 10-15 questions (grandes features, changements architecturaux)
  2. Créer les questions d'élaboration :

    Note : N'incluez PAS une option « Other » dans vos questions. L'UI ajoute automatiquement une option libre « Other » à chaque question.

    chorus_pm_start_elaboration({
      ideaUuid: "<idea-uuid>",
      depth: "standard",
      questions: [
        {
          id: "q1",
          text: "What user roles should have access to this feature?",
          category: "functional",
          options: [
            { id: "a", label: "All users" },
            { id: "b", label: "Admin only" },
            { id: "c", label: "Role-based (configurable)" }
          ]
        }
      ]
    })
  3. Présenter les questions à l'utilisateur — DOIT utiliser AskUserQuestion. N'affichez PAS les questions en texte brut. Mappez chaque question d'élaboration à un appel AskUserQuestion (max 4 questions par appel ; groupez si nécessaire) :

    AskUserQuestion({
      questions: [
        {
          question: "Which new locales should be prioritized for V1?",
          header: "Scope",
          options: [
            { label: "Japanese only", description: "Single locale for initial release" },
            { label: "Japanese + Korean", description: "Two East Asian locales" }
          ],
          multiSelect: false
        }
      ]
    })

    Après que l'utilisateur répond, mappez ses sélections en retour aux IDs d'option et appelez chorus_answer_elaboration. Si l'utilisateur a sélectionné « Other », définissez selectedOptionId: null et customText à son entrée.

  4. Soumettre les réponses :

    chorus_answer_elaboration({
      ideaUuid: "<idea-uuid>",
      roundUuid: "<round-uuid>",
      answers: [
        { questionId: "q1", selectedOptionId: "c", customText: null },
        { questionId: "q2", selectedOptionId: null, customText: "Custom hybrid approach" }
      ]
    })

    Format de réponse :

    • Sélectionner une option : selectedOptionId: "a", customText: null
    • Sélectionner une option + ajouter une note : selectedOptionId: "a", customText: "additional context"
    • Choisir « Other » (texte libre) : selectedOptionId: null, customText: "your answer" — customText est obligatoire quand aucune option n'est sélectionnée

    roundUuid est optionnel sur chorus_answer_elaboration. Omettez-le et le service localise automatiquement le round unique actif (pending_answers) de l'Idea. Passez-le explicitement seulement quand vous devez cibler un round spécifique.

  5. Examiner les réponses et confirmer avec le propriétaire (flux @mention) :

    Après la soumission des réponses, @mention celui qui a répondu (généralement le propriétaire de l'agent) avec un résumé de votre compréhension. Cela prévient les malentendus avant que vous résolviez.

    a. Obtenir les infos du propriétaire de la réponse checkin (agent.owner) ou rechercher :

       chorus_search_mentionables({ query: "owner-name" })

    b. Postez un comment récapitulatif sur l'idea :

       chorus_add_comment({
         targetType: "idea",
         targetUuid: "<idea-uuid>",
         content: "@[Owner Name](user:owner-uuid) I've reviewed the elaboration answers. Here's my understanding:\n\n- Key requirement 1: ...\n- Key requirement 2: ...\n\nDoes this match your intent?"
       })

    c. Attendez la confirmation via comments.

    d. Basé sur la réponse — c'est la décision point de la boucle :

    • Confirmé, rien d'autre à discuter — Traiter cela comme la confirmation humaine requise pour résoudre ; passez à l'étape 6 et appelez chorus_pm_validate_elaboration.
    • L'humain soulève une nouvelle préoccupation / correction / question — Ne PAS résolvez. Bouchez en arrière : ouvrir un nouveau round avec chorus_pm_start_elaboration capturant les nouvelles questions, collectez les réponses (étapes 2–5 à nouveau), et re-confirmez. Répétez jusqu'à ce que l'humain n'ait plus de préoccupations.
    • Les réponses elles-mêmes dérivées de nouvelles questions ou une contradiction — Identique à ci-dessus : bouchez en arrière à chorus_pm_start_elaboration pour un autre round avant de résoudre.
    • Flou — Posez des questions de clarification via un autre comment, puis continuez la boucle.
  6. Résoudre l'élaboration (la porte de commit unique — seulement quand la boucle est terminée) :

    La résolution marque la phase d'élaboration entière complète — elle définit idea.elaborationStatus = "resolved" (Idea → elaborated), qui est le signal de passage qui permet à une Proposal en aval d'être soumise. C'est une action au niveau Idea (prend seulement ideaUuid, ne cible pas un round). Résolvez une seule fois, seulement après la boucle de l'étape 5d entièrement réglée — chaque question dérivée répondue et l'humain n'a pas de préoccupations restantes. Si quelque chose est toujours ouvert, revenez à chorus_pm_start_elaboration au lieu de résoudre.

    Précondition : la résolution nécessite que l'Idea ait au moins un round et que chaque round soit entièrement répondu (aucun laissé en pending_answers). Si un round a toujours des questions ouvertes, répondez-y (sinon il sera rejeté).

    ⚠️ Confirmation humaine requise. En dehors de l'automation YOLO vous DEVEZ obtenir une confirmation humaine explicite avant de résoudre. La réponse « Confirmed » à l'étape 5d ci-dessus compte comme cette confirmation. Ne résolvez jamais selon votre propre jugement seul.

    Permission (N1) : chorus_pm_validate_elaboration nécessite idea:admin. Le preset pm_agent accorde seulement idea:write, donc un agent avec preset PM ne peut pas résoudre — il doit transférer à un agent avec preset admin_agent (ou une clé API avec preset admin) pour effectuer la résolution. Si votre clé manque idea:admin, surfacez cela à l'humain et demandez le transfert plutôt que d'échouer silencieusement.

    Précondition assignee (N2) : l'acteur qui résout doit être l'assignee de l'Idea. Un examinateur humain distinct résolvant une Idea possédée par PM a donc besoin à la fois de idea:admin et d'être assigné l'Idea (claim/reassign d'abord). La permission admin seule n'est pas suffisante.

    chorus_pm_validate_elaboration({
      ideaUuid: "<idea-uuid>"
    })

    Voulez-vous un round de suivi au lieu de résoudre ? Appelez simplement chorus_pm_start_elaboration à nouveau — il n'y a pas de flag « open a round » distinct. Cela fonctionne alors qu'encore elaborating (un round de suivi normal) et, après avoir déjà résolu, comme un round ajouté (isAppended: true) qui garde l'Idea elaborated et ne bloque jamais une Proposal en vol. Le tagging de questions par-question n'existe plus.

  7. Vérifier le statut d'élaboration à tout moment :

    chorus_get_elaboration({ ideaUuid: "<idea-uuid>" })

L'élaboration comme piste d'audit : Même si l'utilisateur discute des exigences avec vous en dehors du flux d'élaboration formel, enregistrez les décisions clés comme rounds d'élaboration afin qu'elles soient persistées et visibles à l'équipe.

Catégories de question : functional, non_functional, business_context, technical_context, user_scenario, scope


Lignée Idea (dériver vs. task)

Les Ideas peuvent former une forêt à parent unique : une idea peut avoir un parent (parentUuid), établissant une lignée faible. « Faible » signifie que le parent affiche seulement un rollup en lecture seule +N derived de ses enfants directs — il ne bloque jamais ou n'altère le flux d'élaboration/proposal/task d'une idea, et un parent est toujours une idea complète de première classe (il peut avoir son propre contenu, proposals, et tasks).

Quand une nouvelle direction émerge (pendant l'élaboration, brainstorm, ou review), décidez où elle appartient :

  • Dériver une child idea (chorus_pm_create_idea avec parentUuid, ou chorus_edit_idea avec parentUuid pour réaffecter le parent d'une idea existante) quand la nouvelle direction a besoin de son propre cycle de vie d'élaboration/proposal — c'est un pass AI-DLC indépendant.
  • Ajouter une task à la proposal de l'idea actuelle quand le nouveau travail est juste comment implémenter l'idea actuelle.
  • Créer une plain top-level idea (pas de parentUuid) quand il n'y a pas de lignée à l'idea actuelle.

C'est une heuristique douce, pas une règle — utilisez le jugement. La prévention de cycle est automatique : vous ne pouvez pas définir un parent qui est l'idea elle-même ou un de ses descendants. Le parent et l'enfant doivent être dans le même projet (la lignée inter-projets n'est pas encore supportée). Supprimer un parent réaffecte ses enfants au niveau supérieur (cela ne cascade jamais).

Ideas thème

Un thème est une idea qui seulement groupe les enfants associés sous une direction partagée — ce n'est pas un livrable en soi. Définissez isContainer: true sur chorus_pm_create_idea / chorus_edit_idea (ou le toggle du panneau de détail) pour en faire un ; c'est librement réversible. La seule règle qui compte : un thème ne peut pas créer une proposal — pour livrer sa direction, dérivez une child idea (parentUuid = <theme>) et écrivez la proposal sur l'enfant. Un thème peut toujours élaborer (son élaboration est du contexte partagé pour les enfants), et son statut/progrès se cumule à partir de ses enfants. Tout le reste est auto-documenté sur les paramètres de l'outil.

Décomposition de thème (assistée par daemon)

Quand un thème est créé via l'entrée conversationnelle « help me break this into child ideas », ne créez pas les enfants immédiatement — proposez puis créez : (1) modifier le thème + optionnellement un short scope-elaboration round ; (2) proposer les enfants candidats comme un round d'élaboration (chorus_pm_start_elaboration), une question single-select par candidat, pour que l'utilisateur accepte/décline dans le panneau ; (3) sur le re-wake de réponse, créez chaque enfant accepté avec chorus_pm_create_idea (parentUuid = <theme>, laissé en open).


Conseils

  • Quand vous combinez plusieurs ideas, expliquez comment elles se rapportent dans la description de la proposal
  • L'élaboration améliore la qualité de la Proposal — ne la sautez pas à moins que les exigences soient trivialement claires
  • Utilisez AskUserQuestion pour toutes les questions interactives — jamais du texte brut
  • Enregistrez les décisions prises en conversation comme rounds d'élaboration pour l'auditabilité
  • Toujours @mention le propriétaire pour confirmer la compréhension avant de résoudre

Suivant

  • Une fois l'élaboration résolue, utilisez /proposal pour créer une Proposal avec des brouillons de document et de tâches
  • Transfert humain « Verify Elaborate »: quand un humain clique sur Verify Elaborate sur le panneau de détail de l'idea, Chorus résout l'élaboration et réveille l'agent daemon assigné à l'Idea pour écrire la proposal — donc l'agent réveillé reprend ce transfert idea→proposal automatiquement (pas de proposal écrite par humain nécessaire).
  • Transfert humain « Start Development »: une fois la proposal approuvée et les tasks inachevées restantes, le panneau de détail de l'idea affiche un bouton Start Development (activé tandis que l'agent assignee est en ligne). Un wake start_development signifie : claim et exécutez TOUTES les tasks restantes inachevées de la proposal approuvée de l'idea dans l'ordre de dépendance jusqu'à ce qu'aucune ne soit claimable — pas juste une task.
  • Transfert humain « Yolo »: le panneau de détail de l'idea affiche aussi un bouton Yolo à TOUTE étape incomplète (activé tandis que l'agent assignee est en ligne), confirmé via une boîte de dialogue avant qu'il se lance. Un wake yolo_requested signifie : conduisez l'ENTIÈRE idea to done via la compétence yolo (le pipeline AI-DLC automatique complet) — lire d'abord l'état actuel de l'idea et reprendre à partir de quelle que soit la phase dans laquelle elle est (auto-elaborate + écrivez la proposal si pas encore résolue ; exécutez si une proposal est approuvée avec des tasks ouvertes ; etc.), sans jamais supposer une étape fixe. Complétez jusqu'à done + le rapport de complètion, mais ne mergez jamais ni ne poussez une PR sans approbation humaine explicite.
  • Pour l'aperçu de plateforme et les outils partagés, voir /chorus

Skills similaires