プロジェクトフロー運用

このスキルは散在する 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 がより大きなプロジェクトチャネルの一部である

すべてをмеханically ミラーリングしないこと。

4. 2つのシステムを同期させたままにする

作業がアクティブな場合：

• GitHub Issue/PR はパブリックな進捗を示すべき
• Linear は内部で所有者、優先度、実行チャネルを追跡すべき

作業が完了または却下された場合：

• パブリックなソリューションを GitHub に投稿する
• それに応じて Linear タスクにマークを付ける

レビュールール

• タイトル、サマリー、または信頼だけでマージしないこと。完全な差分が必要です
• 外部ソースの機能が価値あるが自己完結的でない場合、ECC 内で再構築すべき
• CI が赤い場合は分類し、修正するか、ブロックしてください。マージ可能なふりをしないでください
• 本当の障碍が製品方向である場合、それを直接述べ、ツールの背後に隠さないでください

出力形式

以下を返します：

パブリックステータス
- Issue / Pull Request ステータス
- CI / レビューステータス

分類
- マージ / ポート/リビルド / クローズ / 保留
- 理由の説明

Linear アクション
- 作成 / 更新 / Linear Item 不要
- プロジェクト / スイムレーン（該当する場合）

次のステップ所有者アクション
- 正確な次のステップ

良い使用例

• 「オープンな PR バックログを確認し、どのものをマージすべきか、どのものを再構築すべきか教えてください」
• 「GitHub Issue を ECC 1.x および ECC 2.0 プロジェクトチャネルにマッピングしてください」
• 「これが Linear Issue を作成する必要があるか、GitHub に残すべきかを確認してください」