laohan-skillcreator

laohan Skill 作成・監査・修復・最適化ツール

作成は本番向けの能力、監査は読み取り専用の診断、修復は小規模な誤りの修正、最適化は実験的な進化です。まずモードを判断し、リスクに見合った検証を行います。明確な小規模修正を、完全な最適化プロジェクトに格上げしてはいけません。

参照元

現在、6 組の上流ソースを参考にしています。具体的なファイルと直近の確認 commit は references/upstream-sources.json に記録されています。この Skill 自体を変更する場合、またはユーザーから方法の更新を求められた場合は、まず scripts/check-upstreams.sh を実行します。上流に変更が見つかったら、関連する diff を読み、本番環境での実際の動作を改善できる変更だけを取り込みます。ローカルの方法を自動的に上書きしてはいけません。

1. anthropics/skills · skill-creator（https://github.com/anthropics/skills）

   • 参考にした点：段階的開示（metadata→body→bundled の 3 層）、同一条件での baseline 比較、ブラインド比較、description オプティマイザー、transcript からの反復作業の特定、更新時の名前維持
   • 核心となる考え方：優れた Skill は 3 層で段階的に開示され、一塊ではありません

2. Agent Skills specification / best practices（https://github.com/agentskills/agentskills）

   • 参考にした点：frontmatter の共通仕様、段階的開示、実体験の優先、制御の強さをタスクの脆弱性に合わせること、実行履歴から無効な手順を削除すること
   • 核心となる考え方：Skill はエージェントに不足している分野の経験を補うものであり、常識を繰り返すものではありません。過度に包括的な内容も効果を低下させます

3. mattpocock/skills · writing-great-skills（https://github.com/mattpocock/skills）

   • 参考にした点：トリガー分岐、情報の階層化、完了条件、単一の信頼できる情報源、重複・堆積・無操作の排除
   • 核心となる考え方：Skill が目指すのはプロセスの予測可能性であり、すべての出力を同じにすることではありません。分岐ごとに必要な情報だけを読み込みます

4. thananon/9arm-skills · debug-mantra/post-mortem/scrutinize（https://github.com/thananon/9arm-skills）

   • 参考にした点：verbatim recitation（初回に一度だけ＋逐語的に＋無言で適用）、明確なゲート表現、ドラフト作成の拒否、Skill 間の提案は自動で行わないこと、まず意図を疑うこと、引用できなければ事実として扱わないこと
   • 核心となる考え方：不確かな場合は立ち止まり、すべての主張に引用を付けます

5. alchaincyf/darwin-skill + SkillLens / SkillOpt（https://github.com/alchaincyf/darwin-skill）

   • 参考にした点：9 次元の採点システム、8 項目の反例ブラックリスト、ラチェット機構（git ratchet）、独立したサブエージェントによる再評価、人間参加型の 5 段階プロセス
   • 核心となる考え方：SkillLens によると、評価基準なしの LLM のペアワイズ判定の精度は 46.4% にとどまります。検証済みのメタ Skill 評価基準を使うと 73.8% に向上しますが、実際のタスク検証の代わりにはなりません

6. obra/superpowers · writing-skills（https://github.com/obra/superpowers）

   • 参考にした点：綿密な作成・最適化の場合に限り、Skill なしの baseline とストレスシナリオを用いること、機械的に実行できる制約はスクリプトまたは verifier に優先して任せること
   • 核心となる考え方：テストでは Skill が実際の動作を変えたことを示す必要がありますが、明確な小規模修正に TDD の儀式を押し付けてはいけません

---

核心となる考え方

4 つの原則：

1. ルーティングがコストを決めます — name + description はエージェントが Skill を見つける役割を担い、本文の最初のステップは適切な分岐を選ぶ役割を担います。トリガーが正確だからといって、毎回重いプロセスを通す必要はありません
2. 構造が動作を導きます — 優れた骨組みは、優れた指示よりも効果的です
3. 完全さより簡潔さを優先します — すべてのセクションについて、存在する価値を示す必要があります
4. 書式の点数より効果を優先します — 静的評価基準は問題の発見に使います。変更を維持するかどうかは、トリガー、実行、held-out サンプル、ユーザーの受け入れによって判断します

---

まずモードを選ぶ

毎回、主モードを 1 つだけ選びます：

