git reset（HEAD / ブランチポインタの移動）の安全運用ルール。reset --hard は未コミット変更をどこにも残さず消せる唯一の日常操作であり、git reset を 1 つでも実行する前に必ず本スキルを参照する。
「reset して」「巻き戻して」「直前のコミットを取り消して」「コミットをやり直したい」「変更を全部捨てて」「HEAD を◯◯に戻して」と依頼される、rebase-flow の失敗から backup へ復旧する、reflog から復元する、といった場面すべてが対象。
決定論スクリプトで失われるもの（外れるコミット・push 済み範囲・消える未コミット変更）を判定 → 計画提示 → ユーザー承認 → safety branch 作成（arm）→ 実行 → 検証、のゲートを固定化する。plugin hooks の git-guard により arm なしの git reset は機械的にブロックされる。
unstage 目的なら reset ではなく git restore --staged を使う。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
git reset は 2 つの破壊を同時に起こせる: ブランチからコミットを外す（reflog / backup があれば復旧可）と、--hard による未コミット変更の完全消滅（どこにも残らず復旧不能 — reset 最大の危険）。本スキルは 収集 → 計画提示 → 承認 → arm + 実行 → 検証 をゲートとして固定する。
環境側の強制: plugin hooks の git-guard（PreToolUse） が git reset を監視しており、scripts/reset-arm.sh が置く解錠 marker（30 分有効）が無い実行は機械的に deny される。
| やりたいこと | reset 不要の代替 |
|---|---|
| ステージを外す（unstage） | git restore --staged <paths>（guard 対象外・HEAD を動かさない） |
| ファイルの変更を捨てる | git restore <paths>（対象を限定できる） |
| 直前コミットの修正 | git commit --amend（rebase-flow / commit-flow の範疇） |
| push 済みコミットの取り消し | git revert（履歴を書き換えない） |
本スキルの対象は「HEAD / ブランチポインタを動かす reset」だけ。上記で足りるなら reset しない。
git reset を実行しない。scripts/reset-arm.sh で safety branch + 解錠 marker を作ってから実行する。--abort を使う）では計画に進まない。--hard × 未コミット変更は明示承認 — 消えるファイル一覧を計画に載せ、破棄が意図だと確認できた場合のみ reset-arm.sh --allow-dirty。確認できなければ実行しない。--expect）。bash <skill-dir>/scripts/reset-context.sh <target-ref> <hard|mixed|soft>
--hard で消える未コミット変更。WARNING が出たら制約 4 へ。## reset 計画: <目的を一言>
### 現在の状態
- ブランチ: `<branch>`（HEAD: `<sha7>`、safety 予定名: `backup/reset/<branch>-<ts>`）
- WARNING: <スクリプトの WARNING 全件。無ければ「なし」>
### reset が必要な理由
<目的。reset 以外で足りないことも一言>
### 実行するコマンド
git reset --<mode> <target-ref>
### 失われるもの / 残るもの
- ブランチから外れるコミット: <N 件（一覧）> → safety branch に残る
- 未コミット変更: <--hard: 消滅（一覧）/ それ以外: 保持>
- untracked・stash: 影響なし
### 期待される reset 後の状態
<HEAD がどこを指すか。git log の見え方>
### 復旧手段
- コミットの復旧: reset-flow で target=<safety branch>
- <--hard × dirty の場合: 未コミット変更は復旧不能>
軽量ケース（--soft / --mixed で外れるコミットも push 影響も無い場合）は「現在の状態・コマンド・影響」の 3 点に簡略化してよい。承認と arm は同じく必須。
bash <skill-dir>/scripts/reset-arm.sh（dirty 破棄の承認済み計画のみ --allow-dirty）git rev-parse HEAD が target と一致すること。git status --short と git log --oneline -5 で期待状態を確認。rm -f "$(git rev-parse --git-path reset-flow.armed)"scripts/reset-context.sh — 失われるもの・push 影響・dirty 判定の read-only 収集scripts/reset-arm.sh — safety branch 作成 + guard 解錠まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコミット流儀へ揃える場面でも参照する。plan モードでのコミット計画の立案は commit-plan スキルの領分。
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・メッセージ確定・git commit 実行）は commit-flow スキルが担う。
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。