Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

non-committed-analyzer

Estrelas0

Forks0

Atualizado20 de maio de 2026 às 08:01

未コミットの変更ファイルを全て読み込み、施策の意図を分析し、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。トリガー：「コミット分析」「変更まとめて」「何やってたっけ」「commit analyze」「未コミット確認」「変更の棚卸し」

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

TeXmeijin

TeXmeijin/agent-skills

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	non-committed-analyzer
description	未コミットの変更ファイルを全て読み込み、施策の意図を分析し、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。トリガー：「コミット分析」「変更まとめて」「何やってたっけ」「commit analyze」「未コミット確認」「変更の棚卸し」

Commit Analyzer

未コミットの変更（staged / unstaged / untracked）を全ファイル読み込み、施策の意図を推測した上で、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。

トリガー

「コミット分析」「変更まとめて」「何やってたっけ」
「commit analyze」「未コミット確認」「変更の棚卸し」
「コミットどう分ける」「差分見て」

ワークフロー

Step 1: 変更の全体像を把握

以下のコマンドを 並列で 実行する:

# 変更ファイル一覧（untracked含む）
git status --short

# staged の diff
git diff --cached

# unstaged の diff
git diff

# 直近のコミット履歴（メッセージスタイル把握用）
git log --oneline -10

# untracked ファイル一覧（ディレクトリは展開しない）
git ls-files --others --exclude-standard

Step 2: 全変更ファイルの中身を Read

ここが最重要。diff だけでなく、変更ファイルの全文を Read ツールで読む。

Modified ファイル: ワーキングツリーの現在の状態を Read で読む
New（untracked）ファイル: ファイル全体を Read で読む
Deleted ファイル: diff の - 行から内容を把握（Read は不要）

大量のファイルがある場合は、関連性の高そうなファイルから優先的に読む。読むファイル数が 15 を超える場合は、ユーザーに「全部読みますか？主要ファイルだけにしますか？」と確認する。

Step 3: 施策の分析

読み取った変更内容から、以下を推測・整理する:

何の施策か: 変更の目的・意図を 1-2 文で要約
変更のカテゴリ分類: 各ファイルの変更を以下のカテゴリに分類
- feat: 新機能
- fix: バグ修正
- refactor: リファクタリング
- config: 設定変更
- style: フォーマット・見た目の変更
- docs: ドキュメント
- chore: 雑務（依存関係更新、CI等）
- test: テスト追加・修正
変更間の依存関係: どのファイル群がセットで意味を成すか

Step 4: コミット分割案の提示

以下の形式で提示する:

## 施策の概要

（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: レイアウト管理機能の追加と設定整理 | （全ファイル） |

コミット分割の判断基準

別の施策は別コミット: 無関係な変更は分ける
config + それを使う機能コードはセット: 設定とコードが対の場合はまとめる
削除は独立: ファイル削除が多い場合は「不要ファイルの整理」として独立コミットにする
リポジトリの既存スタイルに合わせる: Step 1 で取得した直近コミットのメッセージスタイルを踏襲する

コミットメッセージのルール

リポジトリの既存コミットメッセージのスタイル（prefix の有無、日本語/英語、長さ）を分析し、それに合わせる
スタイルが判別できない場合は <type>: <scope>: <summary> 形式を使う
「何をしたか」ではなく「なぜしたか」を優先する

Step 5: 検証手順の提示

変更内容に応じて、以下の観点で検証手順を提示する:

## 検証手順

### 動作確認

- [ ] 確認項目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 の整合性

Step 6: テスト実装案の提示（該当する場合）

自動テストが書ける変更の場合のみ提示する。dotfiles のような設定系リポジトリでは省略可。

## テスト案（該当する場合）

### ユニットテスト
- テストファイル: `tests/xxx.test.ts`
- テストケース:
  - `should ...` — 正常系
  - `should throw when ...` — 異常系

### 統合テスト
- テストシナリオ: ...

### スモークテスト（手動）
- 手順: ...

テスト実装の判断基準

変更種別	テスト適用	理由
ライブラリのコード (TypeScript, Python等)	適用	ユニットテスト可能
CLI ツール / シェルスクリプト	条件付き	bats 等でテスト可能な場合のみ
設定ファイル (dotfiles)	不適用	動作確認で代替
AppleScript / GUI 自動化	不適用	手動確認で代替
Neovim プラグイン設定	不適用	起動確認で代替

出力の注意事項

日本語で出力する（コミットメッセージも既存スタイルに合わせる）
コミットの実行はしない。あくまで分析と提案のみ
ユーザーが「これでコミットして」と言った場合のみ、実際の git 操作に移る
変更が大量（20ファイル超）の場合は、まず概要を見せて方針を確認してから詳細分析に入る

Mais deste repositório

mesmo repositório

pj-flow

TeXmeijin/agent-skills

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 両対応。

2026-06-010

image-redaction

TeXmeijin/agent-skills

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.

2026-06-010

centering-judge

TeXmeijin/agent-skills