モード	使用する場面	デフォルトの検証強度
CREATE	再利用可能な Skill を新規作成する	実サンプル、トリガー／非トリガー、実行テスト。複雑または影響の大きい Skill では held-out も追加
AUDIT	点検、採点、妥当性の確認	読み取り専用とし、具体的な行と動作の証拠を引用します。ファイルは変更しません
SURGICAL_FIX	元の版への復元、明確な誤りの修正、固定契約またはパスの更新	信頼できる情報源と比較し、最小限の変更を行い、その誤りを直接対象とする回帰テストを実施します。静的採点、ブラインド判定、無関係な held-out は行いません
OPTIMIZE	ユーザーが効果の向上、新旧案の比較、または全面的な進化を明確に求めている	baseline／指標を固定し、held-out を実行します。主観的な結果に限りブラインド判定を使います
UPSTREAM_REFRESH	この Skill が参考にしている方法を更新する場合、または引用元に変更があったか確認する場合	上流チェックを実行し、変更内容を読み、関連する改善だけを統合して記録 commit を更新します

ユーザーが「Skill を変更して」と言い、明確な誤りまたは元の版の信頼できる情報源を示している場合、デフォルトでは SURGICAL_FIX を選びます。「効果を最適化して」「全面的に監査して」「案を比較して」と求められた場合に限り、OPTIMIZE に進みます。AUDIT に修正の許可は含まれず、CREATE にインストールや公開の許可は含まれません。

上流の更新

UPSTREAM_REFRESH の実行時、および laohan-skillcreator 自体を変更する場合：

1. bash scripts/check-upstreams.sh を実行します。
2. CURRENT：現在のタスクを続行します。
3. UPDATED：記録された commit から最新 commit までの関連ファイルの diff を読み、ローカルで参考にしている方法が変わるかを判断します。
4. 明確な改善がある場合に限り、この Skill を変更します。関連する改善がない場合は、確認情報だけを更新し、上流の全文をそのまま取り込みません。
5. ローカルのモード振り分けに劣化がないことを検証してから、references/upstream-sources.json の commit と verified_at を更新します。
6. UNVERIFIED：検証できなかったことを報告し、上流に追従済みだとは主張しません。上流に関係のない SURGICAL_FIX は妨げません。

---

CREATE の手順

Step 0 · まず意図を疑う（ハードゲート、scrutinize モード）

新規作成の前に、次の 3 つの問いを必ず確認します。まず catalog／プロジェクトの証拠から自分で答え、ユーザーの意図を会話から判断できない場合に限り質問します：

1. 既存の skill を拡張できませんか？（現在の runtime の available-skills catalog とプロジェクトのローカル skill ディレクトリを調べ、重複を確認します。インストール先を推測してはいけません）
2. 作成しない方法はありませんか？（何もしなくてもよいか、手作業での一度限りの操作で十分かを確認します）
3. 新規作成が必須であることを確認した場合 → Step 1 に進みます

1 または 2 の答えが「はい」の場合 → 代替案（どの skill を拡張するか／なぜ作成が不要か）をユーザーに伝え、新規作成しません。

Step 1 · 意図を捉える

会話から次の内容を抽出します（またはユーザーに質問します）：

1. この skill でエージェントに何ができるようになりますか？
2. どのようなときにトリガーしますか？（ユーザーが使うキーワードや状況は何ですか？）
3. 期待する出力形式は何ですか？
4. scripts/ または references/ サブディレクトリが必要ですか？

ユーザーが明確にできない場合は、いったん止まり、不明な点を列挙して補足を待ちます。推測してはいけません。

Step 2 · 調査

Step 0 の「既存のものを拡張できない」という結論を再確認します（catalog と現在のプロジェクトを再調査します）。拡張可能なものが見つかった場合は、Step 0 に戻ります。

• 完了条件： 新規作成が必要であることを確認し、その理由を説明します

Step 3 · SKILL.md を作成

以下の骨組みテンプレートと作成ルールに従います。まず極簡素な骨組みにするか、完全な骨組みにするかを判断してから記入します。

• 完了条件： frontmatter が対象 runtime で許可されている schema に準拠していること（Agent Skills の共通最小要件は name + description、laohan-local profile ではさらに version が必要です）。本文とリソース参照が揃っていること

Step 4 · テストと反復

