| 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 — 非同期プログラミング（該当する場合）