画像（PNG）からUI要素の整列（縦中央揃い / 左端揃い / 間隔均等等）を画素単位で静的判定するスクリプトを、命題ごとに新規実装してから走らせる skill。LLM の主観で「揃ってる」と誤判定するのを防ぐためのメタ手法。固定スクリプトを呼ぶのではなく、検証したい命題ごとに ROI / 判定式 / debug overlay を設計し直す。scripts/ にケース別の参考実装（中央揃い / 左端揃い）を同梱。トリガー：「中央寄せ判定」「縦揃え確認」「左端揃え判定」「centering check」「alignment check」「画像で揃ってるか確認して」

2026-05-280

codex-exec

TeXmeijin/agent-skills

Codex CLI (codex exec) を直接呼び出して rescue（診断・修正）、review（差分レビュー）、adversarial-review（敵対的レビュー）のいずれかを実行する。ユーザーが明示的に /codex-exec、codex-exec、「codex に投げて」「codex でレビュー」「codex rescue」等と呼んだときだけ発動する。会話コンテキストに codex 的ニュアンスが出ただけでは自動起動しない。

2026-05-200

harness-creator

TeXmeijin/agent-skills

検証可能な「ハーネス」を構築する。ハーネス＝ある対象を機械的に駆動して検証する自家製の仕組み。規模で 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）を確認すること。

2026-05-200

cloudwatch-logs-insights-query

TeXmeijin/agent-skills

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.

2026-05-200

name	non-committed-analyzer
description	未コミットの変更ファイルを全て読み込み、施策の意図を分析し、コミット分割案・メッセージ候補・検証手順・テスト案を提示する。トリガー：「コミット分析」「変更まとめて」「何やってたっけ」「commit analyze」「未コミット確認」「変更の棚卸し」

Commit Analyzer

トリガー

「コミット分析」「変更まとめて」「何やってたっけ」
「commit analyze」「未コミット確認」「変更の棚卸し」
「コミットどう分ける」「差分見て」

ワークフロー

Step 1: 変更の全体像を把握

以下のコマンドを 並列で 実行する:

# 変更ファイル一覧（untracked含む）
git status --short

# staged の diff
git diff --cached

# unstaged の diff
git diff

# 直近のコミット履歴（メッセージスタイル把握用）
git log --oneline -10

# untracked ファイル一覧（ディレクトリは展開しない）
git ls-files --others --exclude-standard

Step 2: 全変更ファイルの中身を Read

ここが最重要。diff だけでなく、変更ファイルの全文を Read ツールで読む。

Modified ファイル: ワーキングツリーの現在の状態を Read で読む
New（untracked）ファイル: ファイル全体を Read で読む
Deleted ファイル: diff の - 行から内容を把握（Read は不要）

Step 3: 施策の分析

読み取った変更内容から、以下を推測・整理する:

何の施策か: 変更の目的・意図を 1-2 文で要約
変更のカテゴリ分類: 各ファイルの変更を以下のカテゴリに分類
- feat: 新機能
- fix: バグ修正
- refactor: リファクタリング
- config: 設定変更
- style: フォーマット・見た目の変更
- docs: ドキュメント
- chore: 雑務（依存関係更新、CI等）
- test: テスト追加・修正
変更間の依存関係: どのファイル群がセットで意味を成すか

Step 4: コミット分割案の提示

以下の形式で提示する:

## 施策の概要

（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: レイアウト管理機能の追加と設定整理 | （全ファイル） |

コミット分割の判断基準

別の施策は別コミット: 無関係な変更は分ける
config + それを使う機能コードはセット: 設定とコードが対の場合はまとめる
削除は独立: ファイル削除が多い場合は「不要ファイルの整理」として独立コミットにする
リポジトリの既存スタイルに合わせる: Step 1 で取得した直近コミットのメッセージスタイルを踏襲する

コミットメッセージのルール

リポジトリの既存コミットメッセージのスタイル（prefix の有無、日本語/英語、長さ）を分析し、それに合わせる
スタイルが判別できない場合は <type>: <scope>: <summary> 形式を使う
「何をしたか」ではなく「なぜしたか」を優先する

Step 5: 検証手順の提示

変更内容に応じて、以下の観点で検証手順を提示する:

## 検証手順

### 動作確認

- [ ] 確認項目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 の整合性

Step 6: テスト実装案の提示（該当する場合）

自動テストが書ける変更の場合のみ提示する。dotfiles のような設定系リポジトリでは省略可。

## テスト案（該当する場合）

### ユニットテスト
- テストファイル: `tests/xxx.test.ts`
- テストケース:
  - `should ...` — 正常系
  - `should throw when ...` — 異常系

### 統合テスト
- テストシナリオ: ...

### スモークテスト（手動）
- 手順: ...

テスト実装の判断基準

変更種別	テスト適用	理由
ライブラリのコード (TypeScript, Python等)	適用	ユニットテスト可能
CLI ツール / シェルスクリプト	条件付き	bats 等でテスト可能な場合のみ
設定ファイル (dotfiles)	不適用	動作確認で代替
AppleScript / GUI 自動化	不適用	手動確認で代替
Neovim プラグイン設定	不適用	起動確認で代替

出力の注意事項

日本語で出力する（コミットメッセージも既存スタイルに合わせる）
コミットの実行はしない。あくまで分析と提案のみ
ユーザーが「これでコミットして」と言った場合のみ、実際の git 操作に移る
変更が大量（20ファイル超）の場合は、まず概要を見せて方針を確認してから詳細分析に入る