القائمة
レガシーコード改善のガイド。テストなし・ドキュメントなしのコードを安全に改善する手法を提供。 Use for: "レガシーコード", "テストがない", "引き継いだコード", "リファクタリング", "技術的負債", "コード改善"
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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オブジェクトは高速にテスト可能。