swe-workflow

SWE ワークフロー

すべてのコードタスクは、まずワークフローのトリアージから始めます。範囲が限定された作業は軽量に進め、リスクが高い実装や調整の負担が大きい実装には、永続化された計画を使用します。

契約

1. まずトリアージします。 コード関連タスクへの最初の返信は、次のいずれかの宣言で始めます。

   Workflow mode: Lightweight — <reason>; success: <outcome>; plan: no.
   

   Workflow mode: Full
   Reason: <one sentence>
   Success criteria:
   - <what done means>
   Plan needed: yes
   

   厳密な機械可読契約で追加のテキストが許可されていない場合は、通常のテキストによるトリアージの前置きを追加せず、その契約に従います。スキーマで許可されている場合にのみ、トリアージフィールドを含めます。
2. 明確で局所的な変更、範囲が限定された調査、読み取り専用のレビューや探索では、軽量モードをデフォルトとします。多数のファイルを調べる場合も同様です。振る舞いのガードは適用しますが、永続化された計画は作成しません。
3. 作業にリスクがある、または元に戻すのが難しい場合、API／スキーマ／移行／セキュリティ／設定の契約を変更する場合、複数のサブシステムを結び付ける場合、広範なリファクタリング／移行／クリーンアップである場合、複数セッションまたは複数エージェントにわたる継続的な調整が必要な場合、範囲を限定した調査後も実質的な曖昧さが残る場合、またはユーザーが計画を求めた場合は、実装前にフルモードが必須です。ファイル数は判断材料のひとつですが、それだけで切り替える条件にはなりません。
4. 対象ファイルの編集前にエスカレーションします。 軽量モードでは、まず根拠を集めるために調査できます。フルモードの基準に該当することが判明した場合は、タスクファイルを変更する前に作業を止め、フルモードであることを宣言し、判断に不可欠な質問を明確にしてから計画を作成し、その後に作業を再開します。編集をすでに始めている場合は、検証済みの状態を保持し、作業範囲を広げる前にエスカレーションします。
5. 編集前のゲート（フルモード）。 タスク対象ファイルを変更する前に、plans/<YYYY-MM-DD>-<slug>/ の下に計画ディレクトリが存在し、> Status: IN_PROGRESS のステップファイルがちょうど1つあり、編集内容がそのステップに対応している必要があります。このゲートを通過する前でも、読み取り専用の調査とワークフローの記録更新は許可されます。
6. 計画ファイルの形式。 references/task-overview-template.md を plan.md にコピーし、references/step-template.md を各ステップファイルにコピーします。各ステップには、Status、Goal、Prerequisites、Deliverables、Plan、Quality Checklist、Validation Checklist、Test Checklist、Implementation Notes、Files Changed の10項目があります。
7. 確認のゲート（フルモード）。 リポジトリの根拠からは判断できない、意思決定に不可欠な質問だけをします。有効な計画では Open Questions: None. とします。計画の承認は、実行前に通常必要となる唯一の承認です。
8. 一度に書き込みを行うステップは1つだけです。 アクティブな作業ツリーへの書き込みを許可できるステップは、ちょうど1つだけです。独立した読み取り専用の調査や検証は並行して実行できます。既知の失敗がある状態で COMPLETED にしてはいけません。許可されたステップで修正するか、BLOCKED とします。

委任モード

次の条件をすべて満たす場合は、トリアージ／計画／編集前ゲートを省略します。

1. オープンエンドなユーザー依頼ではなく、別のエージェントまたはオーケストレーターから割り当てられたタスクである
2. 明示的な範囲、成功基準、または受け入れ契約が提示されている
3. 実装者、レビュアー、アナリストなど、特定の役割に集中している

委任モードでは、すべての振る舞いのガードと references/code-quality.md に従います。変更したファイル、実行したコマンド、検証の根拠、予想外の事象を報告します。承認されていない設計／アーキテクチャ上の判断はエスカレーションし、範囲内で作業します。

ステータス

計画レベル（plan.md）：DRAFT → ACTIVE → COMPLETED → ARCHIVED ステップレベル（steps/step-N.md）：PENDING → IN_PROGRESS → COMPLETED | BLOCKED

書き込みを行うステップのうち、IN_PROGRESS にできるのは一度に1つだけです。編集前のゲートでは、ステップレベルのステータスを確認します。実行ステップが終了しても計画は ACTIVE のままとし、全体の振り返りに合格した後にのみ COMPLETED にします。

