mcpField
A
article-prompts-to-skills

article-prompts-to-skills

github.com/akillnessエージェントワークフロー5357 回インストール今日更新
リポジトリ

article-prompts-to-skills について

article-prompts-to-skills は、記事やチュートリアル、プロンプト集を再利用可能な AgentSkills に変換するエージェントスキルです。独立した機能を抽出し、動作するデモで各パッケージを検証します。

主な機能

  1. 01プロンプトから再利用可能な機能を抽出
  2. 02独立した AgentSkills フォルダーを作成
  3. 03各スキルに3種類の例プロンプトを用意
  4. 04自己完結型のデモとプレビューを構築
  5. 05パッケージとブラウザー動作を検証
  6. 06スキル作業にコミット範囲を限定

活用シーン

  1. 01チュートリアルのプロンプトを再利用可能なスキルに変換
  2. 02プロンプト集から独立した動作を分離
  3. 03新しいスキルを検証するデモを作成
  4. 04スキルファイルとレスポンシブデモを検証

インストール

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

$npx skills add https://github.com/akillness/jeo-skills --skill article-prompts-to-skills

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

同梱ファイル

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

SKILL.toon
agents/
openai.yaml
references/
example-packages.md

詳細

記事のプロンプトをスキルに変換する

元のプロンプトを、小さく実証可能な機能パッケージに変換します。元ページのブランドやレイアウトではなく、有用な動作を維持してください。

このスキルを使用する場面

  • 記事、チュートリアル、プロンプト集のプロンプトを、スキルごとに独立した機能を持つスタンドアロンの AgentSkills フォルダー（SKILL.md、agents/openai.yaml、demo/）に変換する場合。
  • 元のブランド、レイアウト、ハードコードされたアセットを取り除きながら、移植可能な仕様（動作、データモデル、タイミング／アクセシビリティのルール、受け入れ確認）を抽出する場合。
  • それぞれの新しいスキルについて、3つのサンプルプロンプト（最小限、デモの再現、リミックス）を作成し、プレビュー用スクリーンショットを含む、動作を確認できるデモを構築する場合。
  • quick_validate.py、複数サイズでのブラウザチェック、および新しいスキルの作業だけに範囲を絞ったコミットで、完成したパッケージを検証する場合。
  • プロンプトがまだ抽出されていない生の HTML ソースには使用しないでください。まず $html-to-interaction-prompts を実行してください。また、記事の内容を再利用可能な AgentSkills にパッケージ化する作業以外には使用しないでください。

1. 抽出前に確認する

  1. リポジトリの指示と元記事の全体を読みます。
  2. git status --short を実行し、無関係な作業を保持します。
  3. 明示されているプロンプト、見出し、例、アセット、受け入れ基準をすべて一覧にします。
  4. フォルダーを作成する前に、既存の SKILL.md ファイルを検索し、機能の重複を確認します。
  5. ソースが生の HTML で、プロンプトがまだ存在しない場合は、まず $html-to-interaction-prompts を使用してから、ここに戻ります。

タイトルだけからスキルの分類を推測しないでください。提案する各スキルを、ソース内の根拠に結び付けます。

2. 抽出台帳を作成する

ファイルを編集する前に、作業用の表を作成します。

ソースのプロンプト再利用可能な機能維持するもの削除するものスキル名デモでの実証

次の基準を適用します。

  • 個別に再利用できる動作ごとに、スキルを1つ作成します。
  • 手順を分けるとどちらかが使えなくなる場合にのみ、手順をまとめます。
  • 既存のスキルの仕様がその機能をすでに網羅している場合は、そのスキルを更新します。
  • 繰り返し可能な手法を生み出さない装飾的または編集的な断片は省きます。
  • スキル名には、元記事ではなく、成果または仕組みを使用します。

3. 移植可能な仕様を抽出する

ソースの有効な仕組みを維持します。

  • 動作と状態遷移。
  • データモデルとパラメーターのデフォルト値。
  • タイミング、イージング、間隔、レスポンシブのルール。
  • アクセシビリティ、モーション低減、キーボード操作の動作。
  • パフォーマンスの制約と障害モード。
  • 成果を実証する受け入れ確認。

ソース固有の構成要素は削除します。

  • ブランド名、マーケティング文、独自コンテンツ。
  • 機能に関係しないページレイアウト。
  • ハードコードされた配色、アセット、セレクター。
  • 成果に影響しない、付随的な実装上の選択。

成果は、指示の中核を書き直さずに、別の題材、レイアウト、ビジュアルシステムに適用できるものでなければなりません。

