Skill.md検索

古いコードパスを完全に削除する前に、新パスが全ての機能を継承したことを証明できます 削除対象と全ての使用箇所（消費者）をリストアップし、マイグレーション計画を立てられます Before/After表を作成して、すべての動作が新パスに正しく移行されたことを検証できます 1コミット=1関心（新パス追加→消費者移行→旧パス削除→docs更新）という段階的なリファクタリング（コード整理・改善）が実行でき、各段階でテスト検証できます モジュール名・型名の変更や古いパスの削除後、残存参照がゼロになったことをスクリプトで自動確認できます 大規模リファクタリング（コード整理・改善）を安全に進めたいエンジニア アーキテクチャの大幅な変更やモジュール再構成が必要なプロジェクト 複雑な依存関係を持つコードベースで破壊的な変更を避けたい開発チーム ドキュメント更新と合わせてコード改善を管理したいメンテナンス担当者 4つのフェーズで実施：Inventoryで削除・変更対象と全消費者をリストアップ（grepで参照検索、マイグレーション先なければ削除不可）、ContractでBefore/After表作成（After空行は準備不足の指標）、Executeで1commit=1concern単位で実行（新パス追加→消費者移行→旧パス削除→docs更新、各commitでscripts/local_ci.sh pass、dead code同一PR内削除）、Verifyでdeno cache --reload後に旧名参照をゼロ化（grepで.ts/.md確認）。root cause分析は/fix-checklist、docs更新は/docs-consistency併用。

既存ログキーの重複チェック：プロジェクト内のBreakdownLoggerインスタンスを全検索し、新規キー作成前に既存キーでカバーしているか自動判定します。 命名規則に基づくキー選定支援：ドメイン別・テストレベル別・機能別の3方式から適切なネーミング方式を提案し、kebab-caseの統一性を確保します。 テストファイル限定の自動検証：実装コード（lib/）へのBreakdownLogger配置を検出し、CLAUDE.md規約違反をブロック。テストファイル（_test.ts）のみの使用を強制します。 ログの重要情報を先頭に配置：LOG_LENGTH末尾切り詰めに対応し、重要情報を先頭40字に配置するログ記述パターンを自動提案します。 キー発見から検証まで一括対応：grep検索→命名判定→配置確認→バリデーション→規約違反検出まで、ログキー管理の全工程を自動化します。 テストコード作成者：テスト時のログフィルタリングを効果的に行いたいが、キー重複を防ぎたいエンジニア。 BreakdownLogger導入プロジェクト開発者：ログキーの命名規則を統一化し、フィルタリング効率を高めたい人。 テストデバッグ効率化を目指す人：ログキーの重複や規約違反を事前に検出し、テスト実行時のノイズを減らしたい人。 チームのテストコード品質を向上させたい人：BreakdownLoggerの使用ルール（テストファイルのみ）を自動検証し、コード規約を遵守したい組織。 BreakdownLoggerの実装時ガイド。テストファイルのみ使用が必須（実装コード lib/は禁止）。ステップ1 KEY Discoveryでは既存キーをgrepで全検索し、既存キーが機能をカバーしているか判定：カバー→再利用、広すぎ→sub-key作成、なし→命名ルール準拠で新規、一時調査→fix-プレフィックス（事後削除）。ステップ2 KEY Namingは3方式から選択：By domain（ドメイン境界ごと）、By test level（テスト粒度ごと）、By feature（機能検証）。制約はlowercase kebab-case + -testサフィックス、汎用名禁止、名前空間プレフィックス必須。ステップ3 Placementはテストファイル先頭でインスタンス生成。ステップ4 Writing Styleは重要情報を先頭40字に、message=何が起きたか、data=証拠の形式。ステップ5 Validationで非テストファイルのBreakdownLogger importを検出し規約違反を通知。

