meeting-report

会議レポート

Microsoft Teams の .vtt 文字起こしから、構造化されたフランス語の会議レポートを生成します。必要に応じて、Teams の .csv 出席レポートの情報も加えられます。

このスキルはあらゆるプロジェクトで動作します。hexagone-monorepoプロジェクトを自動検出し、検出された場合はプロジェクト固有のルール（サブドメイン分類、サブフォルダーへの振り分け、foundation の日付のみの命名規則）を適用します。それ以外のプロジェクトでは、汎用の単一フォルダー出力に切り替わります。

レポートの作成後、レポートをもとにしたフォローアップ用の GitLab/GitHub イシューを任意で提案できます（ステップ 12）。

前提条件

ステップ 1～11 では、外部ツールは必要ありません。**ステップ 12（任意のイシュー作成）**では、Git プラットフォームの CLI を使用します。これらは任意の依存関係であり、CLI がインストールされていない場合や認証されていない場合は、ステップ 12 をスキップするだけで、レポートには影響しません。

• gh（GitHub CLI）— レポートから GitHub イシューを作成する場合にのみ必要です。インストール先：https://cli.github.com
• glab（GitLab CLI）— レポートから GitLab イシューを作成する場合にのみ必要です。インストール先：https://gitlab.com/gitlab-org/cli

このスキルを使うタイミング

ユーザーが次の操作をした場合に有効化します。

• プロンプトに Teams の .vtt ファイルへのパスを添付する
• 「この Teams の文字起こしから会議レポートを作成して」と言う
• 「この会議のレポートを生成して」と言う
• 「この文字起こしをレポートに変換して」と言う
• Teams の出席を記録した .csv ファイルも添付する（任意）

入力

このスキルでは、ユーザープロンプトに1 つまたは 2 つのファイルパスを添付する必要があります。

• 必須： .vtt ファイル — WebVTT 形式の Teams 会議文字起こし
• 任意： .csv ファイル — Teams 出席レポート

検出方法：ユーザープロンプト内のファイル拡張子を確認します。両方ある場合、.vtt が文字起こし、.csv が出席レポートです。ファイルが 1 つだけの場合は、.vtt である必要があります。

プロジェクトモードの検出

処理を始める前に、現在の作業ディレクトリがhexagone-monorepoプロジェクトかどうかを判定します。この判定によって、以降のワークフローでの振り分け方法が決まります。

次の確認を行います（いずれか 1 つに該当すれば、hexagone-monorepo モードになります）。

1. フォルダ構成 — docs/reports/foundation/ と docs/reports/interoperability/ の両方が存在する
2. Git リモート — git remote -v に hexagone-monorepo が含まれている
3. パッケージ名 — ルートの package.json に、hexagone-monorepo を含む name が指定されている

どれにも該当しない場合 → 汎用モードです。

ユーザーは次のように明示的に上書きすることもできます。

• 「mode générique」／「generic mode」→ 汎用モードを強制
• 「mode hexagone」→ hexagone-monorepo モードを強制（フォルダ構成が存在する場合のみ有効）

レポートを作成する前に、検出したモードを短い一文でユーザーに伝えます（例：「検出したモード：hexagone-monorepo。」または「検出したモード：汎用モード。」）。

ワークフロー

ステップ 1：ファイルの場所を特定して読み込む

1. ユーザープロンプトからファイルパスを解析します（.vtt と .csv の拡張子を探します）
2. Read を使って各ファイルが存在することを確認します
3. .vtt が見つからない場合 → 中断し、ユーザーに .vtt の提供を求めます
4. .vtt の内容をすべて読み込みます
5. .csv が提供されている場合は、その内容を読み込みます

ステップ 2：文字起こしを解析する

Teams の .vtt ファイルの構造：

WEBVTT

NOTE
Meeting metadata may appear here (date, title, organizer)

00:00:01.000 --> 00:00:04.000
<v Speaker Name>Speech content</v>

00:00:05.000 --> 00:00:08.000
Anonymous speech without voice tag

以下を抽出します。

1. 会議の日付 — 次の順に試します。
   • (a) 日付形式（ISO YYYY-MM-DD またはフランス語形式 DD/MM/YYYY）を含む NOTE ヘッダーの内容
   • (b) ファイル名の日付形式（例：20260410_...vtt → 2026-04-10）
   • (c) フォールバックとして今日の日付
