qiaomu-meta-skill

Qiaomu メタスキル

長いプロンプトではなく、再利用可能な Qiaomu スキルパッケージを構築します。

ルーターのルール

• まずフロントマターの description に基づいて振り分けます。
• 選択後は、qiaomu-meta-skill を唯一の作成権限とします。ユーザーから比較を明示的に求められた場合、またはこのスキルを利用できない場合を除き、汎用の skill-creator も呼び出してはいけません。
• 既存事例の調査は、このスキルに組み込まれています。別の調査スキルをインストール、読み込み、委任してはいけません。
• GitHub への公開は、このスキルに組み込まれています。このパッケージが選択された後に、別の公開スキルを要求または呼び出してはいけません。
• パッケージのルート SKILL.md は、振り分けと最小限のワークフローに限定します。判断基準は references/ に、決定論的な動作は scripts/ に、回帰ケースは evals/ に、証拠は reports/ に配置します。
• パッケージで検出可能なルート SKILL.md は1つにします。埋め込みの例とフィクスチャには、SKILL.example.md または SKILL.fixture.md を使用します。
• 単発の要約、翻訳、説明、ブレインストーミングをスキルにしてはいけません。
• ユーザーの依頼内容に合わせて対応します。作成、リファクタリング、パッケージ化の依頼では編集してかまいませんが、監査、評価、診断のみの依頼では読み取り専用とします。公開は明示的に依頼された場合に限ります。
• 既定では、中国語を優先した簡潔な qiaomu- 名を使用し、推奨するハイフン区切りの部分は3つ以内にします。
• 別の所有者が指定されていない限り、Copyright (c) 向阳乔木、X の https://x.com/vista8、GitHub の https://github.com/joeseesun/ を追加します。

モード

• Scaffold：探索的または個人用。必要最小限のファイルを用意します。
• Production：チームでの再利用向け。README、インターフェース、トリガー評価、出力契約、インストール証跡を含みます。
• Library：共有インフラ向け。Production に加え、Skill IR、移植性、信頼性、レビュー頻度を含みます。
• Governed：公開用または高い信頼性が求められる用途向け。Library に加え、権限、ロールバック、シークレット、リリース、主張に関するゲートを含みます。

運用モード、ゲートの選定、QA の段階に従い、用途に応じたモードを選びます。

組み込みの既存事例調査

新しいスキルを作成する前、または大幅に再設計する前に、次の手順を実施します。

1. 成果、ドメインでの操作、品質を担保する仕組みを網羅し、必要に応じて隣接する同義語も含めて、目的に沿ったクエリを2～4件導き出します。
2. 統合ランナーを優先します。

python3 scripts/research_prior_art.py "<query 1>" "<query 2>" --strict --summary --output reports/prior-art-candidates.json

その基盤となるカタログ呼び出しは次のとおりです。

npx --yes skills find "<query>"
python3 scripts/search_skillsmp.py "<query>" --limit 20 --sort stars

3. 指標を混同しないようにします。skills.sh のインストール数は採用状況を示し、SkillsMP のスター数はソースリポジトリの評価を示します。どちらもユーザー評価や品質スコアではありません。
4. 正規の GitHub リポジトリとスキルパスに基づいて重複を除外します。翻訳、ミラー、明らかなフォークは統合し、指標を合算しません。
5. 人気、信頼性、補完性の観点から、実際に関連性の高い候補を絞り込みます。ソースの SKILL.md、メンテナンス状況、ライセンス、権限、セキュリティ上の兆候、利用可能な評価証拠を確認します。調査目的であっても、信頼できない候補のコードを実行してはいけません。
6. 維持 / 応用 / 却下 / 新規考案 に分類します。採用した仕組みは、文章を寄せ集めるのではなく、新しいパッケージにどう適用するかを対応づけます。
7. Production 以上、または実質的な調査を行った場合は、日付付きの出典、指標、失敗、重複排除、教訓、却下理由、不足している証拠を reports/prior-art-research.md に記録します。

カタログのいずれかが失敗した場合は、ほかのソースを使って続行し、「証拠不足」を記録して主張の強さを下げます。詳しい手順は既存事例調査を参照してください。

一般化ゲート

失敗事例をコアルールに昇格させる前に、次の手順を実施します。