4. すべてのスキルをパッケージ化する

新しいフォルダーはすべて、インストール済みの skill-creator イニシャライザーで初期化してから、次の仕様を満たします。

agent-skills/<category>/<skill-name>/
  SKILL.md
  agents/openai.yaml
  references/          # only when detailed reusable guidance is needed
  assets/ or scripts/  # only when the workflow genuinely reuses them
  demo/
    index.html
    PROMPT.md
    preview.jpg
    input.md            # required for workflow skills
    expected-output.md  # required for workflow skills

SKILL.md は命令形で記述します。フロントマターには name と description だけを記載します。すべてのトリガーフレーズは説明に含めます。運用手順、制約、落とし穴、検証コマンドは本文に記載します。

最終的なスキルに基づいて agents/openai.yaml を作成します。

  • 人が読みやすい表示名を使用します。
  • 短い説明は25〜64文字にします。
  • デフォルトのプロンプトで $skill-name を明示的に呼び出します。

5. 役立つサンプルプロンプトを3つ作成する

demo/PROMPT.md に次の見出しを記載します。

最小限のプロンプト

スキルを呼び出し、明確な成果を1つ求めます。

Use $skill-name to add <capability> to <target>.
デモの再現

参照する体験、実装仕様、納品物、受け入れ確認について説明します。ローカルで完結し、自己完結した状態にすべき要素を指定します。

プロンプトのリミックス

仕組み、アクセシビリティの動作、レスポンシブ対応のルール、パフォーマンス要件を維持しながら、題材、コンテンツ、配色、構成を変更してください。

ビジュアル、複数ソース、ワークフローの例については、references/example-packages.mdを参照してください。

6. 装飾ではなく、確かな証拠を作る

すべてのデモを独自のものとして、自己完結型で、検証可能にしてください。

  • 最初の画面で中核となる仕組みを実演する；
  • 「デモカード」のようなラベルではなく、現実的なコンテンツを使う；
  • 意味のある状態を示す場合に限り、コントロールを追加する；
  • 390pxから1440pxまでのレイアウトに対応する；
  • セマンティック HTML と視認できるフォーカス状態を使う；
  • アニメーションを使う場合は、視差効果を減らす設定に対応する；
  • 依存関係はローカルに保ち、そのスキルで必要とされない限り、ビルド手順を設けない；
  • 視覚を伴わないワークフローには、input.mdとexpected-output.mdを使う。

スクリーンショットを実装として扱わないでください。HTML デモが動作する必要があります。

7. パッケージ全体を検証する

成果物に応じて検証を実施してください。

  1. 新規または変更したすべてのスキルに対して、スキル作成者のquick_validate.pyを実行する。
  2. リポジトリのデモ検証と、対象を絞った構文チェックを実行する。
  3. 許可されたブラウザーで、各デモをデスクトップとモバイルの画面サイズで開く。
  4. 主要なインタラクション、キーボードフォーカス、視差効果を減らす設定での動作を確認する。
  5. コンソールにエラーがないことを確認する。
  6. リポジトリで共通のサイズを使って、実際のブラウザーのプレビューを撮影する。
  7. デモとスクリーンショットギャラリーを再構築し、再度検証する。
  8. 変更したファイルに秘密情報、トークン、プライベートなパス、非公開のクライアントデータがないか確認する。

静的なファイルの確認だけで、見た目やインタラクションを検証したと主張しないでください。

8. タスクに関係するものだけをコミットする

新しいスキルのフォルダーと、それらに必要なギャラリーファイルをステージングしてください。コミット前にgit diff --cached --statとgit diff --cachedを確認してください。既存の未コミットファイルには手を加えないでください。

以下を報告してください。

  • ソースからスキルへの対応関係；
  • 例のプロンプトとデモのパス；
  • 検証とブラウザーでの確認内容；
  • コミットハッシュ；
  • コミットに含めない、無関係な未コミットファイル。

よくある失敗

  • **ページの複製：**仕組みを抽出せず、元のレイアウトをコピーする。
  • **巨大なスキル：**独立したプロンプトを、曖昧な1つのスキルにまとめる。
  • **細切れの断片：**再利用可能な動作を考慮せず、すべての文をスキルにする。
  • **テーマの固定：**元の配色、アセット、コピーをハードコードする。
  • **プロンプトだけのパッケージ：**動作するデモとプレビューを省略する。
  • **偽の検証：**実際に操作せず、インタラクションを確認したと主張する。
  • **ダーティーツリーの混入：**無関係な変更や生成ファイルをステージングする。

参考資料

コメント

Markdown 対応