1. まず書き込み可能な作業コピーでテストします。対象のランタイムでインストールが必要な場合に限り、公式のパス／パッケージ方法でインストールし、自動でシンボリックリンクを作成しません
2. トリガーテスト：自動ルーティングする Skill では、少なくとも should-trigger と should-not-trigger に近いケースをそれぞれ 1 つずつテストします。分岐が多い場合や description を大幅に変更した場合は、各分岐までテストを広げます。完全に手動で呼び出す場合は NOT_APPLICABLE と記録します
3. 実行テスト：決定論的な Skill では、機械的に検証できる入力／出力のフィクスチャを使います。主観的な Skill では、ブラインド比較と具体的な品質基準を使います
4. held-out 検証：複雑な場合、影響が大きい場合、またはユーザーが効果の比較を求めた場合は、改稿に使っていないサンプルを少なくとも 1 つ保持します。シンプルな Skill では、実際の実行サンプルを 1 つ使えば十分です
5. 作業の重複チェック：実行 transcript を読み、毎回同じ補助コードを生成している場合は、scripts/ に抽出します
6. 不合格 → Step 3 に戻って修正 → 再テスト
7. 3 回の反復で合格しない場合は停止します。小さな修正ではなく構造上の問題かもしれないため、中心となる考え方を再検討します

Step 5 · ローカルでの受け入れ確認

1. 実際の実行結果に基づいて完了を判断します。6 次元スコアは、構造が不明瞭な場合またはユーザーが評価を求めた場合に限り、診断として使います
2. 複雑な Skill や影響の大きい Skill では、held-out での性能が低下しないことが必要です。シンプルな Skill は、対象サンプルとトリガーテストに合格すれば受け入れ可能です
3. 🔴 公開チェックポイント：ユーザーが push／publish／package／install を明確に要求した場合に限り、対応する外部操作を実行します。作成や最適化の依頼だけでは、公開の許可を含みません

---

SKILL.md の骨格テンプレート

すべての Skill に完全な骨格が必要なわけではありません。数行で説明できるほどロジックがシンプルな場合は、そのまま指示を書きます。「プロらしさ」のために余分なセクションを加えないでください。

判断基準：単一ステップで、複雑な条件分岐がなく（シンプルなフォールバックを除く）、役割の区別もない場合 → 最小構成。複数ステップ／条件分岐あり／複数の役割 → 完全な骨格。

最小構成の例（5 行）

---
name: caveman
description: 极简回应模式，只输出关键信息。Use when 用户说"caveman mode""极简""少说废话""简短"。
---

所有回应控制在 3 句话以内。只给结论和关键依据，不解释过程。如果用户要求详细解释，恢复正常模式。

完全な骨格テンプレート（v2 アップグレード）

---
name: skill-name
description: 一句话说清做什么。Use when 用户说"触发词1""触发词2""触发词3"或提到[相关场景]。  # ≤1024字符，3-8触发词，第三人称
# version: 1.0  # 只在目标 runtime/profile 允许时加
---

# Skill 标题

一句话定位。

## 核心理念（复杂 skill 必加，简单可省）

为什么存在、遵循什么原则。先讲 why 再讲 how——比直接列步骤更有效。

## 工作流

### 1. [步骤名]
- 做什么
- **完成条件：** [怎么判断这步做完了]
- **🔴 CHECKPOINT：** [仅当该步有外部副作用、高风险或用户保留决策时填；否则删除]
- **🛑 STOP：** [强制停止条件]

### 2. [步骤名]
- 做什么
- **失败处理（只有存在复杂降级链时用三段式；单一安全 STOP 直接写 if-then）：**

  | 触发条件 | 一线修复 | 仍失败兜底 |
  |---------|---------|-----------|
  | [X 失败] | [Y] | [Z] |

### 3. [步骤名]
- 做什么
- **涉及外部动作 → 🔴 等用户确认再执行**

## 操作规则

跨步骤常驻约束：

- [规则1]
- [规则2]
- 遇到 [异常] → [怎么处理]（不静默跳过）

## 不适用场景（refuse to draft 硬拒绝，v2 升级）

- 场景 A → 改用 [其他 skill]
- **缺 [必要输入 X] → 列出缺什么并停，不硬编、不猜**（9arm post-mortem 模式）

## 反模式（复杂 skill 必加，v2 从可选升级）

❌ 差：
"[反例]"

✅ 好：
"[正例]"

## 输出格式（可选）

# [标题模板]
## [章节1]

---

スコアリング体系（6 次元クイック評価表）

darwin の 9 次元評価を簡略化したものです（完全な 9 次元評価は references/scoring-rubric.md を参照）。任意の Skill を採点できます。

