jira-fix-workflow

Jira バグ修正ワークフロー

Jira のバグ修正を最初から最後まで実行するフローです。ステージ 1～6 は読み取り専用です。手動モード（デフォルト）では、ステージ間で確認が必要です。

前提条件：PAT／認証情報は jira-read の認証情報コントラクトに従います（環境変数 JIRA_PERSONAL_TOKEN、エイリアス JIRA_PAT、または ~/.config/jira-certs/jira-pat.txt）。mcp-atlassian は任意です。Git 環境が正常に動作している必要があります。 形式のリファレンス：出力テンプレート、状態ディレクトリ、コミット形式、終了スクリプトについては、reference.md を参照してください。

トリガーとモード

言い回しの例	モード	備考
「このバグを修正 [URL]」「[URL] を修正して」「jira-fix [URL]」	👤 手動	デフォルト。解決策／計画／コミットにはユーザーの確認が必要です
「自動修正 [URL]」「[URL] を自動モードで修正」「jira-fix [URL] --auto」	🤖 自動	確認なしで全フローを実行します
「強制修正 [URL]」「[URL] を分級修復をスキップして修正」「jira-fix [URL] --force」	🤖 自動	難易度評価をスキップし、自動実行を強制します
「修正を続行 [URL]」「再度修正 [URL]」「jira-fix [URL] --retry」	👤 手動	ステージ 0／1 をスキップし、ステージ 3 から再分析します
「前回の続きから」「修正を再開 [URL]」「jira-fix [URL] --resume」	現在のモード	最後のチェックポイントから再開します
「ai-proxy モード」「AI プロキシモード」「ai-proxy に切り替え」	オーバーレイ	自動の実行主体です。ai-proxy-discipline に従って、薄いフリーズの後に占有します

モード検出：オーバーレイのトリガー（「ai-proxy モード」「AI プロキシモード」「ai-proxy に切り替え」／"ai-proxy mode"／"switch to ai-proxy"）は、workflow-mode-lifecycle に従ってオーバーレイを要求します。自動とオーバーレイの両方が指定された場合は、オーバーレイ＋フリーズが優先されます。それ以外では、「自動」／--auto を含む場合は自動モード、「強制」／「分級をスキップ」を含む場合は評価をスキップ（自動）、「修正を続行」／「再度修正」／--retry を含む場合はステージ 3 から再開、「前回の続きから」／「再開」／--resume を含む場合はチェックポイントから再開し、それ以外は手動モードです。

無人プロキシの終了処理

今回の実行のコントラクトまたはタスクカードに Stage-exit policy: ai-proxy（自動の実行主体。キューの子タスクがあれば十分ですが、必須ではありません）が記録されている場合、各手動停止ポイントは ai-proxy-discipline に従ったプロキシのチェックポイントになります。薄いフリーズ（口頭でのトリガー ≠ 占有）はここで行います。マージ、不可逆な操作、保護ブランチ、Jira への書き戻しは人間のみが行います（保留＋チケット）。それ以外のポリシー値が設定されている場合、または未設定の場合は、従来の非プロキシ動作になります。

停止ポイントの予測：この実行を開始する時点でコントラクトがフリーズ済みの場合（問題とフリーズ済みの決定事項があるキューの子タスク、または独立した薄いフリーズがすでに書き込まれている場合）、分析の前に予測テーブルを出力します。すべての手動終了ポイントについて、フリーズ済みの決定事項で対応済みか、新しいチケットを作成するかを示します。実行の途中でオーバーレイが要求された場合は、薄いフリーズの後に残りの終了ポイントを予測してから、現在のステージを続行します（分析から再開しません）。

強い依存関係と前提条件の確認

強い依存関係はフロントマターの dependencies に記載されています。ステージ 0 の合格後、ステージ 1 の前に利用可能なスキルを確認します。不足がある場合は、構造化された通知を出力し、直ちに中止します（形式は solve-workflow/reference.md を参照）。縮退動作はありません。

