Skip to main content

local-flow

GitHub API を使わずローカルファイルで Issue / PR を管理する開発フロー。デモ・オフライン環境向け。github-flow の代替として使用する。

来源信息

仓库
runceel/agent-teams-sample
最近来源活动
2026年4月8日 05:09
检测到的 SKILL.md 语言
日语
星标
0
分支
0

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
local-flow
description
GitHub API を使わずローカルファイルで Issue / PR を管理する開発フロー。デモ・オフライン環境向け。github-flow の代替として使用する。
# Local Flow 開発ガイド GitHub API(`gh` CLI)を使用せず、リポジトリ内の Markdown ファイルで Issue と PR を管理する開発フローを定義する。 ブランチ運用・コミット規約は `github-flow` スキルと共通。 --- ## 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/` — 実装の変更内容とレビュー記録を管理する - 番号は 3 桁ゼロ埋め連番とする(`001`, `002`, ...) --- ## 1. Issue の作成 ### 採番ルール `issues/` ディレクトリ内の既存ファイルから最大番号を取得し、+1 する。 ディレクトリが空または存在しない場合は `001` から開始する。 ```powershell $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 ``` ### Issue テンプレート ```markdown # <タイトル> | 項目 | 値 | |------|-----| | 番号 | <番号> | | ステータス | open | | 作成日 | <YYYY-MM-DD> | --- <本文: 仕様書の内容をここに記述> --- ## コメント ``` - `ステータス` は `open` / `closed` のいずれか - `## コメント` セクション以降にエージェントや人間のコメントを追記する ### 作成コマンド例 `create-specification` スキルの `gh issue create` の代わりに以下を実行する: ```powershell $number = "001" $slug = "add-search" $path = "issues/${number}-${slug}.md" New-Item -ItemType Directory -Path "issues" -Force # ファイルを作成し、テンプレートの内容を書き込む ``` --- ## 2. Issue へのコメント追記 Issue ファイルの `## コメント` セクション以降に、以下のフォーマットで追記する。 ### フォーマット ```markdown --- ### [エージェント名] -- Step N.N: ステップ名 Phase N / レビューサイクル N回目 <YYYY-MM-DDThh:mm:ss> <コメント本文> ``` ### 追記コマンド例 `gh issue comment <番号> --body "..."` の代わりに: ```powershell $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 ``` --- ## 3. PR の作成 ### 前提 - feature ブランチでの実装・ビルド・テストが完了していること - `github-flow` スキルのコミット規約に従っていること ### 採番ルール Issue と同様に `pull-requests/` 内の最大番号 +1 とする。 Issue 番号と PR 番号は独立した連番とする。 ### ファイル命名規則 ``` pull-requests/<番号>-<type>-<短い説明(kebab-case)>.md ``` ### PR テンプレート ```markdown # <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` のいずれか --- ## 4. PR へのコメント追記 Issue と同じフォーマットで `## コメント` セクション以降に追記する。 `gh pr comment <番号> --body "..."` の代わりに: ```powershell $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 ``` --- ## 5. ステータス更新 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` に編集 | --- ## 6. マージ(ローカル Squash Merge) GitHub 上の Squash Merge の代わりに、ローカルで同等の操作を行う。 ```bash # 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番号>-<説明> ``` ### マージ後 1. PR ファイルの `ステータス` を `merged` に更新する 2. 関連 Issue ファイルの `ステータス` を `closed` に更新する --- ## クイックリファレンス ```bash # 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 ```
在 GitHub 查看