#	次元	重み	評価基準
1	frontmatter の品質	10	name／description が対象ランタイムで許可されたフィールドに準拠していること。description には何をするか、いつ使うかの両方が記されていること。トリガーワードの数はヒューリスティックであり、3～8 個にするためだけに語句を詰め込みません
2	ワークフローの明確さ	20	番号付きの手順、明確な完了条件、明確な入出力があること
3	失敗モードの記述 ⭐	20	実際に発生する可能性があり、結果に影響する失敗を網羅していること。安全な STOP を 1 つ示せば十分な場合に、無理に 3 段階の表を作りません。複雑な縮退チェーンの場合に限り、3 段階形式を求めます
4	チェックポイントの設計 ⭐	15	外部への副作用、高リスク、またはユーザーが判断を保持する場面の前に、明示的な gate があること。自律的／決定論的な Skill では、人的 gate を設けない理由を説明すれば満点でも構いません。形式を整えるためだけに、偽のチェックポイントを設けません
5	実行可能な具体性 ⭐	25	そのまま実行できる具体的なパラメーター／形式／例があること。「曖昧な語句」が必要な判断ルールの代わりになっている場合に限り減点します。引用、ユーザー向けの出力、不確実な事実を機械的に減点しません
6	反例とリスクの境界 ⭐	10	この Skill が実際に引き起こす可能性のある誤用や危険な操作を防ぐこと。git／削除／公開に関わらない Skill は、それらの操作が記載されていなくても減点しません

計算方法：各次元を 1～10 点で採点し、合計点 = Σ（次元の点数／10 × 重み）、満点は 100 点です。

cite or it didn't happen（9arm）：減点する場合は、SKILL.md の具体的な行番号または段落の原文を引用してください。「ここがよくない」といった曖昧な指摘は禁止です。

評価区分：

• 85～100：静的な構造は実行／held-out 検証に進めます。公開可能という意味ではありません
• 70～84：最適化が必要です（最低点の次元を改善します）
• 70 未満：構造に問題があります。中心となる考え方を再検討します

---

AUDIT の手順

1. 監査対象のファイルとユーザーが気にしている問題を固定し、原版、現行版、実際の呼び出し範囲を読みます。
2. まずトリガー、実行、効果、保守コストを変える問題を探し、その後で形式を確認します。各指摘には、具体的な行、diff、または実行証拠を引用します。
3. BLOCKING、BEHAVIOR_RISK、MAINTENANCE、NO_ISSUE を区別し、静的スコアを問題の件数として扱いません。
4. 結論と最小限の提案を出します。ファイルの変更、インストール、コミットは行いません。その後、ユーザーが修正を求めた場合に SURGICAL_FIX または OPTIMIZE に振り分けます。

SURGICAL_FIX の手順

1. 誤り、原版の信頼できる情報源、維持すべき動作を明確にします。
2. その誤りにたどれる行だけを変更します。既存のテンプレート、手法ライブラリ、検証済みの効果は維持し、今回生じた重複ルールや矛盾するルールを整理します。
3. 修正前には失敗し、修正後には合格する、対象を絞ったチェックを 1 つ実行します。既存の機械的な契約に影響する場合は、対応する契約回帰テストも実行します。
4. 今回の小さな修正のために、採点表、blind judge、すべてのトリガーマトリクス、汎用フレームワーク、新しい Skill を追加しません。
5. 変更内容、検証内容、実際の効果を実使用で確認する必要が残っている点を報告します。

OPTIMIZE の手順

既存の Skill を最適化します（自作の laohan シリーズのみを変更します。npx でサードパーティーの fork を取得してから変更します）。

1. 比較可能なベースラインを作る

• メインエージェントが 6 次元を使って構造上の問題を探し、減点箇所には行番号を添えます
• ベースラインの Skill、対象ランタイム、テストサンプル、評価器、成功指標を固定します。これらがない場合は「最適化」と主張しません

2. 1 回の反復につき因果仮説は 1 つ

• 各反復では、検証可能な動作上の欠陥を 1 つだけ修正します。同じ根本原因が複数の rubric 次元に関わる場合は一度に修正し、「1 回の反復につき 1 次元」にこだわって矛盾を残しません
• 未コミットの作業コピーに bounded add/delete/replace を適用し、仮説と変更予算を記録します

3. 独立した検証と held-out gate

• 決定論的な Skill では、固定した機械的 verifier でベースラインと候補を比較します。主観的な出力は、バージョンラベルを知らない judge がブラインド比較します。静的監査だけの場合は、独立した judge に矛盾を見つけさせても構いませんが、73.8% を絶対的な真値として扱いません
• 候補を受け入れるのは、事前登録した指標が明確に改善した場合、または主要指標が同等で、リスクの高い欠陥の修正が確認できた場合に限ります。それ以外は未コミットの変更を破棄します