モードのライフサイクル

コア規則は workflow-mode-lifecycle にあります。「全フロー完了」とは、ステージ 0～10 が正常に終了した状態です（各ステージの最終終了処理を含みます）。失敗による中止／🔴 極めて困難な場合の終了／ユーザーによる停止／レビュー上限到達による介入終了のいずれの場合も、手動モードに戻ります。自動モードを再開するには、明示的なトリガーが必要です。「修正を続行」「もう少し変更」などの暗黙的な続行では再有効化されません。

このワークフロー固有の差異：ステージ 9 の完了／ステージ 10 のマージ完了／🔴 極めて困難な場合の終了（自動モード）では手動モードに戻ります。ステージ 8 でしきい値未満となりロールバックする場合は現在のモードを維持します（自動モード、ロールバックは最大 2 回）。--retry は手動モードにリセットし、--resume はチェックポイントのモードを維持します。

キューチャイルドモード（goal-driven-queue ディスパッチ）

goal-driven-queue によってディスパッチされた場合（呼び出し時に明示的な queue-child コンテキストフラグがある場合。周囲のシグナルから推測してはいけません）、このフローは次のように適応します。カードの目標条件に Jira 課題へのリンクが含まれ、凍結された決定事項ブロックがステージ 0〜1 を規定します。Stage-exit policy も引き継がれます（占有状態は上記の Unattended ポインターによるもので、このフラグ固有のものではありません）。最初に停止ポイントの見通しを示します（すべての手動終了ポイントについて、凍結された決定事項でカバーされるか、新しいチケットが作成されるかを示します）。最終地点は PR オープン です。ステージ 9 の後に、記録のみのクローズアウトを行って停止します。ステージ 10（マージと Jira への書き戻し）は人間に委ねられます（マージ権限と外部トラッカーへの書き戻しを代理で行うことはありません）。キューの受け入れパッケージでは、それらを未対応のフォローアップとして扱います。独立して使用する場合（フラグなし）、オーバーレイ／占有状態は引き続き Stage-exit policy と Unattended ポインターに従いますが、最終地点の PR オープン は適用されません。クローズアウトはこのスキルのステージ 9〜10 で行います（オーバーレイによってマージ／書き戻しまで無条件に自動実行されることはありません）。この実行がキューの子である場合、完了レポートには問題、原因、完了した修正、およびエビデンスの一覧を含めます。各エビデンス項目には、png、jpg、jpeg、webp のパスを示す、UI を開いて確認したチェック、またはコマンドと短い出力概要を示す、UI 以外のチェックを記載します。画像が見つからない、または空の場合は保留とし、キャプチャがまだ必要であることを明記します。画像を捏造してはいけません。UI を開いて確認した画像をチェックの裏付けとして使う前に、completion-evidence-discipline に従って検査してください。この実行では HTML ページもエビデンス HTML も作成しません。

⚡ クイックリファレンス（実行前に読むこと）

ステージ	編集／書き込み	Bash	👤 手動の停止ポイント	🤖 自動の停止ポイント	必須の出力
0 前提条件の確認	❌	✅（worktree ゲート）	失敗時は中止、成功時は→1	失敗時／P0 は中止、成功時は続行	確認の概要
1 Jira の読み取り	❌	❌	→2	→2	Jira の概要
2 理解のすり合わせ	❌	❌	⛔ 確認を待つ→3	スキップ→3	言い換え＋曖昧な点
3 分析	❌	❌	存在確認に失敗したら停止、完了→4、その後⏸️→5	存在確認に失敗したら停止、完了後は続行	根本原因＋難易度
4 難易度評価	❌	❌	🔴⛔ A／B を提示、それ以外は個別に停止しない	🔴⛔ 終了、それ以外は続行	難易度評価
5 解決策のレビュー	❌	❌	⛔ 解決策を選択、⛔ レビュー後	レビューが 3 ラウンドを超えた場合は⛔	解決策の表＋レビュー
6 計画	❌	❌	⛔ 確認を待つ	高難易度／高リスクの場合は⛔	変更一覧
7 実行	✅	✅	⛔ レビューを待つ。複数リポジトリの場合は、まずブランチを確認	高難易度の場合は⛔ レビューを待つ	実行レポート
8 検証	❌	✅ テスト	⛔ 確認を待つ	合格→9、基準未達なら最大 2 回ロールバック	検証結果
9 提出	❌	✅ git／CLI	⛔ 確認後、push＋PR	自動で push＋PR	完了レポート＋URL
10 マージ	❌	✅ マージ／任意のカバレッジ	⛔ 確認後、マージ	⛔ 同様。確認が必要	マージ／クリーンアップ／Jira レポート