新機能やAPI変更、動作変更をコード実装時に自動でドキュメントに反映できます。 git diffを分析して変更種別を自動判定し、README、CLI仕様書、設定ドキュメント等の該当箇所を一括更新できます。 ユーザー向け変更を発見可能にするため、簡潔・例示優先・検索可能なドキュメント形式を自動適用できます。 内部実装詳細やデバッグ専用オプションなど、ユーザーに不要な情報を自動的に除外できます。 新機能実装時にドキュメント更新を忘れたくない開発者 複数のドキュメント箇所を一括で同期させたい技術リード ユーザー向けドキュメントの内容と実装の齟齬を防ぎたい品質管理者 API仕様やCLI仕様の変更を自動で反映させたいマイクロサービスチーム ユーザー向け変更を発見可能にするため、変更種別に応じたドキュメント箇所を更新する。決定マトリックス：新public API→README.md+mod.ts(JSDoc付export)、新機能→README.md+docs/usage.md、動作変更→README.md既存記述更新+CHANGELOG.md、CLI変更→docs/breakdown/interface/cli_commands.ja.md、パス解決変更→docs/breakdown/interface/path_resolution.ja.md、設定変更→docs/breakdown/interface/configuration.ja.md、ドメイン設計変更→docs/breakdown/domain_core/配下、内部変更→CLAUDE.md(開発ワークフロー影響時のみ)。手順：git diff --name-only→変更分類→該当ドキュメント更新→コード例動作確認。守則：簡潔・例示優先・検索可能。記載禁止事項：内部実装詳細、一時的ワークアラウンド、デバッグ専用オプション。

症状駆動の修正を防止：「ここにX を追加」という反射的な修正の前に、「なぜXが生成されるのか」という根本原因を問い、設計から逆算します。 設計ドキュメント・スキーマから動作を理解：docs/や各種ドキュメント、データベーススキーマから意図された動作を確認し、エラー箇所と原因箇所の乖離を特定します。 フロー追跡で問題の発生地点を可視化：トリガー→期待状態→乖離点を図解（Mermaid図）で構造化し、複雑な問題を整理します。 最小限の修正を実装：根本原因に対してのみ変更するため、副作用のない、保守性の高い修正ができます。 修正前の調査結果を記録：複雑な問題はtmp/investigation//に overview.md、trace.md、root-cause.mdとして調査結果を保存し、チーム内で知見を共有できます。 バグ修正を担当する開発者：修正前に根本原因を特定し、同じバグの再発を防ぎたい人 コードレビュアー：修正が症状対症療法になっていないか、判断したい人 チーム全体：バグ調査ノウハウを知見として蓄積・共有したい人 レガシーコード保守者：複雑なシステムの問題箇所を素早く特定したい人 5つの手順：1.コードを書くな（なぜエラーが起きるか問う）、2.設計を読む（docs/やスキーマから意図動作を理解）、3.フローを追う（トリガー→期待状態→乖離点特定）、4.根本原因を特定（エラー箇所と原因箇所は異なることが多い）、5.最小限の修正（根本原因に対してのみ変更）。エラー箇所と根本原因の典型：実行時バリデーションエラー→スキーマ定義、型不一致→インターフェース契約、テスト失敗→実装ロジック。Bad例：「Xが Yにないので Y に Xを追加」（未調査）。Good例：「なぜ X が生成される？設計上 X は不正→生成元を修正」。複雑な問題はtmp/investigation//にMermaid図で構造化（overview.md、trace.md、root-cause.md）、1ファイル500行以内。

CHANGELOG.md に Keep a Changelog 形式で新しいエントリを自動追加し、変更内容を検索しやすく保つことができます。 新機能、バグ修正、削除、非推奨化など、変更の種類ごとにセクション分けして管理できます。 : (identifier) という統一フォーマットで、誰でも変更内容を素早く理解できる履歴を作成できます。 リリース時に [Unreleased] セクションから自動的にバージョン番号と日付付きのセクションに移動させることができます。 プロダクトマネージャーやテックリードで、チーム全体の変更履歴を整理・共有する必要がある人 リリースノートを定期的に作成・管理する立場にある人 過去の変更理由を素早く検索・追跡したいエンジニア 複数のプロジェクトで一貫性のある変更管理を行いたい人 Keep a Changelog 形式に準拠した CHANGELOG.md 管理ツール。セクションは Added（新機能）、Changed（既存動作の変更）、Deprecated（将来削除予定）、Removed（削除済み）、Fixed（バグ修正）、Security（脆弱性修正）の6種類。エントリは : (\identifier\) フォーマットで記述し、[Unreleased] セクションに配置。リリース時に [x.y.z] - YYYY-MM-DD 形式のセクションに移動。曖昧な記述（"New feature for templates"）、実装詳細（"Refactored VariableReplacer"）、文脈不足（"Fixed the bug"）は禁止。例: - Custom variable support with \{variable-name}\ syntax (hyphens allowed)

