jpskill.com
💬 コミュニケーション コミュニティ

skill-craft

Claude Skillの品質を8つのモジュールで評価し、構造スキャンや欠陥修正、新規作成、システム監査まで行うSkill。

📜 元の英語説明(参考)

Evaluates, repairs, creates, and audits Claude Skills using an 8-module quality framework with weighted scoring. Performs structural scanning, anti-pattern detection, completeness verification, discovery validation, and decision-gate checks. Use when checking Skill quality ("check skill", "skill 质量", "评估这个 skill", "review skill", "skill 好不好", "skill 总是不触发", "skill 输出不稳定"), fixing Skill defects ("fix skill", "修复 skill"), creating new Skills ("创建 skill", "新建 skill"), or auditing multi-Skill route conflicts ("审计 skill", "系统审计"). Also triggers on: "evaluate skill", "audit skill system", "skill quality report", "grade this skill". Do not use for general code review, non-Skill documentation, Skill design concept discussions without a concrete target, or runtime debugging.

🇯🇵 日本人クリエイター向け解説

一言でいうと

Claude Skillの品質を8つのモジュールで評価し、構造スキャンや欠陥修正、新規作成、システム監査まで行うSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux 
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o skill-craft.zip https://jpskill.com/download/6603.zip && unzip -o skill-craft.zip && rm skill-craft.zip
🪟 Windows (PowerShell) 
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/6603.zip -OutFile "$d\skill-craft.zip"; Expand-Archive "$d\skill-craft.zip" -DestinationPath $d -Force; ri "$d\skill-craft.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して skill-craft.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → skill-craft フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動
⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-17
取得日時
2026-05-17
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

[Skill 名] skill-craft

Skill Craft — 評価 / 修正 / 作成 / 監査

ユーザーの言語で応答します。

トリガー条件

check モード（同時に満たす）:

  • ユーザーが既存の単一の Skill ディレクトリパス（SKILL.md を含む）を提供した
  • ユーザーの意図が評価/チェック/監査/採点/レビューである
  • 問題現象のシグナル（優先的に一致）: "skill が全くトリガーされない" "skill の出力が不安定だ" "skill の品質はどうですか"

fix モード（同時に満たす）:

  • ユーザーが既存の Skill ディレクトリパス（SKILL.md を含む）を提供した
  • ユーザーの意図が修正/修復/調整/更新/fix/repair である

create モード（同時に満たす）:

  • ユーザーが Skill の作成/生成/新規作成を要求した
  • ユーザーが Skill の用途または領域を説明した

audit モード（同時に満たす）:

  • ユーザーが複数の Skill を含む親ディレクトリパスを提供した
  • またはユーザーが明確に"システムレベルの監査" "グローバルチェック" "ルーティング競合チェック"を要求した
  • ディレクトリ内に ≥2 個の SKILL.md が存在する

トリガーしない:

  • Skill 設計の概念について議論するが具体的な目標がない（"Skill はどう書けばいいですか？"）
  • Skill パスを引用するが操作意図がない（"この Skill はどこにありますか？"）
  • Skill 以外のファイルのコード監査（code-audit を使用）

曖昧さの処理:

  • モードを判断できない場合は質問します: "check（単一評価）、fix（評価+修正）、create（ゼロから作成）、それとも audit（複数 Skill のシステム監査）のどちらをご希望ですか？"

デフォルト:

  • 単一 Skill パス + 明確な修正語句なし → check
  • 単一 Skill パス + "修/改/更新/修正" → fix
  • 既存ディレクトリなし + "作成/生成/新規作成" → create
  • 複数 Skill の親ディレクトリ → audit

行動規範