2. 話者 — <v Speaker Name>...</v> の音声タグを解析します（存在しない場合もあります）
3. 内容ブロック — タイムスタンプ付きの各セグメントが、話者の発話ターンです

ステップ 3：参加者を特定する

優先順位：

1. .csv形式の出席レポートが提供されている場合 → 解析して、Name列を抽出します。Teams の出席 CSV には通常、Name、First Join、Last Leave、Duration、Role、Emailなどの列が含まれています。## Participantsセクションには名前のみを使用します。

2. それ以外で、.vttに<v>音声タグがある場合 → 重複のない話者名を抽出します。

3. それ以外の場合 → 停止して、続行する前にユーザーに確認します：

   « La transcription est anonyme et aucun fichier de présence n'est fourni. Peux-tu me donner la liste des participants ? »

ステップ 4：サブドメインを分類する（hexagone-monorepo モードのみ）

汎用モードではこのステップをスキップします。 汎用モードではドメイン分類は行われません。レポートは単一の出力フォルダーに保存されます（ステップ 10 を参照）。

hexagone-monorepo モードでは、以下の表を使用して、文字起こしの内容からドメインを示す情報を分析します（大文字と小文字を区別しないキーワード照合）。

フォルダー	該当する語句（フランス語／技術キーワード）
foundation/	sprint、rétro、rétrospective、point équipe、stand-up、daily、foundation、équipe foundation
core/	architecture transversale、cross-domain、LDAP、S3A、S3A settings、permissions utilisateur、rôles、authentification
interoperability/	Hexaflux、interopérabilité、interop、HL7、HL7 v2、HL7 v2.5、FHIR、IHE、PAM、ADT、segment、PID、PV1、PV2、NK1、OBX、EVN、MSH、HPK、flux、intégration、message、mapping、broker、Mirth、Rhapsody
gap/	admission、patient、venue、séjour、dossier patient、pré-admission、AMO、AMC、débiteur、couverture sociale、facturation、valorisation、portail patient、ROC、serveur d'actes、actes、urgences、Diapason
grh/	RH、ressources humaines、employé、salarié、contrat、paie、MyRHConnect、RH Dossier
gef/	pharmacie、M21、contentieux、emprunts、trésorerie、HA GHT、immobilisations、achats、fournisseurs、comptabilité générale、Hélios、export comptable
ui-ux/	design、maquette、Figma、atelier UX、atelier UI、wireframe、écran、prototype、UX/UI

分類ルール：

分類はチームの組織上の所属ではなく、プロジェクト／ドメインに基づいて行います。 Hexaflux チームは組織上 Foundation チームの一部ですが、Hexaflux プロジェクト（ドメイン＝interoperability）に専従しているため、定例会議の保存先はfoundation/ではなくinteroperability/です。一般的な Foundation のスタンドアップのルールを適用する前に、必ずプロジェクト固有の語句を確認してください。

1. 会議がHexaflux チームの定例会議（「Hexaflux」への言及、または HL7／相互運用の範囲に関する週次会議、スタンドアップ、レトロ）である場合 → interoperability/
2. それ以外で、会議が横断的なプラットフォームに取り組むFoundation チームの定例会議（sprint、rétro、daily、point équipe、stand-up。プロジェクト固有の範囲に関するものは除く）である場合 → foundation/
3. Interoperability と GAP の判別。 HL7 メッセージには患者データ（PID、PV1、NK1 など）が含まれるため、GAP のキーワード（patient、admission、séjour、venue）が自然に現れます。HL7／相互運用の語句と GAP の語句が併せて現れる場合、会議の主題は患者業務ではなく統合です → interoperability/に分類します。技術的な HL7／メッセージ層を伴わず、機能／業務面（UI、portail patient、facturation、workflow métier admission）に関する議論の場合に限り、gap/に分類します。
4. それ以外の場合は、ドメインフォルダーごとにキーワードの一致数を数え、一致数が最も多いフォルダー（主要なドメイン）を選びます。
5. 同数の場合は、該当する語句が文字起こし内で最初に登場したフォルダーを優先します。
6. 一致する語句がない場合 → 対象フォルダーをユーザーに確認します。

ステップ 5：会議のタイトルとスラッグを抽出する

1. 議事録の冒頭を読み、明示的な議題への言及を確認します（挨拶で会議のタイトルに触れることがよくあります）。
2. フランス語の会議タイトルを簡潔に推定します（例：Atelier UX/UI Recherche Patient）。
3. タイトルからケバブケースのスラッグを生成します。
   • 小文字の ASCII のみを使用します（アクセント記号を削除）。
   • スペースと句読点を - に置き換えます。
   • 最大約 60 文字です。
   • 例：atelier-ux-ui-recherche-patient

