use-workflow

ワークフローの使い方

作業は、最も適した最小限のワークフローに振り分けます。リポジトリ内の指示と、ユーザーからの明示的な依頼に従ってください。両者に実質的な矛盾がある場合は、黙って一方を選ばず、推奨案とともに矛盾を明示してください。明確でリスクの低いタスクを、プロジェクトにまで発展させないでください。

リポジトリに用語集がある場合はそれを使用し、ない場合はworkflow-language.mdを使用してください。

振り分け

• コード領域や処理の流れを説明する -> explain-codebase
• バグ、障害、不安定な動作、予期しない出力、リグレッションを診断する -> diagnose-issue
• 明示的な計画依頼、または重大な曖昧さ、調整、横断的な範囲、取り消し不能性、リスクがある -> plan-work
• Plan、引き継ぎ、調査結果、ブリーフ、ドキュメント作業、修正、リファクタリングで決定済みの範囲を実行する -> implement-work
• 続行用のプロンプトまたはファイルを作成する -> write-handoff
• Plan、変更、修正の一連の作業、またはコード以外の成果物をレビューする -> review-work
• アーキテクチャ改善の機会を発見する -> improve-architecture
• 意図した動作を変えずに、範囲が確定済みの領域を簡素化する -> simplify-work
• 使い捨てのモックアップまたはロジックのプロトタイプで設計上の質問に答える -> plan-prototype
• コミットメッセージを作成する、または変更をコミットする -> インストール済みの場合は commit-work
• PR を作成または更新する、積み重ねた PR を提出する、またはスタックのマージループを実行する -> インストール済みの場合は manage-pr
• 分離された worktree を設定する、または古い worktree を整理する -> インストール済みの場合は manage-worktrees
• コーディング規約に関する質問に答える、または構成や検証の判断の根拠を示す -> インストール済みの場合は coding-standards

明確でリスクの低い作業は、直接進めてもかまいません。実行の規律や続行時のコンテキストが実質的に役立つ場合は、implement-work を使用してください。

具体的なアーキテクチャレビューには review-work を使用してください。動作を維持する簡素化を明示的に選択済みの場合は simplify-work、それ以外の決定済みの変更には implement-work、改善の機会やインターフェースの形状をまだ探る必要がある場合は improve-architecture を使用してください。

複数のスキルが該当する場合は、最も具体的なものを選んでください。ユーザーがスキルを指定した場合は、それを使用してください。

コストと権限

• 質問、調査、ツール、成果物、委任、検証は、実際の不確実性とリスクに合わせてください。
• 責任者への質問はまとめて推奨案を添え、リポジトリで確認できる事実について質問しないでください。
• 結果を実質的に変え得る不足情報のみを調査し、まずローカルの証拠と一次情報を確認してください。
• レビューと診断は、ユーザーが修正または実装を明示的に依頼しない限り、読み取り専用です。
• 認可されたワークフローで依頼された、または自然に必要となる場合を除き、Plan、Roadmap、永続的なドキュメント、引き継ぎファイル、worktree、コミット、PR、issue を作成しないでください。
• すべての実装 Phase は、その Phase の範囲全体について、独立した新しいコンテキストでのレビューを終えてから完了としてください。Plan を使わずに直接実装する場合も、1 つの Phase 相当のレビュー範囲として、提出前に同じレビューを行ってください。
• Plan では、影響の大きい Task または Task グループの後にレビューのチェックポイントを追加できます。影響の小さい Task には、個別の即時レビューは不要です。
• レビューを再帰的にレビューしないでください。委任された主張は一次情報と照合し、依頼された範囲が完了した時点で終了してください。

ワークフローの状態はワークフロー成果物内で管理してください。永続的な納品成果物は、Plan または Roadmap ファイルや、ワークフロー内でのみ有効な識別子に依存してはなりません。