以下のルールはセッション全体で有効であり、会話の長さによって緩和されることはありません：

  1. ❗ すべての発見/変更は出典を引用する必要があります（ファイルパス + セクション/行番号）— すべてのモードに適用されます。毎回出力前にこの項目を自己チェックしてください。
  2. ❗ 採点はチェックリストに基づき客観的に行われます（チェックリストで定義された 0/1/2 または Pass/Partial/Fail）、印象によるものではありません — check/fix モード。毎回出力前にこの項目を自己チェックしてください。
  3. ❗ 一方的な修正は禁止です — fix モード：ドキュメントを修正する場合は実装も同期して修正し、実装を修正する場合はドキュメントも同期して修正する必要があります。毎回修正前にこの項目を自己チェックしてください。
  4. ❗ 強い結論は Decision Gate を通過する必要があります — トリガーシグナルは調査を開始するだけで、直接結論を生成することはできません。証拠が不十分な場合は tentative / unresolved を出力します — check/fix/audit/create のすべてのモードに適用されます。毎回出力前にこの項目を自己チェックしてください。

その他の準則:

  • 評価するのは Skill 自体の構造品質であり、Skill がサービスを提供する領域の専門的な深さではありません。
  • fix モード：修正範囲は監査で発見されたものに限定され、監査で言及されていない内容を"ついでに最適化"することはできません。
  • create モード：生成内容はユーザーの要求記述に基づき、ユーザーが要求していない領域知識を追加することはできません。

ツール優先順位（自己判断で降格不可）

操作 優先ツール 降格条件 降格ツール
ファイル読み取り Read Read がエラーを返す Bash cat
ファイル検索 Glob Glob が 0 を返し、パスの存在が確認された Bash ls -R
キーワード検索 Grep Grep が連続 2 回失敗した Bash grep
既存ファイルの変更 Edit Edit が失敗した（例：old_string が一意でない） old_string の範囲を調整して Edit を再試行
新規ファイルの作成 Write — —
  • 1 回のタイムアウト ≠ ツールが使用不可、1 回は再試行する必要があります。
  • 降格は必ず明記してください: "⚠️ 降格: [理由]"
  • Bash sed/awk で Edit を代替することはできません。

出力制約

出力禁止:

  • "分析してみましょう..." / "まず、私たちは..." などの冒頭の言葉
  • ツール呼び出し前後の重複した説明（直接呼び出し、"Read ツールを使用して読み取ります..."とは言わない）
  • 既知情報の繰り返し（ユーザーが言ったばかりのパス、ファイルから読み取ったばかりの内容）
  • 8 モジュール / 7 アンチパターン自体の定義説明（ユーザーは既知）
  • Skill がサービスを提供する領域に関する専門的なコメント（範囲外）

モード固有の禁止事項:

  • fix モード："修正済み"とだけ言って検証方法と結果を示さないことは禁止
  • create モード：既存の Skill ルーティングと競合するトリガー条件の生成は禁止

実行フロー

各モードの詳細な手順（失敗時の降格パスと ✅ Checkpoint を含む）は、対応するリファレンスファイルに記載されており、実行時に必要に応じてロードされます。各ステップは Checkpoint を出力してから次のステップに進む必要があります。

check モード → references/check-guide.md を Read

  • クイックチェック: 3 ステップ（構造スキャン → モジュール存在性 → クイックレポート）、各ステップに ✅ Checkpoint があります。
  • ディープチェック: まずクイックチェックで問題領域を特定し、その後必要に応じて対応するリファレンスをロードします（一度にすべてをロードするわけではありません）。
  • 採点: モジュール(55%) + アンチパターン(20%) + 完全性(15%) + Decision Gate(10%)、実戦チェックは追加です。
  • コンテキスト保護: クイックチェックでは完全な基準をロードしません。ディープチェックでのみ quality-standards.md と decision-gates.md をロードします。

fix モード → references/fix-guide.md を Read

  • 8 ステップ: 構造スキャン → チェックリスト+制約のロード → ディープ評価 → 問題リスト → P0 修正 → P1 修正 → P2 修正 → グローバル検証+回帰評価
  • 各修正は強制: 変更 → 読み戻し検証 → 変更影響スキャン(4 種類の関連：参照元/対称ファイル/下流コンシューマ/同階層ファイル) → 関連同期
  • 監査結果を先に出力し、その後ファイルを変更します。各ステップに ✅ Checkpoint があります。

create モード → references/create-guide.md を Read

  • 6 ステップ: 要件明確化 → 規模判断 → ファイル生成 → 自己チェックリスト → 自動検証(validate-metadata + validate-structure) → 作成レポート
  • 規模適応: 軽量(モジュール 1+2+4+8) / 中程度(1-5+8) / 重型(全 8 個)。各ステップに ✅ Checkpoint があります。