ステージ 7：まずブランチを作成します。ビルド／lint／tsc の前に node-version-discipline を呼び出してください。ステージ 10 のパート C では、ユーザーの希望／依頼に基づいてカバレッジアナライザーを実行するかどうかを決定します。

ステージごとの自動／手動の違い：reference.md § モードの違い：クイックリファレンス。

一般原則

• 発言する前に調査する：コードの根拠なしに結論を出してはいけません
• 積極的に質問する：clarifying-question-discipline に従ってください（1 回のターンにつき質問は 1 つ。不明点がなくなるまで複数回質問します。まず明確化し、回答を急がないでください）。ドメイン固有の語彙が使われている場合は、domain-language-discipline にも従ってください。
• Jira ステータスの境界：エンジニアリング側が課題を「已修复」（修正済み）に遷移させるのはここまでです。クローズ／検証済みへの変更は QA の担当です

パスの選択

ステージ 4 の評価後に選択します。アップグレードはできますが、ダウングレードはできません。

パス	適合条件	要件
Lean	🟢 簡単	解決策 1 つとリスクに関する注記があれば十分です。計画にまとめてもかまいません。ステージ 8/9 は省略できません
Standard	🟡 中程度	ステージ 1～10 をすべて実行します
Full	🟠 難しい / 🔴 B を選択する場合は非常に難しい	すべてのステージを実行します。ステージ 7 の後にレビューのため中断します

手動モードでアップグレードするには、ユーザーの確認が必要です。

状態の永続化（中断からの復旧）

再開：state.json が存在する場合、🤖 自動モードでは current_phase から続行します。👤 手動モードでは再開するか確認します。実行用の台帳が context-budget-discipline に従って存在する場合は、履歴を再生する代わりに、台帳とそこから参照される成果物から状態を再構築します。クリーンアップ：完了時に current_phase: "completed" を設定します。ディレクトリ構成とスキーマについては、reference.md § State Directory and state.json を参照してください。

--retry（ステージ 3 への再入）：0/1 をスキップします。既存の 01-jira-info.md を読み込み、「前回修正した内容／新しい症状」を一度だけ確認します。「今回の反復のコンテキスト」を 02-analysis.md に書き込み、状態をリセットします（current_phase: 3、completed_phases: [0,1]、grade/selected_option/review_* をクリア）。ブランチ名に -v2/-v3…を追加します。根本原因がまだ不明な場合は、計装によるデバッグを優先します。

---

ステージ 0：前提条件の確認

いずれかの確認に失敗した場合、フローを中止します。

1. モードを検出します（--force / --resume / overlay を含む）。Overlay の場合は、ai-proxy-discipline に従ってリクエストのフリーズを簡略化し、その後に占有を行います。最初に永続化する書き込み（state.json、ドキュメント、またはコード）の前に、git-worktree-discipline（worktree のゲートと任意の分離）を読み込み、その後モードを state.json に書き込みます
2. jira-read に従って認証情報を解決します（mcp-atlassian がないことだけを理由に中止しないでください）。そのツールがある場合は、接続確認に MCP の jira_get_issue を優先します。ない場合は、ローカルの jira-read キャッシュにフォールバックします。課題データをまったく取得できない場合に限り中止します。
3. P0 の割り込み（自動モードのみ）：P0 → 中止し、手動モードに切り替えます
4. Git：🤖 dirty の場合→stash します。👤 dirty の場合→対処方法を確認します

