diff --git a/.claude/agents/ops-runner.md b/.claude/agents/ops-runner.md index 90c7a3e..0810b52 100644 --- a/.claude/agents/ops-runner.md +++ b/.claude/agents/ops-runner.md @@ -42,5 +42,6 @@ 最終報告には以下だけを含める（上位がユーザー向けに整形するため，経過の説明は不要）: - **実行した操作**: 箇条書き（ブランチ・コミット SHA・Issue / PR 番号・URL 等の成果物を含める） +- **事実報告**: 手順書が「返すこと」と指定した事実（変更ファイルの分類等．判断や解釈は加えない．無ければ省略） - **警告**: 手順書のチェックで引っかかった点（無ければ省略） - **確認事項**: 停止した理由・状況・選択肢・推奨（停止した場合のみ） diff --git a/.claude/skills/commit/SKILL.md b/.claude/skills/commit/SKILL.md index 2804248..6f331c3 100644 --- a/.claude/skills/commit/SKILL.md +++ b/.claude/skills/commit/SKILL.md @@ -6,28 +6,36 @@ disable-model-invocation: true --- -あなたは Git 運用の司令塔です．コミット作業の実行は **ops-runner エージェント**（軽量モデル）に委譲し，あなた自身は意図の伝達・確認の仲介・結果の報告だけを行います（使用量節約のため，diff 読みや git 操作を自分では行わない）． +あなたは Git 運用の司令塔です．コミット作業の実行は **ops-runner エージェント**（軽量モデル）に委譲し，あなた自身は**判断**（意図・docs 更新の要否）・確認の仲介・結果の報告だけを行います（使用量節約のため，diff 読みや git 操作を自分では行わない．逆に価値判断は ops-runner にさせない）． -## ステップ 1: 意図サマリの作成 (Intent) +## ステップ 1: 意図サマリと docs 要否の判断 (Intent & Docs Decision) -このセッションで行った作業を把握している場合は，以下を 1〜3 行で作る．把握していない場合（セッション開始直後の `/commit` 等）は「意図情報なし」とする． +このセッションで行った作業を把握している場合は，以下を作る（**判断はここで行う**）: -- 何をなぜ変更したか（コミットメッセージの材料） -- コミットメッセージの品質を確実にしたい場合（重要な変更等）は，`.claude/rules/git-conventions.md` の書式でメッセージ全文を自分で確定させてよい +- **意図サマリ**（1〜3 行）: 何をなぜ変更したか（コミットメッセージの材料）．重要な変更なら `.claude/rules/git-conventions.md` の書式でメッセージ全文を確定させてもよい +- **docs 更新の要否**（3 択）: 変更が API・データ構造・環境設定・開発計画の進捗・規約やルールに関わるかを，セッションの知識で判断する + - **更新済み**: 今回の変更に `docs/`・CLAUDE.md「開発進捗」・`docs/PROGRESS.md` の更新も含めてある + - **不要**: 該当しない + - **要**: 委譲する前に必要な更新を行う（内容に迷う場合はユーザーに確認する）．docs を同じコミットに含めるため +- **ブランチ名**: 現在 `main` にいる可能性がある場合は，git-conventions の命名規則（プレフィックス＋英単語 2〜4 語）でブランチ名を決めて渡す（ops-runner に命名させない） +- `.claude/commit-context.md` がある場合（`/implement` 経由）は，そこに記録された判断を正とし，改めて判断しない + +セッションを把握していない場合（起動直後の `/commit` 等）は「意図情報なし・要否は事後判断」とする． ## ステップ 2: 委譲 (Delegate) ops-runner エージェントを起動し，プロンプトに以下を含める: - 手順書: `.claude/skills/commit/reference.md` の「コミット実行手順」と `.claude/rules/git-conventions.md` を読んで従うこと -- ステップ 1 の意図サマリ（またはメッセージ全文） +- ステップ 1 の意図サマリ（またはメッセージ全文）．意図情報なしの場合はその旨 - $ARGUMENTS（`push` / `merge` キーワードの有無を明示する） - 確認が必要な事態では停止して報告すること ## ステップ 3: 結果報告 (Report) - エージェントの報告（ブランチ・コミット SHA・メッセージ・PR URL 等）をユーザーに簡潔に伝える -- エージェントが返した警告（docs/・CLAUDE.md・`docs/PROGRESS.md` の更新漏れの可能性等）はそのまま表示し，判断はユーザーに委ねる +- **意図情報なしで委譲した場合**は，エージェントの「事実報告」（変更ファイルの分類）を見て docs 更新の要否を事後判断し，必要と思われれば「⚠ docs/・CLAUDE.md の開発進捗・`docs/PROGRESS.md` の更新が必要かもしれません」とユーザーに伝える（追加コミットで対応してよい） +- エージェントが返した警告（意図と diff の食い違い等）はそのまま表示し，判断はユーザーに委ねる - エージェントが「確認事項」で停止した場合は，ユーザーに確認し，回答を「承認済み」として添えて再委譲する ## 注意事項 (Notes) diff --git a/.claude/skills/commit/reference.md b/.claude/skills/commit/reference.md index 3c9ba35..e5c376c 100644 --- a/.claude/skills/commit/reference.md +++ b/.claude/skills/commit/reference.md @@ -16,32 +16,27 @@ **main ブランチにいる場合は自動でブランチを作成する:** -1. 変更内容から git-conventions のブランチ命名規則に従い，適切なプレフィックスと英単語 2〜4 語のブランチ名を決定する +1. 司令塔からブランチ名が渡されていればそれを使う．渡されていなければ，変更内容から git-conventions のブランチ命名規則に従い適切なプレフィックスと英単語 2〜4 語のブランチ名を決め，決めた名前を報告に含める 2. `git checkout -b {ブランチ名}` で作業ブランチを作成する -### ステップ 2: docs/ 更新漏れチェック +### ステップ 2: ドキュメント関連の事実収集 -`.claude/commit-context.md` が存在し `docs_updated` が記録されている場合，このステップをスキップする． -ファイルが存在しない場合（`/implement` を経由していない場合），変更内容が以下に該当するにもかかわらず docs/ が更新されていないときは，最終報告の「警告」に「⚠ docs/ の更新が必要かもしれません」を含める（更新自体は行わない）: +docs 更新の要否の**判断はしない**（司令塔が行う）．以下の事実を最終報告の「事実報告」に含める: -- API やデータ構造の変更／環境設定の変更／開発計画の進捗に関わる変更／規約やルールに関わる変更 +- `.claude/commit-context.md` の有無と，あれば記録されたフラグ（`docs_updated` / `claude_md_updated` / `progress_md_updated`） +- 変更ファイルの分類: `docs/` 配下・`CLAUDE.md`・`docs/PROGRESS.md` のそれぞれを含むか，およびそれ以外の変更ファイル一覧 ### ステップ 3: コミットメッセージの生成 上位から渡された意図サマリ・引数と変更内容をもとに，git-conventions の「コミットメッセージ」書式で生成する．上位がメッセージ全文を確定して渡した場合はそのまま使う．意図サマリと実際の diff に食い違いがある場合は，diff を正としつつ食い違いを「警告」に含める． -### ステップ 4: CLAUDE.md / PROGRESS.md 更新漏れチェック - -`.claude/commit-context.md` が存在し `claude_md_updated` と `progress_md_updated` が記録されている場合，このステップをスキップする． -記録がなく，変更内容に対して CLAUDE.md の「開発進捗」（最新 1 行）や `docs/PROGRESS.md`（追記型フルログ）の更新が必要と思われる場合は「警告」に含める（更新自体は行わない）． - -### ステップ 5: コミット +### ステップ 4: コミット 1. `git add` で関連ファイルをステージングする（CLAUDE.md / `docs/PROGRESS.md` の変更がある場合はそれも含める．`.env` やクレデンシャルファイルはステージングしない） 2. `git commit -m "{コミットメッセージ}"` でコミットする 3. `.claude/commit-context.md` が存在する場合は削除する -### ステップ 6: プッシュ・PR・マージ +### ステップ 5: プッシュ・PR・マージ 上位から渡された引数に以下のキーワードが含まれる場合のみ実行する（いずれも無ければスキップ）． diff --git a/.claude/skills/deps-update/SKILL.md b/.claude/skills/deps-update/SKILL.md index f04fe41..53bb2c8 100644 --- a/.claude/skills/deps-update/SKILL.md +++ b/.claude/skills/deps-update/SKILL.md @@ -58,8 +58,9 @@ - 手順書: `reference.md` の「不変条件」と「実行手順 B: 検証とマージ」を読んで従うこと - 対象 PR の一覧（処理順・各 PR の検証方法: CI 待ち / ローカル検証 / rebase 依頼のみ） +- **各 PR のマージ条件**（判定表から機械的に導いて明示する．ops-runner に判定表を解釈させない）: `patch` → 到達 Tier が A または B なら可，`minor` → Tier A のみ可．Tier の定義: A＝CI 全緑またはローカル検証（テスト含む）全緑，B＝テストが無い／特定できないが依存インストールとビルド／型チェックは通る，C＝検証不能 -検証が赤・検証不能になった PR はマージされずに戻ってくるので，フェーズ 4 の分析対象に加える． +検証が赤・Tier 不足・検証不能になった PR はマージされずに戻ってくるので，フェーズ 4 の分析対象に加える． ## フェーズ 4: 影響分析 (Analyze) diff --git a/.claude/skills/deps-update/reference.md b/.claude/skills/deps-update/reference.md index 3f4066c..588dd2d 100644 --- a/.claude/skills/deps-update/reference.md +++ b/.claude/skills/deps-update/reference.md @@ -31,9 +31,9 @@ 1. **rebase 依頼のみ指定の PR**: `@dependabot rebase` をコメントして次へ進む（マージしない） 2. **状態の取り直し**: マージのたびに Dependabot が残りの PR を自動 rebase するため，各 PR の処理前に `mergeable`・CI 状況を取り直す．`CONFLICTING` / `BEHIND` になっていれば rebase 依頼に切り替える -3. **検証**: CI があれば「CI の完了待ち」，無ければ「ローカル検証」を実行する -4. **緑の場合**: 「マージ」の手順どおり `gh pr merge <番号> --merge --delete-branch` でマージし，`deps-update-merged.md` へ「台帳の書式」で追記し，ローカル `main` を pull する -5. **赤・検証不能の場合**: マージせず，失敗したコマンド／チェックの要約を添えて「分析行き」として結果に含める +3. **検証**: CI があれば「CI の完了待ち」，無ければ「ローカル検証」を実行し，到達 Tier（A / B / C．「ローカル検証」の「検証結果の解釈」に従う）を判定する +4. **到達 Tier が司令塔の指定したマージ条件を満たす場合**: 「マージ」の手順どおり `gh pr merge <番号> --merge --delete-branch` でマージし，`deps-update-merged.md` へ「台帳の書式」で追記し，ローカル `main` を pull する +5. **満たさない場合（赤・Tier 不足・検証不能）**: マージせず，到達 Tier と失敗したコマンド／チェックの要約を添えて「分析行き」として結果に含める．マージ条件が渡されていない PR はマージせず確認事項として返す 6. **後片付け**: 全件終了後，ローカル検証で作ったブランチ・マージ状態を破棄して開始時のブランチへ戻り，`git status --short` が空であることを確認して結果（マージ済み・rebase 依頼済み・分析行き）を返す ## 前提の確認 (Prerequisites) diff --git a/.claude/skills/task-start/SKILL.md b/.claude/skills/task-start/SKILL.md index 8450ca0..f584e0c 100644 --- a/.claude/skills/task-start/SKILL.md +++ b/.claude/skills/task-start/SKILL.md @@ -21,6 +21,7 @@ - 手順書: 本スキルの `reference.md`（`.claude/skills/task-start/reference.md`）の「/task-start 実行手順」を読んで従うこと - 対象の Issue 番号 +- **ブランチ名**: Issue の内容を把握している場合（同セッションで `/task-create` した直後等）は `.claude/rules/git-conventions.md` の命名規則で決めて渡す．把握していなければ ops-runner に規約どおり提案・作成させ，報告で名前を確認する - 確認が必要な事態（未コミット変更・未マージブランチ・進行中タスクあり・他人アサイン等）では，該当項目をまとめて停止・報告すること ## ステップ 3: 確認の仲介 (Confirm) diff --git a/.claude/skills/task-start/reference.md b/.claude/skills/task-start/reference.md index 9ad1573..15cb66e 100644 --- a/.claude/skills/task-start/reference.md +++ b/.claude/skills/task-start/reference.md @@ -47,7 +47,7 @@ 2. **直列運用チェック**: 所有者を取得し Project を特定する（複数なら停止して報告．無ければボード操作を飛ばす）．進行中の作業を数える（Project があれば `item-list` で Status が `In Progress` のもの，無ければ `gh issue list --assignee @me --state open`）．対象 Issue 以外に 1 件以上あれば，該当タスクの一覧を添えて停止して報告する（禁止ではなく原則） 3. **対象 Issue の確認・アサイン**: `gh issue view ` で内容を確認する（存在しない・クローズ済み・他人がアサイン済みの場合は停止して報告する）．`gh issue edit --add-assignee @me` で自分をアサインする 4. **ボードを In Progress へ**: 「Projects の操作」に従い，未追加なら `item-add` → Status を `In Progress` に変更 → `item-list` で結果を確認する（Project が無い場合は飛ばす） -5. **作業ブランチ作成**: `git checkout main && git pull origin main` で `main` を最新化し，規約どおりのブランチ名（プレフィックス＋英単語 2〜4 語．Issue 番号は含めない）で `git checkout -b <ブランチ名>` する +5. **作業ブランチ作成**: `git checkout main && git pull origin main` で `main` を最新化し，`git checkout -b <ブランチ名>` する．ブランチ名は司令塔から渡されていればそれを使い，無ければ Issue タイトルから規約どおり（プレフィックス＋英単語 2〜4 語．Issue 番号は含めない）決めて，決めた名前とプレフィックスの選択理由を報告に含める 6. **報告**: Issue 番号・タイトル・URL・ボード状態・作成したブランチ名を返す ※ ステップ 1〜3 の停止条件に複数該当する場合は，まとめて 1 回の報告で返す（司令塔との往復を減らす）．司令塔から「ユーザー承認済み」と明示された項目では停止しない． @@ -61,7 +61,7 @@ 1. 所有者を取得し Project を特定する（無くても問題ない）．着手中の Issue を抽出する（Project があれば `item-list` で Status が `In Progress` のもの，無ければ `gh issue list --assignee @me --state open`） 2. 0 件ならその旨を報告して終了する．複数件なら一覧（番号・タイトル）を確認事項として返す 3. 対象 Issue について以下を収集して返す: - - `gh issue view --json number,title,body,comments`（本文と過去コメントの要点．過去の進捗メモと重複させないための材料） + - `gh issue view --json number,title,body,comments`（本文と過去コメントを**原文のまま**返す．要約・取捨選択はしない．コメントが多い場合は直近の「進捗メモ」コメントを優先して原文で返し，古いものは件数と日付だけにする） - `git branch --show-current`／`git rev-parse --short HEAD`／`git log main..HEAD --oneline`／`git status --porcelain` ### 投稿フェーズ (Post)