4. 軽量版のラチェット

• 検証に合格してから commit します。ユーザーの許可があり、候補が個別に commit 済みの場合、性能が低下したら破壊的な reset ではなく git revert を使います
• held-out で実質的な改善がない状態が 2 回続いた場合、または 1 回の反復で形式のスコアだけが上がった場合は停止します

5. 詳細な最適化への振り分け（ここでは実施しません）

大規模なサンプルを使った複数回の最適化が必要な場合は、references/scoring-rubric.md を読んで、完全な 9 次元評価を実行します。現在の catalog に darwin-skill がインストール済みの場合は、その held-out サイクルに従っても構いません。このタスクでは自動インストールしません。

---

運用ルール

すべてのモードに共通する制約：

• 簡潔に保つ：書き終えたら各項目を確認し、出力に影響しない指示を削除します
• 遅延作成：内容ができてからファイル／ディレクトリを作成し、空の構造を先に作って仮置きしません
• 過学習せず汎用化する：単一のユースケースのためにニッチな調整を行いません
• 理由を説明する：「A なので B を行う」は「B を必ず行う」より優れています。LLM は賢いため、強制的なルールより理由を示すほうが効果的です（anthropics）
• 対象ユーザーの言語に合わせる：laohan シリーズはデフォルトで中国語とし、技術用語は英語のままにします
• 更新時は元の名前を維持する：installed が research-helper なら、v2 ではなく同じ名前を出力します（anthropics）

dim5 の曖昧な表現の確認（AUDIT／OPTIMIZE の採点時のみ使用）

実行可能な指示のセクションだけを確認します：以下の表現が具体的な条件／操作の代わりになっており、3 か所以上ある場合、dim5 を 3 点以上減点します。引用、反例、ユーザー向け出力、客観的な不確実性は対象外です。

• 「推奨します」／「検討できます」／「状況に応じて」／「柔軟に判断します」／「場合によります」／「適宜」／「適切に」

「X を実行する」（命令形＋具体的なパラメーター／例）のような具体的な指示に置き換えます。禁止表現の完全な一覧は references/blacklist-phrases.md を参照してください。

反例ブラックリスト（v2 新規、darwin の 8 項目を簡略化）

作成／最適化時に禁止：

1. 自己評価を受け入れ確認とみなさない — 同一 session で静的診断を行うことは可能です。決定論的な候補を受け入れるには独立した機械的 verifier と held-out が必要です。主観的な候補には blind judge と held-out が必要です（OPTIMIZE／複雑な候補を受け入れる場合）
2. 評価前に commit しない — まず作業コピーで比較します。個別に commit 済みで、許可も得ている候補に限り git revert を使います
3. 点数稼ぎのために冗長な内容を積み上げない — 上限に達した場合（Δ<2 点の状態が 2 回続いた場合）は停止します
4. 静的スコアを受け入れスコアと偽らない — AUDIT では STRUCTURE_ONLY と明記できます。効果が改善したという結論には、OPTIMIZE で baseline／with-skill／held-out の動作証拠がある場合に限り必要です
5. 1 回の反復で検証する動作上の仮説は 1 つだけ — rubric の分類を使って同じ根本原因を無理に切り分けません
6. 異常を黙って無視しない — fallback に失敗した場合は、まずユーザーに知らせます

---

該当しないケース（草案の作成を拒否し、v2 では明確に拒否）

• エージェントを作成する（エージェント ≠ スキル）→ 対象のランタイムのエージェント設定メカニズムを使用します
• SKILL.md／Agent Skills に対応していないプラットフォームプラグイン → そのプラットフォームのネイティブなプラグイン仕様を使用します
• npx のサードパーティ製スキルを変更する → fork して新規作成します（npx skills update は既存の変更を上書きします）
• 必要な入力が不足している（ユーザーが何をしたいのか明確に説明できない）→ 不足しているものを列挙して停止し、でっち上げたり推測したりしません（9arm refuse to draft）

---

書き方のルール

Frontmatter

---
name: skill-name          # kebab-case，与目录名一致
description: 功能描述。Use when 触发场景列举。  # ≤1024字符，第三人称
# version: 1.0            # 只在目标 runtime/项目 schema 允许时使用；laohan-local 要求
---