パッチ・マイナー・メジャーリリースを選択するだけで、バージョン番号の自動更新とgitタグ付けができます。 deno.jsonとjsr.jsonのバージョンを一括更新し、整合性を保つことができます。 mainブランチを常に安定版に保ちながら、次の開発用にリリースブランチを自動生成できます。 リモートへのプッシュ前にユーザー確認を取り、ミス防止と透明性を確保できます。 JSRで公開中のDenoプロジェクトの管理者 定期的なセマンティックバージョニングでリリースしたいメンテナー gitのタグやブランチ管理に手間がかかると感じている開発チーム テストとバージョン確認を済ませたら、あとはリリース処理を任せたい場合 argument（patch/minor/major）を受け取り実行。deno.jsonからバージョン取得後、指定タイプに応じて新バージョンを計算。release/v{NEW_VERSION}ブランチを作成し、deno.jsonとjsr.jsonのバージョンフィールドを更新してコミット。その後mainへマージ（--no-ff）、タグv{NEW_VERSION}を付与。プッシュ前にユーザー確認を取り、その後リモートプッシュとローカルブランチ削除。最後に次のパッチリリース用ブランチ（release/v{NEXT_PATCH_VERSION}）を作成します。実行前に全テスト確認、バージョン一致確認、変更履歴記録確認を実施。

全体的なゴールを整理し、実行可能な小さなToDoに分解することで、迷いのない作業フローを実現できます 計画・実行・判断・統合の責任を明確に分けることで、各フェーズで最適な判断ができ、スコープクリープを防げます 複数の専門エージェント（調査専用、設計専用、実装専用）に仕事を委譲でき、並列実行により全体の作業時間を大幅短縮できます 進捗記録（progress.md）と分析図（Mermaid）で現在地を常に可視化でき、予期しない問題発生時の対応判断が迅速になります 大規模なシステム構築やリファクタリングプロジェクトを率いるプロジェクトリーダー 複数人のチームを調整しながら、全体のマイルストーン達成を目指すマネージャー 複雑な調査・設計・実装が混在する案件で、ボトルネックを最小化したい開発者 メインエージェントが「指揮者」として機能し、計画・委譲・判断・統合に専念します。Conductorパターンでは Goal → Done Criteria → Team → ToDo の設計を行い、各ToDoを適切なSub Agentに委譲し、成果物の採否・統合・記録を実施します。委譲基準として3行以内の即時修正は自分で実行、調査・探索・複数ファイル横断変更はSub Agentへ委譲します。tmp//配下に plan.md（Goal、Done Criteria、Team、Approach）、progress.md（記録蓄積）、analysis.md（Mermaid図）を作成し、Done Criteriaを先に定義してから着手します。各ToDoの完了時にWhatとWhy（判断根拠）とHow（手順）を分離して記録し、Team テーブルに1Role=1目的の原則を適用します。

新機能、バグ修正、仕様変更などを一定のフォーマットで自動記録し、後から検索しやすい変更履歴を作成できます。 Keep a Changelog形式に従い、「Added」「Fixed」「Changed」などのセクション別に整理されたCHANGELOG.mdを自動更新できます。 ユーザーへの影響を中心に、具体的で分かりやすい記述内容に統一できます。 リリース時に「未リリース」の変更内容をバージョン番号と日付付きで自動整理できます。 プロダクト開発チームで、リリースノートの作成・管理を効率化したい人 変更履歴が散在してしまい、過去の更新内容が見つけにくいと困っている人 複数のチームメンバーで開発を進めており、変更内容の記録フォーマットを統一したい人

新機能やCLIオプション追加時に、README、ヘルプテキスト、その他のドキュメントを漏れなく更新できます。 変更の種類（新機能、仕様変更、設定追加など）に応じて、どのドキュメントを更新すべきか自動判断できます。 多言語ドキュメント（日本語・英語など）の同期状態を確認し、ドキュメント間のズレを防げます。 実装の詳細ではなく、ユーザーに必要な情報だけを簡潔に記載し、分かりやすいドキュメントを保つことができます。 コード変更のたびにドキュメント更新を別途対応するのが手間だと感じている開発者 複数言語のドキュメント管理で、翻訳版が古いままになってしまう問題に困っている人 ユーザーに向けた正確で最新のドキュメントを常に保ちたいプロダクトマネージャーやテックライター