mcpField
L
learn-anything

learn-anything

github.com/light-chengエージェントワークフロー526 回インストール4 日前に更新
リポジトリ

learn-anything について

learn-anythingは、資料に再利用可能な手法が含まれるかを評価し、証拠がそろった場合に限って移植可能なエージェントスキルを作成する、ユーザー起動型のスキルです。厳格な資料充足性の判定を設け、不足があれば具体的な欠落項目や学習要約を返し、一般的な指示で補いません。

主な機能

  1. 01資料から再利用可能な手法を評価
  2. 02証拠不足や矛盾があれば作成を停止
  3. 03完全な契約に基づくスキル生成
  4. 04根拠のある運用詳細を保持
  5. 05生成パッケージの導入と検証

活用シーン

  1. 01メモに再利用可能な手順があるか評価
  2. 02記録された手法をスキル化
  3. 03作成前に不足する証拠を特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/light-cheng/skills --skill learn-anything

インストール後、Claude Code で/learn-anythingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
hooks/
config.example.json
learn_gate.py
package_builder.py
session_reflector.py
skill_candidate_builder.py

詳細

あらゆることを学ぶ

これはユーザーが呼び出すスキルです。永続的なパッケージの作成や更新には、ユーザー自身による明示的な選択が必要です。ユーザーに代わって、別のユーザーが呼び出すスキルを実行してはいけません。

目的

任意のソース資料に、コンパクトで再利用可能なエージェントの手法が含まれているかどうかを学ぶために、このスキルを使用します。起きたことの受動的な要約ではなく、繰り返し実行できる運用手法を抽出します。

ソースが十分である場合の分岐では、証拠がそろっている場合に限り、内部 Method Contractを生成します。今後も繰り返し発生する可能性の高いトリガー、判断、コマンド、制約、失敗モード、検証ゲート、出力仕様を保持する必要があります。不完全な資料から汎用的な既定値を使って、本番環境で使用できるSKILL.mdを作り上げてはいけません。

対応エージェント

生成するスキルは、単一のランタイムだけでなく、一般的なAIエージェントホストにも適応できるように記述します。想定される利用者は次のとおりです。

  • OpenAI CodexおよびCodexスタイルのローカルコーディングエージェント
  • Claude Code
  • Gemini CLI
  • Cursorエージェント
  • Windsurfエージェント
  • GitHub Copilotコーディングエージェント
  • Aider
  • OpenCode
  • Roo Code
  • Continue
  • CrewAIエージェント
  • LangGraphエージェント
  • AutoGenエージェント
  • ReActスタイルのカスタムエージェント
  • Markdownの指示に従い、同梱されたスクリプトを実行できるその他のファイル読み取り型コーディング、調査、文書作成、自動化エージェント

ソースの取り込み

再利用可能な手法の推測に必要なソースだけを収集します。

  • ユーザーの依頼または目標の説明
  • 会話の記録、タスクのメモ、課題スレッド、README、フォルダーツリー、テスト出力、ワークフロー文書
  • ユーザーからの修正。特に、繰り返される「Xをしてはいけない。Yをすること」という指示
  • 将来のエージェントが認識する必要のあるコマンド、パス、ファイル名、API、スキーマ、正確なエラーメッセージ
  • 新しいスキルが準拠する必要のある既存のスキルまたはプロジェクトルール

ソース資料が乏しい場合は、不足している手法のフィールドを正確に示してBLOCKEDを返します。見出しがあっても、TBD、TODO、N/A、unknown、空のプレースホルダー、汎用テンプレートの定型文、<placeholder>のようなインラインのリテラルマークアップ、TBD - decide laterのような埋め込まれた未解決マーカーは、証拠が不足しているものとして扱います。Purpose、Triggers、Inputs、Ordered Method、Decisions、Outputs、Verificationのいずれかに単独で記載されたTBDまたはTODOも、未解決の証拠です。ただし、ガードレールとしてTBD値を残さないよう指示しているだけのConstraintsまたはFailure Modesは、不足している証拠として扱ってはいけません。未解決マーカーが付いたリソースの記述はソースの不足として扱います。リソースを明示的にnoneとすることは認められます。呼び出しの証拠にユーザー呼び出しとモデル呼び出しの両方が記載されている場合は、いずれかを選ぶのではなく、呼び出し方式の矛盾としてBLOCKEDを返します。説明的な記述、単発のタスク、または受動的な要約である場合は、not_promotedと明示した学習の要約を返します。ソースの証拠が十分でない限り、パッケージを作成してはいけません。