出力： reference.md § Stage 0。成功したら、ステージ 1 に直接進みます。

---

ステージ 1：Jira 情報の読み込み

jira-read の認証情報チェーンに従った後、jira-read {JIRA-ID} --live を呼び出します（キャッシュにフォールバック → さらに手動対応／中止にフォールバック）。01-jira-info.md に保存します。抽出する項目：ID、タイトル、優先度、ステータス、説明、再現手順、期待される結果／実際の結果、添付ファイル、コメント。出力：reference.md § Stage 1。ツール：✅ mcp / jira-read、❌ Edit/Write/Bash。ステージ 2 に直接進みます。

パフォーマンス領域の課題（遅い／カクつく／リソース増加）：perf-optimize-workflow のエビデンスに基づく手法（ベンチマークのベースライン → エビデンスゲート → 1 つの対象ごとの反復 → A/B 判定）に従って分析、最適化、検証を実施し、その結論をこのワークフローの各ステージに反映します。Jira のオーケストレーション（ブランチ、MR、書き戻し）はこのワークフローで行います。注：この手法のキャンペーンでは、プロジェクトごとの成果物（ベンチマークログとハーネス、およびシード済みの code-insight/code-optimizer スキル）がリポジトリ内に作成されます。修正と一緒にコミットしてください。最適化と検証のループでは、環境ループランナーも必要です（分析ステージは常に実行します）。参考情報であり、依存関係ではありません。

---

ステージ 2：理解のすり合わせ

ステージ 1 での理解を言い換え、不明点を明らかにします。コードを読むことは禁止です。🤖 自動モードではスキップしてステージ 3 に進みます。👤 手動モードでは、ステージ 3 に進む前に確認が必要です。

出力：問題の言い換え（技術的な判断は含めない）／主要な要素／不明点（1 ターンにつき質問 1 つ）／スコープの分解（該当する場合。コードの調査は引き続き行わない）。形式：reference.md § Stage 2。02-alignment.md に保存します。

---

ステージ 3：問題を分析する

analysis-core §§1-3 を読み込みます。ステージの出力は、分析ゲートの出力ブロック（analysis-core §5 — レッドループ／デバッグエントリー／シナリオ補足／一時的な変更）で必ず締めくくってください。このブロックがない場合、ステージ 4 には進めません。対応関係：{next-stage} = ステージ 4「難易度評価」；{root-cause step} = 根本原因分析；{impact-assessment step} = 影響範囲；{upstream-eval step} = 上流依存関係の修正評価。期待される成果が、ユーザーが確認または操作できる結果である場合、同じ読み込みで analysis-core に従い competitive-research も実行します。その方法を再説明しないでください。

ワークフロー固有の違い：① 業界全体の問題に関する評価はゲートです。② 🚫 実行可能な修正策がない場合 → 報告して停止し、ステージ 5 に進まないでください + Jira コメントを記入します（jira-wiki-markup を読み込みます。テンプレートは reference.md を参照）。③ 存在確認 ❌ → 停止 + Jira コメント（jira-wiki-markup を読み込みます）+ ユーザーを待ちます。④ 成果物 02-analysis.md（難易度の事前評価を含みます）。

👤 ステージ 4 に直接進み、評価を出力の末尾に追記した後、⏸️ 確認のため一時停止してから →5 に進みます。 🤖 → ステージ 4。

---

ステージ 4：難易度評価 + モード決定ゲートウェイ

🔴 非常に難しい（次のいずれかに該当）

