fast-meeting

Fast Meeting

専門家のペルソナと完全自律型の会議を行い、推奨される解決策をすぐに実装し、マージリクエストまたはプルリクエストを作成して、フランス語で説明を投稿します。これらすべてを、ユーザーに確認を求めずに行います。

前提条件

• gh（GitHub CLI）：プロジェクトで GitHub を使用している場合に必要です。https://cli.github.com または brew install gh からインストールしてください
• glab（GitLab CLI）：プロジェクトで GitLab を使用している場合に必要です。https://gitlab.com/gitlab-org/cli または brew install glab からインストールしてください

このスキルを使用するタイミング

次の場合に有効化します：

• ユーザーがあるテーマについて「fast meeting」または「réunion rapide」を依頼した場合
• 中断なしで、意思決定と自動実装の両方を求めている場合
• 「fast-meeting」と言う、または「lance un fast meeting sur...」と依頼した場合
• あるテーマを分析し、決定し、1つのコマンドで実装することを求めている場合

基本原則

1. 完全な自律性

• パイプライン全体を、ユーザーに質問することなく実行します
• コンテキスト分析に基づいて、ペルソナを自動的に選択します
• 会議の直後に、最善の方針を実装します
• 検出されたリモート（GitLab または GitHub）に MR/PR を自動作成します

2. 徹底よりもスピードを重視

• 会議を短縮し、3ラウンドではなく2ラウンド（開始＋収束）で行います
• ペルソナは最大3～4人に限定します
• 分析は簡潔で、行動につながる内容にします
• 会議の終了後、すぐに実装を開始します

3. 多様でありながら焦点を絞った視点

• テーマに基づいてペルソナを自動選択します
• 各ペルソナが、実質的に異なる視点をもたらします
• 会議では、実行可能な推奨事項へ迅速に収束します

4. 完全な成果物

• コード変更は専用ブランチにコミットします
• MR/PR を自動作成します
• MR/PR のフランス語による説明には、会議の分析と実装内容をまとめます

ワークフロー

ステップ 0：ワークツリーの整理

開始前に、前回の会議がクラッシュして残った古いワークツリーをクリーンアップします：

1. git worktree prune を実行して、古いワークツリーの参照を削除します
2. git worktree list を確認し、兄弟ディレクトリのうち fast-meeting-* または fm-* という名前に一致するものがある場合：
   • 並行実行の安全性： 削除前に、ワークツリーのディレクトリでアクティブな git プロセスが実行されていないことを確認します（fuser -s <worktree-path> 2>/dev/null）。ディレクトリが使用中の場合は、別の fast-meeting が使用しているため、スキップしてください
   • 古いと確認できたワークツリーのみ削除します：git worktree remove <path> --force