ステップ 6：トピックごとに内容を書き直す

スタイル： 大幅に書き直し、トピックごとにまとめます。時系列順にはせず、逐語的にも書きません。

1. 話し合われた主なトピックを特定します。話者の発言を主題ごとにまとめます（話者順ではなく、トピックを検出します）。
2. 各トピックについて、次の内容を抽出します。
   • 決定事項 — 実際に決定された内容（必ず ### Décisions サブセクションを設けます）。
   • 要注意事項 — あいまいな点、未解決の項目（任意で ### Point d'attention サブセクションを設けます）。
   • 特定された問題 — 阻害要因、技術的な問題、不足している依存関係（任意で ### Problèmes identifiés サブセクションを設けます）。
3. プロフェッショナルなフランス語で記述します。
   • 「nous」または非人称の表現を使います。
   • 欠落しているアクセント記号をすべて徹底的に補います。Teams のフランス語の文字起こしは、アクセント記号や句読点に誤りが多いことで知られています。
   • フィラー語を削除します。「euh」「du coup」「en fait」、繰り返し、言いよどみなどを取り除きます。
   • 決定事項の箇条書きでは、重要な用語を **太字** で強調します。
4. 全体の目標文字数：800～1500 語
5. セクションに番号を付けます。## 1. <トピック>、## 2. <トピック> など。
6. 話者の発言を逐語的に引用しないでください。 出力は統合したレポートであり、議事録ではありません。

ステップ 7：Mermaid 図を追加するか判断する

内容の可視化に明確な利点がある場合にのみ、Mermaid 図を追加します。適している例：

• 複数の手順からなるワークフロー（例：請求の 6／8／7 ステップのプロセス）
• 分岐が明確な判断ツリー
• 複数の関係者間の一連のイベント（例：入院 → 滞在 → 請求）
• システム間のデータフロー

以下の図の種類を推奨します。

• プロセスや判断には flowchart LR または flowchart TD
• 関係者間のやり取りには sequenceDiagram
• プロジェクトの段階には timeline

図はレポートの先頭ではなく、関連するトピックのセクション内に配置します。

デフォルトでは図を追加しません。 判断に迷った場合は、省略します。図のないレポートが標準であり、例外ではありません。

ステップ 8：レポートを作成する

次のテンプレートをそのまま使用します。

# Compte-rendu — <Type de réunion> <Sujet>

**Date :** DD/MM/YYYY
**Organisateur :** <Nom> (<Rôle>)

## Participants

<Nom1>, <Nom2>, <Nom3>, ...

---

## 1. <Topic 1>

### Décisions

- **<Key term>** : <decision>
- ...

### Point d'attention

<Optional paragraph — only when there is an ambiguity or unresolved item>

### Problèmes identifiés

- <Optional bullet list — only when problems were raised>

---

## 2. <Topic 2>

### Décisions

- ...

---

<...as many topics as needed...>

ルール：

• YAML フロントマターは使用しません。
• 本文の日付はフランス語形式の DD/MM/YYYY にします（ISO 形式はファイル名のみ）。
• 参加者は、役職を含めない、カンマ区切りの 1 行にします。表にはしません。
• 主催者：文字起こし／CSV から特定できる場合は、**Organisateur :** 氏名（役割） と記載します。特定できない場合は、**Organisateur :** À préciser と記載します。
• トピック間の区切りには --- の水平線を使用します。

ステップ 9：ファイル名を決定する

hexagone-monorepo モード：

• Foundation チームの会議（foundation/ フォルダー）→ YYYY-MM-DD.md（日付のみ。1 日につき定例チーム会議は最大 1 件）。
• その他のフォルダー → YYYY-MM-DD-<slug>.md

汎用モード：

• 常に YYYY-MM-DD-<slug>.md

ファイル名には ISO 日付形式の YYYY-MM-DD を使用します。これは、レポート本文で使用するフランス語形式の DD/MM/YYYY とは異なります。

ステップ 10：出力フォルダーを特定してファイルを書き込む

hexagone-monorepo モード：

1. 出力先パス：docs/reports/<sub-domain>/<filename>.md
2. サブドメインのフォルダーが存在することを確認します（ls docs/reports/<sub-domain>/）。存在しない場合は作成します。

