Project Flow Ops
このスキルは、散在する GitHub Issue、PR、Linear タスクをひとつの実行フローに変換します。
問題がコーディングではなく調整である場合に使用してください。
使用タイミング
- オープンな 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 タスクを適切にマークする
レビュールール
- タイトル、概要、または信頼だけでマージしないでください。完全な差分を使用してください。
- 外部ソースの機能は、価値があるが自己完結型でない場合、ECC 内で再構築する必要があります。
- CI が赤の場合、分類して修正するかブロックしてください。マージ準備完了と偽装しないでください。
- 本当のブロッカーがプロダクトの方向性である場合、ツールのせいにせず、そう伝えてください。
出力形式
以下を返します：
公開ステータス
- Issue / PR の状態
- CI / レビューの状態
分類
- マージ / ポート再構築 / クローズ / 保留
- 1段落の根拠
Linear アクション
- 作成 / 更新 / Linear 項目は不要
- 該当する場合：プロジェクト / レーン
次のオペレーターアクション
- 正確な次のアクション
適切なユースケース
- "オープンな PR バックログを監査し、マージすべきものと再構築すべきものを教えて"
- "GitHub Issue を ECC 1.x および ECC 2.0 のプログラムレーンにマッピングして"
- "これに Linear Issue が必要か、それとも GitHub のみで良いか確認して"