リファレンスの読み込み

現在のフェーズで必要なものだけを読み込みます。

• 計画： references/create-plan.md、references/task-overview-template.md、references/step-template.md
• 実行： references/execute-step.md、references/code-quality.md
• 検証： references/verify-step.md
• コマンドの確認： references/command-discovery.md
• リスクのレビュー： references/risk-classification.md
• プロジェクトのセットアップ： references/project-agents-template.md

動作上のガード

セッション全体で有効です。逸脱しないでください。

1. まず根拠を確認 — 編集前に対象ファイルを読みます。共有動作を変更する前に、呼び出し元や使用箇所を検索します。根拠の状態が重要な場合は、Verified／Assumption／Unknown を区別し、重要な主張の根拠を示します。
2. 近道を防ぐゲート — 編集前に、対象の読み込み ✓、影響範囲の検索（または N/A — isolated）✓、検証コマンド（または省略理由）✓ を確認します。
3. コードで考える — 集計分析では、多数のファイルをそのまま出力するより、結果を算出する短いスクリプトやコマンドを優先します。出力が多い場合は /tmp に保存し、範囲を絞って表示します。
4. 最小化の順序 — コードを追加する前に、次の順に検討します。不要なら削除またはスキップ → 標準ライブラリやネイティブ機能 → 既存の依存関係やヘルパー → 最小限で安全な実装。セキュリティ、データの安全性、アクセシビリティ、明示された要件を決して削りません。
5. 必要箇所だけを変更 — 必要なファイルや行だけを変更し、既存の書式、命名、規約に従います。劣化したパターンをコピーしません。
6. 実装の品質 — ローカルのパターンに従い、既存の同等機能を検索します。完全な変更を、できるだけ小さく実現します。ビジネスルールを重複させたり、推測に基づく抽象化、オプション、依存関係、リファクタリングを追加したりしません。共有動作については、回帰の影響範囲を特定し、要求された動作と維持される動作を検証します。DRY の原則は、時期尚早な抽象化や範囲外の整理を正当化しません。
7. 設計の規律 — 設計上の選択を黙って行いません。決定事項を提示し、ユーザーの確認を求めます。アプローチが既存の規約または Design Decisions テーブルに沿っていることを確認します。
8. 目標を重視 — コードを書く前に成功の条件を定義します。テスト、lint、ビルド、型チェックで検証します。新しいコードやバグ修正には、対象を絞ったテストを追加します。新たに発生した問題を修正するか、阻害要因として報告します。
9. STE に着想を得た文章作成（必須） — エージェントが書くすべての文章にこのスタイルを適用します。短く、直接的な文を使います。1 文につき主な考えは 1 つにします。用語を統一します。it、this、その他の指示語が曖昧になり得る場合は、指示対象を明示します。この規則は、回答、引き継ぎ、計画、レポート、ドキュメント、コメント、docstring に適用します。通常のプログラミング用語、識別子、コード、コマンド、パス、引用、生成コンテンツ、サードパーティーのコンテンツ、厳密な形式の意味は変えません。正式な ASD-STE100 準拠を主張しません。この規則を適用するためだけに、無関係な文章を書き換えません。
10. まず回答 — 必要なトリアージの後、回答または結果を先に述べます。重要な根拠、検証、不確実性、注意事項、残存リスクを含めます。重要な所見を省略せず、繰り返しや不要な説明を削ります。明確さの向上に役立つ場合に限り、見出し、リスト、表、根拠ラベルを使います。JSON などの機械可読な契約は厳密に保持します。

ワークフローの全フェーズ

1. 明確化 — リポジトリの情報では解決できない、意思決定に不可欠な曖昧さのみを解消します。詳細はreferences/require-clarification.mdを参照してください。
2. 計画 — 垂直スライスのステップに分割します。詳細はreferences/create-plan.mdを参照してください。
3. 実行 — 一度に1つのステップを進めます：references/execute-step.md → references/verify-step.md → references/persist-plan.md。2～3ステップごとに、references/checkpoint.mdを実施します。中断する前に、コンテキストを出力します。
4. 振り返り — すべての実行ステップが完了した後も、計画をACTIVEのままにします。最終的な計画の完了はreferences/global-reflection.mdが担当します。

再開プロトコル

新しいセッションでは、plans/context.md → 関連するplan.md → 現在のステップファイルの順に読み込みます。詳細はreferences/resume-workflow.mdを参照してください。