diff --git a/.claude/hooks/check_sync.sh b/.claude/hooks/check_sync.sh index f7ece22..2e00c35 100644 --- a/.claude/hooks/check_sync.sh +++ b/.claude/hooks/check_sync.sh @@ -3,7 +3,7 @@ # JSON で systemMessage (UI 表示) と additionalContext (モデルに注入) を出力する. # 読み取り専用 (git fetch のみ). 失敗してもセッション開始は阻害しない. # -# GUIDE_06「直列運用」「main を常に動作可能」を補助する目的で, +# GUIDE_03「直列運用」「main を常に動作可能」を補助する目的で, # 古い main から作業を始めるミスをセッション開始時に可視化する. # JSON 整形は python3 に任せる (jq 非依存. 既存 hook も python3 を利用). diff --git a/.claude/rules/progress-log.md b/.claude/rules/progress-log.md index 90d826c..cd788a3 100644 --- a/.claude/rules/progress-log.md +++ b/.claude/rules/progress-log.md @@ -6,7 +6,7 @@ `CLAUDE.md` の「開発進捗」セクションと `docs/PROGRESS.md` を更新するときは本ルールに従うこと． -> ⚠ **チーム開発モード（team）では本ルールは上書きされる**．team プロジェクトでは進捗を `CLAUDE.md`・`docs/PROGRESS.md` に書かず，GitHub Issues と git 履歴で追う（[GUIDE_06](../../docs/01_GUIDE/GUIDE_06_チーム開発ルール.md)）．以下は個人開発モード（solo）の既定ルールである．team モードでは Phase 4 の進捗更新を Issue コメント（`/task-handoff` 等）に置き換える． +> ⚠ **チーム開発モード（team）では本ルールは上書きされる**．team プロジェクトでは進捗を `CLAUDE.md`・`docs/PROGRESS.md` に書かず，GitHub Issues と git 履歴で追う（[GUIDE_03](../../docs/01_GUIDE/GUIDE_03_チーム開発ルール.md)）．以下は個人開発モード（solo）の既定ルールである．team モードでは Phase 4 の進捗更新を Issue コメント（`/task-handoff` 等）に置き換える． ## 二段構成 (Two-tier Structure) diff --git a/.claude/skills/auto-audit/SKILL.md b/.claude/skills/auto-audit/SKILL.md index 6964142..01ec9fa 100644 --- a/.claude/skills/auto-audit/SKILL.md +++ b/.claude/skills/auto-audit/SKILL.md @@ -7,7 +7,7 @@ あなたは**自律バグ／脆弱性 監査ループの制御層（オーケストレータ）**です． ユーザーが席を外している無人時間に，空いた稼働枠を「コードベース全体を巡回してバグ・脆弱性を発見し，安全に直せるものを直す」ことに充てるために起動されました． -Git 規約（`.claude/rules/git-conventions.md`），GUIDE_05（エージェント運用）を読み，書式・規約・パイプラインのルールを理解した上で，以下の不変条件を厳守してループを回してください． +Git 規約（`.claude/rules/git-conventions.md`），GUIDE_02（エージェント運用）を読み，書式・規約・パイプラインのルールを理解した上で，以下の不変条件を厳守してループを回してください． このループが扱う作業は，入口の「発見の観点」が **2 種類**あるだけで，後段の「修正の機械」は共通です． diff --git a/.claude/skills/auto-refactor/SKILL.md b/.claude/skills/auto-refactor/SKILL.md index 330ec39..e0b4b84 100644 --- a/.claude/skills/auto-refactor/SKILL.md +++ b/.claude/skills/auto-refactor/SKILL.md @@ -7,7 +7,7 @@ あなたは**自律リファクタリング＆ドキュメント同期ループの制御層（オーケストレータ）**です． ユーザーが席を外している無人時間に，空いた稼働枠を「コードの大規模リファクタリング」と「実装とドキュメントのズレ解消」に充てるために起動されました． -Git 規約（`.claude/rules/git-conventions.md`），GUIDE_05（エージェント運用）と，ドキュメント書式・命名のルール（`.claude/rules/markdown-style.md`・`.claude/rules/docs-naming.md`）を読み，書式・規約・パイプラインのルールを理解した上で，以下の不変条件を厳守してループを回してください． +Git 規約（`.claude/rules/git-conventions.md`），GUIDE_02（エージェント運用）と，ドキュメント書式・命名のルール（`.claude/rules/markdown-style.md`・`.claude/rules/docs-naming.md`）を読み，書式・規約・パイプラインのルールを理解した上で，以下の不変条件を厳守してループを回してください． このループが扱う作業は **4 種類**ある．前の3種をすべて拾い尽くした後にだけ，最後の「テストリファクタ系」を行う（最も安全網が特殊で危険なため，最後に回す）． diff --git a/.claude/skills/implement/SKILL.md b/.claude/skills/implement/SKILL.md index 22c51b8..b84d2d7 100644 --- a/.claude/skills/implement/SKILL.md +++ b/.claude/skills/implement/SKILL.md @@ -6,7 +6,7 @@ --- あなたはオーケストレーターです． -GUIDE_05（エージェント運用ルール）を読み，パイプラインのルールを理解した上で以下の手順を実行してください． +GUIDE_02（エージェント運用ルール）を読み，パイプラインのルールを理解した上で以下の手順を実行してください． ## 前提確認 (Pre-check) diff --git a/.claude/skills/set-mode/SKILL.md b/.claude/skills/set-mode/SKILL.md index dc3444e..8db463a 100644 --- a/.claude/skills/set-mode/SKILL.md +++ b/.claude/skills/set-mode/SKILL.md @@ -19,10 +19,10 @@ モードに応じて配置／削除する対象．`/sync-template` の「モード依存ファイル」と同一のリストに保つこと． ``` -docs/01_GUIDE/GUIDE_06_チーム開発ルール.md -docs/01_GUIDE/GUIDE_07_Issues・Projects運用ガイド.md +docs/01_GUIDE/GUIDE_03_チーム開発ルール.md .claude/skills/task-create/SKILL.md .claude/skills/task-start/SKILL.md +.claude/skills/task-start/reference.md .claude/skills/task-handoff/SKILL.md .claude/hooks/check_sync.sh ``` @@ -40,7 +40,7 @@ ## ステップ 2: ブランチ作成 (Branch) -モード切替は共有設定（`CLAUDE.md` のルール部・`.claude/`）の変更を含むため，GUIDE_06「共有設定の扱い」に従い専用ブランチで行う． +モード切替は共有設定（`CLAUDE.md` のルール部・`.claude/`）の変更を含むため，GUIDE_03「共有設定の扱い」に従い専用ブランチで行う． ```bash git checkout -b chore/set-mode-$TARGET @@ -61,10 +61,10 @@ # team 層ファイルをコピー（既存があっても最新版で上書き） for f in \ - "docs/01_GUIDE/GUIDE_06_チーム開発ルール.md" \ - "docs/01_GUIDE/GUIDE_07_Issues・Projects運用ガイド.md" \ + "docs/01_GUIDE/GUIDE_03_チーム開発ルール.md" \ ".claude/skills/task-create/SKILL.md" \ ".claude/skills/task-start/SKILL.md" \ + ".claude/skills/task-start/reference.md" \ ".claude/skills/task-handoff/SKILL.md" \ ".claude/hooks/check_sync.sh" ; do mkdir -p "$(dirname "$f")" @@ -91,18 +91,18 @@ ### 3-A.3 CLAUDE.md を team 化 -`CLAUDE.md` を Read し，`/setup` の Phase 7（team 化）および GUIDE_06 に合わせて以下を反映する（既に反映済みの項目は触らない）: +`CLAUDE.md` を Read し，`/setup` の Phase 7（team 化）および GUIDE_03 に合わせて以下を反映する（既に反映済みの項目は触らない）: -- **「開発進捗」節**を，進捗欄（最新 1 行）ではなく **Issues ポインタ**に置き換える（例:「進捗・タスクは GitHub Issues と git 履歴で追う（GUIDE_06）．現在のタスクは `gh issue list` で確認する．`CLAUDE.md` には進捗を書かない．」）． -- **「必須ルール（コード実装時）」に「チーム開発（GUIDE_06 準拠）」小節を追加**する（直列運用・Issue ベースのタスク管理・`/task-create`／`/task-start`／`/task-handoff` の案内・条件付きセルフマージ・共有設定変更は専用 PR＋他メンバー 1 名 Approve 必須）． +- **「開発進捗」節**を，進捗欄（最新 1 行）ではなく **Issues ポインタ**に置き換える（例:「進捗・タスクは GitHub Issues と git 履歴で追う（GUIDE_03）．現在のタスクは `gh issue list` で確認する．`CLAUDE.md` には進捗を書かない．」）． +- **「必須ルール（コード実装時）」に「チーム開発（GUIDE_03 準拠）」小節を追加**する（直列運用・Issue ベースのタスク管理・`/task-create`／`/task-start`／`/task-handoff` の案内・条件付きセルフマージ・共有設定変更は専用 PR＋他メンバー 1 名 Approve 必須）． - **「Git 運用」小節**に，セッション開始時の `[sync-check]` 警告を必ず認識する旨の 1 行を追加する． -- **「ドキュメント」→「01_GUIDE」一覧**に `GUIDE_06`・`GUIDE_07` の行を追加する． +- **「ドキュメント」→「01_GUIDE」一覧**に `GUIDE_03` の行を追加する． Edit 後に `git diff CLAUDE.md` で結果を確認する． ### 3-A.4 その他 -- `.gitignore` に `.claude/settings.local.json` が無ければ追記する（個人設定用．GUIDE_06）． +- `.gitignore` に `.claude/settings.local.json` が無ければ追記する（個人設定用．GUIDE_03）． - `echo team > .claude/project-mode` でモードを記録する． ## ステップ 3-B: team → solo（TARGET が solo のとき） @@ -113,14 +113,14 @@ ```bash rm -f \ - "docs/01_GUIDE/GUIDE_06_チーム開発ルール.md" \ - "docs/01_GUIDE/GUIDE_07_Issues・Projects運用ガイド.md" \ + "docs/01_GUIDE/GUIDE_03_チーム開発ルール.md" \ ".claude/skills/task-create/SKILL.md" \ ".claude/skills/task-start/SKILL.md" \ + ".claude/skills/task-start/reference.md" \ ".claude/skills/task-handoff/SKILL.md" \ ".claude/hooks/check_sync.sh" -# SKILL.md 削除で空になったスキルディレクトリを取り除く +# 中身が無くなったスキルディレクトリを取り除く rmdir ".claude/skills/task-create" ".claude/skills/task-start" ".claude/skills/task-handoff" 2>/dev/null || true ``` @@ -140,9 +140,9 @@ ※ 本欄は**最新ステップ 1 行のみ上書き更新**．詳細な進捗履歴は docs/PROGRESS.md に追記する．運用ルールは .claude/rules/progress-log.md 参照． ``` 「最新」行に入れる現状はユーザーに確認する（team 期間の進捗は Issues / git 履歴にあるため，ここへ移し替える必要はない）． -- **「チーム開発（GUIDE_06 準拠）」小節を削除**する． +- **「チーム開発（GUIDE_03 準拠）」小節を削除**する． - **「Git 運用」小節**の `[sync-check]` 警告の行を削除する． -- **「ドキュメント」→「01_GUIDE」一覧**から `GUIDE_06`・`GUIDE_07` の行を削除する（GUIDE_08 以降のプロジェクト固有ドキュメントがあれば残す）． +- **「ドキュメント」→「01_GUIDE」一覧**から `GUIDE_03` の行を削除する（GUIDE_04 以降のプロジェクト固有ドキュメントがあれば残す）． Edit 後に `git diff CLAUDE.md` で確認する． @@ -164,11 +164,11 @@ - `.claude/project-mode`: `{TARGET}` 内容を確認のうえ `/commit push` で取り込んでください． -{team に切り替えた場合: 「チーム運用の管理者初期設定（GitHub repo・CI 等）は GUIDE_06 を参照してください．共有設定の変更のため，他メンバー 1 名の Approve を得てからマージしてください（GUIDE_06）．」}」 +{team に切り替えた場合: 「チーム運用の管理者初期設定（GitHub repo・CI 等）は GUIDE_03 を参照してください．共有設定の変更のため，他メンバー 1 名の Approve を得てからマージしてください（GUIDE_03）．」}」 ## 注意事項 (Notes) - 本コマンドは**コミットしない**．変更は `chore/set-mode-*` ブランチに未コミットで乗るので，`/commit` で取り込む． -- team ↔ solo の切替は共有設定の変更にあたる（GUIDE_06「共有設定の扱い」）．team プロジェクトでは専用 PR＋他メンバー 1 名 Approve を経てマージする． +- team ↔ solo の切替は共有設定の変更にあたる（GUIDE_03「共有設定の扱い」）．team プロジェクトでは専用 PR＋他メンバー 1 名 Approve を経てマージする． - team 層ファイルのリストは `/sync-template` の「モード依存ファイル」と一致させること．どちらかを増減したら両方を更新する． - solo→team で取得する team 層ファイルはテンプレート HEAD 版．版の細かな追従は以後の `/sync-template` に任せる（`template-sync-sha` は本コマンドでは変更しない）． diff --git a/.claude/skills/setup/SKILL.md b/.claude/skills/setup/SKILL.md index 11b6df6..8e64530 100644 --- a/.claude/skills/setup/SKILL.md +++ b/.claude/skills/setup/SKILL.md @@ -37,7 +37,7 @@ 「**このプロジェクトの開発モードを選んでください．** - **solo（個人開発）**: 1 人で開発する．進捗は `CLAUDE.md` の進捗欄＋ `docs/PROGRESS.md` で追う． -- **team（チーム開発）**: 複数人が Claude Code で開発する．進捗・タスクは GitHub Issues と git 履歴で追い，直列運用・条件付きセルフマージ等のチームルール（GUIDE_06）を適用する． +- **team（チーム開発）**: 複数人が Claude Code で開発する．進捗・タスクは GitHub Issues と git 履歴で追い，直列運用・条件付きセルフマージ等のチームルール（GUIDE_03）を適用する． どちらにしますか？（後から `/set-mode ` で切り替えられます）」 @@ -45,8 +45,7 @@ 1. `.claude/project-mode` にモード（`solo` または `team` のいずれか 1 語）を書き出す． 2. **solo の場合**: チーム層ファイルが clone で配置されていれば削除し，solo プロジェクトを clean に保つ: - - `docs/01_GUIDE/GUIDE_06_チーム開発ルール.md` - - `docs/01_GUIDE/GUIDE_07_Issues・Projects運用ガイド.md` + - `docs/01_GUIDE/GUIDE_03_チーム開発ルール.md` - `.claude/skills/task-create/` / `task-start/` / `task-handoff/`（各ディレクトリごと削除） - `.claude/hooks/check_sync.sh` - ※ `.claude/settings.json` はそのまま（solo でも `restrict_repo_access.py` を使う）．SessionStart(check_sync) の配線は追加しない． @@ -61,7 +60,7 @@ } ] ``` - - `.gitignore` に `.claude/settings.local.json` が無ければ追記する（個人設定用．GUIDE_06）． + - `.gitignore` に `.claude/settings.local.json` が無ければ追記する（個人設定用．GUIDE_03）． - CLAUDE.md のチーム化は Phase 7 で行う（この時点ではまだ立ち上げ中で Issue/repo が無いため，進捗欄は setup 再開用にそのまま使う）． ### 進捗記録（立ち上げ中） @@ -98,17 +97,17 @@ 1. GUIDE_01 の「CLAUDE.md の管理」セクションに従い，CLAUDE.md を最終更新する - **team モードの場合**（`.claude/project-mode` が `team`）は，ここで CLAUDE.md をチーム開発向けに変換する: - - 「開発進捗」節を，進捗欄（最新 1 行）ではなく **Issues ポインタ**に置き換える（例: 「進捗・タスクは GitHub Issues と git 履歴で追う（GUIDE_06）．現在のタスクは `gh issue list` で確認する．`CLAUDE.md` には進捗を書かない．」）． - - 「必須ルール（コード実装時）」に **「チーム開発（GUIDE_06 準拠）」小節**を追加する（直列運用・Issue ベースのタスク管理・`/task-create`／`/task-start`／`/task-handoff` の案内・条件付きセルフマージ・共有設定変更は専用 PR＋他メンバー 1 名 Approve 必須）． + - 「開発進捗」節を，進捗欄（最新 1 行）ではなく **Issues ポインタ**に置き換える（例: 「進捗・タスクは GitHub Issues と git 履歴で追う（GUIDE_03）．現在のタスクは `gh issue list` で確認する．`CLAUDE.md` には進捗を書かない．」）． + - 「必須ルール（コード実装時）」に **「チーム開発（GUIDE_03 準拠）」小節**を追加する（直列運用・Issue ベースのタスク管理・`/task-create`／`/task-start`／`/task-handoff` の案内・条件付きセルフマージ・共有設定変更は専用 PR＋他メンバー 1 名 Approve 必須）． - 「Git 運用」小節に，セッション開始時の `[sync-check]` 警告を必ず認識する旨の 1 行を追加する． - - 「ドキュメント」→「01_GUIDE」一覧に `GUIDE_06`・`GUIDE_07` の行を追加する． + - 「ドキュメント」→「01_GUIDE」一覧に `GUIDE_03` の行を追加する． - **solo モードの場合**は従来どおり（進捗欄＋ PROGRESS.md 運用）． 2. 作成した全ドキュメントの一覧を表示する 3. 最初の実装ステップを確認する -4. **team モードの場合**は，AI に実施できない「管理者の初期設定」（GUIDE_06「管理者の初期設定」）をユーザーに案内する: +4. **team モードの場合**は，AI に実施できない「管理者の初期設定」（GUIDE_03「管理者の初期設定」）をユーザーに案内する: - GitHub リポジトリ作成・メンバー招待 - Issue テンプレートの用意 - - CI 構築（未構築の間は GUIDE_06「CI 構築までの暫定ゲート」を適用） + - CI 構築（未構築の間は GUIDE_03「CI 構築までの暫定ゲート」を適用） - 依存脆弱性対策が必要ならスタックに応じた `.github/dependabot.yml` を追加（エコシステムはプロジェクト固有のため setup では作らない） 「**全フェーズが完了しました．** @@ -119,7 +118,7 @@ 開発モード: {solo / team} CLAUDE.md を更新しました． 最初の実装ステップは `{ステップ名}` です．`/implement {タスク}` で開始できます． -{team の場合: 「チーム運用の管理者初期設定（GitHub repo・CI 等）は GUIDE_06 を参照してユーザー側で実施してください．」}」 +{team の場合: 「チーム運用の管理者初期設定（GitHub repo・CI 等）は GUIDE_03 を参照してユーザー側で実施してください．」}」 ## 中断時の処理 diff --git a/.claude/skills/sync-template/SKILL.md b/.claude/skills/sync-template/SKILL.md index 829fd6f..5560d52 100644 --- a/.claude/skills/sync-template/SKILL.md +++ b/.claude/skills/sync-template/SKILL.md @@ -38,14 +38,14 @@ ## モード依存ファイル (Mode-gated / Team-layer Files) -テンプレートは個人開発（solo）とチーム開発（team）の両モードを 1 つのリポジトリで提供する（GUIDE_06）．以下の**チーム層ファイル**は team モードのプロジェクトにのみ配置し，solo モードのプロジェクトには同期しない． +テンプレートは個人開発（solo）とチーム開発（team）の両モードを 1 つのリポジトリで提供する（GUIDE_03）．以下の**チーム層ファイル**は team モードのプロジェクトにのみ配置し，solo モードのプロジェクトには同期しない． | ファイル | レイヤ | | --- | --- | -| `docs/01_GUIDE/GUIDE_06_チーム開発ルール.md` | team | -| `docs/01_GUIDE/GUIDE_07_Issues・Projects運用ガイド.md` | team | +| `docs/01_GUIDE/GUIDE_03_チーム開発ルール.md` | team | | `.claude/skills/task-create/SKILL.md` | team | | `.claude/skills/task-start/SKILL.md` | team | +| `.claude/skills/task-start/reference.md` | team | | `.claude/skills/task-handoff/SKILL.md` | team | | `.claude/hooks/check_sync.sh` | team | @@ -159,10 +159,10 @@ MERGE_FILES=(".gitignore" "CLAUDE.md" "docs/PROGRESS.md" ".gitattributes" ".claude/settings.json") SKIP_FILES=("README.md") TEAM_LAYER_FILES=( - "docs/01_GUIDE/GUIDE_06_チーム開発ルール.md" - "docs/01_GUIDE/GUIDE_07_Issues・Projects運用ガイド.md" + "docs/01_GUIDE/GUIDE_03_チーム開発ルール.md" ".claude/skills/task-create/SKILL.md" ".claude/skills/task-start/SKILL.md" + ".claude/skills/task-start/reference.md" ".claude/skills/task-handoff/SKILL.md" ".claude/hooks/check_sync.sh" ) @@ -395,7 +395,7 @@ - コード修正はユーザーの確認なしに実行しない - マージ必須ファイル（`.gitignore`, `CLAUDE.md`, `docs/PROGRESS.md`, `.gitattributes`, `.claude/settings.json`）は必ずステップ 5.4 の手順でマージする．盲目的な `cp` で上書きしない（フレームワーク固有の除外ルールやプロジェクト固有セクションが失われる） - 同期対象外ファイル（`README.md`）はテンプレート紹介用のためプロジェクトには反映しない．テンプレート側で追加・変更・削除があってもプロジェクトの該当ファイルは触らない -- チーム層ファイル（`GUIDE_06`／`GUIDE_07`／`task-*`／`check_sync.sh`）は `.claude/project-mode` が `team` のプロジェクトにのみ同期する．`solo`（または未設定）のプロジェクトには配置・更新・削除いずれもしない．`/sync-template` は「版の追従」のみを行い，**モードの切り替えはしない**．solo↔team の切替は `/set-mode ` を使う（team 層ファイルの配置／削除・`settings.json` 配線・`CLAUDE.md` の team 化／solo 化・`project-mode` 更新を一括で行う）．`.claude/project-mode` を手で書き換えるだけでは切り替わらない +- チーム層ファイル（`GUIDE_03`／`task-*`／`check_sync.sh`）は `.claude/project-mode` が `team` のプロジェクトにのみ同期する．`solo`（または未設定）のプロジェクトには配置・更新・削除いずれもしない．`/sync-template` は「版の追従」のみを行い，**モードの切り替えはしない**．solo↔team の切替は `/set-mode ` を使う（team 層ファイルの配置／削除・`settings.json` 配線・`CLAUDE.md` の team 化／solo 化・`project-mode` 更新を一括で行う）．`.claude/project-mode` を手で書き換えるだけでは切り替わらない - `.claude/settings.json` はマージ必須ファイル．team の SessionStart(check_sync) 配線を保持したままテンプレートの hook 変更を統合する．盲目的な `cp` で上書きしない - 通常コピー対象でもプロジェクト固有の変更が上書きされうる場合は，`git diff` で確認してユーザーに報告する - テンプレートが管理するのは `.claude/` 配下のうち `agents/`，`skills/`，`rules/`，`hooks/`，`settings.json`，`template-sync-sha` のみ．`.claude/plans/` や `.claude/commit-context.md` 等のプロジェクト固有ファイルはテンプレートに含まれないため同期対象外 diff --git a/.claude/skills/task-create/SKILL.md b/.claude/skills/task-create/SKILL.md index 051ac85..09dafa1 100644 --- a/.claude/skills/task-create/SKILL.md +++ b/.claude/skills/task-create/SKILL.md @@ -1,14 +1,14 @@ --- name: task-create model: inherit -description: "GUIDE_06/07 に従い，Issue を作成しボードに追加する（着手はしない）．タスクの事前計画用．" +description: "GUIDE_03 に従い，Issue を作成しボードに追加する（着手はしない）．タスクの事前計画用．" argument-hint: "<タスクの説明>" --- あなたはタスク計画担当です． -GUIDE_06（チーム開発ルール）と GUIDE_07（Issues・Projects 運用ガイド）に従い，新しいタスクの Issue を作成してボードに並べてください． +GUIDE_03（チーム開発ルール）と `.claude/skills/task-start/reference.md`（Issues・Projects の gh 操作リファレンス）に従い，新しいタスクの Issue を作成してボードに並べてください． -本コマンドは**タスクを事前に定義する**ためのものです．着手は別途 `/task-start ` で行います（または手動で）．Issue 無しで進める作業はこのコマンドを使う必要はありません（GUIDE_06）． +本コマンドは**タスクを事前に定義する**ためのものです．着手は別途 `/task-start ` で行います（または手動で）．Issue 無しで進める作業はこのコマンドを使う必要はありません（GUIDE_03）． ## 前提確認 (Pre-check) @@ -17,25 +17,25 @@ ## ステップ 1: Project の特定 (Project Lookup) 1. リポジトリ所有者を取得する（`gh repo view --json owner --jq .owner.login`）． -2. Project を特定する（`gh project list --owner `）．複数ある場合はユーザーに確認する．見つからない場合はその旨を伝え，ステップ 3（ボード追加）は飛ばして進める（管理者の初期設定が未完了．GUIDE_06）． +2. Project を特定する（`gh project list --owner `）．複数ある場合はユーザーに確認する．見つからない場合はその旨を伝え，ステップ 3（ボード追加）は飛ばして進める（管理者の初期設定が未完了．GUIDE_03）． ## ステップ 2: Issue 作成 (Create Issue) $ARGUMENTS の説明から Issue 本文を組み立てる． - **やること**は必ず書く． -- **完了条件（受け入れ基準）**は非自明な場合のみ書く（GUIDE_06）． +- **完了条件（受け入れ基準）**は非自明な場合のみ書く（GUIDE_03）． - 担当者は**アサインしない**（誰が拾うかは着手時に決まる）． `gh issue create --title "<タイトル>" --body "<本文>"` で作成する． ## ステップ 3: ボードに追加 (Add to Board) -GUIDE_07「Projects の操作」に従う（Project が無い場合は飛ばす）． +`.claude/skills/task-start/reference.md` の「Projects の操作」に従う（Project が無い場合は飛ばす）． 1. `gh project item-add --owner --url ` でボードに追加する． 2. 追加されたアイテムの Status を `Todo` に設定する（`gh project field-list`・`item-list` で必要な ID を取得し `gh project item-edit`）． -3. `gh project` の書き込み系は成功しても無出力のことがある．`gh project item-list` で結果を確認する（GUIDE_07）． +3. `gh project` の書き込み系は成功しても無出力のことがある．`gh project item-list` で結果を確認する（同 reference.md「トラブルシューティング」）． ## ステップ 4: 完了サマリー (Summary) @@ -48,4 +48,4 @@ ## 注意事項 (Notes) - 複数タスクを一括で作る場合は，本コマンドを複数回実行してください． -- Projects 操作には `project` スコープが必要．スコープエラーが出たら `gh auth refresh -s project` を実行する（GUIDE_07）． +- Projects 操作には `project` スコープが必要．スコープエラーが出たら `gh auth refresh -s project` を実行する（`.claude/skills/task-start/reference.md`「必要なスコープ」）． diff --git a/.claude/skills/task-handoff/SKILL.md b/.claude/skills/task-handoff/SKILL.md index b4cede2..31d355a 100644 --- a/.claude/skills/task-handoff/SKILL.md +++ b/.claude/skills/task-handoff/SKILL.md @@ -7,7 +7,7 @@ あなたは作業引継ぎ担当です．現在 **In Progress** の Issue に，次セッション・次メンバーが再開できるだけの情報を進捗メモとして投稿します． -GUIDE_06（チーム開発ルール）の「進捗は Issues / Projects と git 履歴で追う」方針に沿い，引継ぎ情報を Issue コメントに集約します（`CLAUDE.md` に進捗は書かない）． +GUIDE_03（チーム開発ルール）の「進捗は Issues / Projects と git 履歴で追う」方針に沿い，引継ぎ情報を Issue コメントに集約します（`CLAUDE.md` に進捗は書かない）． ## 前提確認 (Pre-check) @@ -15,7 +15,7 @@ ## ステップ 1: 対象 Issue の特定 (Identify Issue) -1. Project を特定する（`gh project list --owner `）．見つからない場合は「Project 未設定のため進捗メモを投稿できません．管理者の初期設定が必要です（GUIDE_06）．」と伝えて終了する． +1. Project を特定する（`gh project list --owner `）．見つからない場合は「Project 未設定のため進捗メモを投稿できません．管理者の初期設定が必要です（GUIDE_03）．」と伝えて終了する． 2. ボードから Status が `In Progress` の Issue を抽出する（`gh project item-list --owner --format json`）． 3. 件数で挙動を変える: - **0 件**: 「In Progress の Issue がありません．まず `/task-start ` で着手してから本コマンドを使ってください．」と伝えて終了． @@ -105,4 +105,4 @@ - 本コマンドは Issue を **Done に動かさない**．In Progress のまま残す（作業継続前提）．完了させたい場合は別途 `/commit merge` で PR をマージ → `Closes #<番号>` で自動クローズ． - 進捗メモは**コメント**として投稿する．Issue 本文は書き換えない． -- Projects 操作には `project` スコープが必要．スコープエラーが出たら `gh auth refresh -s project` を実行する（GUIDE_07）． +- Projects 操作には `project` スコープが必要．スコープエラーが出たら `gh auth refresh -s project` を実行する（`.claude/skills/task-start/reference.md`「必要なスコープ」）． diff --git a/.claude/skills/task-start/SKILL.md b/.claude/skills/task-start/SKILL.md index 17e6c56..7aa0acd 100644 --- a/.claude/skills/task-start/SKILL.md +++ b/.claude/skills/task-start/SKILL.md @@ -1,28 +1,28 @@ --- name: task-start model: inherit -description: "GUIDE_06/07 に従い，既存 Issue を拾って作業を開始する（アサイン・ボード In Progress・作業ブランチ作成）．" +description: "GUIDE_03 に従い，既存 Issue を拾って作業を開始する（アサイン・ボード In Progress・作業ブランチ作成）．" argument-hint: "" --- あなたはタスク着手の準備担当です． -GUIDE_06（チーム開発ルール）と GUIDE_07（Issues・Projects 運用ガイド）に従い，**既存 Issue を拾って**作業に取り掛かるための準備を整えてください． +GUIDE_03（チーム開発ルール）と本スキルの `reference.md`（Issues・Projects の gh 操作リファレンス）に従い，**既存 Issue を拾って**作業に取り掛かるための準備を整えてください． -本コマンドは既存 Issue から作業を始めるためのものです．新規 Issue を立てる場合は `/task-create` を使ってください．Issue 無しで小さい変更や試験的作業を進める場合はこのコマンドは不要です（GUIDE_06）． +本コマンドは既存 Issue から作業を始めるためのものです．新規 Issue を立てる場合は `/task-create` を使ってください．Issue 無しで小さい変更や試験的作業を進める場合はこのコマンドは不要です（GUIDE_03）． ## 前提確認 (Pre-check) 1. 作業ツリーの状態を確認する（`git status`）．未コミットの変更がある場合は，その旨をユーザーに伝え，先に片付けるか続行するか確認する． -2. 現在のブランチを確認する（`git branch --show-current`）．`main` 以外にいる場合は，そのブランチに未マージのコミットが残っていないか確認する（`git log main..HEAD --oneline`）．残っていれば「前の作業が未マージです．先にマージしてから着手するのが推奨です．続行しますか？」とユーザーに確認する（直列運用．GUIDE_06）． +2. 現在のブランチを確認する（`git branch --show-current`）．`main` 以外にいる場合は，そのブランチに未マージのコミットが残っていないか確認する（`git log main..HEAD --oneline`）．残っていれば「前の作業が未マージです．先にマージしてから着手するのが推奨です．続行しますか？」とユーザーに確認する（直列運用．GUIDE_03）． 3. $ARGUMENTS を確認する．Issue 番号（数値または `#数値`）が指定されていなければ「対象の Issue 番号を指定してください．新規 Issue を立てる場合は `/task-create` を使います」と伝えて終了する． ## ステップ 1: 直列運用チェック (Serial Check) -GUIDE_06「作業の直列化」より，同時に進行中のコード作業は原則 1 件とする． +GUIDE_03「作業の直列化」より，同時に進行中のコード作業は原則 1 件とする． 1. リポジトリ所有者を取得する（`gh repo view --json owner --jq .owner.login`）． -2. Project を特定する（`gh project list --owner `）．複数ある場合はユーザーに確認する．見つからない場合はその旨を伝え，ステップ 3（ボード操作）は飛ばして進める（管理者の初期設定が未完了．GUIDE_06）． -3. ボードのアイテムで Status が `In Progress` のものを数える（`gh project item-list --owner --format json`）．対象 Issue 以外で 1 件以上ある場合は，該当タスクを示し「直列運用では進行中の作業は原則 1 件です．続行しますか？」とユーザーに確認する（禁止ではなく原則．GUIDE_06）． +2. Project を特定する（`gh project list --owner `）．複数ある場合はユーザーに確認する．見つからない場合はその旨を伝え，ステップ 3（ボード操作）は飛ばして進める（管理者の初期設定が未完了．GUIDE_03）． +3. ボードのアイテムで Status が `In Progress` のものを数える（`gh project item-list --owner --format json`）．対象 Issue 以外で 1 件以上ある場合は，該当タスクを示し「直列運用では進行中の作業は原則 1 件です．続行しますか？」とユーザーに確認する（禁止ではなく原則．GUIDE_03）． ## ステップ 2: 対象 Issue の確認・アサイン (Verify & Assign) @@ -31,18 +31,18 @@ ## ステップ 3: ボードを In Progress へ (Board) -GUIDE_07「Projects の操作」に従う（Project が無い場合はこのステップを飛ばす）． +`reference.md` の「Projects の操作」に従う（Project が無い場合はこのステップを飛ばす）． 1. 対象 Issue がボードに未追加なら `gh project item-add --owner --url ` で追加する． 2. 対象アイテムの Status を `In Progress` に変更する（`gh project field-list`・`item-list` で必要な ID を取得し `gh project item-edit`）． -3. `gh project` の書き込み系は成功しても無出力のことがある．`gh project item-list` で結果を確認する（GUIDE_07）． +3. `gh project` の書き込み系は成功しても無出力のことがある．`gh project item-list` で結果を確認する（`reference.md`「トラブルシューティング」）． ## ステップ 4: 作業ブランチ作成 (Branch) Git 規約 `.claude/rules/git-conventions.md` に従う． 1. `git checkout main && git pull origin main` で `main` を最新化する． -2. git-conventions ルールの基本形式（`[プレフィックス][概要]`）でブランチ名を決める．プレフィックスはタスク種別（`feature` / `fix` / `refactor` / `docs` / `chore`），概要は内容を表す英単語 2〜4 語（kebab-case）とする．ブランチ名に Issue 番号は含めない（GUIDE_06）． +2. git-conventions ルールの基本形式（`[プレフィックス][概要]`）でブランチ名を決める．プレフィックスはタスク種別（`feature` / `fix` / `refactor` / `docs` / `chore`），概要は内容を表す英単語 2〜4 語（kebab-case）とする．ブランチ名に Issue 番号は含めない（GUIDE_03）． 3. `git checkout -b <ブランチ名>` で作業ブランチを作成する． ## ステップ 5: 完了サマリー (Summary) @@ -56,6 +56,6 @@ ## 注意事項 (Notes) -- branch↔Issue の紐付けは，後の PR 本文の `Closes #` で行う（GUIDE_06）．ブランチ名には番号を入れない． -- Projects 操作には `project` スコープが必要．スコープエラーが出たら `gh auth refresh -s project` を実行する（GUIDE_07）． +- branch↔Issue の紐付けは，後の PR 本文の `Closes #` で行う（GUIDE_03）．ブランチ名には番号を入れない． +- Projects 操作には `project` スコープが必要．スコープエラーが出たら `gh auth refresh -s project` を実行する（`reference.md`「必要なスコープ」）． - 新規 Issue を立てる場合は `/task-create`，Issue 無しで進める場合は本コマンドを使わず直接 `/implement` 等へ． diff --git a/.claude/skills/task-start/reference.md b/.claude/skills/task-start/reference.md new file mode 100644 index 0000000..895e526 --- /dev/null +++ b/.claude/skills/task-start/reference.md @@ -0,0 +1,73 @@ +# Issues・Projects gh 操作リファレンス (gh Operations Reference) + +`/task-create`・`/task-start`・`/task-handoff` の Issue・ボード操作で参照する詳細手順． +運用方針（Issue = 作業単位，直列運用，ボードの列等）は [GUIDE_03_チーム開発ルール](../../../docs/01_GUIDE/GUIDE_03_チーム開発ルール.md) に従う． + +- 操作は GitHub CLI（`gh`）に統一する．Web UI でも同じことはできるが，再現性とドキュメント化のため `gh` を基準とする． +- AI に Issue を読ませる場合は `gh issue view ` を使う（構造化出力は `--json title,body,assignees,labels`）． + +## 必要なスコープ (Required Scopes) + +`gh` のトークンスコープが操作範囲を決める． + +| 操作 | 必要スコープ | +| --- | --- | +| Issues の読み書き | `repo` | +| Projects の読み書き | `repo` ＋ `project` | + +スコープの確認と追加: + +```bash +gh auth status # 現在のスコープを確認 +gh auth refresh -s project # Projects 用スコープを追加（対話的な再認証が走る） +``` + +## ブランチと Issue のリンク (Branch-Issue Link) + +既存 Issue から作業ブランチを作る場合は `gh issue develop` を使うと，ブランチ作成と Issue↔ブランチのリンクを同時に行える（ブランチ名に依存しないリンク手段）: + +```bash +gh issue develop --name feature/<概要> --base main +``` + +## Projects の操作 (Projects) + +> ⚠ **Projects（ボード）は既定では未使用**（GUIDE_03）．以下は将来導入時の参考として残す． + +※ `gh project` 系は `project` スコープが必要（「必要なスコープ」参照）．`` はリポジトリ所有者（個人またはオーガニゼーション）． + +### 参照 (View) + +```bash +gh project list --owner # プロジェクト一覧（Project 番号を確認） +gh project view --owner # プロジェクトの概要 +gh project item-list --owner # ボード上のアイテム一覧 +gh project field-list --owner # フィールド（Status 等）と選択肢の ID を確認 +``` + +### Issue をボードに追加 (Add) + +```bash +gh project item-add --owner --url +``` + +### カードの状態（列）を移す (Move) + +`Status` フィールドの選択肢（`Todo` / `In Progress` 等）を変更する．フィールド ID と選択肢 ID は `field-list` で確認する． + +```bash +gh project item-edit \ + --id <アイテム ID> \ + --project-id <プロジェクト ID> \ + --field-id \ + --single-select-option-id <移動先の選択肢 ID> +``` + +※ ID の確認が煩雑なため，日常のカード移動は Web UI のボードで行い，一覧取得や自動化に `gh` を使う，という使い分けでもよい． + +## トラブルシューティング (Troubleshooting) + +- **`gh project` の書き込み系が無反応に見える**: `create` / `item-add` / `item-edit` は成功しても標準出力が空のことがある．`gh project list` / `item-list` で結果を確認する． +- **`gh project` がスコープエラーになる**: `project` スコープが未付与．`gh auth refresh -s project` を実行する． +- **コラボレーターが操作できない**: 招待を承認していない．`gh api "repos///collaborators" --jq '.[].login'` で承認済みメンバーを確認する． +- **`item-edit` の ID がわからない**: `gh project item-list` でアイテム ID，`gh project field-list` でフィールド ID・選択肢 ID を確認する． diff --git a/.gitignore b/.gitignore index 4ca9a56..aa42353 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,4 @@ -# 個人・マシン固有の Claude 設定（共有 settings.json を汚さない．GUIDE_06） +# 個人・マシン固有の Claude 設定（共有 settings.json を汚さない．GUIDE_03） .claude/settings.local.json # /implement が /commit に渡すコンテキストファイル diff --git a/CLAUDE.md b/CLAUDE.md index 3aa3765..1b61dc3 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -20,7 +20,7 @@ - `/auto-refactor`（リファクタ／ドキュメント整理ループ）→ `refactor/` 専用ブランチ - `/auto-audit`（バグ／脆弱性の巡回監査ループ）→ `fix/` 専用ブランチ -### エージェントチーム（GUIDE_05 準拠） +### エージェントチーム（GUIDE_02 準拠） - 実装は `/implement <タスク>` で開始する（コーディング → テスト → リファクタリング → ドキュメント更新） - Phase 1 後に人間が動作確認，Phase 2 でテスト失敗時のみ方針判断 @@ -43,7 +43,7 @@ ### 01_GUIDE（規約・ルール） - プロジェクト立ち上げフロー: docs/01_GUIDE/GUIDE_01_プロジェクト立ち上げフロー.md -- エージェント運用ルール: docs/01_GUIDE/GUIDE_05_エージェント運用ルール.md +- エージェント運用ルール: docs/01_GUIDE/GUIDE_02_エージェント運用ルール.md - ※ Git 規約・ドキュメント書式・命名規則・進捗記録は `.claude/rules/`（git-conventions / markdown-style / docs-naming / progress-log）に定義されている（git-conventions は常時，他は該当ファイル編集時に自動ロード） - ※ コーディング規約，テスト方針等はプロジェクト立ち上げ時に path-scoped rules（`.claude/rules/`）として作成する（GUIDE_01 参照） diff --git a/README.md b/README.md index 9ebde2a..71e4f02 100644 --- a/README.md +++ b/README.md @@ -5,7 +5,7 @@ **個人開発（solo）とチーム開発（team）の 2 モード**を 1 つのテンプレートで提供する．`/setup` の冒頭でモードを選ぶだけで，チーム開発向けのルール・コマンドが有効化される． - **solo**: 1 人で開発．進捗は `CLAUDE.md` の進捗欄＋ `docs/PROGRESS.md` で追う．チーム層ファイルは配置されない． -- **team**: 複数人が Claude Code で開発．進捗・タスクは GitHub Issues と git 履歴で追い，直列運用・条件付きセルフマージ等のチームルール（GUIDE_06）と `/task-create`・`/task-start`・`/task-handoff` コマンド，SessionStart の同期チェック（`check_sync.sh`）が有効になる． +- **team**: 複数人が Claude Code で開発．進捗・タスクは GitHub Issues と git 履歴で追い，直列運用・条件付きセルフマージ等のチームルール（GUIDE_03）と `/task-create`・`/task-start`・`/task-handoff` コマンド，SessionStart の同期チェック（`check_sync.sh`）が有効になる． ## Quick Start @@ -32,7 +32,7 @@ その後 Claude Code を起動し，`/setup ` でプロジェクト立ち上げを開始する．`/setup` の冒頭で **solo / team のモードを選択**する（選択結果は `.claude/project-mode` に記録され，以降の `/sync-template` がモードに応じてチーム層ファイルを出し分ける）．以降，テンプレートの更新を取り込むときは `/sync-template` を実行する． -> 途中でモードを切り替える場合は **`/set-mode `** を実行する．team 層ファイル（GUIDE_06/07・`task-*`・`check_sync.sh`）の配置／削除，`settings.json` の hook 配線，`CLAUDE.md` の team 化／solo 化，`.claude/project-mode` の更新を一括で整合させる（`.claude/project-mode` を手で書き換えるだけでは切り替わらない）． +> 途中でモードを切り替える場合は **`/set-mode `** を実行する．team 層ファイル（GUIDE_03・`task-*`・`check_sync.sh`）の配置／削除，`settings.json` の hook 配線，`CLAUDE.md` の team 化／solo 化，`.claude/project-mode` の更新を一括で整合させる（`.claude/project-mode` を手で書き換えるだけでは切り替わらない）． ## 主なスラッシュコマンド @@ -48,8 +48,7 @@ `docs/01_GUIDE/` にプロジェクト運用の規約・ルールが置かれている．`/setup` を実行すれば AI がこれらを順次参照しながら立ち上げを進める． - `GUIDE_01_プロジェクト立ち上げフロー.md` — 立ち上げの 7 フェーズ（方針決定 → 実装開始） -- `GUIDE_05_エージェント運用ルール.md` — `/implement` のエージェントチーム運用 -- `GUIDE_06_チーム開発ルール.md` — **team モードのみ**．直列運用・条件付きセルフマージ・共有設定の扱い -- `GUIDE_07_Issues・Projects運用ガイド.md` — **team モードのみ**．`gh` による Issue/Project 操作手順 +- `GUIDE_02_エージェント運用ルール.md` — `/implement` のエージェントチーム運用 +- `GUIDE_03_チーム開発ルール.md` — **team モードのみ**．直列運用・条件付きセルフマージ・共有設定の扱い -Git 規約（ブランチ命名・コミット書式）・ドキュメントの書式・ファイル命名・進捗記録のルールは `.claude/rules/`（`git-conventions` / `markdown-style` / `docs-naming` / `progress-log`）にあり，Claude へ自動ロードされる（git-conventions は常時，他は該当ファイル編集時）．push・PR・マージの詳細手順は `.claude/skills/commit/reference.md` にある． +Git 規約（ブランチ命名・コミット書式）・ドキュメントの書式・ファイル命名・進捗記録のルールは `.claude/rules/`（`git-conventions` / `markdown-style` / `docs-naming` / `progress-log`）にあり，Claude へ自動ロードされる（git-conventions は常時，他は該当ファイル編集時）．push・PR・マージの詳細手順は `.claude/skills/commit/reference.md`，Issues・Projects の `gh` 操作リファレンスは `.claude/skills/task-start/reference.md`（**team モードのみ**）にある． diff --git "a/docs/01_GUIDE/GUIDE_01_\343\203\227\343\203\255\343\202\270\343\202\247\343\202\257\343\203\210\347\253\213\343\201\241\344\270\212\343\201\222\343\203\225\343\203\255\343\203\274.md" "b/docs/01_GUIDE/GUIDE_01_\343\203\227\343\203\255\343\202\270\343\202\247\343\202\257\343\203\210\347\253\213\343\201\241\344\270\212\343\201\222\343\203\225\343\203\255\343\203\274.md" index 5f8ff78..aeb009d 100644 --- "a/docs/01_GUIDE/GUIDE_01_\343\203\227\343\203\255\343\202\270\343\202\247\343\202\257\343\203\210\347\253\213\343\201\241\344\270\212\343\201\222\343\203\225\343\203\255\343\203\274.md" +++ "b/docs/01_GUIDE/GUIDE_01_\343\203\227\343\203\255\343\202\270\343\202\247\343\202\257\343\203\210\347\253\213\343\201\241\344\270\212\343\201\222\343\203\225\343\203\255\343\203\274.md" @@ -70,8 +70,8 @@ - `.claude/rules/testing.md` — テストの種類，粒度，実行タイミング，カバレッジ基準，モック方針，テストファイルの配置規則（例: `paths: ["test/**", "**/*.test.*"]`） - `.claude/rules/error-handling.md` — エラーの分類，処理方法，ログ出力の方針（`paths` はソースディレクトリ全般） - ※ リファクタリング方針は言語に依存しないため，`.claude/agents/refactorer.md` の判断基準を共通ルールとして使用する - - ※ 機能実装完了フローは GUIDE_05 と `/implement` で定義済みのため，別途作成しない - - ※ 規約以外の運用フロー文書を `docs/01_GUIDE/` に追加する場合は，team 層の `GUIDE_06`・`GUIDE_07` との衝突を避けるため `GUIDE_08` 以降の番号を使う + - ※ 機能実装完了フローは GUIDE_02 と `/implement` で定義済みのため，別途作成しない + - ※ 規約以外の運用フロー文書を `docs/01_GUIDE/` に追加する場合は，team 層の `GUIDE_03` との衝突を避けるため `GUIDE_04` 以降の番号を使う ## 開発計画 (Development Plan) diff --git "a/docs/01_GUIDE/GUIDE_02_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" "b/docs/01_GUIDE/GUIDE_02_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" new file mode 100644 index 0000000..91f9daf --- /dev/null +++ "b/docs/01_GUIDE/GUIDE_02_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" @@ -0,0 +1,49 @@ +# エージェント運用ルール (Agent Operation Rules) + +実装品質を担保するために，3 つの専門エージェントを用いた開発パイプラインを定義する． +本ガイドは運用の**原則**を定める．各フェーズの具体的な実行手順（委譲プロンプト・分岐・確認メッセージ）は `/implement`（`.claude/skills/implement/SKILL.md`）が正本である． + +## 基本方針 (Basic Policy) + +- 「実装完了」とは，コーディング・テスト・リファクタリングの全フェーズが完了した状態を指す． +- 各フェーズは専門エージェントが担当し，フレッシュなコンテキストでレビューする．各エージェントは前フェーズのサマリーを入力として受け取り，加えて `git diff` で実際の変更差分を自ら確認する． +- フェーズのスキップは原則禁止する．リファクタリング不要の判断は Refactorer エージェント自身が行う． +- テストは実装コードではなく**仕様**（`docs/04_SPEC/`）を基準に書く．実装が仕様と異なればテストが失敗し，バグを検出する． +- 人間の本質的な役割は「AI にできない判断と確認」であり，各フェーズの品質のゲートキーパーとなる． + +## エージェント一覧 (Agent List) + +| エージェント | 役割 | フェーズ | +| --- | --- | --- | +| `coder` | 機能実装・バグ修正 | Phase 1 | +| `tester` | 仕様ベースのテスト作成・実行 | Phase 2 | +| `refactorer` | コード品質の改善 | Phase 3 | + +## パイプラインの流れと人間の役割 (Pipeline & Human's Role) + +`/implement <タスク内容>` で開始する（作業ブランチは git-conventions ルールに従い作成される）． + +| フェーズ | 担当 | やること | 人間の関与 | +| --- | --- | --- | --- | +| Phase 1: コーディング | `coder` | 実装に集中する（テスト・リファクタ・コミットはしない） | 完了後にブラウザ・実機で動作確認（AI にできない確認）．NG ならフィードバックして修正させる | +| Phase 2: テスト | `tester` | 仕様（`docs/04_SPEC/`）を基準にテストを作成・実行する | テスト失敗時のみ方針判断（仕様・実装・テストのどれの問題か）．全成功なら自動で Phase 3 へ | +| Phase 3: リファクタリング | `refactorer` | テストを安全網に，挙動を変えずに品質を改善する | なし（不要判断は Refactorer 自身が行う） | +| Phase 4: ドキュメント更新 | メイン | `docs/`・進捗記録を必要に応じて更新し，結果を `.claude/commit-context.md` に書き出す | 更新がある場合のみ確認 | +| 完了 | — | `/implement` はコミットしない | `/commit` でコミットする | + +チェック観点や委譲プロンプト等の詳細は `.claude/skills/implement/SKILL.md` を参照．`.claude/commit-context.md` は `/commit` が参照し，ドキュメント更新漏れチェックをスキップするために使う（`.gitignore` 対象）． + +## コミットルール (Commit Rules) + +パイプライン完了後は `/commit` でコミットする．コミットメッセージのタグ等は `.claude/rules/git-conventions.md` に従う． + +※ リファクタリングとテストは実装と一体の成果物として，まとめてコミットする．必要に応じて分割コミットも可． + +※ **例外（無人運転）**: 以下のループは CLAUDE.md の「`/commit` 自発実行禁止」ルールに対するユーザー承認済みの例外として，専用ブランチに自律コミットする．いずれも push・PR・マージ・`main` への操作は行わず，取り込み可否は人間が判断する． + +- `/auto-refactor`（リファクタ／ドキュメント整理ループ）→ `refactor/` 専用ブランチ +- `/auto-audit`（バグ／脆弱性の巡回監査ループ．発見を裏取り後，再現テストで正しさを担保できるものだけ自動修正し，それ以外は台帳へ報告）→ `fix/` 専用ブランチ + +## 進捗記録の運用ルール（CLAUDE.md / PROGRESS.md） + +進捗記録（CLAUDE.md「開発進捗」・`docs/PROGRESS.md` の書き方）のルールは `.claude/rules/progress-log.md` に定義されている．該当ファイルを編集する際に自動で読み込まれる． diff --git "a/docs/01_GUIDE/GUIDE_03_\343\203\201\343\203\274\343\203\240\351\226\213\347\231\272\343\203\253\343\203\274\343\203\253.md" "b/docs/01_GUIDE/GUIDE_03_\343\203\201\343\203\274\343\203\240\351\226\213\347\231\272\343\203\253\343\203\274\343\203\253.md" new file mode 100644 index 0000000..0450c47 --- /dev/null +++ "b/docs/01_GUIDE/GUIDE_03_\343\203\201\343\203\274\343\203\240\351\226\213\347\231\272\343\203\253\343\203\274\343\203\253.md" @@ -0,0 +1,142 @@ +# チーム開発ルール (Team Development Rules) + +チーム全員が Claude Code を用い，人間が直接コードを書くことはほぼない前提で，並行開発を破綻させずに進めるための協調ルールを定義する． + +> 本ガイドは**チーム開発モード**（`/setup` で team を選択したプロジェクト）でのみ有効．個人開発モード（solo）のプロジェクトには本ファイル・`task-*` コマンドは配置されない． + +Git の規約は `.claude/rules/git-conventions.md`（push・PR・マージ手順は `.claude/skills/commit/reference.md`），1 タスクの実装パイプラインは [GUIDE_02](GUIDE_02_エージェント運用ルール.md) に従う．本ガイドはそれらの上に立つ「複数人が同時に動くときの調整」を扱う． + +## 基本方針 (Basic Policy) + +- 全員が Claude Code で開発し，実装はエージェントが行う（チーム規模はプロジェクトによる）． +- 原則として並行作業を行わず，1 人ずつ直列で開発する．急ぎではないため，スループットより単純さと `main` の整合性を優先する．これは禁止ではなく既定のスタンスであり，状況に応じた判断は妨げない（詳細は「作業の直列化」）． +- 人間の本質的な役割は「AI にできない判断と確認」（GUIDE_02 と同じ）．加えて「共有設定の番人」を担う． +- 進捗・タスクは GitHub Issues と git 履歴で追う．`CLAUDE.md` には進捗を書かない（この点は solo 既定の進捗記録ルール `.claude/rules/progress-log.md` を**上書き**する）． +- `main` は常に動作可能な状態を保つ（`.claude/rules/git-conventions.md`）．壊れたら他の作業より優先して直す． + +## タスク管理 (Task Management) + +進捗管理の補助として GitHub Issues と Projects を用いる．`gh` コマンドでの具体的な操作手順（スコープ・Projects 操作・トラブル対応）は `.claude/skills/task-start/reference.md` を参照． + +### Issue (Issue) + +Issue は**進捗管理の補助**として使う．追跡したい作業に対して立て，PR と紐付けてボードで可視化する． + +- 作業 1 単位 = 1 Issue を推奨する．既に Issue がある作業は，新たに作らずそれに従って進める（重複 Issue を作らない）． +- **Issue は着手・PR 作成・マージのいずれの段階でも必須としない**．小さい変更（typo・1 行修正等）や試験的・探索的な作業は Issue 無しで進めてよい． +- ただし**追跡する価値のある作業には Issue を立てるのが望ましい**（後追いと進捗可視化のため）．特に複数回の `/implement` に跨る作業や，他メンバーに見えていてほしい作業は Issue を作る． +- PR と Issue を紐付ける場合は本文に `Closes #` を記載する．マージ時に Issue が自動クローズされ，ボードのカードも `Done` へ移る． +- Issue 本文には少なくとも「やること」を書く．「完了条件（受け入れ基準）」は非自明な作業のみで構わない． +- 担当者は明確にしておくのが望ましい（重複着手を避けるため）． +- Issue は最初に書き切らなくてよい．`/implement` の Phase 4 で実装サマリーを Issue にコメントし，必要に応じて本文も育てる（GUIDE_02）． + +### Project ボード (Project Board) + +> ⚠ **既定では未使用**．タスク管理は Issue ベース（`gh issue list`）で運用する．Project ボードはチームが拡大したり Issue が常時 10 件超になった等の局面で再導入する想定．以下は将来導入時の参考． + +- 列: `Todo` / `In Progress` / `In Review` / `Done`． +- Issue をカードとして配置し，状態を移動して可視化する． +- マージ連動の自動化を設定し，カード移動の手作業を最小化する（設定は管理者作業．「管理者の初期設定」参照）． + +### タスクの流れ (Task Flow) + +Issue を立てる場合の標準フロー（小さい変更や探索的作業はこの限りでない）． + +```text +1. Issue 起票（完了条件を明記） +2. 自分にアサイン（ボード未使用のためアサインのみ．ボード運用復活時は In Progress へ移動） +3. main から作業ブランチ作成（git-conventions ルール） +4. /implement に Issue の内容を渡して実装（GUIDE_02） +5. PR 作成，本文に "Closes #<番号>" +6. セルフマージ条件を確認 → マージ +7. マージで Issue 自動クローズ → カード自動 Done +``` + +- 上記 1 は `/task-create`（事前定義用），2 と 3 は `/task-start `（既存 Issue から着手）で半自動化できる．Issue 無しで進める場合はどちらも不要． +- Claude へのタスク文脈は `CLAUDE.md` ではなく Issue から渡す．`gh issue view ` で取得する． + +## ブランチと PR (Branch & PR) + +`.claude/rules/git-conventions.md` に従う．チーム運用上の追加事項のみ以下に定める． + +- ブランチ命名は git-conventions ルールの基本形式（`[プレフィックス][概要]`）に従う．ブランチ名に Issue 番号は含めなくてよい． +- branch↔Issue の紐付けは PR 本文の `Closes #<番号>` で行う．マージ時に Issue が自動クローズされる．既存 Issue からブランチを作る場合は `gh issue develop` でネイティブにリンクできる（`.claude/skills/task-start/reference.md`）． +- PR の `--title` はコミットメッセージと同じ書式（`[タグ] 内容`，`.claude/rules/git-conventions.md`）． + +## レビューとマージ (Review & Merge) + +誰も手書きしない体制では，マージ条件が唯一の品質ゲートとなる．本プロジェクトは**条件付きセルフマージ**を採用する．他メンバーの Approve 待ちは原則作らない代わりに，作者自身が満たすべき条件を実質的なゲートとして定める． + +### 通常の機能 PR (Feature PR) + +次を全て満たせば，作者がセルフマージしてよい． + +- CI で全テストが緑である． +- 作者自身が Phase 1 の動作確認（実機・ブラウザ等，AI にできない確認）を済ませている（GUIDE_02）． +- `/implement` のパイプラインをスキップせず完走している． +- 対応 Issue がある場合は完了条件を満たしている（Issue 無しの PR は不要）． +- 共有設定（`CLAUDE.md` のルール部・`.claude/`）の変更を含まない． + +※ レビューは任意．他メンバーはコメントしてよいが，マージをブロックしない． + +### 共有設定を変更する PR (Shared Config PR) + +`CLAUDE.md` のルール部や `.claude/` を変更する PR は，全員の Claude の挙動を変えるため例外とする． + +- 機能 PR に混ぜず，専用 PR とする（「共有設定の扱い」参照）． +- 他メンバー 1 名の Approve を必須とする（セルフマージ不可）． + +### CI 構築までの暫定ゲート (Interim Gate) + +CI が未構築の間は「CI 緑」を以下で代替する．CI 構築後はこの節を削除する． + +- `/implement` を完走している． +- ローカルで全テストが緑である． +- 作者自身が Phase 1 の動作確認を済ませている． + +## 共有設定の扱い (Shared Configuration) + +`CLAUDE.md` と `.claude/`（agents・skills・hooks・settings.json）は全員の Claude の挙動を決める共有インフラである． + +- **git 追跡を継続する**．untrack や `.gitignore` 化はしない（履歴の保全と挙動の統一のため）． +- **進捗は `CLAUDE.md` に書かない**．進捗は Issues と git 履歴で追う（「タスク管理」参照）． +- **変更は「チームルール変更」カテゴリ**として扱う． + - 機能 PR に混ぜない．専用 PR とする（ブランチは `chore/` または `docs/`）． + - 他メンバー 1 名の Approve を必須とする． + - マージ後はチームに周知し，全員が `git pull` して Claude セッションを再起動する． + - ※ Claude はセッション開始時に `CLAUDE.md` を読むため，古いまま動くと文脈がずれる． +- **例外: ドキュメント一覧への追記**は，そのドキュメントを追加する PR と同じ PR で行ってよい．衝突しても両方の行を残せば解決できる． +- **個人・マシン固有の設定**は `.claude/settings.local.json` に置く．これは `.gitignore` 対象とし，共有の `settings.json` を個人都合で汚さない． + +## 作業の直列化 (Serialized Work) + +- 原則として，同時に進行中のコード作業は 1 件とする（進行中の Issue は原則 1 件．Project ボード運用復活時は `In Progress` 列も同様）． +- 次の作業に着手してよいのは，前の作業の PR が `main` にマージされた後とする（マージ条件は「レビューとマージ」参照）． +- タスクは小さく保つ．直列運用では，1 単位が小さいほど次の人の待ち時間が短くなる． +- 直列運用により並行コンフリクトと共有設定のドリフトは原理的にほぼ発生しない．例外的に並行が生じてコンフリクトした場合は `.claude/skills/commit/reference.md` の rebase 手順をフォールバックとして用いる． +- `main` を壊した場合は他作業より優先して復旧する．自分で対処できない場合は直ちにチームへ報告する（`.claude/skills/commit/reference.md`「間違えて main にコミットしてしまった場合」）． + +## メンバーのオンボーディング (Onboarding) + +新メンバー参加時の手順． + +1. リポジトリへのコラボレーター招待を承認する（GitHub の通知，または `https://github.com///invitations`）． +2. リポジトリを clone する． +3. `ENV_02_環境構築手順.md`（GUIDE_01 参照，立ち上げ時に作成）に従い開発環境を構築する． +4. `gh auth login` で GitHub CLI を認証する．Projects も操作する場合は `project` スコープを含める（`.claude/skills/task-start/reference.md`「必要なスコープ」）． +5. 必要なら `.claude/settings.local.json` を用意する（個人設定．git 追跡されない）． +6. 最初に `CLAUDE.md` と `docs/01_GUIDE/` を読む（特に本ガイドと GUIDE_02）．Git 規約は `.claude/rules/git-conventions.md` にある． +7. `.gitignore` が整備されていることを確認する（`.claude/rules/git-conventions.md`）． + +## 管理者の初期設定 (Admin Setup) + +以下は外部サービス操作を含み，AI には実施できない．ルール確定後に管理者（人間）が一度だけ行う． + +- GitHub リポジトリの作成，メンバー招待． +- （既定では未使用）GitHub Project の作成，列（`Todo` / `In Progress` / `In Review` / `Done`）の定義． +- （既定では未使用）マージ連動の自動化設定（PR マージ時に Issue クローズ・カードを `Done` へ移動）． +- Issue テンプレートの用意（「やること」「完了条件」欄）． +- 共有設定変更 PR に他メンバー Approve を求める運用の周知（必要なら `main` のブランチ保護設定）． +- CI の構築（全テストを実行し，緑をマージ条件にできる状態にする）． + +※ 完了するまでは本ガイドの「CI 構築までの暫定ゲート」を適用する． diff --git "a/docs/01_GUIDE/GUIDE_05_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" "b/docs/01_GUIDE/GUIDE_05_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" deleted file mode 100644 index 91f9daf..0000000 --- "a/docs/01_GUIDE/GUIDE_05_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" +++ /dev/null @@ -1,49 +0,0 @@ -# エージェント運用ルール (Agent Operation Rules) - -実装品質を担保するために，3 つの専門エージェントを用いた開発パイプラインを定義する． -本ガイドは運用の**原則**を定める．各フェーズの具体的な実行手順（委譲プロンプト・分岐・確認メッセージ）は `/implement`（`.claude/skills/implement/SKILL.md`）が正本である． - -## 基本方針 (Basic Policy) - -- 「実装完了」とは，コーディング・テスト・リファクタリングの全フェーズが完了した状態を指す． -- 各フェーズは専門エージェントが担当し，フレッシュなコンテキストでレビューする．各エージェントは前フェーズのサマリーを入力として受け取り，加えて `git diff` で実際の変更差分を自ら確認する． -- フェーズのスキップは原則禁止する．リファクタリング不要の判断は Refactorer エージェント自身が行う． -- テストは実装コードではなく**仕様**（`docs/04_SPEC/`）を基準に書く．実装が仕様と異なればテストが失敗し，バグを検出する． -- 人間の本質的な役割は「AI にできない判断と確認」であり，各フェーズの品質のゲートキーパーとなる． - -## エージェント一覧 (Agent List) - -| エージェント | 役割 | フェーズ | -| --- | --- | --- | -| `coder` | 機能実装・バグ修正 | Phase 1 | -| `tester` | 仕様ベースのテスト作成・実行 | Phase 2 | -| `refactorer` | コード品質の改善 | Phase 3 | - -## パイプラインの流れと人間の役割 (Pipeline & Human's Role) - -`/implement <タスク内容>` で開始する（作業ブランチは git-conventions ルールに従い作成される）． - -| フェーズ | 担当 | やること | 人間の関与 | -| --- | --- | --- | --- | -| Phase 1: コーディング | `coder` | 実装に集中する（テスト・リファクタ・コミットはしない） | 完了後にブラウザ・実機で動作確認（AI にできない確認）．NG ならフィードバックして修正させる | -| Phase 2: テスト | `tester` | 仕様（`docs/04_SPEC/`）を基準にテストを作成・実行する | テスト失敗時のみ方針判断（仕様・実装・テストのどれの問題か）．全成功なら自動で Phase 3 へ | -| Phase 3: リファクタリング | `refactorer` | テストを安全網に，挙動を変えずに品質を改善する | なし（不要判断は Refactorer 自身が行う） | -| Phase 4: ドキュメント更新 | メイン | `docs/`・進捗記録を必要に応じて更新し，結果を `.claude/commit-context.md` に書き出す | 更新がある場合のみ確認 | -| 完了 | — | `/implement` はコミットしない | `/commit` でコミットする | - -チェック観点や委譲プロンプト等の詳細は `.claude/skills/implement/SKILL.md` を参照．`.claude/commit-context.md` は `/commit` が参照し，ドキュメント更新漏れチェックをスキップするために使う（`.gitignore` 対象）． - -## コミットルール (Commit Rules) - -パイプライン完了後は `/commit` でコミットする．コミットメッセージのタグ等は `.claude/rules/git-conventions.md` に従う． - -※ リファクタリングとテストは実装と一体の成果物として，まとめてコミットする．必要に応じて分割コミットも可． - -※ **例外（無人運転）**: 以下のループは CLAUDE.md の「`/commit` 自発実行禁止」ルールに対するユーザー承認済みの例外として，専用ブランチに自律コミットする．いずれも push・PR・マージ・`main` への操作は行わず，取り込み可否は人間が判断する． - -- `/auto-refactor`（リファクタ／ドキュメント整理ループ）→ `refactor/` 専用ブランチ -- `/auto-audit`（バグ／脆弱性の巡回監査ループ．発見を裏取り後，再現テストで正しさを担保できるものだけ自動修正し，それ以外は台帳へ報告）→ `fix/` 専用ブランチ - -## 進捗記録の運用ルール（CLAUDE.md / PROGRESS.md） - -進捗記録（CLAUDE.md「開発進捗」・`docs/PROGRESS.md` の書き方）のルールは `.claude/rules/progress-log.md` に定義されている．該当ファイルを編集する際に自動で読み込まれる． diff --git "a/docs/01_GUIDE/GUIDE_06_\343\203\201\343\203\274\343\203\240\351\226\213\347\231\272\343\203\253\343\203\274\343\203\253.md" "b/docs/01_GUIDE/GUIDE_06_\343\203\201\343\203\274\343\203\240\351\226\213\347\231\272\343\203\253\343\203\274\343\203\253.md" deleted file mode 100644 index 48f78eb..0000000 --- "a/docs/01_GUIDE/GUIDE_06_\343\203\201\343\203\274\343\203\240\351\226\213\347\231\272\343\203\253\343\203\274\343\203\253.md" +++ /dev/null @@ -1,142 +0,0 @@ -# チーム開発ルール (Team Development Rules) - -チーム全員が Claude Code を用い，人間が直接コードを書くことはほぼない前提で，並行開発を破綻させずに進めるための協調ルールを定義する． - -> 本ガイドは**チーム開発モード**（`/setup` で team を選択したプロジェクト）でのみ有効．個人開発モード（solo）のプロジェクトには本ファイル・GUIDE_07・`task-*` コマンドは配置されない． - -Git の規約は `.claude/rules/git-conventions.md`（push・PR・マージ手順は `.claude/skills/commit/reference.md`），1 タスクの実装パイプラインは [GUIDE_05](GUIDE_05_エージェント運用ルール.md) に従う．本ガイドはそれらの上に立つ「複数人が同時に動くときの調整」を扱う． - -## 基本方針 (Basic Policy) - -- 全員が Claude Code で開発し，実装はエージェントが行う（チーム規模はプロジェクトによる）． -- 原則として並行作業を行わず，1 人ずつ直列で開発する．急ぎではないため，スループットより単純さと `main` の整合性を優先する．これは禁止ではなく既定のスタンスであり，状況に応じた判断は妨げない（詳細は「作業の直列化」）． -- 人間の本質的な役割は「AI にできない判断と確認」（GUIDE_05 と同じ）．加えて「共有設定の番人」を担う． -- 進捗・タスクは GitHub Issues と git 履歴で追う．`CLAUDE.md` には進捗を書かない（この点は solo 既定の進捗記録ルール `.claude/rules/progress-log.md` を**上書き**する）． -- `main` は常に動作可能な状態を保つ（`.claude/rules/git-conventions.md`）．壊れたら他の作業より優先して直す． - -## タスク管理 (Task Management) - -進捗管理の補助として GitHub Issues と Projects を用いる．`gh` コマンドでの具体的な操作手順は [GUIDE_07](GUIDE_07_Issues・Projects運用ガイド.md) を参照． - -### Issue (Issue) - -Issue は**進捗管理の補助**として使う．追跡したい作業に対して立て，PR と紐付けてボードで可視化する． - -- 作業 1 単位 = 1 Issue を推奨する．既に Issue がある作業は，新たに作らずそれに従って進める（重複 Issue を作らない）． -- **Issue は着手・PR 作成・マージのいずれの段階でも必須としない**．小さい変更（typo・1 行修正等）や試験的・探索的な作業は Issue 無しで進めてよい． -- ただし**追跡する価値のある作業には Issue を立てるのが望ましい**（後追いと進捗可視化のため）．特に複数回の `/implement` に跨る作業や，他メンバーに見えていてほしい作業は Issue を作る． -- PR と Issue を紐付ける場合は本文に `Closes #` を記載する．マージ時に Issue が自動クローズされ，ボードのカードも `Done` へ移る． -- Issue 本文には少なくとも「やること」を書く．「完了条件（受け入れ基準）」は非自明な作業のみで構わない． -- 担当者は明確にしておくのが望ましい（重複着手を避けるため）． -- Issue は最初に書き切らなくてよい．`/implement` の Phase 4 で実装サマリーを Issue にコメントし，必要に応じて本文も育てる（GUIDE_05）． - -### Project ボード (Project Board) - -> ⚠ **既定では未使用**．タスク管理は Issue ベース（`gh issue list`）で運用する．Project ボードはチームが拡大したり Issue が常時 10 件超になった等の局面で再導入する想定．以下は将来導入時の参考． - -- 列: `Todo` / `In Progress` / `In Review` / `Done`． -- Issue をカードとして配置し，状態を移動して可視化する． -- マージ連動の自動化を設定し，カード移動の手作業を最小化する（設定は管理者作業．「管理者の初期設定」参照）． - -### タスクの流れ (Task Flow) - -Issue を立てる場合の標準フロー（小さい変更や探索的作業はこの限りでない）． - -```text -1. Issue 起票（完了条件を明記） -2. 自分にアサイン（ボード未使用のためアサインのみ．ボード運用復活時は In Progress へ移動） -3. main から作業ブランチ作成（git-conventions ルール） -4. /implement に Issue の内容を渡して実装（GUIDE_05） -5. PR 作成，本文に "Closes #<番号>" -6. セルフマージ条件を確認 → マージ -7. マージで Issue 自動クローズ → カード自動 Done -``` - -- 上記 1 は `/task-create`（事前定義用），2 と 3 は `/task-start `（既存 Issue から着手）で半自動化できる．Issue 無しで進める場合はどちらも不要． -- Claude へのタスク文脈は `CLAUDE.md` ではなく Issue から渡す．`gh issue view ` で取得する． - -## ブランチと PR (Branch & PR) - -`.claude/rules/git-conventions.md` に従う．チーム運用上の追加事項のみ以下に定める． - -- ブランチ命名は git-conventions ルールの基本形式（`[プレフィックス][概要]`）に従う．ブランチ名に Issue 番号は含めなくてよい． -- branch↔Issue の紐付けは PR 本文の `Closes #<番号>` で行う．マージ時に Issue が自動クローズされる．既存 Issue からブランチを作る場合は `gh issue develop` でネイティブにリンクできる（GUIDE_07）． -- PR の `--title` はコミットメッセージと同じ書式（`[タグ] 内容`，`.claude/rules/git-conventions.md`）． - -## レビューとマージ (Review & Merge) - -誰も手書きしない体制では，マージ条件が唯一の品質ゲートとなる．本プロジェクトは**条件付きセルフマージ**を採用する．他メンバーの Approve 待ちは原則作らない代わりに，作者自身が満たすべき条件を実質的なゲートとして定める． - -### 通常の機能 PR (Feature PR) - -次を全て満たせば，作者がセルフマージしてよい． - -- CI で全テストが緑である． -- 作者自身が Phase 1 の動作確認（実機・ブラウザ等，AI にできない確認）を済ませている（GUIDE_05）． -- `/implement` のパイプラインをスキップせず完走している． -- 対応 Issue がある場合は完了条件を満たしている（Issue 無しの PR は不要）． -- 共有設定（`CLAUDE.md` のルール部・`.claude/`）の変更を含まない． - -※ レビューは任意．他メンバーはコメントしてよいが，マージをブロックしない． - -### 共有設定を変更する PR (Shared Config PR) - -`CLAUDE.md` のルール部や `.claude/` を変更する PR は，全員の Claude の挙動を変えるため例外とする． - -- 機能 PR に混ぜず，専用 PR とする（「共有設定の扱い」参照）． -- 他メンバー 1 名の Approve を必須とする（セルフマージ不可）． - -### CI 構築までの暫定ゲート (Interim Gate) - -CI が未構築の間は「CI 緑」を以下で代替する．CI 構築後はこの節を削除する． - -- `/implement` を完走している． -- ローカルで全テストが緑である． -- 作者自身が Phase 1 の動作確認を済ませている． - -## 共有設定の扱い (Shared Configuration) - -`CLAUDE.md` と `.claude/`（agents・skills・hooks・settings.json）は全員の Claude の挙動を決める共有インフラである． - -- **git 追跡を継続する**．untrack や `.gitignore` 化はしない（履歴の保全と挙動の統一のため）． -- **進捗は `CLAUDE.md` に書かない**．進捗は Issues と git 履歴で追う（「タスク管理」参照）． -- **変更は「チームルール変更」カテゴリ**として扱う． - - 機能 PR に混ぜない．専用 PR とする（ブランチは `chore/` または `docs/`）． - - 他メンバー 1 名の Approve を必須とする． - - マージ後はチームに周知し，全員が `git pull` して Claude セッションを再起動する． - - ※ Claude はセッション開始時に `CLAUDE.md` を読むため，古いまま動くと文脈がずれる． -- **例外: ドキュメント一覧への追記**は，そのドキュメントを追加する PR と同じ PR で行ってよい．衝突しても両方の行を残せば解決できる． -- **個人・マシン固有の設定**は `.claude/settings.local.json` に置く．これは `.gitignore` 対象とし，共有の `settings.json` を個人都合で汚さない． - -## 作業の直列化 (Serialized Work) - -- 原則として，同時に進行中のコード作業は 1 件とする（進行中の Issue は原則 1 件．Project ボード運用復活時は `In Progress` 列も同様）． -- 次の作業に着手してよいのは，前の作業の PR が `main` にマージされた後とする（マージ条件は「レビューとマージ」参照）． -- タスクは小さく保つ．直列運用では，1 単位が小さいほど次の人の待ち時間が短くなる． -- 直列運用により並行コンフリクトと共有設定のドリフトは原理的にほぼ発生しない．例外的に並行が生じてコンフリクトした場合は `.claude/skills/commit/reference.md` の rebase 手順をフォールバックとして用いる． -- `main` を壊した場合は他作業より優先して復旧する．自分で対処できない場合は直ちにチームへ報告する（`.claude/skills/commit/reference.md`「間違えて main にコミットしてしまった場合」）． - -## メンバーのオンボーディング (Onboarding) - -新メンバー参加時の手順． - -1. リポジトリへのコラボレーター招待を承認する（GitHub の通知，または `https://github.com///invitations`）． -2. リポジトリを clone する． -3. `ENV_02_環境構築手順.md`（GUIDE_01 参照，立ち上げ時に作成）に従い開発環境を構築する． -4. `gh auth login` で GitHub CLI を認証する．Projects も操作する場合は `project` スコープを含める（GUIDE_07「必要なスコープ」）． -5. 必要なら `.claude/settings.local.json` を用意する（個人設定．git 追跡されない）． -6. 最初に `CLAUDE.md` と `docs/01_GUIDE/` を読む（特に本ガイド・GUIDE_05・GUIDE_07）．Git 規約は `.claude/rules/git-conventions.md` にある． -7. `.gitignore` が整備されていることを確認する（`.claude/rules/git-conventions.md`）． - -## 管理者の初期設定 (Admin Setup) - -以下は外部サービス操作を含み，AI には実施できない．ルール確定後に管理者（人間）が一度だけ行う． - -- GitHub リポジトリの作成，メンバー招待． -- （既定では未使用）GitHub Project の作成，列（`Todo` / `In Progress` / `In Review` / `Done`）の定義． -- （既定では未使用）マージ連動の自動化設定（PR マージ時に Issue クローズ・カードを `Done` へ移動）． -- Issue テンプレートの用意（「やること」「完了条件」欄）． -- 共有設定変更 PR に他メンバー Approve を求める運用の周知（必要なら `main` のブランチ保護設定）． -- CI の構築（全テストを実行し，緑をマージ条件にできる状態にする）． - -※ 完了するまでは本ガイドの「CI 構築までの暫定ゲート」を適用する． diff --git "a/docs/01_GUIDE/GUIDE_07_Issues\343\203\273Projects\351\201\213\347\224\250\343\202\254\343\202\244\343\203\211.md" "b/docs/01_GUIDE/GUIDE_07_Issues\343\203\273Projects\351\201\213\347\224\250\343\202\254\343\202\244\343\203\211.md" deleted file mode 100644 index c86a0a1..0000000 --- "a/docs/01_GUIDE/GUIDE_07_Issues\343\203\273Projects\351\201\213\347\224\250\343\202\254\343\202\244\343\203\211.md" +++ /dev/null @@ -1,136 +0,0 @@ -# Issues・Projects 運用ガイド (Issues & Projects Operations Guide) - -GitHub Issues と Projects を `gh` コマンドで操作する手順を定義する．人間も AI（Claude Code）も同じコマンドで操作する． - -> ⚠ **Projects の操作は現時点では未使用**．本ガイドの「Projects の操作」セクションは将来導入時の参考として残す．現状の運用は Issue ベースで完結する（[GUIDE_06](GUIDE_06_チーム開発ルール.md)）．Issue 操作・タスクライフサイクルは引き続き本ガイドの該当セクションを参照する． - -タスク管理の方針（Issue = 作業単位，ボードの列，直列運用等）は [GUIDE_06](GUIDE_06_チーム開発ルール.md) に従う．本ガイドはその操作手順を扱う． - -## 基本方針 (Basic Policy) - -- 操作は GitHub CLI（`gh`）に統一する．Web UI でも同じことはできるが，再現性とドキュメント化のため `gh` を基準とする． -- Issue がタスクの単位であり，`/implement` の入力でもある（GUIDE_06）． -- AI に Issue を読ませる場合は `gh issue view ` を使う． - -### 必要なスコープ (Required Scopes) - -`gh` のトークンスコープが操作範囲を決める． - -| 操作 | 必要スコープ | -| --- | --- | -| Issues の読み書き | `repo` | -| Projects の読み書き | `repo` ＋ `project` | - -スコープの確認と追加: - -```bash -gh auth status # 現在のスコープを確認 -gh auth refresh -s project # Projects 用スコープを追加（対話的な再認証が走る） -``` - -## Issues の操作 (Issues) - -### 参照 (View) - -```bash -gh issue list # 一覧 -gh issue list --assignee @me # 自分の担当のみ -gh issue list --state open # 未クローズのみ -gh issue view # 詳細表示 -gh issue view --json title,body,assignees,labels # 構造化出力（AI への受け渡し等） -``` - -### 作成 (Create) - -```bash -gh issue create --title "<タイトル>" --body "<本文>" -``` - -- 本文には「やること」と「完了条件（受け入れ基準）」を必ず書く（GUIDE_06）． -- `--assignee <ユーザー名>`，`--label <ラベル>` で担当・ラベルを同時に指定できる． - -### 更新・コメント・状態変更 (Edit / Comment / State) - -```bash -gh issue edit --add-assignee @me # 自分をアサイン -gh issue edit --add-label "<ラベル>" # ラベル追加 -gh issue comment --body "<コメント>" # コメント追加 -gh issue close # クローズ -gh issue reopen # 再オープン -``` - -## Projects の操作 (Projects) - -※ `gh project` 系は `project` スコープが必要（「必要なスコープ」参照）．`` はリポジトリ所有者（個人またはオーガニゼーション）． - -### 参照 (View) - -```bash -gh project list --owner # プロジェクト一覧（Project 番号を確認） -gh project view --owner # プロジェクトの概要 -gh project item-list --owner # ボード上のアイテム一覧 -gh project field-list --owner # フィールド（Status 等）と選択肢の ID を確認 -``` - -### Issue をボードに追加 (Add) - -```bash -gh project item-add --owner --url -``` - -### カードの状態（列）を移す (Move) - -`Status` フィールドの選択肢（`Todo` / `In Progress` 等）を変更する．フィールド ID と選択肢 ID は `field-list` で確認する． - -```bash -gh project item-edit \ - --id <アイテム ID> \ - --project-id <プロジェクト ID> \ - --field-id \ - --single-select-option-id <移動先の選択肢 ID> -``` - -※ ID の確認が煩雑なため，日常のカード移動は Web UI のボードで行い，一覧取得や自動化に `gh` を使う，という使い分けでもよい． - -## タスクのライフサイクル (Task Lifecycle) - -GUIDE_06 の「タスクの流れ」を `gh` コマンドで具体化したもの． - -※ ステップ 1 は `/task-create <タスクの説明>` で，ステップ 2〜4 は `/task-start ` で半自動化できる．以下は手動でも行える操作の参照． - -1. **Issue 起票**（完了条件を明記） - - ```bash - gh issue create --title "<タイトル>" --body "<やること・完了条件>" - ``` - -2. **アサインしてボードを In Progress へ** - - ```bash - gh issue edit --add-assignee @me - gh project item-add --owner --url # 未追加の場合 - ``` - - ボードの `Status` を `In Progress` に移す（`item-edit` または Web UI）． - -3. **作業ブランチ作成**（`.claude/rules/git-conventions.md` の基本形式） - - ```bash - git checkout main && git pull origin main - git checkout -b feature/<概要> - ``` - - ※ 既存 Issue から作る場合は `gh issue develop --name feature/<概要> --base main` を使うと，ブランチ作成と Issue↔ブランチのリンクを同時に行える（ブランチ名に依存しないリンク手段）． - -4. **実装**: `gh issue view ` で本文を取得し，`/implement` に渡す（GUIDE_05）． - -5. **PR 作成**: 本文に `Closes #` を記載する（PR 作成手順は `.claude/skills/commit/reference.md`）． - -6. **マージ**: マージで Issue は自動クローズされ，連動設定があればカードも `Done` へ移る（自動化設定は管理者作業．GUIDE_06「管理者の初期設定」）． - -## トラブルシューティング (Troubleshooting) - -- **`gh project` の書き込み系が無反応に見える**: `create` / `item-add` / `item-edit` は成功しても標準出力が空のことがある．`gh project list` / `item-list` で結果を確認する． -- **`gh project` がスコープエラーになる**: `project` スコープが未付与．`gh auth refresh -s project` を実行する． -- **コラボレーターが操作できない**: 招待を承認していない．`gh api "repos///collaborators" --jq '.[].login'` で承認済みメンバーを確認する． -- **`item-edit` の ID がわからない**: `gh project item-list` でアイテム ID，`gh project field-list` でフィールド ID・選択肢 ID を確認する．