根本原因が不明 | アーキテクチャの変更 | データ移行 | API プロトコルの変更 | 推定ファイル数が 10 を超える、または行数が 500 を超える | リポジトリ間／サービス間

その他の評価

ファイル数 ≤3 かつ根本原因が明確 → 🟢；4-10 かつほぼ明確 → 🟡；≤10 だが、大きな変更を伴い、やや不明確 → 🟠

モード × 評価

評価	🤖	👤
🟢/🟡	通常どおり実行	自動モードへの切り替えを提案してもかまいません。手動で続行します
🟠	ステージ 7 の後にレビューのため一時停止	通常の手動操作
🔴	終了 + レポートにフラグを付ける	リスクを通知し、A/B を選択

評価を 04-grade.md に記入し、grade を明記してパスを宣言します。テンプレート：reference.md § Stage 4。👤 非常に難しいケース以外では個別に停止しません。🔴 の B 選択スクリプトは reference.md にあります。🤖 非常に難しくない場合 →5。

---

ステージ 5：解決策を調査してレビューする

方針がまだ不明瞭な場合は、解決策の表を作成する前に decision-fog-discipline に従います。解決策を 2-3 件提示します（YAGNI）。🤖 自動選択（優先順位：網羅性 > ベストプラクティス > コード品質 > 最小限の変更）→ レビュー。👤 希望が不明な場合は一度だけ質問し、その後、比較表を提示します。

アーキテクチャ境界の事前確認（判断の順序）：候補となる解決策がプロセスまたはレイヤーの境界を越える場合、短期的なコスト（変更規模／再利用／単一リポジトリ）を検討する前に、事前確認に回答します — (1) 実行時の初期化場所：呼び出される機能を初期化するプロセス／レイヤーはどこか；(2) 境界の妥当性：レイヤーをまたぐインポートによって、呼び出し先の依存関係ツリーが呼び出し元のバンドルグラフに取り込まれるか（バンドラーが静的に事前スキャンするため、回避策としての動的な require/import では防げません）；(3) 所有者の分類：システムの機能か、データ／製品の機能か、呼び出し側レイヤーの位置づけか。境界に関する判定は比較表とともに提示し、自動モードの選択可否を決定します。方法論：code-design-review のレイヤー A、依存方向の評価軸。単一レイヤー内の解決策では、この事前確認は不要です。

出力：一覧 → 詳細説明 → 1 つの比較表（reference.md § Stage 5 Solution Comparison を参照）→ 03-options.md。👤 比較表の後で停止します。

レビュー：staged-review-flow を読み込みます。対応関係：{next-stage} = ステージ 6；{artifact-sink} = 03-options.md；{extra-dimensions} = なし；{batch-overcap-behavior} = 「レビュー失敗（上限）」と記録して次の問題に進みます。✅ 読み取り；❌ 編集／書き込み／Bash。

---

Stage 6: 計画を立てる

必須項目：根本原因と解決策の要約、アーキテクチャ（Mermaid は任意）、ファイル変更表、作業順序、テストシナリオ、影響範囲、ロールバック。04-plan.md に保存します。

シナリオ	動作
🤖 通常	自動で→7
🤖 🟠 またはリスクが中程度を超える場合	確認のため一時停止
👤 通常	確認を待つ
👤 🔴 B を選択	2 回目の確認が必要：「リスクを理解しました。続行します」

終了スクリプト：reference.md。

---

Stage 7: 計画を実行する

本番環境への変更を行う前に、design-approval-gate に従います（手動：ユーザーの承認、自動／強制：名前付きの例外措置と記録）。

コンテキスト予算：context-budget-discipline に従い、フェーズ境界でのリセットと圧縮のしきい値を評価します（台帳のパスはステージ 6 の計画／カードから取得）。リセットする場合は、事前に台帳へ完全な記録を残す必要があります。

