القائمة
小規模な修正（バグ修正、UI 調整、レビュー指摘対応など）を軽量フローで反映するスキル。feature-lifecycle のような重いフェーズをスキップし、Developer が直接修正を行う。小さな変更やちょっとした修正を行う場合は、このスキルに従ってください。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Prompt for creating the high-level technical architecture for an Epic, based on a Product Requirements Document.
Modular Monolith + Clean Architecture の設計ガイド。新しいモジュールの作成、画面の実装、機能追加を行う際には、必ずこのスキルを参照して従ってください。
playwright-cli を使った E2E テストの実行スキル。ブラウザを headless モードで起動し、テスト結果をスクリーンショットとして screenshots/ 配下の日付付きフォルダーに保存する。E2E テストを実行する際には、必ずこのスキルに従ってください。
大きな機能を実装する際に使用するワークフロースキル。6 つのカスタムエージェント（Orchestrator / Product Manager / Architect / Developer / Reviewer / Tester）が協調し、仕様策定から実装・テスト・マージまでの全ライフサイクルを自律的に駆動する。新機能の追加や大規模な変更を行う場合は、必ずこのスキルに従ってください。
このリポジトリでの開発フロー（GitHub Flow）を定義するスキル。feature ブランチの作成から Draft PR、レビュー、Squash Merge までの一連の作業手順とルールを示します。コードを変更する作業を行う場合は、必ずこのスキルに従ってください。
GitHub API を使わずローカルファイルで Issue / PR を管理する開発フロー。デモ・オフライン環境向け。github-flow の代替として使用する。
| name | quick-fix |
| description | 小規模な修正（バグ修正、UI 調整、レビュー指摘対応など）を軽量フローで反映するスキル。feature-lifecycle のような重いフェーズをスキップし、Developer が直接修正を行う。小さな変更やちょっとした修正を行う場合は、このスキルに従ってください。 |
feature-lifecycle で作成された PR に対する 微修正ワークフロー。 仕様策定・設計・E2E テスト等の重いフェーズをスキップし、Developer エージェントが直接修正を行う。
以下の すべて を満たす場合に使用する:
判断基準: 修正がアーキテクチャや仕様に影響しない範囲であること。影響がある場合は
feature-lifecycleに切り替える。
| 入力 | 必須 | 説明 |
|---|---|---|
| PR 番号 | 必須 | 対象の Pull Request を特定する |
| 修正指示 | 必須 | 下記いずれかの方法で取得する |
gh pr view <番号> および review comments を取得し、未解決の指摘を修正対象とするOrchestrator: 修正リクエスト受領
→ Developer に委譲（quick-fix モード）
→ Developer: 修正実施（下記手順）
→ Orchestrator: 完了報告
Orchestrator は Developer への委譲と完了報告のみ行う。 Reviewer / Tester / Architect の介入は行わない。
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 | レビューコメントへの返信（該当する場合） |
cd src && dotnet build <YourSolution>.slnx && dotnet test <YourSolution>.slnx
ビルドまたはテストが失敗した場合は修正して再実行する（最大 3 回）。 3 回失敗した場合はユーザーにエスカレーションする。
git add .
git commit -m "fix(<scope>): <修正内容の説明>"
fix を使用するstyle, refactor, docs 等も可github-flow スキルの scope 規約に従うレビューコメントから読み取った指摘に対しては、修正完了後に 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 | 不要 |
以下の場合はユーザーに判断を求める:
github-flow — Conventional Commits・ブランチ運用dotnet-best-practices — .NET コーディング規約csharp-async — 非同期プログラミング（該当する場合）