메뉴
Git 運用の規律 (branch / worktree 運用、commit / push / pull / rebase / conflict 解決、remote 同期、完了時の統合) を一元的に担う skill。コード変更を伴う依頼・セッション開始・Git 操作の話題のいずれかに該当したら、他より先に必ず最初に使う。ファイルを 1 行でも書き換える依頼なら Git に無関係に見えても発火し、セッション開始・作業再開 (「前回の続き」「何から始めよう」等) でも必ず発火する。発火しないのはコードを読むだけの質問、Git の概念学習質問、doc のサマリ依頼。project 固有ルールでの部分上書きに対応する。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
xp-harness の skill / subagent が意図どおり振る舞えているか (発火するか・あるべき振る舞いができているか) を transcript で事実確認する手順。skill / subagent を改修した後に sandbox で動作検証したいとき、または本番の実運用セッションを「あるべき振る舞い」に照らして分析したいとき、「検証したい」「発火するか確かめたい」「このセッションを分析したい」と言われたときに発火させる。核は発火・振る舞いができたかの事実確認で、本番セッションでは自走の良し悪し (止まり方・判断の質など) も見る。
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。
設計判断・ライブラリ選定・アーキ判断・実装アプローチが 2 つ以上ありえる場面で必ず発火させる、「複数案＋メリデメ＋推奨」を提示する横断スキル。「どっちがいい？」「これでいい？」「方針を相談したい」と聞かれたとき、ライブラリ選定・ディレクトリ構成・API 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。
エンジニアとして手を動かす作業全般で必ず発火させる: コードを書く / テストを書く / リファクタ / バグ修正 / E2E spec 追加 / 既存仕様への小さな修正など、コードに触る作業すべて。「実装して」「テスト書いて」「リファクタして」「バグ直して」のような依頼を受けたとき、または基本設計が済んで実装フェーズに入るときに発火。基本作業は TDD（テスト先書き → 最小実装 → リファクタ → コミット）で進め、要件が大きければ適切な小ささに分割しつつサイクルを回す。発火しないのは要件定義 / 基本設計の対話中（まだ手を動かしていない時）だけ。
SOC 직업 분류 기준
| name | git-workflow |
| description | Git 運用の規律 (branch / worktree 運用、commit / push / pull / rebase / conflict 解決、remote 同期、完了時の統合) を一元的に担う skill。コード変更を伴う依頼・セッション開始・Git 操作の話題のいずれかに該当したら、他より先に必ず最初に使う。ファイルを 1 行でも書き換える依頼なら Git に無関係に見えても発火し、セッション開始・作業再開 (「前回の続き」「何から始めよう」等) でも必ず発火する。発火しないのはコードを読むだけの質問、Git の概念学習質問、doc のサマリ依頼。project 固有ルールでの部分上書きに対応する。 |
開発タスクの開始から push まで、Git 操作はあらゆる skill の context で発生する。各 skill に Git ルールを重複させると DRY 違反になり、project 固有の override も難しい。
この skill は Git 運用全般のデフォルト動作と override 機構を 1 か所に集約する。各 skill は自分の責務に集中し、Git 操作はこの skill に従う。
git push まで: 完了時に user の affirmative な確認を取った上で、main への統合 (ローカル merge) と push まで行う。PR 作成・PR 上の merge は依頼者の責務。あなたが PR を立ててはいけない新セッション / /clear 直後 / user の最初の依頼を処理する前に必ず実行:
git fetch origin — 副作用なし、必ず最初に叩く（remote の差分が見えるだけ）git branch --show-current — 現 branchgit status — working treegit log --oneline origin/main..main main..origin/main — 同期差分git worktree list --porcelain — worktree の有無（下記の掃除提案の入力）git status の "up to date with origin/main" は前回 fetch 時点での比較。fetch しないと古い情報のまま "up to date" を返すので信用できない。fetch を先に叩く理由はそこ。
確認結果を 1 メッセージにまとめる:
git branch --merged main と git worktree list --porcelain を突き合わせ、main に取り込まれ済みの branch を持つ worktree (使い終わったもの) を列挙する。見つかったときだけ AskUserQuestion で削除を提案する:
git branch -d)」の選択を含めるgit worktree remove 自体が拒否する (拒否されたら force せず報告) / 万一中にセッションが居ても worktree から抜ける操作で復旧できるremote が進んでいて pull したい場合、手元を先に整理する。理由:
git pull --autostash などで逃がすと stash の履歴が残らず、戻すのが大変具体的な振る舞い:
git stash push -m "<intent>" で明示 stash する / どちらか整理が終わってから pull、その後元依頼に進む。
worktree / branch 作成判断は 必ず AskUserQuestion ツールで選択肢を提示して、user の affirmative な選択を取る。チャットで「〜で切ります、違ったら教えてください」のように書いて即作成するのは禁止 — 沈黙を同意と扱うと、user が想定しない worktree / branch / タイミング / base ができて事故る。auto mode でも例外なし (worktree / branch 作成は routine decision ではなく state-changing operation)。
推奨は常に worktree に置く。タスクの軽重を理由に推奨を branch に入れ替えない (軽いタスクでも worktree のコストは小さく、並行作業の自由は常に価値がある)。branch で十分かどうかは user が選択肢の中から自分で選ぶ。
新セッション / /clear 直後の同期確認 (上記 §セッション開始時の同期確認) の後、必ず AskUserQuestion を出す。別 branch / worktree にいるからといって skip しない — 前 session の続きか / 新 task か / 違うことやりたいか、user に確認しないと事故る。
main / master にいる場合の例:
question: "main にいます。この session どう進めますか？"
header: "作業場所"
options:
- "worktree を切る (推奨)"
description: "repo の外に別ツリーを作りそこで作業。あなたは元 repo で並行作業できます。提案名: feat/<inferred>"
- "branch を切る"
description: "同じツリーで軽量。並行作業しないならこちらでも十分"
- "そのまま main で作業"
description: "branch 切らず続行 (commit / push 注意)"
- "違う名前で切る"
description: "選んだら名前をチャットで教えてください"
別 branch / worktree にいる場合の例:
question: "現 `<branch>` にいます。この session どう進めますか？"
header: "作業場所"
options:
- "そのまま `<branch>` の作業を続ける"
description: "前 session の続き"
- "新しく worktree を切る (新 task)"
description: "違う task を始める。提案名: `feat/<inferred>`"
- "新しく branch を切る (新 task)"
description: "worktree を使わない軽量運用"
- "違う名前で切る"
description: "選んだら名前をチャットで教えてください"
「違う名前で切る」が選ばれたら、チャットで名前を聞く。
worktree の選択肢を出す前に、セッションに追加の作業ディレクトリ (repo 外の add-dir) が登録されていないか確認する。ある場合のみ、worktree 選択肢の description に注意を含める:
worktree の隔離は repo 単位なので、追加ディレクトリはそこであなたが作業すると user の並行作業と踏み合いうる。user が分かった上で選べるようにする。
セッション中に user が新 task を切り出したとき:
依頼の core から推測する。規約:
feat/ (新機能)、fix/ (バグ修正)、chore/ (定型作業)、docs/ (文書)、refactor/ (リファクタ)feat/dialogue-principles、fix/login-redirect、refactor/extract-validators配置・命名規約:
../<repo名>-worktrees/<branch名のスラッシュを - に変えたもの>/
例: repo が myapp、branch が feat/order-review → ../myapp-worktrees/feat-order-review/
repo の外 (兄弟階層) に置く理由: repo 内に作るとメイン側の git status に漏れて gitignore が必要になる。外部なら完全分離。<repo名>-worktrees/ で束ねると複数 worktree が散らからず、丸ごと消せば掃除も簡単。
作成と入り方は 2 手:
git worktree add -b <branch名> ../<repo名>-worktrees/<dir名> — branch 付き worktree を外部に作るEnterWorktree の path 指定)注意:
EnterWorktree の name 形式) は repo 内 (.claude/worktrees/) に作られてしまうので使わない。必ず上記の 2 手worktree / branch 作成だけでなく pull / checkout / rebase / merge / push / cherry-pick / force push / worktree remove など state を変える操作も、user の affirmative な選択を取ってから実行する。沈黙 / 「違ったら言って」形式は禁止。
commit は高頻度 OK (TDD サイクル毎の commit は実装 skill の責務)。push は最終形に到達してから。作業が完了 (テスト含む) したら、以下の順で完了フローに入る。
done-verifier の検証は統合手順に入る前 (branch が生きていて、まだ何も統合していない状態) に通す。検証は「外に出る前の最後の砦」であり、統合・削除の後に検証する順序にしない。
git -C <メインrepoパス> status --short と git -C <メインrepoパス> branch --show-current で確認し、結果を統合確認の質問文に添えるgit fetch origin し、origin の主ブランチ (origin/main 等) が進んでいないか確認する。進んでいれば「origin/main が N コミット進んでいます」と確認の質問文に添える (人が立ち会う確認の直前に置く)。「main に統合」「branch のまま push (PR 運用)」「そのまま main で push」いずれの確認でも同じメイン側がきれい (main にいて未コミット変更なし) な通常ケース:
question: "開発完了しました (branch: feat/order-review)。成果をどう取り込みますか？
メイン側: main、変更なし (統合可能な状態です)"
header: "統合方法"
options:
- "main に統合して push (推奨)"
description: "main へ取り込んで push し、worktree と branch を削除します"
- "branch のまま push (PR 運用)"
description: "branch を push して終了。PR 作成はお願いします。worktree は残ります"
- "何もしない (保留)"
description: "worktree をこのまま残します。後で統合できます"
メイン側が汚れている / 別 branch にいる場合: 状態を質問文に明示し、推奨を「保留して報告のみ」に入れ替える (user の作業を踏まないことを優先)。「それでも main に統合する」が選ばれたら、変更の退避 (明示 stash) を伝えてから行う。
「そのまま main で作業」していた場合: 統合の概念がないため統合確認は出さない。push の確認を取って push して終わり。
git -C <メインrepoパス> status --short。完了報告から選択までの間に user の並行作業で汚れた可能性がある。汚れていたら統合に進まず報告し、保留を提案し直すgit -C <メインrepoパス> pullgit rebase main — branch の commit を最新 main の上に乗せ直すgit merge --ff-only <branch名> — rebase 済みなので必ず fast-forward。できない場合は想定とずれているサイン、無理に進めず user に報告。worktree に居たまま git -C <メインrepoパス> で遠隔実行しない (次の後始末まで worktree の中から実行することになり、自分の作業ディレクトリが宙吊りになる)git worktree remove <worktreeパス> → git branch -d <branch名>。統合済みなので即消せる (push を待たない — 成果はローカル main の履歴に入っており、push が失敗しても失われない)git push origin main完了の報告:
main に統合して push 完了 (branch: feat/xxx は統合済みのため削除)
worktree ../<repo>-worktrees/feat-xxx も削除しました。
branch のみ (worktree なし) で作業していた場合も同じ流れ (worktree 関連の手順だけ読み飛ばす): main 最新化 → rebase → fast-forward 統合 → branch 削除 → push。
git push origin <branch名> して終了。worktree は残す (統合・削除はしない)。
push 完了 (branch: feat/xxx)
PR 作成はお願いします。worktree ../<repo>-worktrees/feat-xxx は残っています
(マージ後の次セッションで掃除を提案します)。
git -C <メインrepoパス> を使って worktree の中から消すのも同じ (cwd がその worktree に居る限り宙吊りになる)。必ず先に worktree から抜けてメインに戻り、それから git worktree removegit branch -d (安全側) 限定。-D (強制) は使わない。-d が拒否される = 未統合の何かが残っているサインなので、止まって user に報告git worktree remove が未コミット変更で拒否されたら、--force を勝手に使わず user に確認gh コマンドは使わない明示的に git CLI を使う。gh は入っていない環境もあり、認証や引数で失敗することが多い。挙動の安定性を優先して git で統一。
例:
gh pr create ... (やらない)gh pr view ... (やらない)git push origin <branch>git log --onelinegit diff main...HEAD多くのコーディングエージェントの system prompt は「commit は明示依頼まで作らない」がデフォルト。このプロジェクトでは上記ルールで override する (project の instruction (Claude Code なら CLAUDE.md) と skill が system prompt のデフォルトより優先)。「commit は user の依頼を待つべきでは」と迷ったら、この明示ルールが上書きしていることを思い出す。
Project 固有の Git 運用ルール (branch protected、commit message 規約、push 禁止 branch、PR 必須運用など) がある場合は、project 固有のルールがこの skill の既定動作より優先する。
書かれた部分だけ上書き、書かれていない部分はこの skill の既定動作に従う (部分上書きが標準)。例えば「PR 必須 (main への直 push 禁止)」だけ project 固有ルールに書かれていれば、完了時の統合提案は出さず「branch のまま push (PR 運用)」を既定にし、それ以外 (worktree 提案 / commit リズム / 一般規律) はこの skill の既定で動く。