汎用モード：

1. 次の中から、最初に見つかった既存のフォルダーを選びます。
   • docs/reports/
   • docs/meetings/
   • meetings/
   • reports/
2. どのフォルダーも存在しない場合は、docs/reports/ を作成して使用します。
3. 出力先パス：<chosen-folder>/<filename>.md

両方のモードに共通：

1. 同じ名前のファイルがすでに存在するか確認します。存在する場合は、上書きせず、書き込み前に -2、-3 などを追加します。
2. Write ツールを使ってファイルを書き込みます。

ステップ 10b：HTML レポートを生成する（任意）

Markdown を書き込んだ後、HTML 生成が有効になっているか確認します。.meeting-reports.json に htmlGeneration:true があるか、package.json に meetingReports.htmlGeneration があるかを確認します。見つからない場合は、何も表示せずにスキップします。

有効になっている場合は、レスポンシブデザイン、ダーク／ライト切り替え、テーマ設定用の CSS 変数、Web セーフフォント、CSS ベースの図、セクションごとの色分けを備えたモダンな HTML を生成します。.html 拡張子で書き込み、同じ衝突処理を行います。生成に失敗した場合は警告を記録して続行します。

ステップ 11：ユーザーに報告する

簡潔な要約を表示します。

1. ✓ モード：hexagone-monorepo または generic
2. ✓ 保存先のパス 3a. ✓ HTML レポート：生成済み（有効な場合）、スキップ（無効な場合）、または失敗（警告付き）
3. 1 行の要約：（hexagone モードではサブドメイン）、トピック数、参加者数
4. 発生したフォールバックを記載します（出席者 CSV なし、音声タグなし、日付が見つからなかったため今日の日付を使用、デフォルトフォルダーを作成した、など）。
5. git add、git commit、git push は実行しないでください。ユーザーがレポートを確認した後、手動でコミットします。

その後、ステップ 12 に進みます。

ステップ 12：フォローアップ Issue を提案する（任意）

レポートを書き込み、報告した後、必要に応じてレポートからフォローアップの GitLab／GitHub Issue の作成を提案します。このステップによってレポートが妨げられたり、遅れたり、変更されたりしてはなりません。ステップ 11 のレポートはすでに提供済みです。これは両方のモード（generic と hexagone-monorepo）で実行されます。

ステップ 12a：事前確認（サイレントゲート）

次のチェックを実行します。いずれか 1 つでも失敗した場合は、理由を示す短い行を 1 行だけ表示して終了します。プロンプトは表示しないでください。

1. 対話コンテキスト — スキルが非対話形式またはバッチで実行されている場合はスキップします。
2. 単一プラットフォーム — 現在のディレクトリで git remote -v を実行し、対象プラットフォームが 1 つだけであることを確認します。GitHub リモート（github.com）または GitLab リモートのいずれかです。リモートがない場合、または両方のプラットフォームがある場合はスキップします。
3. CLI の準備完了 — 対応する CLI がインストールされ、認証済みである必要があります。GitHub の場合は gh auth status、GitLab の場合は glab auth status を確認します。未インストールまたは未認証の場合はスキップします。
4. 品質基準を満たす候補 — ステップ 12b を通過する品質基準を満たす候補が 1 つ以上必要です。0 件の場合はスキップします。

スキップメッセージ（1 行、フランス語）の例：「提案する Issue はありません：git リモートが検出されませんでした。」／「提案する Issue はありません：glab が認証されていません。」／「提案する Issue はありません：レポートに実行可能な決定がありません。」

ステップ 12b：Issue 候補を抽出する

書き込んだばかりのレポート（生のトランスクリプトではありません）から、実行可能なフォローアップ項目を抽出します。

• 主な情報源： ### Problèmes identifiés と ### Point d'attention の箇条書き。
• ### Décisions の箇条書きは、決定がフォローアップ作業を伴う場合にのみ対象とします（例：「X を移行することにした」→ 移行が候補です）。確定した事実は Issue にしません。
• 品質フィルター — 単なる情報提供、先送り（「また後で話し合う」）、または実行可能な動詞を含まない項目は除外します。曖昧な候補を多数挙げるより、明確な候補を少数選びます。
• 各候補について、以下を作成します。
  • タイトル — 箇条書きをそのまま転記せず、フランス語の命令形に書き換えます。約 80 文字以内とし、制御文字と余分な改行を取り除きます。
  • 推奨タイプ — Problèmes identifiés → bug、Point d'attention／Décisions → task
