一键导入
non-committed-analyzer
未コミットの変更ファイルを全て読み込み、施策の意図を分析し、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。トリガー:「コミット分析」「変更まとめて」「何やってたっけ」「commit analyze」「未コミット確認」「変更の棚卸し」
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
未コミットの変更ファイルを全て読み込み、施策の意図を分析し、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。トリガー:「コミット分析」「変更まとめて」「何やってたっけ」「commit analyze」「未コミット確認」「変更の棚卸し」
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| 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 プラグイン設定 | 不適用 | 起動確認で代替 |