**Figma のピクセル忠実度：**目標、カード、課題、または計画のテキストに figma.com または node-id= が含まれる場合、あるいはユーザーがピクセル単位での復元（像素级还原）を求めた場合は、figma-pixel-implement を読み込み、それに従います。この部分文字列がスコープを決定します。該当する行はハード要件として維持し、タスクで動作も確認するからといって、ソフト要件や人手による確認の対象にしてはいけません。表示テキストの確認、表示フラグ、リストの長さでは、ピクセル要件を満たしたことになりません。同じテキストに 参考、match the existing、または same as も含まれる場合は、その情報を verify に渡し、指定されたコントロールの操作状態を行として追加します。実装は、対象リポジトリ内に永続的なインベントリと仕様のパスがなければ完了ではありません。このスキルは、全体が PASS になるか、計測コマンドを実行できなくなるまで、同じ実行内で figma-pixel-verify に引き継がれます。ここでその手法を繰り返し説明しないでください。

ブランチ：命名と単一／複数リポジトリのフローについては、reference.md § Stage 7 Branch-Creation Details を参照し、00-branch.md に記録します。

計画に厳密に従って実行し、TodoWrite／計画のチェックボックスを項目ごとに完了した時点でチェックします。すべての変更に // fix [JIRA-ID] を付けます。品質ゲート：node-version-discipline → ReadLints → tsconfig が存在する場合は typescript-check。🤖 複数リポジトリにまたがる変更と lint はリポジトリごとに実施し、reports/[JIRA-ID]-analysis.md に記録します。

実行後：🤖 通常→8、🟠 レビューのため一時停止。👤 通常は確認を待って→8、🔴 B を選択した場合は自動コミットせずに一時停止します。レポート→05-execution.md。動作変更の場合は test-first-discipline に従います。ビジネスロジックにテストがない場合は、test-suite-ensure を呼び出します（mode=advisory）。test-suite-ensure は test-first の要件を満たしません。終了スクリプト：reference.md。

---

Stage 8: チェックと検証

結果のみを出力してください。コードは変更しないでください。コンテキスト予算：リセットが発生した場合は、台帳と成果物に照らして検証してください（context-budget-discipline に従う）。前のセッションの履歴を再生しないでください。Jira の再現手順／期待結果、Stage 6 の計画、テスト、副作用、根本原因を比較してください。デバッグと検証のループには analysis-core §4 を使用してください。検証の実行は runtime-verification-discipline に従います（AI が環境内で検証を自ら実行し、分類された真のハード境界に限って、その理由を明記したうえでユーザーに手順を依頼します）。目標、カード、課題、計画に figma.com または node-id= が含まれている場合、もしくは今回の実行で Figma を基に実装した場合は、figma-pixel-verify を読み込んでその手順に従ってください。計測レポート（作業中の成果物の Verify セクション、または Spec のソースと同じ階層にあるファイル）がない場合、この検証ステージは合格できません。Spec の不足による FAIL は検証合格になりません。表を完成させるため、figma-pixel-implement に戻ってください。同じ実行内で実装を行っていない場合でも、位置合わせの確認が必要なら読み込んでください。このステージに合格するには、そのレポートの全体ステータスが PASS（受け入れ済みの残存事項を含む）であり、かつチャンネルがレイアウト計測結果（storybook、isolated-harness、preview、full-app、または layout-probe）である必要があります。それ以外の結果はすべてこのステージで不合格となり、修正と再計測のループのため実装ステージに戻ります。このステージでは、レポートに対して figma-pixel-verify スキルの scripts/check-figma-verify-report.mjs も実行します。終了コードが 0 以外の場合、このステージは不合格です。検証レポートの誠実性については、staged-review-flow と completion-evidence-discipline に従ってください。テンプレート：reference.md § Stage 8。

判定	次へ
✅	→9
❌	実装エラー→7、解決策の欠陥→5、根本原因の特定が不完全→3