• 上位 4 件まで（AskUserQuestion の選択肢上限）。品質フィルターを通過する候補がそれ以上ある場合は、最も有力な 4 件を残し、残りは再実行時に作成できることをユーザーに伝えます。

ステップ 12c：提示して選択する

multiSelect: true を指定して 単一の AskUserQuestion を使用します。

• 質問のヘッダーに、正確な対象を明記します：「Issue は <owner/repo>（<host>）に作成されます。どれを作成しますか？」これは選択と対象の確認を兼ねます。
• 候補ごとに 1 つの選択肢を用意します。ラベルにはタイトル、説明には情報源のセクション、トピック、推奨タイプを記載します。
• ユーザーは 0 件以上を選択できます。何も選択されない場合、またはプロンプトが閉じられた場合は、何も作成せず、完了したことを報告します。

ステップ 12d：選択した課題を作成する

選択した候補ごとに、プラットフォームの CLI を直接実行してください。gitlab-issue／github-issues スキル経由にはしないでください（これらは対話型コンソールであり、すでにここで解決した内容をすべて再度質問するためです）。

1. 最初に重複を検索します： gh issue list --search "<title>"／glab issue list --search "<title>"。ほぼ同一の未解決課題がある場合は提示し、その候補を作成するかスキップするか、ユーザーに確認してください。
2. 作成します：
   • GitHub：gh issue create --title "<title>" --body "<body>"
   • GitLab：glab issue create --title "<title>" --description "<body>"
3. 本文 = 項目のフランス語による 2～3 行の要約 + レポートファイルへの相対リンク。生の文字起こしの抜粋や患者を特定できる内容を本文に貼り付けてはいけません。詳細はローカルのレポートに記載します。
4. ラベル — 明確に適合する既存のプロジェクトラベル（例：bug）がある場合に限り適用します。新しいラベルは作成しません。適合するラベルがない場合は省略します。
5. 常に検出されたホスト／プロジェクトを使用してください。ハードコードされたデフォルトは使用しないでください。

ステップ 12e：結果を報告する

課題ごとの結果を表示します。作成した課題の URL と、失敗した場合は候補のタイトルとエラーを示します。失敗した項目や表示しなかった項目について、再実行するかユーザーに確認してください。

ステップ 12 の注意事項：

• このステップではネットワーク上の副作用（課題の作成）が発生しますが、git 操作は行いません。コミットもプッシュもしません。
• v1 では実行間の状態を保持しません。同じ文字起こしに対してスキルを再実行すると、同じ候補が再び提案されます。デフォルトで何も選択されないことと、作成前に重複を検索することが安全策です。

重要な注意事項

• デフォルトではプロジェクトに依存しません。 サブドメインの分類と docs/reports/<sub-domain>/ への振り分けは、hexagone-monorepo プロジェクトが検出された場合にのみ適用されます。
• マスキングや仮名化は行いません。 チーム会議は内部向けで、信頼できるものとみなします。レポートには名前や内容がそのまま記載される場合があります。
• git のコミットやプッシュは行いません。 スキルはレポートファイルを書き込みます。ユーザーが手動でコミットし、プッシュします。ステップ 12 では GitLab／GitHub の課題を作成する場合があります。これはオプトインで、制御されたネットワーク上の副作用ですが、git add、git commit、git push は実行しません。
• 課題の作成はオプトインで、制御され、範囲が限定されています。 ステップ 12 ではレポートに基づく簡易なフォローアップ課題を提案しますが、自動作成はしません（デフォルトでは何も選択されません）。詳細な調査を伴う、単一のバグに関する課題は、ここではなく triage-issue スキルで扱います。
• 大幅に書き直してください。書き起こしてはいけません。 出力はテーマ別の要約であり、時系列の議事録ではありません。
• フランス語のアクセント記号は徹底して修正してください。 チームの .vtt 形式のフランス語文字起こしでは、アクセント記号や句読点が頻繁に抜けています。
• 日付のみを使った Foundation の命名規則は、hexagone-monorepo モードでのみ適用されます。 汎用モードでは常に YYYY-MM-DD-<slug>.md を使用します。
• Mermaid は任意で、使用頻度は低く、有用な場合に限ります。 デフォルトでは図を作成しません。
• 参加者を特定する際のフォールバック順序： まず .csv、次に <v> の音声タグ、最後にユーザーに質問します。名前を捏造してはいけません。
• 既存のレポートを上書きしてはいけません。 同名のファイルがすでに存在する場合は、数値のサフィックスを追加してください。

