Menu
レガシーコード改善のガイド。テストなし・ドキュメントなしのコードを安全に改善する手法を提供。 Use for: "レガシーコード", "テストがない", "引き継いだコード", "リファクタリング", "技術的負債", "コード改善"
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
Claude Code の /compact 実行前に、現セッションの作業状態を一時 state file へ保存する。 MANDATORY TRIGGERS: /compact-prep, compact-prep, 圧縮準備, compact 準備, コンパクト準備, 圧縮前状態保存。 DO NOT TRIGGER: compact 後の復旧、通常の進捗報告、plan 作成、context 使用率の雑談。
プロジェクトの分析・計画・監査結果を構造化された HTML レポートとして管理するスキル。 .claude/reports/ にプロジェクト毎のデータを出力し、4種類のテンプレート (review / plan / audit / adr-analysis) からスケルトン生成、index による横断管理を提供する。 Use when: "レポート初期化", "新規レビュー作って", "実装計画ファイル作って", "品質監査レポート作成", "ADR分析作って", "html-reports init", "/reports-init", "/report-new", ".claude/reports をセットアップ"
Figma Prototype 相当の操作可能 HTML モックアップを生成する。 画面遷移俯瞰図 + States Matrix + viewport プリセット (実機 CSS px W×H) + auto-layout 検証を1ファイルにまとめる。プロジェクトの既存 CSS トークンを自動取り込み。 Use when: ユーザーが「モックアップ作って」「画面遷移図」「Figma 風プロトタイプ」 「flow mockup」「画面比較ページ」「デザイン案を並べて」「states matrix」 「auto-layout 確認」「画面遷移を可視化」と依頼したとき。 単独画面のスタイル提案だけなら frontend-design 系を使う。本スキルは 「複数画面 + 遷移 + 状態網羅」を1ページで俯瞰したいときに使う。
Always use when user asks to create, generate, draw, or design a diagram, flowchart, architecture diagram, ER diagram, sequence diagram, class diagram, network diagram, mockup, wireframe, or UI sketch, or mentions draw.io, drawio, drawoi, .drawio files, or diagram export to PNG/SVG/PDF.
GitHub Actions CI/CD for Unity projects — compile check, test execution, multi-platform builds, and artifact distribution. Covers GameCI setup, license activation, build matrix, and unilyze quality gates. Does NOT cover deployment to app stores (that varies by project).
リポジトリのドキュメント構成を診断し、雛形生成・増築・再編を行うスキル。 約 50 OSS の構成調査 (survey-any: oss-documentation-structure-patterns) に基づき、 「診断 → 処方 → 承認 → 適用 → 検証」のパイプラインで段階に合った構成を処方する。 モード: audit (診断のみ) / init (新規雛形) / grow (増築) / restructure (構造再編)。 Use when: ユーザーが「ドキュメント整備して」「docs の雛形作って」「README 整理したい」 「ドキュメント構成を診断して」「docs が陳腐化してるので再編したい」「docs-architect」 「ドキュメント構造を見直したい」「この repo に必要なドキュメントは?」と依頼したとき。 新規 OSS リポジトリの立ち上げ、コードが動き始めた段階での docs 着手、 既存 docs の大規模リストラクチャのいずれにも使う。
| name | legacy-code-improvement |
| description | レガシーコード改善のガイド。テストなし・ドキュメントなしのコードを安全に改善する手法を提供。 Use for: "レガシーコード", "テストがない", "引き継いだコード", "リファクタリング", "技術的負債", "コード改善" |
| context | fork |
| agent | general-purpose |
| user-invocable | true |
t_wadaの「実録レガシーコード改善」に基づく実践的アプローチ。
1. 現状確認 → 2. 闘う準備を整える → 3. 段階的に改善
コードの状態を把握：
[ ] バージョン管理の有無
[ ] テストの有無
[ ] 自動化（CI/CD）の有無
[ ] 主要ロジックの特定
[ ] 外部依存の把握
開発の3本柱を確立（優先度順）：
「undefinedでなければ良い」程度の雑さで始める：
it('returns something', () => {
assert(result !== undefined);
});
| 状況 | 戦術 | 説明 |
|---|---|---|
| 既存コードをテストで保護可能 | Extract | ロジックを抽出してテスト |
| 既存コードが複雑すぎる | Sprout | 新コードを別に育てる |
外部依存やランダム性を関数引数として差し込み可能にする：
// Before: テスト困難
function getNext() {
return Math.random() * items.length;
}
// After: テスト可能
function createHandler(getNextIndex) {
// getNextIndexを外から渡せる
}
フレームワーク依存をPlain Oldオブジェクトから分離：
[Framework層] → [Plain Old モデル] ← [テスト]
Plain Oldオブジェクトは高速にテスト可能。