用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/shinpr/ai-coding-project-boilerplate --skill skill-optimization命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Detects code smells, anti-patterns, and readability issues. Use when implementing features, reviewing code, or refactoring.
Determines which PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires and where each is stored. Use when deciding documentation scope or creating or reviewing a technical document.
Selects implementation strategy (vertical slice, horizontal, or hybrid) with risk assessment. Use when planning feature implementation.
| name | skill-optimization |
| description | スキルファイルの品質を9つのコンテンツパターンと10の編集原則で評価・最適化。スキル作成、内容改善、品質監査時に使用。 |
スキル読み込み時のLLM実行精度に直接影響する問題。
| 検出条件 | 変換方法 |
|---|---|
| 「〜しない」「〜を避ける」「禁止」等の否定形指示 | 望ましい操作または許可された状態を先に示す。違反が不可逆な運用操作であり、呼び出し元が通常は回復できず、肯定形だけでは境界が曖昧になる場合に限り、明示的な禁止を残す。その場合も、安全な代替手段と境界を越えるための条件を併記する。レビュー可能な品質方針は肯定形に書き換える。 |
例外の境界例:
品質ポリシー、ロール境界、採点基準、一般的な作業ルールは常に肯定形を使用する。呼び出し元が検証・上書き・破棄する出力は不可逆ではない。
スキルでの例:
xではなくuserId）」スキルで重大な理由: 禁止だけでは、実行すべき目標状態が示されない。
| 検出条件 | 変換方法 |
|---|---|
| 成果に必要な判断を残す曖昧語（「適切に」「良い」「正しく」「ベスト」「明確に」等）で、解釈の違いが実行や検証を実質的に変えるもの | 必要な精度を満たす、最も制約の少ない基準で解決する（手順は下記） |
| 形式・長さ・スコープ・トーン・成功基準が未定義でも、想定されるどの解釈でも成果を同等に満たすもの | 許容される自由度として扱い、解釈を一つに絞る必要がある場合のみ制約を追加する（下流の利用側が要求する形式はBP-003を参照） |
解決手順（1行目の該当箇所向け）:
スキル例外: 入力コンテキストから一意に解決できる表現（例: ユーザーのプロンプトと照合できる状況での「ユーザーが省略した箇所」）は曖昧ではない — 主観的判断ではなく決定論的な処理を記述している。
スキルでの例:
スキルで重大な理由: 曖昧な指示は、成果に影響する振る舞いを、基準なしにモデルへ選ばせる。
| 検出条件 | 変換方法 |
|---|---|
| 何をすべきかは書いてあるが成果物の形式が未定義 | 出力の利用側が要求する構造・フィールド・順序を定義した出力セクションを追加する（パース、振り分け、比較、検証のため）。慣習で形式を選ばない |
スキルレビューの出力契約には、BP-001〜BP-009の網羅結果、再レビューでも維持する指摘ID、重大度、場所、引用した根拠、根拠付きで却下した指摘、保持すべき要件、未解決の入力、最終評価を含める。スキル作成の出力は、完成したSKILL.mdの内容と、必要な同一ディレクトリ内のreferenceまたはscriptとする。
スキルでの例:
## 検出した問題 を、レポート描画側がパースできるテーブルで出力する: | 重大度 | 箇所 | 説明 | 修正案 |」スキルで重大な理由: 構造化出力の制約はハルシネーションを抑制し、スキル適用結果の一貫性を確保する。
| 検出条件 | 変換方法 |
|---|---|
| 指摘、可能性、または技術的に有効な改善が、成果、必要な境界、実際の利用側、必要な証明を変えないまま必須作業になる | 候補として扱い、必要な作業だけを残し、変更なし、再利用、根拠に基づく却下を許容する |
| 調査範囲が実装または成果物の範囲を決める | 必要な成果を観測できた時点で完了し、発見だけを理由に作業を増やさない |
スキルで重大な理由: 能力の高いモデルは暗黙の義務も実行するため、根拠のない可能性が成果を改善せずに作業を生み出す。
対処により実効性が向上する問題。
| 検出条件 | 変換方法 |
|---|---|
| 見出しのない文章の塊 | 標準セクション順序を適用（下記参照） |
| 複数トピックが1セクションに混在 | 見出し付きの個別セクションに分割 |
| 参照データがリスト形式のまま | テーブル形式に変換 |
標準セクション順序:
適用条件: 30行未満かつ単一トピックのスキルには構造化を省略。
| 検出条件 | 変換方法 |
|---|---|
| 記述されていない前提知識に依存 | 必要な前提を列挙したPrerequisitesセクションを追加 |
| 定義なしにドメイン用語を使用 | インラインまたは用語テーブルで定義を追加。スキル例外: LLMのベースライン知識に含まれる用語（広く使われる技術用語、標準的なドメイン語彙）は定義不要。プロジェクト固有の用語、内部命名規則、LLMの一般知識に含まれないドメイン用語のみ明示的な定義が必要。 |
| 使用場面の指針がない | 具体的なシナリオ付きのトリガー条件を追加 |
| 重複している、注意をそらす、または下流の判断・実行・検証に影響しないコンテキスト | 繰り返される事実を一つの実効的な記述に集約する。抽出した事実だけが必要な場合は、元の背景情報はパスや参照の形で残す。プロジェクト固有の事実には情報源を明記する。 |
スキルでの例:
| 検出条件 | 変換方法 |
|---|---|
| 前提となる根拠がなければ後続の操作が無効になる | 必要な根拠と遷移条件を示すゲートを追加する |
| 権限、不可逆な操作、機械が読み取る契約、完了証明が暗黙的 | その境界を明示する |
| 可逆な選択に一つの経路を必須としている | 目的、根拠、選択基準を示し、経路はモデルに選択させる |
| 機械による厳密な形式要求がないのに、特定のラベルや成果物だけをゲートが要求する | 意味的に同等な根拠を受け入れる |
要点: 予測した経路ではなく、境界と必要な根拠を制御する。
スキル作成では、以下の3つのゲートを順に使用する：
レビュー指摘に基づく修復では、現状レビューを分析の根拠とし、合意済みの修復範囲に最適化ゲートとバランスゲートを適用する。
特定の状況で効果がある段階的な改善。
| 検出条件 | 変換方法 |
|---|---|
| LLMが既に知っている挙動を例が繰り返しているだけ | 簡潔なルールまたは利用側が要求する出力形式に置き換え、例を削除する |
| ドメイン・製品・組織固有のマッピング、非自明な例外、ルールで表現できない境界を例が担っている | 解消対象の曖昧さを覆う最小限の例集合だけ残し、各例を「解消する曖昧さ」に対応づける |
| 複数の例が同じ曖昧さを解消している、または全例が同じ表層パターン | 解消対象の曖昧さを覆う最小限の例集合まで削減し、別の曖昧さを解消する場合のみ異なるケースを追加する |
| 検出条件 | 変換方法 |
|---|---|
| 常に確定的な回答を要求 | 主張を観測事実・推論・不明に分類し、曖昧な場合のエスカレーション基準を追加 |
| 「いつ止めるか」の指針がない | 「不明」が次のステップを塞ぐ場合、そのゲートで停止し、続行に必要なエビデンスまたはユーザー判断を明示する |
スキルでの例:
スキルコンテンツの測定可能な品質基準。各原則に合否判定基準を設定。
| # | 原則 | 合格基準 | 不合格例 |
|---|---|---|---|
| 1 | コンテキスト効率 | 各文がベースライン外の知識、判断規則、必要な境界、または実行根拠を提供する | 観測された失敗、レビュー指摘、プロジェクト要件との関係がないベースライン知識の説明 |
| 2 | 重複排除 | 1つのスキル内で同じ抽象度の概念を二重に説明しない。独立して読み込まれるpure skill間の重複は、各スキルの単独実行に必要な場合は有効とする。その場合はsibling skillへの参照に置き換えず、意味の整合性を確認する | 1つのスキル内で、異なる実行上の役割を加えずに同じルールを再記述 |
| 3 | 関連内容の集約 | 関連する基準を1セクションに集約（読み込み回数最小化） | エラーハンドリング規則が4セクションに散在 |
| 4 | 測定可能性 | 各基準が観測可能なエビデンス、決定論的な判断ルール、または根拠のある閾値を示す | 「きれいなコードを書く」に観測可能な条件がない |
| 5 | 肯定形 | 指示は「何をするか」を記述（BP-001適用済み） | 「一切使わないこと」→「Xのみ使用する」 |
| 6 | 表記の一貫性 | 見出しレベル、リスト記法、テーブル形式が統一 | 同一文脈で-、*、1.が混在 |
| 7 | 前提条件の明示 | プロジェクト固有・非ベースラインの前提を記述またはリンクする。ベースラインの技術知識は簡潔にとどめる | 「DI」を定義もリンクもせずに使用 |
| 8 | 重要度順の記述 | 最重要項目が先頭、例外は末尾 | エッジケースが共通パターンより先に記述 |
| 9 | スコープ境界 | スキルが扱う範囲と、条件付き内容を有効にする条件を明示する。pure skillは単独実行に必要なコンテキストを自身に含める。スキル間参照は、orchestrationまたはskill selectionを担うスキルに限定する | 他のpure skillにも同じ内容があることを理由に、実行に必要なルールがpure skillから欠けている |
| 10 | 作業量の妥当性 | 必須の成果物、テスト、ゲート、判断が、成果、境界、利用側の結果、または必要な証明を変える | 全ての指摘や技術的に有効な改善を実装必須にする |