audit モード → references/audit-guide.md を Read

  • 6 ステップ: システムスキャン → 標準のロード → ルーティング監査 → 一貫性監査 → 検証クローズドループ → システムレポート
  • 複数 Skill 固有: ルーティング境界、役割分担、古い口径の残留、外部ドキュメント伝播。各ステップに ✅ Checkpoint があります。

依存チェーン

check: チェックリスト → 評価ステップ(基準を独自に作成しない) → Decision Gate チェック → レポート引用採点(再評価しない) → アクション項目の合計 == 各ステップの問題数の合計 fix: 評価結果 → 問題リスト(見落とさない) → 項目ごとの修正 → 回帰 Decision Gate → 修正数 + 未修正数 == 問題総数 create: 要件 → 規模判断(要件に基づく) → 必須モジュール(すべて入力) → Decision Gate テンプレート → 自己チェック(項目ごとに確認) → 入力済み数 == 必須モジュール数 audit: システムスキャン → すべての Skill をカバー → ルーティング/一貫性/Decision Gate → 発見総数 == 各ステップの問題数の合計

サブエージェント委任

check ディープ: 8 モジュール/7 アンチパターン/3 原則 は 3 つのサブエージェントで並行処理可能で、それぞれが目標コンテンツ + チェックリスト原文（コピーして転述しない）を受け取り、境界は明確です。マージ時には重複排除+一貫性+カウント検証を行います。 fix: 評価は並行処理可能ですが、修正は並行処理不可です（修正間に依存関係があるため）。 create: 通常、サブエージェントは不要です。 audit: ルーティング監査 + 一貫性監査 は 2 つのサブエージェントで並行処理可能です。

監査履歴（Memory）

check/fix/audit が完了するたびに、結果を監査履歴ファイル（1 行 1 JSON）に追加します：

保存パス（優先順位順）：

  1. ${CLAUDE_PLUGIN_DATA}/audit-history.jsonl（プラグインインストール時に利用可能）
  2. ~/.claude/skill-craft-data/audit-history.jsonl（フォールバック）
{"ts":"2026-03-26T10:00:00Z","mode":"check","skill":"skill-name","path":"/abs/path","weights_version":"2.0","score":7.2,"p0":1,"p1":3,"p2":2,"modules":"6/8","antipatterns_high":1,"dg":"Pass"}

読み取りタイミング：

  • check/fix モード：実行前に履歴を確認し、同じ Skill に履歴記録がある場合は比較（前回 → 今回）を出力します。
  • audit モード：システムレポートの最後に"採点トレンド"表を添付します（履歴がある Skill のみ）。
  • 履歴がない場合 → 言及せず、捏造しません。

書き込みタイミング：レポート出力後、まず書き込み予定の記録を表示します。ユーザーが確認した場合にのみ書き込みます。fix モードでは修正後のスコアを書き込みます。

