quick-fix

# 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: ビルド & テスト ```bash cd src && dotnet build <YourSolution>.slnx && dotnet test <YourSolution>.slnx ``` ビルドまたはテストが失敗した場合は修正して再実行する（最大 **3 回**）。 3 回失敗した場合はユーザーにエスカレーションする。 ### Step 5: コミット ```bash git add . git commit -m "fix(<scope>): <修正内容の説明>" ``` - type は基本 `fix` を使用する - 修正内容に応じて `style`, `refactor`, `docs` 等も可 - scope は `github-flow` スキルの scope 規約に従う ### Step 7: レビューコメントへの返信 レビューコメントから読み取った指摘に対しては、修正完了後に PR コメントで返信する。 **github-flow の場合:** ```bash 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` — 非同期プログラミング（該当する場合）