3. 古い fast-meeting/* ブランチもクリーンアップします：git branch --list 'fast-meeting/*' | xargs -r git branch -D

これにより、並行して実行中の fast-meeting を妨げることなく、クリーンな状態で開始できます。

ステップ 1：コンテキストの収集

1. ユーザーのプロンプトを読む — テーマ、制約、目標を抽出します
2. Issue が参照されている場合（GitLab #123 または GitHub #123）：
   • Issue の詳細（説明、ラベル、コメント）を取得します
   • ステップ 8 と 9 で使うため、Issue の参照情報（番号、URL、プロジェクト）を保存します
3. Issue が参照されていない場合は、その旨を記録します。ステップ 4b で後から Issue を作成する可能性があります
4. コードが関係する場合は、関連ファイルを読んで現在の状態を把握します
5. リモートリポジトリの種類を検出する：
   • git remote -v を実行して、リモートが GitLab か GitHub かを特定します
   • MR/PR 作成のため、この情報をステップ 8 で使えるよう保存します
6. 決定すべき事項を特定する — 明確な1行の質問としてまとめます

次へ進む前に、決定に関する質問を出力します。例：

"Question: 認証システムをセッションベースから JWT トークンに移行すべきでしょうか？"

ステップ 2：ペルソナを自動選択する

主題に基づいて、3〜4 人のペルソナを自動的に選択します。次のヒューリスティックを使用してください。

主題...	自動選択されるペルソナ
バックエンド／API／データベース	SOLID Alex (Backend), Whiteboard Damien (Architecte), EXPLAIN PLAN Isabelle (DBA Oracle)
フロントエンド／UI／UX	Pixel-Perfect Hugo (Frontend), Figma Fiona (UX/UI), Sprint Zero Sarah (PO), Whiteboard Damien (Architecte)
セキュリティ／認証／アクセス制御	Paranoid Shug (Sécurité), RGPD Raphaël (DPO), SOLID Alex (Backend), Whiteboard Damien (Architecte)
インフラストラクチャ／デプロイ／CI-CD	Pipeline Mo (DevOps), SOLID Alex (Backend), Whiteboard Damien (Architecte)
データ／移行／ETL	Schema JB (Data), EXPLAIN PLAN Isabelle (DBA Oracle), Whiteboard Damien (Architecte)
相互運用性／HL7／FHIR／HPK	RFC Santiago (PO Interop), HL7 Victor (Dev Interop), SOLID Alex (Backend)
レガシー／Uniface／モダナイゼーション	Legacy Larry (Uniface), Whiteboard Damien (Architecte), SOLID Alex (Backend)
テスト／品質／リグレッション	Edge-Case Nico (QA), SOLID Alex (Backend), Pipeline Mo (DevOps)
プロダクト／機能／UX の判断	Sprint Zero Sarah (PO), Pixel-Perfect Hugo (Frontend), Figma Fiona (UX/UI), Whiteboard Damien (Architecte)
医療／臨床ワークフロー	Dr. Workflow Wendy (Santé), Sprint Zero Sarah (PO), RGPD Raphaël (DPO)
GDPR／個人データ／コンプライアンス	RGPD Raphaël (DPO), Paranoid Shug (Sécurité), Whiteboard Damien (Architecte)
BI／ダッシュボード／レポート／財務／会計	Dashboard Estelle (BI Finance), Pixel-Perfect Hugo (Frontend), EXPLAIN PLAN Isabelle (DBA Oracle), Whiteboard Damien (Architecte)
フルスタック／横断的な主題	Whiteboard Damien (Architecte), SOLID Alex (Backend), Sprint Zero Sarah (PO), Edge-Case Nico (QA)

複数の領域にまたがる場合は、最も関連性の高い 3〜4 人のペルソナを選択します。技術的な判断では、必ず Whiteboard Damien (Architecte) を含めます。プロダクトに関する判断では、必ず Sprint Zero Sarah (PO) を含めます。

役割、視点、バイアスを含むペルソナの全一覧： reference/personas.md を参照してください。

ミーティングを開始する前に、選択したペルソナとその役割を発表してください。

ステップ 3：高速ミーティングを実施する

ミーティングではサブエージェントを使い、各ペルソナを個別かつ並行して実行します。高速ミーティングでは、プロセスを 2 ラウンドに短縮します。

重要：Agent ツールを使って、各ペルソナを個別のサブエージェントとして起動してください。

ラウンド 1：立場と推奨事項（並行サブエージェント）

Agent ツールを使い、各ペルソナにつき 1 つのサブエージェントを並行して起動します。各サブエージェントには次の内容を渡します。

1. ステップ 1 の判断に関する質問
2. 収集したすべてのコンテキスト（課題の詳細、コードスニペット、制約）
3. ペルソナのアイデンティティプロンプト

サブエージェントのプロンプトテンプレート：

You are {name}, a {role}.

Your perspective: {perspective}
Your natural bias: {bias}

You are participating in a fast meeting about: {decision_question}

Context:
{context}

As {name}, provide your position:
1. What is your recommended approach? Be specific and concrete.
2. What are the top 2 risks? Be specific about failure scenarios.
3. What is your preferred implementation strategy in concrete steps?
4. What would you push back on from other typical perspectives?

Stay fully in character. Be concise and actionable — this is a fast meeting.

This is a research task — do NOT write or edit any files.

すべてのペルソナのサブエージェントを 1 つのメッセージで起動し、並行して実行されるようにしてください。subagent_type: "general-purpose" を使い、"Fast persona: {name}" のような短い説明を指定します。

すべての立場を集め、引用として提示します。

SOLID Alex (Senior Backend Engineer)：「私は……を推奨します」

集団思考チェック

ラウンド 1 の回答を収集した後、合意の度合いを評価します。

1. すべてのペルソナが同じアプローチに収束しているか確認します（同じ推奨事項で、意味のある意見の相違がない）
2. 合意の度合いが高すぎる場合（すべてのペルソナが反論なく同じアプローチに賛成している場合）：
   • 悪魔の代弁者として、サブエージェントを 1 つ追加で起動し、合意した立場に対する最も強力な反論を見つけるよう指示します
   • 次のプロンプトを使用します。

     あなたは迅速な会議における悪魔の代弁者です。
     
     参加者全員が、次のアプローチに賛成しました：{consensus_summary}
     
     あなたの役割：この合意に対する、可能な限り最も強力な反論を見つけてください。
     - 誰も挙げなかった、どのような問題が起こり得ますか？
     - 全員が前提としているものの、誤っている可能性があることは何ですか？
     - どのような代替案を、早々に退けてしまいましたか？
     
     具体的かつ明確に述べてください。実際に起こり得る失敗シナリオを挙げてください。
     これは調査タスクです。ファイルの作成や編集はしないでください。
     

   • 推奨事項が変わらない場合でも、分析に反対意見を含めます
3. **すでに意味のある意見の相違がある場合：**そのままラウンド 2 に進みます

ラウンド 2：収束（単一の統合）

ラウンド 1 の回答をすべて収集した後、サブエージェントではなく、進行役であるあなた自身が統合します。

• ペルソナ間で一致した点
• 明らかになった主なトレードオフ
• 理由を添えた最終的な推奨事項
• 具体的な実装計画（変更するファイル、アプローチ、作業順序）

**サブエージェントによる 2 回目のラウンドは起動しないでください。**速度を優先し、直接統合してください。

Step 4: 簡潔な決定事項を提示する

ユーザーに表示する簡潔な分析を作成します。

## Fast Meeting : [Sujet]

**Question :** [La question de décision]

**Participants :** [Name (Role)] | [Name (Role)] | [Name (Role)]

### Recommandation retenue
[The recommended approach in 2-3 sentences]

### Justification
- [Reason 1]
- [Reason 2]
- [Reason 3]

### Risques et mitigations
- [Risk 1 → Mitigation]
- [Risk 2 → Mitigation]

### Plan d'implémentation
1. [Step 1]
2. [Step 2]
3. [Step 3]

Step 4b: Issue が存在することを確認する

Step 1 ですでに Issue が参照されている場合は、すでに利用可能です。Step 5 に進んでください。

Issue が参照されていない場合は、追跡可能性を確保するため、自動的に作成します。ユーザーへのプロンプトや確認は不要です。これは fast-meeting の完全自律型の契約に沿ったものです。

1. 会議の分析をもとに Issue を作成します。
   • **タイトル：**決定に関する質問を短くまとめたもの（70 文字未満、フランス語）
   • **説明：**以下のテンプレートを使用した、PO 向けの要約
2. すぐに Issue を作成します。
   • GitLab：glab issue create --title "<title>" --description "<description>" を使用します
   • GitHub：gh issue create --title "<title>" --body "<description>" を使用します
   • 新しく作成した Issue の番号と URL を保存し、Steps 8 と 9 で使用します
   • プロジェクトに存在することを確認できていないラベルは追加しないでください（まずラベル一覧を取得してください）
3. Issue の作成に失敗した場合（API エラー、権限拒否、プロジェクトが見つからないなど）：Run Summary にエラーを記録し、Issue なしで続行します。Steps 8 と 9 はそれに応じて対応します

自動作成する Issue の説明テンプレート（フランス語 — PO／コンサルタント向け）

## Contexte
[Business context derived from the user's prompt — what problem or opportunity triggered this analysis]

## Question analysée
[The decision question from Step 1, framed in business terms]

## Participants
| Expert | Rôle |
|--------|------|
| [Name] | [Role] |
| ... | ... |

## Recommandation
[The recommended approach in 2-3 sentences, focusing on user/business value rather than technical details]

## Risques identifiés
- [Risk 1 in business impact terms → Mitigation]
- [Risk 2 in business impact terms → Mitigation]

---
_Issue créée automatiquement par un fast-meeting IA_

Step 5: スコープの確認

実装に入る前に、推奨された変更のスコープを見積もります。

1. **スコープを評価します。**変更予定のファイル数、追加・変更するコード行数、新しい依存関係やインフラストラクチャが必要かどうかを数えます
2. しきい値を適用します。
   • 小規模なスコープ（ファイル数 ≤10、行数 ≤500、新しいインフラストラクチャなし）：通常どおり Step 6 に進みます
   • 中規模なスコープ（ファイル数 >10、または行数 >500）：続行しますが、最も重要な最初のステップだけにスコープを絞ります。残りのステップは MR／PR の説明に ### Étapes restantes セクションを設け、チェックリストとして追加します
   • 大規模なスコープ（複数サービスにまたがる変更、アーキテクチャの移行、新しいインフラストラクチャが必要）：実装を中止します。Step 4 の会議分析を出力し、実装前に適切な計画と検証を行うため、ユーザーに完全版の /meeting スキルを実行するよう提案します
3. **スコープを絞った場合：**今回実装する内容と、後回しにする内容を分析で明確に示します

ステップ 6：ワークツリーを作成して実装する

ユーザーに確認せず、すぐに実装に進んでください。 これが会議との主な違いです。

実装は git ワークツリー で行います。これにより、リポジトリの分離されたコピーが作成されます。ユーザーの作業ツリーは 一切変更されません。スタッシュもブランチの切り替えも行わず、状態が破損するリスクもありません。

ワークツリーを作成する

1. 現在のブランチを記録して 参照できるようにします（例：main）
2. 会議での推奨事項に基づいて ブランチの種類を決定します：
   • バグ修正 → fix/
   • 新機能 → feat/
   • リファクタリング → refactor/
   • デフォルト → feat/
3. 衝突を確認する前に リモートの状態を取得します：
   • git fetch origin を実行して、ブランチ情報を最新の状態にします
4. ワークツリーを作成する前に ブランチ名の衝突を確認します：
   • git branch -a を実行し、<type>/fm-<topic> がすでに存在するか確認します（ローカル、または remotes/origin/<type>/fm-<topic>）
   • ブランチが存在する場合は、一意の名前が見つかるまで数値のサフィックス（-2、-3 など）を追加します。既存のブランチを強制削除しないでください。レビュー済み、または作業中の内容が含まれている可能性があります
5. 専用ブランチを使って ワークツリーを作成します：
   • ブランチ名：<type>/fm-<short-kebab-case-topic>（例：feat/fm-jwt-auth-migration、fix/fm-notification-display）。衝突が見つかった場合はサフィックスを付けます
   • ワークツリーのパス：$(git rev-parse --show-toplevel)/../fm-<topic>
   • 次を実行します：git worktree add ../fm-<topic> -b <type>/fm-<topic>
6. ワークツリーの作成に失敗した場合：
   • エラーがブランチの既存を示している場合：git branch -D <type>/fm-<topic> を実行してから、ワークツリーの作成を再試行します
   • それでも失敗する場合（ディスク容量、権限、パス長、サブモジュール、その他の理由）：実装パイプラインを中止します。ステップ 4 の会議分析全文と正確なエラーメッセージを出力して、停止します。ユーザーは根本原因を解決してから再実行できます。スタッシュやチェックアウトへの切り替えは絶対に行わないでください。ユーザーの作業ツリーは決して変更してはなりません

ワークツリーで実装する

1. すべてのファイル変更はワークツリーのパス内で行います。すべての読み書き操作には、ワークツリーの絶対パスを使用します
2. ステップ 4 の実装計画に従って 変更を実装します
   • 必要に応じてコードを記述し、ファイルを変更し、テストを追加します
   • プロジェクト既存の規約とパターンに従います
3. ワークツリー内からすべての変更を ステージングしてコミットします：
   • git コマンドを実行する前に、ワークツリーのパスへ cd します
   • 次の形式のコミットメッセージを使用します：feat(<scope>): <description>
   • コミットメッセージに Co-Authored-By: Claude Opus 4.6 <[email protected]> を含めます
   • git commit が pre-commit フックによって失敗した場合： フックの出力を分析し、フックを通過するようにコードを修正してから、コミットを一度だけ再試行します。それでも失敗する場合は、テスト失敗と同様に扱い、MR/PR の説明にフックエラーを記載して Draft としてプッシュします。--no-verify は絶対に使用しないでください

ステップ 7：テスト、プッシュ、クリーンアップ

テストの実行

コミット後、プロジェクトのテストスイートで実装を検証します。

1. テストランナーを自動検出します。
   • package.json で test、test:unit、test:e2e スクリプトを確認します
   • Makefile、pytest.ini、phpunit.xml、その他のテスト設定ファイルを確認します
   • テストランナーが見つからない場合は、この手順をスキップし、MR/PR の説明に「テストスイートが検出されませんでした」と記載します
2. テストを実行します（テストランナーが対応している場合は影響を受けるファイル／モジュールに限定し、そうでない場合はスイート全体を実行します）
3. テストが成功した場合： プッシュに進みます
4. テストが失敗した場合：
   • 失敗を分析し、修正サイクルを1回実施します（コードを修正し、テストを再実行します）
   • 修正後にテストが成功した場合：修正を含めてコミットを修正し、プッシュに進みます
   • 1回の修正を試みてもテストが失敗する場合：
     • MR/PR を Draft にします（タイトルの先頭に Draft: を付けます）
     • MR/PR の説明に ### 失敗したテスト セクションを追加し、失敗したテストとエラーメッセージを記載します
     • チームがレビューできるよう、そのままプッシュします
5. テスト結果の概要（実行数、成功数、失敗数）を MR/PR の説明に記載します

ブランチをプッシュする

1. ワークツリー内からブランチをプッシュします。
   • 実行：git push -u origin <type>/fm-<topic>（ワークツリーのパスから）
   • プッシュに失敗した場合（認証エラー、リモートなし、権限拒否、ネットワークの問題）：
     • ワークツリーを削除しないでください — コミットした作業を保持する必要があります
     • ワークツリーのパス、ブランチ名、正確なエラーメッセージを出力します
     • 手動で復旧するためのコマンドを出力します：cd <worktree-path> && git push -u origin <branch>
     • ステップ 8 と 9 は完全にスキップします — リンクするものはありません
     • プッシュ状況を「失敗」として、直接実行サマリー（ステップ 10）に進みます

ワークツリーをクリーンアップする

2. ワークツリーを削除します（プッシュが成功した場合のみ）：
   • 元のリポジトリのパスに戻ります
   • 実行：git worktree remove ../fm-<topic>
   • 削除に失敗した場合（例：ワークツリーに未コミットの変更がある場合）、git worktree remove ../fm-<topic> --force を実行します
   • クリーンアップ後の確認： git worktree list を実行し、fast-meeting ワークツリーが表示されないことを確認します。表示される場合は、ユーザーにクリーンアップコマンドを出力します：git worktree remove <path> --force
3. 復元は不要です： ユーザーの作業ツリーは変更されていないため、未コミットの変更をすべて保持したまま元のブランチに残っています

ステップ 8：MR/PR を作成する

ステップ 1 で検出したリモートの種類に応じて、以下を実行します。

GitLab の場合：

glab mr create --title "<title>" --description "<description>" --target-branch main を使用して、以下の内容でマージリクエストを作成します。

• タイトル： 短い説明（70文字未満、英語）
• 説明： フランス語での会議分析と実装の概要（下記のテンプレートを参照）
• Issue のリンク： Issue が存在する場合（参照されているか、ステップ 4b で作成された場合）、マージ時に Issue を自動クローズするため、説明に Closes #XX を含めます

GitHub の場合：

gh pr create を使用して、以下の内容でプルリクエストを作成します。

• タイトル： 短い説明（70文字未満、英語）
• 本文： フランス語での会議分析と実装の概要（下記のテンプレートを参照）
• Issue のリンク： Issue が存在する場合（参照されているか、ステップ 4b で作成された場合）、マージ時に Issue を自動クローズするため、本文に Closes #XX を含めます

MR/PR の作成に失敗した場合：

MR/PR の作成に失敗した場合（API のタイムアウト、レート制限、認証、MCP ツールのエラー）：

• リモート URL とブランチ名を出力します
• ユーザーが貼り付けて実行できる、書式設定済みの手動コマンドを出力します。
  • GitLab：MR を手動で作成するための Web URL を提示します
  • GitHub：gh pr create --head <branch> --title "<title>" --body "<body>"
• MR/PR の説明全文を会話の出力に含め、内容が失われないようにします
• 該当する場合はステップ 9（Issue へのコメント）に進みます — MR/PR のリンクがなくても Issue へのコメントは有用です
• 失敗を実行サマリー（ステップ 10）に記録します

MR/PR の説明テンプレート（フランス語 — 開発者向け／技術者向け）

MR/PR の説明は、コードをレビューする開発者を対象とします。技術的な詳細に焦点を当ててください。変更内容、技術的にこのアプローチを選んだ理由、レビュー時に確認すべき点を説明します。

## Résumé technique

### Contexte
[Brève description du problème technique ou de la décision d'architecture qui a motivé ces changements]

### Approche retenue
[L'approche technique choisie et pourquoi — patterns utilisés, alternatives considérées et rejetées techniquement]

### Changements implémentés
| Fichier | Modification | Justification technique |
|---------|-------------|------------------------|
| `path/to/file` | [Ce qui a changé] | [Pourquoi ce choix technique] |
| ... | ... | ... |

### Points d'attention pour la revue
- [Point technique à vérifier — ex: gestion d'erreurs, performance, rétrocompatibilité]
- [Impact potentiel sur d'autres modules]
- [Cas limites à valider]

### Tests
- [Résultats des tests : nombre exécutés, passés, échoués]
- [Couverture des cas limites identifiés]

### Prochaines étapes
- [ ] Revue de code par l'équipe
- [ ] Validation des tests
- [ ] Merge après approbation

---
_Implémentation générée automatiquement par IA_

Issue のリンク： Issue が存在する場合（Step 1 で参照したか、Step 4b で作成した場合）、--- セパレーターの後、斜体のフッターの前に、独立した行として Closes #<issue_number> を追加します。Issue が存在しない場合は、この行を完全に省略します。

Step 9: Issue への投稿（PO／コンサルタント向け）

リンクされた Issue に、プロダクトオーナー／コンサルタント向けのコメントを投稿します。このコメントは、チケットを再度開いた PO／コンサルタントのための意思決定の記録です。「何が決定され、その理由は何か？」に、画面上の表示で15行以内で答える必要があります。流し読みしやすいように最適化してください。読者が詳細を確認するかどうかを3秒で判断できる内容にします。

Issue の解決方法：

• Issue が Step 1 で参照されていた場合： その Issue にコメントを投稿します
• Issue が Step 4b で作成されていた場合： 新しく作成した Issue にコメントを投稿します
• Step 4b で Issue の作成に失敗した場合： このステップを省略し、失敗を実行サマリーに記録します

作成ルール

• H2 は1つだけ — ## Décision を先頭に置き、判断結果を実行可能な1～2文で述べます。読者の80％が読むのはここだけです。
• 質問は省略します — Issue のタイトルにすでに記載されています。言い換えないでください。
• ペルソナの表は不要です。 ペルソナは内部の作成プロセスであり、成果物ではありません。監査用に、フッターでインラインのフラットなリストとしてのみ記載してください。
• 各セクションの箇条書きは最大3項目です。 それ以上必要な場合は、決定が十分に明確ではありません。
• 空のプレースホルダーは使用しません。 フィールドに実際の内容がない場合（期限がない、依存関係がないなど）は、項目自体を省略します。「N/A」や「該当する場合」などとは記載しないでください。
• 技術的な詳細は記載しません。 実装の詳細は MR/PR の説明に記載します。

Issue コメントテンプレート（フランス語）

## Décision

[1-2 phrases actionnables au présent, en termes métier]

**Pourquoi**
- [Bénéfice utilisateur / métier 1]
- [Bénéfice utilisateur / métier 2]
- [Bénéfice utilisateur / métier 3 ou trade-off assumé]

**Risques**
- [Risque métier → mitigation]
- [Risque métier → mitigation]

**Impact** : [utilisateurs concernés] · [délai si pertinent] · [dépendances si pertinentes]

**MR/PR** : [Lien]

---
_Fast-meeting IA · [Persona1, Persona2, Persona3]_

簡潔化ルール：

• 会議で重要なビジネスリスクが明らかにならなかった場合、Risques セクションを省略します。
• 回答が一般的な「すべてのユーザー」になる場合、Impact の行を省略します。
• フッターは1行に収めます。ペルソナをカンマ区切りのフラットなリストとして記載し、役割や役職は含めません。

適切なツールを使用してコメントを投稿します。

• GitLab： glab issue note <iid> --message "<comment>"
• GitHub： gh issue comment <number> --body "<comment>"

Step 10: 実行サマリー

パイプラインがいずれかのステップで成功したか失敗したかにかかわらず、すべての fast-meeting 実行の最後に、必ず構造化された実行サマリーを出力します。 これにより、自律型パイプラインの可観測性を確保できます。

### Fast Meeting — Run Summary
- **Sujet :** [topic]
- **Branche :** `<type>/fm-<topic>`
- **Worktree :** [path] (nettoyé : oui/non)
- **Push :** succès / échec ([erreur si applicable])
- **MR/PR :** [URL] / non créé ([raison si applicable])
- **Tests :** [N exécutés, N passés, N échoués] / non détectés
- **Issue :** liée (#XX) / créée (#XX) / échec de création ([erreur])
- **Commentaire issue :** publié (#XX) / ignoré (pas d'issue)
- **Durée totale :** [durée wall-clock de l'ensemble du pipeline]

いずれかのステップが失敗した場合、サマリーには失敗の理由と、前のステップですでに提示した手動復旧コマンドを含める必要があります。

会議の品質ルール

ペルソナの真正性

• 各ペルソナは、役割とバイアスに沿った一貫性のある発言をします
• ペルソナは抽象的な美辞麗句ではなく、具体例を使います
• セキュリティエンジニアは曖昧な「セキュリティ上の懸念」ではなく、攻撃ベクトルについて話します
• プロダクトオーナーはコードのパターンではなく、ユーザーへの影響や納期について話します

スピードのルール

• 会議のペルソナは最大3～4人です
• 並列サブエージェントによるラウンドは1回のみとし、ファシリテーターが統合します（第2ラウンドの議論は行いません）
• コンセンサスが高すぎる場合に限り、任意で悪魔の代弁者となるサブエージェントを追加します（約10秒追加）
• 実装前にユーザーの確認を求めません
• コミットメッセージと MR/PR は自動的に作成されます

実装の品質

• 既存のプロジェクト規約とパターンに従います
• クリーンで、テスト済みのコードを書きます
• 実装後にプロジェクトのテストスイートを実行し、失敗した場合は1回の修正を試みます
• 推奨事項に関係する変更に絞り、過剰な設計は避けます
• スコープの制御：変更が10ファイルまたは500行を超える場合は、重要な最初のステップに範囲を絞ります。スコープがアーキテクチャに関わる場合は、実装を中止して /meeting を提案します
• ユーザーの作業ツリーを保護します。実装は分離された git worktree で実行され、ユーザーの作業ディレクトリは変更されません

例

例 1：技術的な決定

User: fast-meeting : est-ce qu'on doit utiliser GraphQL ou REST pour la nouvelle API

→ Auto-sélection : SOLID Alex (Backend), Pixel-Perfect Hugo (Frontend), Whiteboard Damien (Architecte)
→ Lance le fast meeting (1 tour + synthèse)
→ Implémente l'approche recommandée
→ Crée la branche feat/fm-graphql-vs-rest-api
→ Commit, push, crée la MR/PR avec description en français

例 2：Issue を伴うバグ修正

User: fast-meeting sur l'issue #42 - les notifications ne s'affichent pas

→ Récupère les détails de l'issue #42
→ Auto-sélection : Pixel-Perfect Hugo (Frontend), SOLID Alex (Backend), Edge-Case Nico (QA)
→ Lance le fast meeting
→ Implémente le correctif
→ Crée la MR/PR, poste le lien sur l'issue #42

例 3：リファクタリング

User: fast-meeting : refactorer le module d'authentification pour supporter OAuth2

→ Auto-sélection : Paranoid Shug (Sécurité), SOLID Alex (Backend), Whiteboard Damien (Architecte), Pipeline Mo (DevOps)
→ Lance le fast meeting
→ Implémente le refactoring
→ Crée la MR/PR avec analyse en français

例 4：Issue が参照されていない場合 — 自動作成

User: fast-meeting : migrer le cache Redis vers Valkey

→ Pas d'issue référencée
→ Auto-sélection : SOLID Alex (Backend), Pipeline Mo (DevOps), Whiteboard Damien (Architecte)
→ Lance le fast meeting (1 tour + synthèse)
→ Crée automatiquement l'issue #58 avec résumé PO (aucune confirmation requise)
→ Implémente la migration dans un worktree isolé
→ Commit, push, crée la MR/PR (Closes #58) avec description technique
→ Poste le résumé PO sur l'issue #58

重要な注意事項

• GitLab や GitHub で新しいラベルを作成しないでください。 Issue やマージリクエストにラベルを追加する場合は、プロジェクトにすでに存在するラベルのみを使用してください。どのラベルが存在するか不明な場合は、まずラベルを一覧表示し（GitHub では gh label list を実行するか、GitLab では既存の Issue ラベルを確認してください）、利用可能なラベルから選んでください。適切なラベルがない場合は、新しいラベルを作成せず、ラベル付けを省略してください。
• このスキルはユーザーへの確認を求めません — パイプライン全体を自律的に実行します
• 修正を 1 回試みた後もテストが失敗する場合は、MR/PR を Draft に設定し、失敗について記録してください
• 実装範囲が大きすぎる場合（アーキテクチャに関わる変更、複数サービスにまたがる変更）は中止し、代わりに /meeting を提案してください
• ユーザーの作業ツリーは常に保護されます。実装は隔離された git worktree で実行されるため、stash やブランチの切り替えは発生せず、状態が破損するリスクもありません。worktree の作成に失敗した場合、stash/checkout にフォールバックせず、パイプラインは安全に中止されます
• 複数の fast-meeting を別々の worktree で並行して実行できます。ステップ 0 ではアクティブなプロセスがない worktree のみをクリーンアップするため、並行実行しても安全です
• MR/PR を作成するときは、git branch -r | grep '/fm-' を実行して、ほかにアクティブな fast-meeting ブランチがないか確認してください。ほかのブランチがある場合は、MR/PR の説明に警告を追加してください。「注意：ほかの fast-meeting ブランチがアクティブです。マージする前に、競合の可能性を確認してください。」
• MR/PR の説明は常にフランス語で記述します
• ブランチ名は Git flow の規則に従います：<type>/fm-<topic>（例：feat/fm-<topic>、fix/fm-<topic>）。会議での推奨内容に基づき自動的に決定されます
• リモートの種類を判別できない場合は、既定で gh pr create（GitHub）を使用します
• 強制プッシュや既存ブランチの変更は行わず、常に新しいブランチを作成してください