Project Flow Ops
このスキルは、散在するGitHubのIssue、プルリクエスト（PR）、Linearのタスクを1つの実行フローに変換します。
問題がコーディングではなく、調整（コーディネーション）である場合に使用してください。
使用するタイミング
- 未処理のPRやIssueのバックログをトリアージする
- 何をLinearに含め、何をGitHubのみに留めるかを判断する
- アクティブなGitHub作業を内部実行レーンにリンクする
- PRを「マージ」「ポート/再構築」「クローズ」「保留」に分類する
- レビューコメント、CIの失敗、古くなったIssueが実行を妨げていないかを監査する
運用モデル
- GitHub は公開・コミュニティの真実（ソース）です
- Linear はアクティブなスケジュール作業のための内部実行の真実です
- すべてのGitHub IssueにLinear Issueが必要なわけではありません
- Linearの作成または更新は、以下の場合のみ行います：
- アクティブ
- 委任済み
- スケジュール済み
- クロスファンクショナル
- 内部で追跡するほど重要
コアワークフロー
1. まず公開面を読む
以下を収集します：
- GitHub IssueまたはPRの状態
- 作成者とブランチの状態
- レビューコメント
- CIの状態
- リンクされたIssue
2. 作業を分類する
各項目は、以下のいずれかの状態に分類されます：
| 状態 | 意味 |
|---|---|
| マージ | 自己完結型、ポリシー準拠、準備完了 |
| ポート/再構築 | 有用なアイデアだが、ECC内で手動で再導入すべき |
| クローズ | 方向性が誤り、古い、安全でない、または重複 |
| 保留 | 潜在的に有用だが、現時点ではスケジュールされていない |
3. Linearが必要か判断する
以下の場合のみLinearを作成または更新します：
- 実行が積極的に計画されている
- 複数のリポジトリやワークストリームが関与している
- 作業に内部の所有権や順序付けが必要
- Issueがより大きなプログラムレーンの一部である
機械的にすべてをミラーリングしないでください。
4. 2つのシステムの一貫性を保つ
作業がアクティブな場合：
- GitHub Issue/PRは、公開で何が起こっているかを示すべき
- Linearは内部でオーナー、優先度、実行レーンを追跡すべき
作業がリリースまたは却下された場合：
- 公開された解決策をGitHubに投稿する
- 対応するLinearタスクを適切にマークする
レビュールール
- タイトル、要約、または信頼だけでマージしないでください。完全な差分（diff）を使用してください
- 外部ソースの機能は、価値はあるが自己完結型でない場合、ECC内で再構築する必要があります
- CIが赤の場合、分類して修正するかブロックします。マージ準備完了と偽装しないでください
- 実際のブロッカーがプロダクトの方向性である場合、ツールの背後に隠れずにそう伝えてください
出力形式
以下を返却します：
公開ステータス
- Issue / PRの状態
- CI / レビューの状態
分類
- マージ / ポート-再構築 / クローズ / 保留
- 1段落の根拠
Linearアクション
- 作成 / 更新 / Linear項目は不要
- 該当する場合はプロジェクト / レーン
次の運用手順
- 正確な次のアクション
適切なユースケース
- "未処理のPRバックログを監査し、何をマージすべきか、何を再構築すべきか教えてください"
- "GitHub IssueをECC 1.xおよびECC 2.0プログラムレーンにマッピングしてください"
- "これにLinear Issueが必要か、GitHubのみに留めるべきかを確認してください"