🤖 しきい値未満の結果では自動的にロールバックします。上限は 2 回で、その後一時停止します。👤「通过」（合格）／「返回修复」（修正に戻る）／「重选方案」（解決策を再選択）を待ちます。06-verification.md を保存してください。

---

Stage 9: PR/MR の提出

コンテキスト予算：レポートの作成時は、トランスクリプト全体ではなく、台帳と参照先の成果物を読み込みます（context-budget-discipline に従う）。

delivery-discipline を読み込み、その手順に従ってください。以下を用意します。

• {commit-context}：type／scope／subject／jira_id（メッセージ形式は reference.md § Commit Message Format を参照。Jira ID を必ず含めてください）
• {pr-body-extra}：根本原因、解決策、ファイル、検証シナリオ（機能／境界／回帰の各カテゴリで 2 件以上）、Jira リンク

👤 配信計画を提示した時点で停止してください。ユーザーの確認後、AI が実行します。🤖 はそのまま実行します。完了時の出力：reference.md § Stage 9 → 07-report.md。

---

Stage 10: レビューとマージ

PR/MR の URL を提示します（Stage 9 のもの）。クローズ処理のメニュー（PR がすでに開いている場合は通常、マージ／保持／続行）を確認するため、feature-branch-closeout を読み込みます。自動実行と手動実行のどちらでも、マージ前にユーザーの確認が必要です。

マージが選択されたら：

1. feature-branch-closeout が merge-discipline を読み込みます（Part A→B→C→R→D。チェックリストはそのスキルの reference.md を参照）
2. マージ（gh pr merge --merge／glab mr merge）→ リモートの修正ブランチを削除 → デフォルトブランチを同期 → ローカルブランチを削除
3. jira-status-writeback を読み込みます（フィールドマップ：ブランチ、コミット、PR URL、根本原因、解決策、ファイル、レポート、検証シナリオ）。書き戻しに失敗しても完了を妨げません。Jira に直接コメントする場合は、jira_add_comment の前に jira-wiki-markup を読み込みます。

08-merge.md を作成し、current_phase: "completed" を記載してください。

振り返り（learn-and-improve に委任）

Stage 10 のクローズ処理（マージと書き戻し、または保持／続行）の後、learn-and-improve を読み込み、そのフレームワークに従ってください。振り返りの手法をここに改めて記載しないでください。

---

安全機構（自動モード）

変更前に stash してください。ファイル数が 10 を超える場合、または変更行数が 500 行を超える場合は警告してください。ファイル数が 20 を超える場合、または変更行数が 1000 行を超える場合はブロックしてください（--force が必要です）。リンターエラーがある場合はブロックしてください。レビューのループは最大 3 回までとし、自動的な判断はすべて記録してください。

---

よくある間違い

ここでは、気づきにくい落とし穴のみを記載しています。マージ → merge-discipline、書き戻し → jira-status-writeback、コメントの Wiki マークアップ → jira-wiki-markup、業界全体／上流の問題 → known-issue-research / upstream-dependency-debug。ステージ本文ですでに説明されているルールは繰り返しません。

間違い	対処
👤 がステージ 2 を省略する、またはステージ 2 でコードを読む	まず認識を合わせます。ステージ 2 では Jira 情報のみを扱います
存在確認の不一致があっても続行する	停止して Jira にコメントし、確認を待ちます
🤖 が🔴の状態でも実行する、一時停止せずに 2 回を超えてロールバックする、または確認なしにマージする	ステージ 4 のゲートウェイに従います。上限に達したら一時停止します。マージには必ず確認が必要です
// fix [JIRA-ID] がない	すべての変更にタグを付けます

---

一括修正

jira-fix-queue スキルを使用します（薄いシェル：Jira のリストを解析し、Engine: jira-fix-workflow を指定して goal-driven-queue に登録します。このワークフローのループ処理やマージは行いません）。