プロジェクト監査。「監査して」「audit」「/audit」で発火。設計/UX/品質/テストなどの観点でコードベース全体を監査し、課題をissuesディレクトリに書き出す。実行ログで重複実行を防止。特定の差分・コミットのレビューには使わない(codex-review / cross-review を使う)。
perf-analysis
Performance Analysis - パフォーマンス分析。./tmp/perf.log を分析してボトルネックを特定し、パフォーマンス改善 Issue を作成するスキル。「パフォーマンス分析」「perf-analysis」「ボトルネックを調べて」で発火。ThumbnailThumb 専用(bin/tt-client と ./tmp/perf.log 出力に依存。bin/tt-client が無いプロジェクトでは発火しない)。
インストール方法を見る含まれるファイル(1)
- SKILL.md7.0 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Performance Analysis - パフォーマンス分析
./tmp/perf.log を分析してボトルネックを特定し、パフォーマンス改善 Issue を作成するスキル。
使い方
/perf-analysis
前提条件
- ThumbnailThumb リポジトリのルートで実行すること(
bin/tt-clientが存在しない場合、このスキルは使用不可) - ThumbnailThumb アプリが起動していること(
bin/tt-client /statusで確認) - 複数のキャンバス(3つ以上推奨)が含まれるワークスペースが開かれていること
- 各キャンバスに要素が配置されていること(リアルな負荷テストのため)
実行手順
1. 事前準備
# アプリの状態確認
bin/tt-client /status
# 既存の perf.log をクリア
rm -f ./tmp/perf.log
キャンバスが 3 つ未満、またはカレントキャンバスの要素が 0 件(bin/tt-client --current elements で確認)の場合は、負荷テストの前提を満たさないため、テストを開始せずユーザーに準備を依頼する。
2. 負荷テストの実行
以下の操作を API 経由で実行し、./tmp/perf.log にログを蓄積する。
2.1 キャンバス切り替えテスト
# キャンバス一覧を取得
bin/tt-client --current GET '/projects/{projectId}/canvases'
# 各キャンバスに順番に切り替え(3回以上)
bin/tt-client -p PROJECT_ID POST '/projects/{projectId}/canvases/CANVAS_ID_1/switch'
bin/tt-client -p PROJECT_ID POST '/projects/{projectId}/canvases/CANVAS_ID_2/switch'
bin/tt-client -p PROJECT_ID POST '/projects/{projectId}/canvases/CANVAS_ID_3/switch'
2.2 要素追加テスト
# テキスト追加(複数回)
bin/tt-client text "パフォーマンステスト1" 200 200
bin/tt-client text "パフォーマンステスト2" 400 200
bin/tt-client text "パフォーマンステスト3" 600 200
# 図形追加(複数回)
bin/tt-client shape rectangle 200 400
bin/tt-client shape circle 400 400
bin/tt-client shape star 600 400
2.3 要素更新テスト
# 要素一覧を取得
bin/tt-client --current elements
# 複数要素を連続更新(位置、サイズ、プロパティ)
bin/tt-client --current PATCH '/projects/{projectId}/canvases/{canvasId}/elements/{elementId}' '{"x":250,"y":250}'
bin/tt-client --current PATCH '/projects/{projectId}/canvases/{canvasId}/elements/{elementId}' '{"fontSize":96}'
bin/tt-client --current PATCH '/projects/{projectId}/canvases/{canvasId}/elements/{elementId}' '{"rotation":15}'
2.4 プレビュー生成テスト
# プレビュー連続取得(3回以上)
bin/tt-client --current preview -o ./tmp/perf-test-1.png
bin/tt-client --current preview -o ./tmp/perf-test-2.png
bin/tt-client --current preview -o ./tmp/perf-test-3.png
2.5 バッチ操作テスト
# 大量要素の一括作成
bin/tt-client --current POST '/projects/{projectId}/canvases/{canvasId}/elements/batch' '{"elements":[{"type":"text","text":"Batch1","x":100,"y":600},{"type":"text","text":"Batch2","x":200,"y":600},{"type":"text","text":"Batch3","x":300,"y":600},{"type":"text","text":"Batch4","x":400,"y":600},{"type":"text","text":"Batch5","x":500,"y":600}]}'
2.6 Undo/Redo 連続テスト
# Undo を連続実行
bin/tt-client undo
bin/tt-client undo
bin/tt-client undo
# Redo を連続実行
bin/tt-client redo
bin/tt-client redo
bin/tt-client redo
2.7 クリーンアップ
# カレントキャンバスの全要素を削除(注意: テスト前から存在した要素も消える)
bin/tt-client --current clear
# テスト用プレビューファイルを削除
rm -f ./tmp/perf-test-*.png
ユーザーの既存要素が残っているキャンバスでは clear を使わず、テストで追加した要素 ID を控えておき個別に DELETE すること。
3. ログ分析
3.1 ログファイルの読み込み
# perf.log の内容を確認
cat ./tmp/perf.log
3.2 分析観点
以下の観点でログを分析する:
1. 処理時間(duration_ms)
- 操作種別ごとの判定は「閾値設定」表を優先する
- 表に無い操作は 100ms 以上を要注意、500ms 以上を要改善として報告
- 同種操作の平均・最大・最小を算出
2. CPU 使用率(cpu_percent)
- 50% 以上のスパイクを検出
- ドラッグ操作中の CPU 推移を確認
3. メモリ使用量(mem_mb)
- 操作前後のメモリ増加量を確認
- メモリリークの兆候(増加し続ける)を検出
4. 操作別パフォーマンス
addImage/addImageFromURL: 画像読み込みaddText/addShape: 要素追加drag*: ドラッグ操作(フレームレート確認)deleteSelected: 削除操作removeBackground: 背景除去(時間がかかる操作)
5. ドラッグ操作の分析
total_frames/duration_msからフレームレートを算出- 60fps を下回る場合は問題として報告
4. 結果報告と Issue 作成
分析結果は以下を含めて報告する: 操作別の平均/最大 duration_ms と判定(良好/要注意/要改善)、CPU スパイク・メモリリーク兆候の有無、要改善項目とその根拠となるログ行。
「要改善」判定が 1 件以上ある場合のみ issues/ ディレクトリに Issue を作成する(要注意のみの場合は報告に留める)。新規 Issue は issue-creation-codex-review ルールに従い codex review を通す。
次の Issue 番号を確認:
ls issues/*.md | grep -oE 'issues/[0-9]+' | sort -t/ -k2 -n | tail -1
閾値設定
| 項目 | 良好 | 要注意 | 要改善 |
|---|---|---|---|
| 要素追加 | < 50ms | 50-200ms | > 200ms |
| プレビュー生成 | < 100ms | 100-300ms | > 300ms |
| ドラッグ FPS | > 50fps | 30-50fps | < 30fps |
| CPU スパイク | < 30% | 30-60% | > 60% |
| メモリ増加/操作 | < 1MB | 1-5MB | > 5MB |
注意事項
- テストは負荷をかけるため、本番データには実行しないこと
- テスト用に追加した要素は必ずクリーンアップすること
- ログは追記モードなので、分析前に
rm -f ./tmp/perf.logでクリアすること - ドラッグ操作は API 経由では実行できない。ドラッグ FPS の分析が依頼に含まれる場合のみユーザーに手動ドラッグを依頼し、含まれない場合は「分析対象外」と結果報告に明記すること
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
AVFoundation (AVPlayer / AVPlayerLayer / AVPlayerItemVideoOutput / AVAsset) の落とし穴・文書化されていない実装挙動・debugging チェックリストを集約した reference skill。Swift / Objective-C で AVPlayer を使った動画再生 / seek / scrub / frame stepping を実装・debug するときに発火。VLCKit ではなく **AVFoundation 系** の問題に特化。
このセッションで行った変更をコミットする。「コミットして」「commit」「/c」で発火。push はしない/クレデンシャルは混入させない。
ディレクトリ・レイヤーごとに置いた CLAUDE.md と README.md が実体 (コード・コマンド・構成) とずれていないかを点検し、裏の取れた乖離だけを直す。引数で対象のディレクトリを任意に指定できる (省略時は repo 全体)。「CLAUDE.md を refresh して」「README が古くないか見て」「claude-md-refresh」「/claude-md-refresh」で発火。issues/ の更新漏れは issue-writeback / issue-sync の担当で、この skill は扱わない。
Codex が設計・実装を担い、Claude が要件確定・成果物の検証・反復・commit/push を管理する。「codex に書かせて」「codex メインで実装」「codex-drive」で発火。大きめの機能・移植・プロトコル実装向け。余剰トークンを厚く使う運用も選べる。
タスク着手時に codex にリードしてもらうワークフロー。codex に設計/方針を主導(リード)させ、その方針に沿って Claude が実装し、実装後は codex で設計適合・実装正当性・敵対的(red team)の 3 観点でレビューする。余っている codex トークンを積極的に消費したい時に使う。「codexにリードしてもらって」「設計から codex に任せて」「タスクを codex 主導で」「codex-lead」「/codex-lead」で発火。