プロジェクト監査。「監査して」「audit」「/audit」で発火。設計/UX/品質/テストなどの観点でコードベース全体を監査し、課題をissuesディレクトリに書き出す。実行ログで重複実行を防止。特定の差分・コミットのレビューには使わない（codex-review / cross-review を使う）。
jiikko/dotfiles22026年10月11日 更新
無料GitHub で公開
crash-log-analyzer
macOS アプリのクラッシュログ (.ips) を解析し、根本原因を特定するスキル。「クラッシュした」「crash」「.ips」「DiagnosticReports」「SIGSEGV / SIGABRT」で発火。
**macOS 専用**（.ips の読み方が macOS の DiagnosticReports 前提。iOS の .ips は未対応）。解析は crash-analyzer subagent に委譲する。クラッシュログが存在しない一般のバグ調査・テスト失敗には使わない。
含まれるファイル（1）
- SKILL.md2.8 KB
SKILL.md（原文）
インストールする前に、エージェントに与えられる指示の中身を確認できます。
macOS Crash Log Analyzer
対象のクラッシュログを選び、解析を crash-analyzer agent に渡して、結果を検閲して報告する。
.ips の読み方・分類・報告の書式の正本は _claude/agents/crash-analyzer.md。ここには写さない
(2 箇所に書くと片方だけ直って食い違う。実際に食い違っていた)。
Step 1: 候補を出す
- プロジェクトに
bin/*crash-logがあれば (ThumbnailThumb のbin/tt-crash-logなど)、それで最新のログを特定してよい - 無ければ
crash-analyzer.mdの「0. 対象のログを決める」にある一覧のコマンドを、APPにアプリ名を入れて回す。 1 行目のメタデータ (timestamp/bug_type/app_name) だけを読むので速い
Step 2: ユーザーに確認する (必要なときだけ)
候補が 1 件で、app_name がカレントプロジェクトのアプリ名と一致し、24 時間以内なら確認を省いて Step 3 へ進む。
それ以外 (候補が複数 / 0 件 / アプリ名が違う / 古いものしかない) は AskUserQuestion で聞く:
- 対象のログ: 候補 (アプリ名・日時) から選んでもらう
- クラッシュしたときの状況: 何をしていたか (任意)
Step 3: agent に渡す
subagent_type: crash-analyzer
prompt: |
次のクラッシュログを解析してください。手順と報告の書式はあなたの定義に従ってください。
- ログ: {crash_log_path}
- プロジェクトのソース: カレントディレクトリ
- クラッシュしたときの状況: {user_context または「不明」}
Step 4: 結果を検閲して報告する
agent (sonnet) の報告はそのまま採らない (~/.claude/rules/subagent-model-tiering.md):
- 「根本原因」とされた
file:lineを自分で開き、そのコードがスタックトレースの関数と合っているかを見る。 合わなければ「仮説」に落とす - 仮説のまま確度が低い / ソースの深い理解が要るなら、main モデルで自分が読み直すか debugger agent へ回す
- issue を起こすかはユーザーに確認し、起こすならその repo の issue 規約で書く (type は
bug)。 agent には起票させない
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
AVFoundation (AVPlayer / AVPlayerLayer / AVPlayerItemVideoOutput / AVAsset) の落とし穴・文書化されていない実装挙動・debugging チェックリストを集約した reference skill。Swift / Objective-C で AVPlayer を使った動画再生 / seek / scrub / frame stepping を実装・debug するときに発火。VLCKit ではなく **AVFoundation 系** の問題に特化。
jiikko/dotfiles22026年10月11日 更新
このセッションで行った変更をコミットする。「コミットして」「commit」「/c」で発火。push はしない／クレデンシャルは混入させない。
jiikko/dotfiles22026年10月11日 更新
ディレクトリ・レイヤーごとに置いた CLAUDE.md と README.md が実体 (コード・コマンド・構成) とずれていないかを点検し、裏の取れた乖離だけを直す。引数で対象のディレクトリを任意に指定できる (省略時は repo 全体)。「CLAUDE.md を refresh して」「README が古くないか見て」「claude-md-refresh」「/claude-md-refresh」で発火。issues/ の更新漏れは issue-writeback / issue-sync の担当で、この skill は扱わない。
jiikko/dotfiles22026年10月11日 更新
Codex が設計・実装を担い、Claude が要件確定・成果物の検証・反復・commit/push を管理する。「codex に書かせて」「codex メインで実装」「codex-drive」で発火。大きめの機能・移植・プロトコル実装向け。余剰トークンを厚く使う運用も選べる。
jiikko/dotfiles22026年10月11日 更新
タスク着手時に codex にリードしてもらうワークフロー。codex に設計/方針を主導（リード）させ、その方針に沿って Claude が実装し、実装後は codex で設計適合・実装正当性・敵対的（red team）の 3 観点でレビューする。余っている codex トークンを積極的に消費したい時に使う。「codexにリードしてもらって」「設計から codex に任せて」「タスクを codex 主導で」「codex-lead」「/codex-lead」で発火。
jiikko/dotfiles22026年10月11日 更新