بنقرة واحدة
local-flow
GitHub API を使わずローカルファイルで Issue / PR を管理する開発フロー。デモ・オフライン環境向け。github-flow の代替として使用する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
GitHub API を使わずローカルファイルで Issue / PR を管理する開発フロー。デモ・オフライン環境向け。github-flow の代替として使用する。
التثبيت باستخدام 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 までの一連の作業手順とルールを示します。コードを変更する作業を行う場合は、必ずこのスキルに従ってください。
小規模な修正(バグ修正、UI 調整、レビュー指摘対応など)を軽量フローで反映するスキル。feature-lifecycle のような重いフェーズをスキップし、Developer が直接修正を行う。小さな変更やちょっとした修正を行う場合は、このスキルに従ってください。
| name | local-flow |
| description | GitHub API を使わずローカルファイルで Issue / PR を管理する開発フロー。デモ・オフライン環境向け。github-flow の代替として使用する。 |
GitHub API(gh CLI)を使用せず、リポジトリ内の Markdown ファイルで Issue と PR を管理する開発フローを定義する。
ブランチ運用・コミット規約は github-flow スキルと共通。
| 操作 | github-flow | local-flow |
|---|---|---|
| Issue 作成 | gh issue create | issues/<番号>-<説明>.md を作成 |
| Issue コメント | gh issue comment | Issue ファイルの末尾にセクション追記 |
| PR 作成 | gh pr create --draft | pull-requests/<番号>-<説明>.md を作成 |
| PR コメント | gh pr comment | PR ファイルの末尾にセクション追記 |
| リモート Push | git push -u origin | 不要(ローカルのみ) |
| マージ | GitHub 上で Squash Merge | git merge --squash をローカル実行 |
上記以外(ブランチ命名、Conventional Commits、ビルド・テスト確認、テスト作成義務)は github-flow スキルに従う。
<repo-root>/
issues/
001-add-search.md
002-fix-pagination.md
pull-requests/
001-feat-add-search.md
issues/ — 仕様書・タスクを管理するpull-requests/ — 実装の変更内容とレビュー記録を管理する001, 002, ...)issues/ ディレクトリ内の既存ファイルから最大番号を取得し、+1 する。
ディレクトリが空または存在しない場合は 001 から開始する。
$maxNum = (Get-ChildItem issues/*.md -ErrorAction SilentlyContinue |
ForEach-Object { if ($_.Name -match '^(\d+)') { [int]$Matches[1] } } |
Measure-Object -Maximum).Maximum
$next = "{0:D3}" -f (($maxNum ?? 0) + 1)
issues/<番号>-<短い説明(kebab-case)>.md
# <タイトル>
| 項目 | 値 |
|------|-----|
| 番号 | <番号> |
| ステータス | open |
| 作成日 | <YYYY-MM-DD> |
---
<本文: 仕様書の内容をここに記述>
---
## コメント
ステータス は open / closed のいずれか## コメント セクション以降にエージェントや人間のコメントを追記するcreate-specification スキルの gh issue create の代わりに以下を実行する:
$number = "001"
$slug = "add-search"
$path = "issues/${number}-${slug}.md"
New-Item -ItemType Directory -Path "issues" -Force
# ファイルを作成し、テンプレートの内容を書き込む
Issue ファイルの ## コメント セクション以降に、以下のフォーマットで追記する。
---
### [エージェント名] -- Step N.N: ステップ名
Phase N / レビューサイクル N回目
<YYYY-MM-DDThh:mm:ss>
<コメント本文>
gh issue comment <番号> --body "..." の代わりに:
$issuePath = "issues/001-add-search.md"
$comment = @"
---
### [Reviewer] -- Step 1.2: 仕様レビュー
Phase 1 / レビューサイクル 1回目
$(Get-Date -Format "yyyy-MM-ddTHH:mm:ss")
## レビュー結果
- **BLOCKER**: 受け入れ基準 #3 が曖昧です
**REQUEST CHANGES**
"@
Add-Content -Path $issuePath -Value $comment -Encoding UTF8
github-flow スキルのコミット規約に従っていることIssue と同様に pull-requests/ 内の最大番号 +1 とする。
Issue 番号と PR 番号は独立した連番とする。
pull-requests/<番号>-<type>-<短い説明(kebab-case)>.md
# <PR タイトル(Conventional Commits 形式)>
| 項目 | 値 |
|------|-----|
| 番号 | <番号> |
| ブランチ | feature/<issue番号>-<説明> → main |
| 関連 Issue | <Issue 番号> |
| ステータス | draft |
| 作成日 | <YYYY-MM-DD> |
---
## 概要
<変更の目的と背景>
## 変更内容
- <変更点 1>
- <変更点 2>
## 確認事項
- [ ] `dotnet build <YourSolution>.slnx` が成功する
- [ ] `dotnet test <YourSolution>.slnx` が成功する
- [ ] 新規・変更したビジネスロジックに単体テストがある
---
## コメント
ステータス は draft / review / merged / closed のいずれかIssue と同じフォーマットで ## コメント セクション以降に追記する。
gh pr comment <番号> --body "..." の代わりに:
$prPath = "pull-requests/001-feat-add-search.md"
$comment = @"
---
### [Developer] -- Step 3.1: 実装
Phase 3 / レビューサイクル 1回目
$(Get-Date -Format "yyyy-MM-ddTHH:mm:ss")
## 実装完了
- ブランチ: feature/001-add-search
- 変更ファイル: 8 ファイル
- ユニットテスト: 5 テスト追加、全パス
- ビルド: 成功
"@
Add-Content -Path $prPath -Value $comment -Encoding UTF8
Issue または PR のステータスを変更する場合、ファイル冒頭のメタデータテーブルを直接編集する。
| 操作 | github-flow | local-flow |
|---|---|---|
| PR を Ready for Review に変更 | GitHub UI | ステータス を draft → review に編集 |
| Issue をクローズ | gh issue close | ステータス を open → closed に編集 |
| PR をマージ済みに変更 | GitHub Squash Merge | ステータス を review → merged に編集 |
GitHub 上の Squash Merge の代わりに、ローカルで同等の操作を行う。
# 1. main に切り替え
git switch main
# 2. feature ブランチの変更を squash で取り込み
git merge --squash feature/<issue番号>-<説明>
# 3. Conventional Commits 形式でコミット
git commit -m "feat(<scope>): 変更内容の説明
Refs #<issue番号>"
# 4. feature ブランチを削除
git branch -d feature/<issue番号>-<説明>
ステータス を merged に更新するステータス を closed に更新する# 1. ブランチ作成
git switch main
git switch -c feature/<issue番号>-<説明>
# 2. 作業・コミット
git add .
git commit -m "feat(<scope>): 変更内容の説明"
# 3. ビルド確認
cd src && dotnet build <YourSolution>.slnx && dotnet test <YourSolution>.slnx
# 4. PR ファイル作成
# pull-requests/<番号>-<type>-<説明>.md を作成
# 5. レビュー・テスト(コメントは PR ファイルに追記)
# 6. マージ
git switch main
git merge --squash feature/<issue番号>-<説明>
git commit -m "feat(<scope>): 変更内容の説明"
git branch -d feature/<issue番号>-<説明>
# 7. ステータス更新
# PR: merged, Issue: closed