name + description は、エージェントのルーティングに使われるスキルの常設メタデータです。description には以下を含める必要があります。

1. 機能の説明（何をするのかを一文で）
2. 「Use when」＋類似スキルと区別できるだけの具体性を備えた自然言語のトリガー場面。3～8 個という数は laohan-local のヒューリスティックであり、汎用スキーマの厳格な制約ではありません
3. 三人称（mattpocock）
4. 競合するスキルがある場合は、違いを明確にする

本文の書き方

ルール	説明
分量の調整	完全に読み込まれ、冗長さがないことを基準にします。できるだけ <500 行にし、500 行に近づく、または超える場合は、長い参考資料や詳細な評価手順を references/ に分割します
基本理念を先に示す	3 ステップ以上のスキルでは、ワークフローの前に基本理念のセクションを設けます（先に why、その後に how）
ワークフローと操作ルールを分ける	ワークフロー＝手順の並び、操作ルール＝複数の手順にまたがる制約として、独立したセクションにします
フェーズゲート	外部への副作用、高リスク、またはユーザーに判断を委ねる前にのみ、厳格なゲートを設けます。確定的な内部手順には、見せかけの CHECKPOINT を追加しません
反パターン WRONG/RIGHT	中核となるルールは対比ブロックで示します（❌悪い／✅良い）
口訣の組み込み（verbatim）	暗記できる規律が実際に必要なタスクでのみ使用します。debug-mantra の形式をすべてのスキルに当てはめません
出力形式	テンプレートで定義し、曖昧な指示は避けます
フォールバックの連鎖	複数の方法がある場合は、厳格な優先順位（順番に試す）を定め、選択肢の一覧にはしません
スキル間の呼び出し	完了後に別のスキルへの引き継ぎを提案します（自動で引き継がない。9arm post-mortem）
執筆の原則	命令形＋具体例を使い、ALL CAPS の ALWAYS／NEVER は使わず、コンテンツ作成系では定義的な語調にします
scripts/ の判断基準	確定的な操作／毎回同じコードを生成する処理／明示的なエラー処理が必要な場合は scripts にします（mattpocock）
references/ の判断基準	プラットフォーム固有の方法／長いテンプレート／毎回読み込む必要のない背景知識は references にします（階層は 1 つのみ）

段階的開示（anthropics）：メタデータ（常設）→ SKILL.md 本文（トリガー時に読み込み）→ バンドルされたリソース（必要に応じて）。SKILL.md にすべて詰め込まず、量の多い内容は references/scripts に分けます。

6 項目の簡易セルフチェックリスト（CREATE 後にすばやく確認）

• description に Use when とトリガー語が含まれている
• SKILL.md はできるだけ <500 行にする。超える場合は必ず references に分割し、100～500 行の場合は読み込みの価値を基準に判断する
• 時間とともに変化する情報がない（必要な場合を除き、具体的な日付やバージョン番号は記載しない）
• 用語が統一されている
• 具体例がある
• references の階層は 1 つのみ

---

受け入れと公開のチェックリスト

作成／最適化の完了後：

• SKILL.md が作成され、frontmatter が対象のランタイムスキーマに準拠している（汎用的な最小構成は name + description、laohan-local では version も必要）
• 対象のランタイム／プロファイルが明確で、インストールパスまたはパッケージ方法が現在のホスト仕様に基づいている
• 今回のモードが記録されている。AUDIT は読み取り専用を維持し、SURGICAL_FIX を完全な最適化へ拡大していない
• CREATE／OPTIMIZE のトリガー、非トリガー、実行テストに合格している。SURGICAL_FIX の対象を絞った回帰テストに合格している
• 重複作業のチェックを実施している（毎回同じ補助コードを生成していない）
• held-out が必要なのは OPTIMIZE または複雑／影響の大きい CREATE のみ。主観的な比較の場合に限り blind judge が必要
• ランタイムのスキャンをプロファイルに応じて実行している。fatal は必ず修正し、portable 固有のパスに関する警告については、該当する capability branch がすでにあるかを人が判断する
• この Skill 自体を変更する場合は scripts/check-upstreams.sh を実行し、実際の確認結果に基づいて上流の記録を更新している
• セキュリティチェックに合格している（API キー／個人の絶対パスがなく、公開操作に明確な許可がある）
• ローカル commit、インストール、package、push、publish を個別に記録している。ローカル commit は現在のタスク／リポジトリの許可に従い、インストール、package、push、publish はユーザーから明確な許可がある場合にのみ実行する