判断ワークフロー

  1. 情報源が再利用可能なワークフロー、ナレーション、受動的な要約、単発タスク、または評価するには情報が少なすぎるもののいずれに該当するかを特定します。単発タスクまたは受動的な要約と分類する際は、肯定的なタイトル、冒頭の文脈、目的、トリガー、または範囲/コンテキストが限定されていることを示す根拠を使用します。一般的な失敗モードの記述を調べて分類を変えないでください。また、項目に not merely a one-off、no longer a one-off と記載されていることや、失敗モードにのみ no procedure と記録されていることを理由に、完全な手法を格下げしないでください。
  2. 長期的に有効な手順と、その場限りのタスク詳細を分けます。今後の動作を変える情報を残し、信頼できる資料にある正確な運用上の詳細を保持します。
  3. 目的、トリガーの分岐、明示的な呼び出しタイプ、入力、順序立てた手法、判断、制約、失敗モード、出力、リソース、検証を抽出します。
  4. 修正と失敗モードを、情報源に裏付けられた制約、安全策、または検証チェックに変換します。コマンド、パス、判断、エラーを言い換えて失わないでください。
  5. 必須の手法フィールドすべてに根拠がある場合に限り、内部 Method Contract を作成します。この契約には、確信度と未解決の不足情報を記録します。
  6. 根拠が不十分な場合は、昇格させない学習要約、または必要な情報源の不足を具体的に示す BLOCKED のいずれかを返します。不足しているフィールドを、一般的なワークフロー、制約、品質チェックで補わないでください。
  7. 完全な内部 Method Contract が作成された後に限り、統合 Package Build Layer でパッケージを検討できます。Method Contract は、単独でインストールできる Skill ではありません。

パッケージビルドの前提条件

生の情報源からパッケージビルドに進まないでください。完全な内部 Method Contract が前提条件です。情報源の十分性を判定するゲート自体は、SKILL.md を出力しません。

パッケージビルド

ゲートが outcome: method_contract を返した後、その JSON の結果を統合パッケージビルダーに渡します。ビルダーは決定論的に動作し、Method Contract は内部に保持されます。

python learn-anything/hooks/package_builder.py \
  --contract-file <method-contract-result.json> \
  --output-root <skill-collection-root> \
  [--resource-root <source-resource-root>]

--name が指定されていない場合、ビルダーは契約のタイトルからケバブケースの名前を導き出します。情報源に裏付けられた目的、トリガーの分岐、呼び出しタイプ、入力、順序立てた手法、判断、制約、失敗モード、出力、リソース、保持された根拠、検証を記述した、直接的な指示形式の SKILL.md を生成します。順序立てられた各ステップには、確認可能な完了条件が設定されます。実行時に writing-great-skills をインポート、コピー、または必要とすることはありません。

ビルダーの結果を明示的な状態として扱います。

  • created は、新しいパッケージが作成されたことを意味します。
  • updated は、--update が指定され、無関係なファイルを保持したまま、生成されたパッケージの指示だけが変更されたことを意味します。ビルダーはコピーしたリソースを .learn-anything-managed.json で追跡し、以前に生成された契約が所有していたものの、新しい契約には含まれないリソースのみを削除します。
  • no-op は、同じ契約によってすでにパッケージが生成されていることを意味します。そのパッケージを保持してください。
  • duplicate は、所有されていないパッケージ、または異なるインストールがすでに存在することを意味します。明示的な更新権限を得るまで停止してください。
  • blocked は、契約が不完全、未解決、矛盾している、またはパッケージの範囲外であることを意味します。具体的な理由を返し、書き込みは行わないでください。

生成済みのパッケージからのみ、クリーンなホストディレクトリにインストールしてください。ビルダーの install_package() 境界を使用するか、ホストが文書化しているインストーラーでパッケージディレクトリ全体をコピーし、その後、SKILL.md、宣言されたメタデータ、正当性が確認されたすべてのリソースが存在することを検証してください。同一パッケージを再度インストールした場合は、何も変更されない必要があります。ユーザーが更新を明示的に許可しない限り、既存の別のパッケージは重複として扱います。

内部作成ルール