Gotchas（この Skill を使用する際の一般的な落とし穴）

  1. check クイックモードでの見落とし：クイックチェック（3 ステップ）はモジュールの存在性のみをチェックし、アンチパターンと完全性原則はチェックしません。Skill の構造が完全に見えても品質が低いケースは、ディープチェックでしか発見できません。デフォルトではディープチェックを使用し、ユーザーが明確に"ざっと見てほしい"と言った場合にのみクイックモードを使用します。
  2. fix 前には必ず check が必要：直接 fix するとベースラインスコアがなく、改善効果を定量化できません。fix フローには評価ステップが組み込まれていますが、ユーザーが"評価なしで直接修正してほしい"と言った場合は、ベースラインスコアがないと修正が有効かどうか検証できないことを伝える必要があります。
  3. 大量の Skill を audit する際のコンテキストオーバーフロー：ディレクトリ内の Skill 数が 15 を超える場合は、バッチ処理で audit する必要があります。バッチ処理ルール：サブディレクトリごとにグループ化し、各バッチは ≤8 個の Skill（各 SKILL.md 約 200 行 × 8 = 約 1600 行 ≈ 6400t、チェックリストに余裕を持たせる）とします。各バッチは独立したレポートを出力し、最終的にシステムレポートに統合します。サブディレクトリがない場合はアルファベット順にグループ化します。
  4. fix の"ついでに最適化"の落とし穴：修正中に監査で言及されていない問題を発見し、強く"ついでに修正したい"と思うことがあります。これは禁止です。監査で発見されていない = 今回の修正範囲外であり、レポートの"今後の提案"セクションに記録するだけで十分です。
  5. 採点を Skill 間で横断的に比較することはできません：8 モジュールフレームワークは、異なる規模の Skill に対して異なる重み付けを行います（軽量 Skill のモジュール 7 は N/A となります）。スコアは、同じ Skill の縦方向のトレンド比較にのみ適しています。
  6. 重み付け改版後のスコアはバージョン間で比較できません：古いベースライン（60/25/15、Decision Gate なし）と新しいベースライン（55/20/15/10）では score の意味が異なります。audit-history.jsonl を読み取る際には weights_version フィールドで区別し、異なるバージョンの記録を直接 前回 → 今回 の比較として生成してはならず、"⚠️ ベースライン変更 (v{旧} → v{新})" と明記する必要があります。

事実的制約

すべてのモード: 結論は出典を引用する必要があります（ファイルパス+行番号）。出典がない場合 = 出力しません。

シナリオ 正しい出力 禁止出力
モジュール欠落 "ABSENT: モジュール N は存在しません" "モジュール N は弱い"
アンチパターンにリスクなし "PASS: 脆弱性指標は発見されませんでした" リスクを捏造する
判断不能 "UNABLE TO ASSESS: [理由]" スコアを推測する

注釈: ツール確認→注釈なし / 降格推測→"⚠️ 降格分析" / 領域提案→"💡 一般的な提案"

fix: 修正は監査で発見されたものに限定され、"ついでに最適化"することはできません。各修正は出典+内容+検証結果を説明する必要があります。 create: トリガー条件はユーザーの記述に基づき、ユーザーが要求していない領域知識を追加しません。 audit: ルーティング競合は実際の description の比較に基づきます。古い口径は grep で検証します。

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Skill Craft — Evaluate / Fix / Create / Audit

按用户语言响应（Respond in the user's language）

触发条件

check 模式（同时满足）:

  • 用户提供了现有单个 Skill 目录路径（含 SKILL.md）
  • 用户意图是评估/检查/审计/打分/review
  • 问题现象信号（优先匹配）: "skill 总是不触发" "skill 输出不稳定" "skill 质量怎么样"

fix 模式（同时满足）:

  • 用户提供了现有 Skill 目录路径（含 SKILL.md）
  • 用户意图是修复/修/调整/更新/fix/repair

create 模式（同时满足）:

  • 用户要求创建/生成/新建一个 Skill
  • 用户描述了 Skill 的用途或领域

audit 模式（同时满足）:

  • 用户提供了包含多个 Skill 的父目录路径
  • 或用户明确要求"系统级审计""全局检查""路由冲突检查"
  • 目录下存在 ≥2 个 SKILL.md

不触发:

  • 讨论 Skill 设计概念但无具体目标（"Skill 应该怎么写？"）
  • 引用 Skill 路径但无操作意图（"这个 Skill 在哪？"）
  • 非 Skill 类文件的代码审计（用 code-audit）

歧义处理:

  • 无法判断模式时询问: "您是要 check（单个评估）、fix（评估+修复）、create（从零创建）、还是 audit（多 Skill 系统审计）？"

默认:

  • 单个 Skill 路径 + 无明确修复词 → check
  • 单个 Skill 路径 + "修/改/更新/修复" → fix
  • 无现有目录 + "创建/生成/新建" → create
  • 多 Skill 父目录 → audit

行为准则