1. ドメインに依存しない動作として言い換えます。
2. コアの仕組み、任意のアダプター、評価専用フィクスチャのいずれかに分類します。
3. 安全性、事実性、権限に関する不変条件、または無関係な複数のドメインで繰り返される動作だけを昇格させます。
4. 単発の詳細は、フィクスチャまたは専門的なリファレンスに残します。
5. 元のケースと、無関係な境界ケースを再実行します。

対象分野の百科事典を拡大するよりも、意図への忠実さ、ソースへの忠実さ、判断ルールを優先します。

Qiaomu Skill OS

1. Intent：繰り返し発生する業務、ユーザー、入力、出力、対象外事項、標準、参考資料。
2. Skill IR：プラットフォームに依存しない意味とエビデンスの境界。
3. Package：簡潔なルート指示、インターフェース、README、必要性が認められたリソース。
4. Eval：まずトリガーの境界を評価します。リスクに応じて、出力／実行時／人間による評価を行います。
5. Review：パッケージ、コンテキスト、信頼性、インストール、README、公開する主張。
6. Operate：生の非公開コンテンツを含めず、明示的なフィードバック、失敗、ドリフト、次の反復に向けた提案を扱います。

コンパクトなワークフロー

1. リクエストが再利用可能なスキルに値するかを判断します。該当しない場合は、そのまま回答し、パッケージは作成しません。
2. 業務、完成品、対象ユーザー、入力、対象外事項、権限、標準、既存のアセット、プラットフォーム、公開の意向を記録します。
3. 先行事例の調査を完了するか、該当しない理由またはエビデンス不足を記録します。
4. サンプルに基づくコアの変更について、一般化ゲートを通過します。
5. 要件を満たす最も軽量なモードを選択します。
6. 早い段階で description を記述します（: を含む場合は、引用符で囲むか description: | を使用します。例：Excludes:）。構成を拡張する前に evals/trigger_cases.json を実行します。
7. 必要性が認められたリソースのみを作成します。形式だけのディレクトリや、README／SKILL の文章の重複は決して作成しません。
8. Production+、公開用、またはクロスプラットフォームのパッケージでは、reports/skill-ir.json をエクスポートします。
9. トリガーテストだけでは正確性、安全性、説得力、再現性を示せない場合は、出力評価を追加します。
10. 変更はリクエストされた操作の境界内にとどめ、リスクのある変更ではロールバック手段を維持します。
11. パッケージ、ユニットテスト、トリガー動作、コンテキスト予算、シークレット／信頼の境界、エビデンスに基づく主張を検証します。
12. 作成時の引き継ぎ資料を作成し、不足しているエビデンスを明確に示します。
13. 公開がリクエストされた場合は、自己完結型スキルの公開を読み、同梱のパブリッシャーを使用して、フィーチャーブランチ → 検証 → PR → マージ → リリース／インストールの検証を行います。デフォルトブランチへ直接プッシュしてはいけません。

コアコマンド：

python3 scripts/validate_skill.py .
python3 scripts/export_skill_ir.py . --output reports/skill-ir.json
python3 scripts/trigger_eval.py . --cases evals/trigger_cases.json --output reports/trigger-eval.json
python3 scripts/release_check.py . --phase local --run-tests
python3 scripts/publish_skill.py /path/to/skill --dry-run

ゲートの段階

• Scaffold：有効なフロントマター、有用な README フック、自然なトリガー、明示的な対象外事項。
• Production：Scaffold に加え、インターフェース、トリガー評価、出力契約、トラブルシューティング、ルートの分離、インストールの検証。
• Library：Production に加え、Skill IR、移植性、信頼性、レビュー頻度、エビデンスの成果物。
• Governed：Library に加え、権限／ロールバックの境界、シークレットスキャン、出力エビデンスまたは完全性を保持した人間によるエビデンス、公開する主張のガード。

テレメトリー、プロバイダーの実行、承認、インストールの証明、または人間によるレビューが利用できない場合は、missing evidence のままにする必要があります。計画した作業は証明にはなりません。レビューとリリースのゲートおよびリソース境界の仕様を参照してください。

出力契約

パッケージを作成するリクエストでは、選択したモードで必要性が認められたものだけを提供します。

1. 動作するスキルディレクトリと、トリガーを考慮したルート SKILL.md
2. 整合性の取れた agents/interface.yaml
3. 共有／公開スキル向けのユーザー用 README
4. Production+ 向けのトリガーケースと生成されたトリガーレポート
5. Production+ 向けの Skill IR、先行事例レポート、作成時の引き継ぎ資料
6. 判断力、再現性、またはエビデンスを高める場合の、任意の参考資料、スクリプト、出力評価、レポート、マニフェスト
7. 公開がリクエストされた場合に限り、公開用の成果物