パッケージを作成する際は、以下のルールを適用してください。これらは内部向けのガイダンスであり、別の Skill に対する実行時依存関係ではありません。

  • すべてのトリガー分岐に必要な最小限の順序付き手順を SKILL.md に記載してください。分岐固有の参考資料は、その分岐で必要な場合にのみ明示してください。
  • 説明には、パッケージの機能と使用すべき状況を記載してください。各判断の信頼できる情報源は一つにし、重複した文章や何もしない文章は削除してください。
  • 承認済みのソースにある正確なコマンド、パス、修正内容、失敗条件を保持してください。欠けているフィールドを一般的な見出しやデフォルト値で補わないでください。
  • リソースは、契約で明示され、その必要性が正当化されている場合にのみ含めてください。空のディレクトリ、プレースホルダーファイル、未検証のスクリプトのコピーを作成しないでください。相対リソースは、存在確認と包含確認を行ったうえで、明示的に指定された --resource-root からのみコピーしてください。絶対パスは外部の前提条件として記載したままにしてください。
  • 宣言された呼び出し境界を明確にしてください。ユーザーが呼び出す別の Skill を推奨し、代わりに暗黙的に実行せず、そこで停止してください。

生成される Skill の形式

生成するすべての Skill には、以下を含める必要があります。

  • name と description のみを含む YAML フロントマター付きの SKILL.md
  • 64 文字未満の kebab-case のフォルダー名と Skill 名
  • Skill の機能と、エージェントが使用すべき状況の両方を記載した説明
  • 直接的な操作指示で書かれた本文
  • 目的、トリガー、入力、ワークフロー、制約、出力形式、品質チェックを網羅するセクションまたは同等の内容
  • 直接役立つ場合に限り、バンドルされたリソース

ソースが明らかに別の簡潔な形式を示している場合を除き、本文には以下の構成を推奨します。

# Skill Title

## Purpose

State what repeatable work the skill enables.

## Inputs

List source artifacts, credentials, paths, or context needed before acting.

## Workflow

Give the minimum ordered procedure that a future agent should follow.

## Constraints

Capture user preferences, scope boundaries, failure modes, safety rules, and exact decisions.

## Output Format

Describe the artifact, summary, patch, command output, or decision the skill should produce.

## Quality Checks

List concrete verification gates before final response.

抽出ルール

  • 運用上の意味を持つ場合は、正確なコマンド、ファイル名、見出し、API、エラー文字列、ユーザーによる修正を保持してください。
  • 説明文よりも、命令形のワークフロー手順を優先してください。
  • 例は短く、具体的にしてください。
  • トリガーの判定材料、パスの規則、または例として必要な場合を除き、プロジェクト固有の名前を含めないでください。
  • 一度限りの回答、翻訳、天気の検索、時刻の確認を Skill にしないでください。
  • 広範な記憶の要約を作成しないでください。次回以降に行動をどう変えるかを記述してください。
  • 未解決の手法フィールドをスタブのセクションにしないでください。ソースの不足を返してください。
  • 使用していないリソースフォルダーを含めないでください。

フックスクリプト

オプションの決定論的なヘルパーは hooks/ に配置します。

  • learn_gate.py:タスクの前にリクエストを分類し、normal_task、observe_and_summarize、create_or_update_skill のいずれかを返します。
  • session_reflector.py:完了したトランスクリプトを調べ、再利用可能な学びを見つけて、ignore、summarize_candidate、create_skill のいずれかを返します。
  • skill_candidate_builder.py:ソースの十分性を評価し、内部向けの Method Contract、Skill 化しない学習の要約、または BLOCKED のソース不足を返します。

標準入力から生テキストまたは JSON オブジェクトを渡して実行します。JSON を出力するため、他のエージェントは文章を解析せずに判断を利用できます。

品質チェック

生成または更新した Skill を提出する前に、以下を確認してください。

  • ソースの十分性の判定結果が learning_summary や blocked ではなく、method_contract であること。
  • Method Contract に、目的、トリガー、呼び出しタイプ、入力、順序付きの手法、判断、制約、失敗モード、出力、リソース、検証、未解決の不足情報、確信度が含まれていること。
  • ソースが提供されている場合、正確なコマンド、パス、判断、修正内容、失敗モードが、ソースの根拠として引き続き表現されていること。
  • SKILL.md のフロントマターが有効で、name と description のみを含んでいること。
  • 説明に具体的なトリガー条件が含まれていること。
  • 本文がセッションを要約するのではなく、繰り返し実行できる操作手法を教えていること。
  • 制約に、ユーザーによる修正と既知の失敗モードが反映されていること。
  • 出力形式と品質チェックが実行可能であること。
  • Skill フォルダーがある場合は、Skill Creator の検証を実行すること。

コメント