Menu
小規模な修正（バグ修正、UI 調整、レビュー指摘対応など）を軽量フローで反映するスキル。feature-lifecycle のような重いフェーズをスキップし、Developer が直接修正を行う。小さな変更やちょっとした修正を行う場合は、このスキルに従ってください。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional 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 — 非同期プログラミング（該当する場合）