Ein GitHub-Issues-Backlog in OrgGen importieren
Sie fügen die JSON-Ausgabe von `gh issue list` ein und OrgGen liest sie ohne Sprachmodell: gleiche Datei, gleicher Plan, jedes Mal. Die Identität eines Tickets stammt aus seiner URL, nie aus dem Titel — eine Wiederholung konvergiert, ein umbenanntes Ticket wird aktualisiert statt dupliziert.
Der vollständige Text dieses Leitfadens liegt derzeit nur auf Französisch vor. Titel und Zusammenfassung oben sind übersetzt.
La commande à lancer
OrgGen lit la sortie JSON de la CLI GitHub — gh v2.102.0 (dépôt cli/cli, lue le 2026-10-10). Lance-la dans le dépôt voulu (ou avec `--repo`) et colle le résultat tel quel — sans le retoucher, sans le résumer.
gh issue list --repo <propriétaire>/<dépôt> --state all --limit 500 \
--json number,title,body,state,stateReason,closedAt,url,labels,assignees,milestone,parent,blockedByLes champs `parent` et `blockedBy` (la hiérarchie des sous-tickets et les dépendances) n'existent dans `--json` qu'à partir de la version 2.94.0 de `gh`. Avec une version plus ancienne, le lot est importé à plat, et le plan le dit.
Ce que chaque champ devient
| Dans GitHub | Dans OrgGen |
|---|---|
| `url` | l'identité du ticket : `propriétaire/dépôt#numéro` — et le lien d'origine, affiché sur la tâche |
| `title`, `body` | le titre et le corps de la tâche (un corps trop long est tronqué avec un marqueur visible, et le plan le dit) |
| `state`, `closedAt` | ouvert → à faire ; fermé → fait, avec `closedAt` pour date d’achèvement |
| `stateReason` | un ticket fermé « not planned » est fait MAIS étiqueté `not-planned` : il ne se confond pas avec un ticket terminé |
| `labels` | les étiquettes de la tâche (20 au plus ; le plan compte celles qui dépassent) |
| `assignees` | les responsables, par leur `login` — rapprochés des personnes du projet quand ils correspondent |
| `milestone` | une étiquette `milestone:<titre>` (ce n’est pas un jalon d’OrgGen : ni échéance ni description ne passent) |
| `parent` | la tâche parente |
| `blockedBy` | les dépendances de la tâche |
Trois niveaux chez GitHub, deux dans OrgGen
Les sous-tickets de GitHub peuvent descendre sur plusieurs niveaux (Epic → Feature → tâche). OrgGen en tient deux : une tâche parente et ses sous-tâches. Un ticket de troisième niveau ou plus est donc rattaché à l'ancêtre le plus haut que le lot connaisse, et son parent direct reste lisible dans une étiquette `parent:<référence>`.
Le geste, dans l’ordre
- Tu lances la commande ci-dessus et tu colles la sortie à ton agent — le chat d'OrgGen, ou un client MCP qui envoie une clé d'API.
- L'agent appelle `import_tasks` avec `format: "github-issues-json"` et ta sortie dans `text`. Par défaut c'est un calcul : le plan est rendu (créées, mises à jour, ignorées, conflits, erreurs) sans rien écrire.
- L'agent a pour consigne de te montrer ce plan. Lis surtout les erreurs : un parent ou un bloqueur absent du lot y est nommé, avec le ticket qu'il retient.
- Rien ne s'écrit sans un second appel explicite, avec `dryRun: false` et le même lot. L'agent garde l'`importId` rendu.
- Un doute après coup : `list_imports` retrouve le lot, `rollback_import` l'annule — d'abord à blanc.
Rejouer, mettre à jour, annuler
- Rejouer ne duplique jamais : la clé de rejeu est l'URL du ticket. Relancer la commande et recoller le résultat ne crée que les tickets neufs.
- Un ticket renommé est la même tâche. Avec `onExisting: "update"`, l'import réécrit les champs fournis d'une tâche déjà importée — seulement si personne ne l'a modifiée depuis ; sinon elle sort en conflit, jamais écrasée.
- Annuler un lot supprime ce qu'il a créé et garde ce qu'un humain a modifié. Les mises à jour qu'il a faites ne sont pas restaurées.
- Une tâche terminée garde sa date d'achèvement : c'est `closedAt` de GitHub.
- Plus de 500 tickets : plusieurs appels avec le même `importId`, découpés PAR ARBRE — un ticket racine et tout ce qui en descend dans le même appel. La hiérarchie est calculée sur l'appel : un ticket de troisième niveau importé après son parent, déjà importé sous un autre, est refusé, nommé.
- Une dépendance vers un ticket d'un autre appel doit déjà être importée : sinon le ticket est refusé, nommé, et rejouer son appel une fois l'autre importé converge.
- Des tâches déjà importées par le format d'OrgGen sous une autre clé ne sont pas reconnues : leurs tickets seraient créés en double. Annule d'abord ce lot (`rollback_import`).
Ce qui ne se transporte pas
- Les commentaires des tickets (`comments`) : une tâche n’a pas de logement pour eux.
- L'auteur, les dates de création et de mise à jour, les réactions, l'épinglage et les éléments de projet GitHub : lus s'ils sont demandés, jamais importés.
- L'échéance et la description d'un milestone : seul son titre devient une étiquette.
- Les tickets enfants (`subIssues`, `subIssuesSummary`) et la relation inverse (`blocking`) : le lien se lit par le `parent` et le `blockedBy` de chaque ticket.
- Le type de ticket (`issueType`) et les pull requests liées (`closedByPullRequestsReferences`).
- Un parent ou un bloqueur retiré dans GitHub depuis un import précédent : OrgGen sait poser un lien, pas le détacher.
Le plan rend, pour la lecture en cours, la liste des clés lues et non importées (ses `notes`), et le nombre de tickets concernés par chaque transformation (fermés « not planned », rattachés, étiquettes tronquées). Une perte n'est jamais découverte après coup.
Probieren Sie es an Ihrem eigenen Fall
Beschreiben Sie Ihre Situation in einem Satz — OrgGen baut das Diagramm und rechnet.
Probieren Sie es an Ihrem eigenen Fall