例

例 1：汎用プロジェクト、通常の会議

User: crée un compte-rendu de cette transcription Teams /tmp/kickoff.vtt

→ Detection: no docs/reports/foundation/ found → generic mode
→ Skill reads the .vtt
→ Parses <v> voice tags → 5 speakers
→ Extracts date 2026-04-22
→ Picks docs/reports/ (exists) as output folder
→ Writes docs/reports/2026-04-22-kickoff-projet.md
→ Reports: « Mode détecté : générique. »

例 2：汎用プロジェクト、docs/reports フォルダーがまだない場合

User: génère le compte-rendu /tmp/atelier.vtt /tmp/attendees.csv

→ Detection: generic mode
→ No docs/reports/, no docs/meetings/, no meetings/, no reports/ → creates docs/reports/
→ Writes docs/reports/2026-04-15-atelier-architecture.md
→ Reports: « Mode détecté : générique. Dossier docs/reports/ créé. »

例 3（hexagone-monorepo）：出席者 CSV がある UX/UI ワークショップ

User: crée un compte-rendu de cette transcription Teams /tmp/atelier_recherche_patient.vtt /tmp/attendees.csv

→ Detection: docs/reports/foundation/ + interoperability/ exist → hexagone-monorepo mode
→ Skill reads both files
→ Extracts date from .vtt NOTE header: 2026-03-18
→ Participants from .csv: Chloé Julenon, Richard Gill, Adrien Marcos, Myriam Fatoux, Damien Battistella
→ Detects ui-ux signals (atelier, écran, maquette, recherche patient)
→ Classifies as ui-ux/
→ Writes docs/reports/ui-ux/2026-03-18-atelier-recherche-patient.md

例 4（hexagone-monorepo）：Foundation チームのスプリントレビュー、CSV なし

User: génère le compte-rendu de cette réunion /tmp/sprint_review.vtt

→ Detection: hexagone-monorepo mode
→ Parses <v Speaker> voice tags → extracts 4 speakers
→ Extracts date from NOTE header: 2026-04-10
→ Detects foundation signals (sprint, rétro, point équipe)
→ Classifies as foundation/
→ Uses date-only naming
→ Writes docs/reports/foundation/2026-04-10.md

例 5：CSV のない匿名の文字起こし（すべてのモード）

User: transforme cette transcription en rapport /tmp/meeting.vtt

→ No <v> tags found
→ No .csv provided
→ Stops and asks: « La transcription est anonyme et aucun fichier de présence n'est fourni. Peux-tu me donner la liste des participants ? »
→ Waits for the user, then continues with the provided names

例 6（hexagone-monorepo）：Hexaflux の週次会議 — HL7 に関する議論、GAP ではない

User: crée un compte-rendu /tmp/hexaflux_weekly.vtt

→ Detection: hexagone-monorepo mode
→ Detects HL7 / ADT / PID / PV1 / NK1 / OBX / segment / mapping signals
→ Patient and admission keywords are present BUT tied to HL7 message segments, not business workflows
→ Applies the interop-vs-gap disambiguation rule → picks interoperability/
→ Writes docs/reports/interoperability/2026-04-17-hexaflux-weekly.md

例 7：レポート作成後のフォローアップ課題の提案（GitHub）

User: génère le compte-rendu /tmp/sprint.vtt

→ Report written to docs/reports/2026-05-12-sprint-planning.md and reported (Steps 1–11)
→ Step 12a preflight: git remote → github.com/Dedalus-ERP-PAS/foo, `gh` authenticated → pass
→ Step 12b: derives 3 quality candidates from Problèmes identifiés + Point d'attention
→ Step 12c: AskUserQuestion « Les issues seront créées sur Dedalus-ERP-PAS/foo (github.com). Lesquelles créer ? »
→ User selects 2 of 3
→ Step 12d: `gh issue create` ×2 (duplicate search first, no label invented)
→ Step 12e: reports the 2 created issue URLs

例 8：課題ステップをスキップ — git リモートがない場合

User: transforme cette transcription en rapport /tmp/atelier.vtt

→ Report written and reported (Steps 1–11)
→ Step 12a preflight: `git remote -v` empty → no platform
→ Prints « Aucune issue proposée : pas de remote git détecté. » and stops