Menu
未コミットの変更ファイルを全て読み込み、施策の意図を分析し、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。トリガー：「コミット分析」「変更まとめて」「何やってたっけ」「commit analyze」「未コミット確認」「変更の棚卸し」
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | non-committed-analyzer |
| description | 未コミットの変更ファイルを全て読み込み、施策の意図を分析し、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。トリガー：「コミット分析」「変更まとめて」「何やってたっけ」「commit analyze」「未コミット確認」「変更の棚卸し」 |
未コミットの変更（staged / unstaged / untracked）を全ファイル読み込み、施策の意図を推測した上で、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。
以下のコマンドを 並列で 実行する:
# 変更ファイル一覧（untracked含む）
git status --short
# staged の diff
git diff --cached
# unstaged の diff
git diff
# 直近のコミット履歴（メッセージスタイル把握用）
git log --oneline -10
# untracked ファイル一覧（ディレクトリは展開しない）
git ls-files --others --exclude-standard
ここが最重要。diff だけでなく、変更ファイルの全文を Read ツールで読む。
- 行から内容を把握（Read は不要）大量のファイルがある場合は、関連性の高そうなファイルから優先的に読む。読むファイル数が 15 を超える場合は、ユーザーに「全部読みますか？ 主要ファイルだけにしますか？」と確認する。
読み取った変更内容から、以下を推測・整理する:
feat: 新機能fix: バグ修正refactor: リファクタリングconfig: 設定変更style: フォーマット・見た目の変更docs: ドキュメントchore: 雑務（依存関係更新、CI等）test: テスト追加・修正以下の形式で提示する:
## 施策の概要
（1-2文で何をやっていたかの要約）
## コミット分割案
### 案A: N コミットに分割（推奨）
| # | タイプ | コミットメッセージ | 対象ファイル |
|---|--------|-------------------|-------------|
| 1 | config | ghostty: キーバインドの設定を更新 | config, keybindings.conf |
| 2 | feat | zsh: ghostty-dev 関数を追加 | dot_zsh/functions/ghostty-dev |
| 3 | ... | ... | ... |
### 案B: 1 コミットにまとめる
| # | タイプ | コミットメッセージ | 対象ファイル |
|---|--------|-------------------|-------------|
| 1 | feat | ghostty: レイアウト管理機能の追加と設定整理 | （全ファイル） |
<type>: <scope>: <summary> 形式を使う変更内容に応じて、以下の観点で検証手順を提示する:
## 検証手順
### 動作確認
- [ ] 確認項目1（具体的な手順）
- [ ] 確認項目2
- ...
### 副作用の確認
- [ ] 既存機能への影響（具体的に何が壊れうるか）
- [ ] 設定ファイルの反映確認（`chezmoi apply` 後の状態等）
変更の種類に応じた検証テンプレート:
| 変更種別 | 検証観点 |
|---|---|
| シェル関数 | which <func> で認識されるか、引数パターン別の動作、エラーケース |
| Neovim プラグイン | :Lazy sync 後にエラーなく読み込まれるか、既存キーマップとの衝突 |
| Ghostty 設定 | ghostty +show-config で構文エラーがないか、レイアウトスクリプトの実行 |
| chezmoi テンプレート | chezmoi diff で意図通りの出力か、chezmoi apply --dry-run |
| zshrc / 環境変数 | 新しいシェルセッションで echo $VAR 確認、source ~/.zshrc で構文エラーなし |
| Git config | git config --list で反映確認 |
| AppleScript | osascript <file> で実行、権限ダイアログの確認 |
| CSS / UI | ブラウザでの表示確認、レスポンシブ確認 |
| API 連携 | エンドポイントへのリクエスト/レスポンス確認 |
| パッケージ更新 | npm install / pip install 後の動作確認、lockfile の整合性 |
自動テストが書ける変更の場合のみ提示する。dotfiles のような設定系リポジトリでは省略可。
## テスト案（該当する場合）
### ユニットテスト
- テストファイル: `tests/xxx.test.ts`
- テストケース:
- `should ...` — 正常系
- `should throw when ...` — 異常系
### 統合テスト
- テストシナリオ: ...
### スモークテスト（手動）
- 手順: ...
| 変更種別 | テスト適用 | 理由 |
|---|---|---|
| ライブラリのコード (TypeScript, Python等) | 適用 | ユニットテスト可能 |
| CLI ツール / シェルスクリプト | 条件付き | bats 等でテスト可能な場合のみ |
| 設定ファイル (dotfiles) | 不適用 | 動作確認で代替 |
| AppleScript / GUI 自動化 | 不適用 | 手動確認で代替 |
| Neovim プラグイン設定 | 不適用 | 起動確認で代替 |
PJ管理フロー（長期記憶＋Threadの積み上げ）を任意リポジトリに展開するスキル。デフォルトでは `.claude/my-projects/<slug>/` 配下にProject長期記憶（CLAUDE.md）とThread（OBJECTIVE.md→OUTPUT.md）を積むが、runner / repo 方針に応じて `.agents/my-projects/` 等へカスタム可能。トリガー：「<slug>を再開」「続きやる」「PJ立ち上げ」「新スレッド作って」「OUTPUT書いて」「pbcopyして」「PJクローズ」「このやりとりをPJ管理下に置きたい」「○○PJに合流させたい」「PR/Issueから In Progress PJを作って」「pj-flow にマイグレ」「pj-flow の挙動を直したい」「pjflow」。Claude Code / Codex Agent Skill 両対応。
Create publication-safe redacted images from screenshots or other images that contain internal, private, or company-specific text. Use when the user asks to mask, redact, hide, anonymize, or sanitize sensitive information in an attached/local image, especially when they want selective text masking, public-release screenshots, article images, or iterative "消しすぎ/もっと隠して" adjustment. Always prefer writing a purpose-built script for the specific image before running ffmpeg/ImageMagick, rather than manually guessing rectangles.
画像（PNG）からUI要素の整列（縦中央揃い / 左端揃い / 間隔均等 等）を画素単位で静的判定するスクリプトを、命題ごとに新規実装してから走らせる skill。LLM の主観で「揃ってる」と誤判定するのを防ぐためのメタ手法。固定スクリプトを呼ぶのではなく、検証したい命題ごとに ROI / 判定式 / debug overlay を設計し直す。scripts/ にケース別の参考実装（中央揃い / 左端揃い）を同梱。トリガー：「中央寄せ判定」「縦揃え確認」「左端揃え判定」「centering check」「alignment check」「画像で揃ってるか確認して」
Codex CLI (codex exec) を直接呼び出して rescue（診断・修正）、review（差分レビュー）、adversarial-review（敵対的レビュー）のいずれかを実行する。ユーザーが明示的に /codex-exec、codex-exec、「codex に投げて」「codex でレビュー」「codex rescue」等と呼んだときだけ発動する。会話コンテキストに codex 的ニュアンスが出ただけでは自動起動しない。
検証可能な「ハーネス」を構築する。ハーネス＝ある対象を機械的に駆動して検証する自家製の仕組み。規模で 2 形態に分かれる：**unit harness**（特定の操作・ファイル変更・コードパスに差し込む小さな自動検証。hook / CI step / lint runner 等。最小要件は Red/Green 機械判定のみ）と **system harness**（施策・プロジェクト全体を覆い、複数の検証点・進捗・成果物を一括管理する大きな仕組み。最小要件は REPF: Red/Green 観測 + Progress 追跡 + Executable artifacts + Flow 文書）。複数の unit harness が集まって system harness を構成しうる。トリガー：「ハーネスを作って」「harness を構築」「RED/GREEN で観測したい」「再発防止のフックを差し込みたい」「失敗が許されない作業の前準備」「複数の検証点を一括管理したい」。**コピペ用 HTML / Markdown 手順書 / チェックリスト単独はハーネスではない**（機械的検証 R が無いため）。依頼が抽象的なら最初に規模（unit / system）を確認すること。
Write and validate AWS CloudWatch Logs Insights (Logs Insights QL) queries. Use when asked to turn raw log samples/JSON into working queries, build filters/aggregations/statistics, or troubleshoot query errors. Ensure syntax correctness, field parsing, and log class compatibility.