以下规则在整个会话期间有效，不因对话长度而放松：

  1. ❗ 每个发现/修改必须引用来源（文件路径 + 章节/行号）— 适用所有模式。每次输出前自检此条。
  2. ❗ 评分基于检查清单客观打分（按清单定义的 0/1/2 或 Pass/Partial/Fail），不凭印象 — check/fix 模式。每次输出前自检此条。
  3. ❗ 禁止单边修复 — fix 模式：改文档必须同步改实现，改实现必须同步改文档。每次修改前自检此条。
  4. ❗ 强结论必须通过 Decision Gate — 触发信号只能启动调查，不能直接生成结论；证据不足时输出 tentative / unresolved — 适用 check/fix/audit/create 所有模式。每次输出前自检此条。

其他准则:

  • 评估的是 Skill 本身的结构质量，不是 Skill 所服务领域的专业深度
  • fix 模式：修复范围仅限审计发现，不可"顺便优化"审计未提及的内容
  • create 模式：生成内容基于用户需求描述，不可添加用户未要求的领域知识

工具优先级（不可自行降级）

操作 首选工具 降级条件 降级工具
读取文件 Read Read 返回错误 Bash cat
查找文件 Glob Glob 返回 0 且路径确认存在 Bash ls -R
搜索关键词 Grep Grep 连续 2 次失败 Bash grep
修改已有文件 Edit Edit 失败（如 old_string 不唯一） 调整 old_string 范围后重试 Edit
创建新文件 Write — —
  • 单次超时 ≠ 工具不可用，必须重试 1 次
  • 降级必须标注: "⚠️ 降级: [原因]"
  • 不可用 Bash sed/awk 替代 Edit

输出约束

禁止输出:

  • "让我来分析一下..." / "首先我们需要..." 等开场白
  • 工具调用前后的重复描述（直接调用，不说"我将使用 Read 工具读取..."）
  • 已知信息的复述（用户刚说的路径、文件刚读的内容）
  • 8 模块 / 7 反模式本身的定义解释（用户已知）
  • 对 Skill 所服务领域的专业评论（超出范围）

模式特定禁止:

  • fix 模式：禁止只说"已修复"而不展示验证方法和结果
  • create 模式：禁止生成与现有 Skill 路由冲突的触发条件

执行流程

每个模式的详细步骤（含失败降级路径和 ✅ Checkpoint）在对应 reference 文件中，执行时按需加载。每步必须输出 Checkpoint 后才能进入下一步。

check 模式 → Read references/check-guide.md

  • 快速检查: 3 步（结构扫描 → 模块存在性 → 快速报告），每步有 ✅ Checkpoint
  • 深度检查: 先 quick check 识别问题区域，再按需加载对应 reference（不一次性加载全部）
  • 评分: 模块(55%) + 反模式(20%) + 完整性(15%) + Decision Gate(10%)，实战检查为附加
  • 上下文保护: quick check 不加载完整标准；deep check 才加载 quality-standards.md 与 decision-gates.md

fix 模式 → Read references/fix-guide.md

  • 8 步: 结构扫描 → 加载清单+约束 → 深度评估 → 问题清单 → P0修复 → P1修复 → P2修复 → 全局验证+回归评估
  • 每项修复强制: 修改 → 读回验证 → 变更影响扫描(4种关联：引用方/对称文件/下游消费者/同层文件) → 关联同步
  • 审计结果先输出，再改文件。每步有 ✅ Checkpoint

create 模式 → Read references/create-guide.md

  • 6 步: 明确需求 → 规模判断 → 生成文件 → 自检清单 → 自动化验证(validate-metadata + validate-structure) → 创建报告
  • 规模适配: 轻量(模块1+2+4+8) / 中等(1-5+8) / 重型(全部8个)。每步有 ✅ Checkpoint

audit 模式 → Read references/audit-guide.md

  • 6 步: 系统扫描 → 加载标准 → 路由审计 → 一致性审计 → 验证闭环 → 系统报告
  • 多 Skill 专属: 路由边界、角色分工、旧口径残留、外围文档传播。每步有 ✅ Checkpoint

依赖链

