quick-fix

name	quick-fix
description	小規模な修正（バグ修正、UI 調整、レビュー指摘対応など）を軽量フローで反映するスキル。feature-lifecycle のような重いフェーズをスキップし、Developer が直接修正を行う。小さな変更やちょっとした修正を行う場合は、このスキルに従ってください。

Quick Fix スキル

feature-lifecycle で作成された PR に対する 微修正ワークフロー。 仕様策定・設計・E2E テスト等の重いフェーズをスキップし、Developer エージェントが直接修正を行う。

---

適用条件

以下の すべて を満たす場合に使用する:

• 既存の PR（feature-lifecycle で作成済み）が存在する
• 修正内容が小規模である（UI 調整、テキスト変更、バグ修正、レビュー指摘対応 等）
• 新規機能の追加ではない

判断基準: 修正がアーキテクチャや仕様に影響しない範囲であること。影響がある場合は feature-lifecycle に切り替える。

---

入力

入力	必須	説明
PR 番号	必須	対象の Pull Request を特定する
修正指示	必須	下記いずれかの方法で取得する

修正指示の取得方法

• A) PR レビューコメントから自動読取: gh pr view <番号> および review comments を取得し、未解決の指摘を修正対象とする
• B) ユーザーからの直接指示: 「ここを直して」等のユーザー発言をそのまま修正指示とする
• C) A + B の組み合わせ: レビューコメントに加え、追加の修正指示がある場合

---

フロー

Orchestrator 経由の場合

Orchestrator: 修正リクエスト受領
  → Developer に委譲（quick-fix モード）
    → Developer: 修正実施（下記手順）
  → Orchestrator: 完了報告

Orchestrator は Developer への委譲と完了報告のみ行う。 Reviewer / Tester / Architect の介入は行わない。

Developer が直接実行する場合

Developer が下記の修正手順をそのまま実行する。

---

修正手順（Developer）

Step	内容
1	対象 PR の feature ブランチをチェックアウト（git switch <branch>）
2	修正内容を把握する
2a	レビューコメント読取の場合: gh pr view <番号> + review comments を確認
2b	ユーザー指示の場合: 指示内容を確認
3	コード修正を実施
4	ビルド & テスト確認
5	Conventional Commits でコミット
6	既存 PR にプッシュ（git push）
7	レビューコメントへの返信（該当する場合）

Step 4: ビルド & テスト

cd src && dotnet build <YourSolution>.slnx && dotnet test <YourSolution>.slnx

ビルドまたはテストが失敗した場合は修正して再実行する（最大 3 回）。 3 回失敗した場合はユーザーにエスカレーションする。

Step 5: コミット

git add .
git commit -m "fix(<scope>): <修正内容の説明>"

• type は基本 fix を使用する
• 修正内容に応じて style, refactor, docs 等も可
• scope は github-flow スキルの scope 規約に従う

Step 7: レビューコメントへの返信

レビューコメントから読み取った指摘に対しては、修正完了後に PR コメントで返信する。

github-flow の場合:

gh pr comment <番号> --body "> **[Developer]** — Quick Fix 完了
>
> 以下の指摘を修正しました:
> - <指摘1の要約>: <対応内容>
> - <指摘2の要約>: <対応内容>
>
> コミット: <SHA>"

local-flow の場合:

PR ファイル（pull-requests/<番号>-<説明>.md）の末尾に同内容を追記する。

---

必須事項

項目	ルール
ビルド成功	dotnet build <YourSolution>.slnx が通ること
テスト成功	dotnet test <YourSolution>.slnx が通ること
Conventional Commits	fix(<scope>): ... 形式でコミット
既存ブランチ	新しいブランチは作成しない
既存 PR	新しい PR は作成しない

---

スキップするもの

フェーズ	担当エージェント	理由
仕様書 Issue 作成・更新	Product Manager	小規模修正に仕様書更新は不要
設計方針策定	Architect	アーキテクチャ影響なし
コードレビューループ	Reviewer	人間が指摘した修正を反映するだけ
E2E テスト実行	Tester	ビルド & ユニットテストで十分
完成判断	Architect	不要

---

エスカレーション

以下の場合はユーザーに判断を求める:

• ビルド / テストが 3 回連続で失敗した
• 修正範囲が当初の想定より大きくなった（feature-lifecycle への切り替えを提案）
• 修正内容が仕様やアーキテクチャに影響する可能性がある

---

参照スキル

• github-flow — Conventional Commits・ブランチ運用
• dotnet-best-practices — .NET コーディング規約
• csharp-async — 非同期プログラミング（該当する場合）