作成時の最終引き継ぎ資料には、調査した参考スキルを明記し、対象候補に固有の学びを示し、意図的に採用しなかったものと独自の貢献を説明し、各特長を 設計上の利点、検証済みの利点、または 仮説として明示する必要があります。公平な比較なしに、全般的な優位性を主張してはいけません。作成時の引き継ぎ資料を使用してください。

公開フロー

1. README を製品ページとして扱います。価値、インストール方法、自然な使用例、前提条件、出力、設定、リスク、トラブルシューティングを記載します。
2. 必要に応じて、変更を加えずに監査します。python3 scripts/publish_skill.py /path/to/skill --dry-run
3. 明示的な公開依頼を受けた後にのみ、python3 scripts/publish_skill.py /path/to/skill を実行します。
4. 同梱のパブリッシャーは、MIT LICENSE、README、Qiaomu プロファイルのアセットを準備し、スキルとリポジトリの識別情報を解決して、秘密情報や再利用されたリリースバージョンをブロックします。また、GitHub リポジトリを作成または再利用し、フィーチャーブランチと PR のみを通じて公開します。
5. 競合、チェックの失敗または保留、変更依頼がある場合、マージはブロックされます。公開が成功すると、vX.Y.Z を作成し、npx skills add --list を検証して、分離環境へのインストールを行い、公開リリースのゲートを実行します。
6. リモートのデフォルトバージョン、GitHub Release、ディスカバリー、クリーンインストールを検証するまで、公開が完了したと報告してはいけません。

CLI の詳細と安全性に関する判断については、自己完結型スキルの公開を参照してください。README の手法については、GitHub README プレイブックを参照してください。運用の手法については、SkillOps ループを参照してください。

Qiaomu のデフォルト

• 実用的で簡潔な、公開可能な中国語の出力を優先します。
• 作成者の権限元とルートのスキルエントリーポイントは、それぞれ 1 つに保ちます。
• プラットフォームに依存しないソースと最小限のアダプターを維持します。
• 公開する主張は、実際に存在するトリガー、出力、ランタイム、インストール方法、または人間による証拠に合致させます。
• スキルが生成し、人が目にするもの（インストーラーページ、ダイアログ、生成ドキュメントなど）は、検証済みとする前にレンダリングして確認します。構造や署名のチェックだけでは不十分です。
• スキルが美的な選択（テキストスタイル、色、モーション、レイアウトなど）を定める場合は、実際の対象コンテンツを実際のレンダラーで使い、抑制した方向性を少なくとも 3 つ試作して並べて比較してから、採用案を実装します。「デザインされた」ように見せるためにエフェクトを重ねてはいけません。時間のかかるゲートや外部ゲート（公証、レビューチューなど）は、高速なローカルチェックに合格してから実行します。
• 上流のアイデアは、出典を明記したうえで意味を取り入れ、丸ごと模倣してはいけません。まずライセンスを確認し、コピーレフト（GPL）コードをパーミッシブライセンスのパッケージにコピーしてはいけません。
• スキルが記録するマシン固有の情報（キーチェーンのプロファイル名、ローカルパス、インストール済みツールなど）は、その保存場所と再作成方法を記載します。秘密情報やパスワードをスキルに書き込んではいけません。
• 実際のプロジェクトから得た教訓は、新しいスキルではなく、既存スキルの該当するリファレンスに追加します。
• ビジュアル出力スキルは、装飾ではなく構造によって多様性を生み出す必要があります。ユニットごとの視覚的メタファー、複数のレイアウトトポロジー、物語の文法軸として定義されたスタイル、実際の失敗出力をシードにした実行可能なチェックを用意してください。スキルエンジニアリング手法の項目 20 を参照してください。
• 長時間実行され、出力を生成するスキルでは、所要時間の見積もりを含むサイズ区分を宣言し、段階別のサンプルを用意して、ゼロに到達する必要があるチェックでゲートを設けます。スキルエンジニアリング手法の項目 17〜19 を参照してください。

リファレンスマップ

• 設計：スキルエンジニアリング手法、スキルの類型、意図の対話、スキル以外の判断ツリー
• エビデンス：評価プレイブック、出力評価、スキル IR、ガバナンス
• リリース：自己完結型の公開、レビューとリリースのゲート、GitHub README、SkillOps