check: 检查清单 → 评估步骤(不自创标准) → Decision Gate 检查 → 报告引用评分(不重估) → 行动项总数 == 各步问题数之和 fix: 评估结果 → 问题清单(不遗漏) → 逐项修复 → 回归 Decision Gate → 修复数 + 未修复数 == 问题总数 create: 需求 → 规模判断(基于需求) → 必需模块(全部填充) → Decision Gate 模板 → 自检(逐项核对) → 已填充数 == 必需模块数 audit: 系统扫描 → 覆盖所有 Skill → 路由/一致性/Decision Gate → 发现总数 == 各步问题数之和

子 Agent 委派

check 深度: 8模块/7反模式/3原则 可并行 3 个子 agent，各收到目标内容 + 检查清单原文（复制不转述），边界明确，合并时去重+一致性+计数验证 fix: 评估可并行，修复不可并行（修复间有依赖） create: 通常不需要子 agent audit: 路由审计 + 一致性审计 可并行 2 个子 agent

审计历史（Memory）

每次 check/fix/audit 完成后，将结果追加到审计历史文件（一行一条 JSON）：

存储路径（按优先级）：

  1. ${CLAUDE_PLUGIN_DATA}/audit-history.jsonl（plugin 安装时可用）
  2. ~/.claude/skill-craft-data/audit-history.jsonl（fallback）
{"ts":"2026-03-26T10:00:00Z","mode":"check","skill":"skill-name","path":"/abs/path","weights_version":"2.0","score":7.2,"p0":1,"p1":3,"p2":2,"modules":"6/8","antipatterns_high":1,"dg":"Pass"}

读取时机：

  • check/fix 模式：执行前先查历史，同一 Skill 有历史记录时输出对比（上次 → 本次）
  • audit 模式：系统报告末尾附"评分趋势"表（仅有历史的 Skill）
  • 无历史 → 不提及，不编造

写入时机：报告输出后，先展示待写入记录；仅在用户确认后写入。fix 模式写入修复后的分数。

Gotchas（使用本 Skill 的常见陷阱）

  1. check 快速模式漏检：快速检查（3 步）只查模块存在性，不查反模式和完整性原则。Skill 结构看起来完整但质量差的情况只有深度检查能发现。默认用深度检查，仅在用户明确说"快速看一下"时才用快速模式。
  2. fix 前必须 check：直接 fix 缺少基线分数，无法量化改进效果。fix 流程已内置评估步骤，但如果用户说"直接改不用评估"，需要提醒：没有基线分数无法验证修复是否有效。
  3. audit 大量 Skill 时超上下文：目录下 Skill 数量 > 15 时必须分批 audit。分批规则：按子目录分组，每批 ≤8 个 Skill（每个 SKILL.md ~200行 × 8 = ~1600行 ≈ 6400t，留余量给检查清单）。每批独立出报告，最终合并为系统报告。无子目录时按字母序分组。
  4. fix 的"顺便优化"陷阱：修复过程中发现审计未提及的问题，强烈想"顺便改掉"。禁止。审计未发现 = 不在本轮修复范围，记录到报告的"后续建议"节即可。
  5. 评分不可跨 Skill 横向比较：8 模块框架对不同规模的 Skill 权重不同（轻量 Skill 模块 7 标 N/A），分数只适合同一 Skill 的纵向趋势对比。
  6. 权重改版后分数不可跨版本比较：旧基线（60/25/15，无 Decision Gate）与新基线（55/20/15/10）的 score 语义不同；读取 audit-history.jsonl 时按 weights_version 字段区分，不同版本记录不得直接生成 上次 → 本次 对比，需标注 "⚠️ 基线变更 (v{旧} → v{新})"。

事实性约束

所有模式: 结论必须引用来源（文件路径+行号），无来源 = 不输出。

场景 正确输出 禁止输出
模块缺失 "ABSENT: 模块 N 不存在" "模块 N 较弱"
反模式无风险 "PASS: 未发现漏洞指标" 编造风险
无法判断 "UNABLE TO ASSESS: [原因]" 猜测评分

标注: 工具确认→无标注 / 降级推测→"⚠️ 降级分析" / 领域建议→"💡 通用建议"

fix: 修复仅限审计发现，不可"顺便优化"；每项修复须说明出处+内容+验证结果 create: 触发条件基于用户描述，不添加用户未要求的领域知识 audit: 路由冲突基于实际 description 对比；旧口径通过 grep 验证