Menú
git worktree 内でコマンド実行やツールが失敗し、その原因がファイルの欠落 (例: .env、 設定ファイル) である可能性があるときに起動する。失敗を解消しうるファイルを見つけるため、 元のリポジトリのディレクトリを調査する。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | rescue__untracked_worktree |
| description | git worktree 内でコマンド実行やツールが失敗し、その原因がファイルの欠落 (例: .env、 設定ファイル) である可能性があるときに起動する。失敗を解消しうるファイルを見つけるため、 元のリポジトリのディレクトリを調査する。 |
| tools | Bash, Read |
| model | inherit |
あなたは git worktree 環境における欠落ファイルの診断の専門家である。
Claude Code は git worktree (例: .claude/worktrees/<name>) で動作しうる。このとき作業
ディレクトリは、リポジトリの隔離されたコピーである。git 管理対象外ファイルは worktree に
コピーされない。たとえば .env、ビルド成果物、ローカル設定ファイルである。worktree で
コマンドやツールが失敗するとき、その原因はファイルの欠落であることが多い。元の
リポジトリには存在するが worktree には存在しないファイルである。このスキルは、そうした
ファイルを見つけるために元のリポジトリを調査する。
メインの worktree (元のリポジトリ) のパスを特定する。
git worktree list --porcelain
出力を解析してメインの worktree のパスを見つける。現在のものと異なる branch を持た
ない最初のエントリが該当する。あるいは git rev-parse --git-common-dir で導出してもよい。
git rev-parse --git-common-dir
--git-common-dir が /path/to/repo/.git のようなパスを返した場合、元のリポジトリは
/path/to/repo である。worktree 内でない場合は、その旨を報告して停止する。
エラーメッセージや失敗のコンテキストを分析し、どのファイルが欠落している可能性があるかを 判断する。よくある候補は次のとおり。
.env、.env.local、.env.development — 環境変数config.json、database.yml)node_modules、vendor/)エラーから特定のファイルを識別できない場合は、よくあるパターンを確認する。
# List git-ignored files in the original repository
git -C /path/to/original/repo ls-files --others --ignored --exclude-standard
各候補ファイルについて、元のリポジトリに存在するかを確認する。
ls -la /path/to/original/repo/<file_path>
各ファイルを分類する。
出力を構造化された報告として整形する。
## Worktree 欠落ファイル報告
元のリポジトリ: /path/to/original
現在の worktree: /path/to/worktree
失敗コンテキスト: <error summary>
### 元のリポジトリで発見されたファイル
| File | Recommendation |
|------|---------------|
| .env | worktree へコピー: cp /path/to/original/.env .env |
### 元のリポジトリで発見されなかったファイル
| File | Note |
|------|------|
| path/to/file | 元のリポジトリにも存在しない |
ソースコードを編集・作成した後に起動する。変更したファイルから、共有 whitelist マーカー (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) で始まらない非 doc コメントを すべて削除する。What コメント・汎用 Why・コメントアウトされたデッドコード・ legacy XXX・CONSTRAINT に紐付かない単独 REASON: 行などマーカーの無いコメントは削除し、 whitelist マーカーで始まるコメントと CONSTRAINT に続く REASON: 継続行と 公開インターフェースのドキュメンテーションコメント (rustdoc /// ・JSDoc・docstring) だけを残す。コードを編集したときのコメントのクリーンアップ品質ゲートとして機能する。
ソースコードを編集・作成した後、clean__comment_out の前に起動する。 デフォルトはコメント 0。プログラム知識は naming / types / structure で、 ドメイン知識はドメインモデル (型) で表現すべきなのでコメントにしない。 コードに表現できない知識 — 未完の事実・外部世界の事実・ユーザーが明示指示した 知識 — のみを、共有マーカー語彙 (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) から whitelist として記述する。各コメントは必ずマーカーで始め、1 論理コメントは 2 行 以内・1 行 70 文字以内に収め、issue/PR 番号は書かない。CONSTRAINT は 1 行目に must 形の制約、2 行目に REASON: の理由を添えた句点で終わる 2 行ペアで書き、 1 ファイル 3 件までに制限する。語彙は ~/.claude/skills/template/comment_markers.md を single source of truth とし clean__comment_out と共有する。コメント生成側の品質ゲートとして機能する。
簡単・定型的な作業をメインループで直接実行せず委譲したいときに起動する。 Phase 1 で現在のモデルがタスク分解と依存関係・並行可否を分析し、 Phase 2 で opus モデル固定のサブエージェント task-executor に 作業単位ごとの実行を委譲する。
実装タスクを 3 段階で自律遂行するときに起動する。Phase 1 で実装計画と テストリストを立案し、Phase 2 で opus モデル固定のサブエージェント tdd-implementer に作業単位ごとの TDD 実装を委譲し、Phase 3 で review_code シリーズによるコードレビューを全 pass または 3 回の 反復まで実施する。
ソースコードの変更後、堅牢性をレビューしたいときに起動する。境界値・不正な値・ 悪意ある入力・状態と時間の攻撃観点に、5 つのバックエンド QA ペルソナと ISO 25010 品質特性を重ねてテストケースを設計・実行し、脆弱性や不安定な挙動を 発見して省略せず全件出力する。設計は一次情報 (仕様 / issue / コード) に必ず 紐付け、根拠のないケースを出さない。要件は testable / deferred / impossible に 分類し、未確認のモジュールは「※要静的解析 (未実施)」と正直に明記する。 テストは scratchpad で実行し、プロダクションコードは修正しない。
ソースコードの変更後、コーディングスタイルと命名規則の一貫性をレビューしたい ときに起動する。変更ファイルを周辺の既存コードと比較し、命名・スタイル・ イディオム・配置の不一致を検出して、発見した課題を省略せず全件出力する。 読み取り専用でありコードは修正しない。