著者注：この記事では、プログラミング初心者の方に向けて、mattpocock/skillsの2つの主要なスキルを実際に使いながら紹介します。まず /grill-me で要件を明確にし、次に /tdd でコードを書きます。各ステップには、完了を確認するための基準も示します。
一言でまとめると、まず /grill-me でAgentに要件をしっかり確認してもらい、次に /tdd でテストを1つずつ書きながら実装を進めます。
2026年10月22日（北京時間）時点で、GitHubのmattpocock/skillsは約30万スターを獲得しており、MITライセンスで公開されています。最新バージョンはv1.3.1です。スター数は注目度の高さを示すものですが、あなたのプロジェクトで必ず役立つとは限りません。そこでこの記事では、導入方法、使い方、正常に動作しているかの確認方法に絞って紹介します。効果を大げさにアピールすることはありません。
画面をクリックして入力するだけで進められる、実践ガイドです。「注文フローにクーポンの検証を追加する」という小さな要件を題材に、インストールから最初のテストが成功するまで進めていきます。
- 目標：スキルをインストールし、
/grill-meで要件を一通り確認したあと、/tddで最初の「失敗→成功」テストを書く - 所要時間：インストールは数分（作者によると「30秒で完了」）。要件の確認やテスト作成にかかる時間は、回答の速さによって変わります。以下は編集部の見積もりで、全体で約30分〜1時間です
- 前提条件：Claude Code、Codex、GitHub Copilot、Gemini CLI、Cursorなど、いずれかのプログラミングAgentをすでに使っていること。気軽に試せるコードリポジトリがあること
- 難易度：入門。基本的には画面とチャットで操作します。ターミナルコマンドは任意の手順として紹介します
mattpocock/skills の要点：grill-me と tdd の役割
mattpocock/skills は、Matt Pocock が公開している Agent 向けスキル集です。リポジトリの説明は「Skills for Real Engineers」。README では、これらのスキルは小さく、組み合わせやすく、あらゆるモデルに適応できるうえ、「数十年にわたるエンジニアリングの経験に基づいている」と紹介されています。
| 要点 | 説明 | 価値 |
|---|---|---|
| /grill-me | 1問ずつ質問し、各質問に推奨回答を添える。ファイルは一切書き換えず、手動で入力したときだけ起動する | 作業を始める前に Agent と要件をすり合わせ、自分では気づいていなかった判断事項を洗い出せる |
| /tdd | まずテスト境界（seam）を提示して確認を待ち、その後「レッド→グリーン」で進める。テストは1つずつ作成する | 各ステップでフィードバックを得られ、リファクタリングにも耐えられるテストになる |
| /setup-matt-pocock-skills | リポジトリごとに1回実行し、issue tracker、トリアージ用ラベル、ドキュメントの保存先を設定する | エンジニアリング系スキルが、どこに情報を書き込めばよいか把握できる |
| インストール方法 | プラグイン（自動更新）と skills.sh（ファイルを編集可能）から選ぶ | 両方をインストールすると、各スキルが2つずつ表示される |
grill-me と tdd を続けて使う理由
README では、よくある失敗パターンがいくつか挙げられています。そのうち2つは、この2つのスキルにぴったり対応しています。1つ目は「Agent が期待どおりに作業しない」こと。その原因は、あなたと Agent の間に認識のずれがあることです。対策として、Agent にこちらの要望を詳しく質問させる「grilling」を行います。/grill-me の本体は、実は「grilling スキルを呼び出す」という一文だけです。具体的な質問のルールは、grilling 側に書かれています。
もう1つは「コードが動かない」ことです。要件が合意できていても、Agent がコードの実行結果を確認できなければ、手探りで進めることになります。/tdd では、まず失敗するテストを書き、それを通すために必要最低限のコードを追加します。こうすることで、Agent は各ステップで安定したフィードバックを得られます。この2つを続けて使えば、前者で「何を作るか」を明確にし、後者で「正しくできているか」を確かめられます。
mattpocock/skills をインストールして grill-me と tdd を動かす：5ステップで始める
第 1 ステップ：mattpocock/skills をインストールする（GUIを優先）
公式には、Claude Code、Codex、GitHub Copilot、Gemini CLI 向けのインストール方法が案内されています。それ以外のエージェントでは skills.sh を使います。README には、これらのスキルはあらゆるモデルで利用できると明記されています。また、公式によると、Auggie、Droid、Goose などではまだ動作確認が行われていないため、現時点では skills.sh の利用が推奨されています。
| 利用するエージェント | 推奨されるインストール方法 | 自動更新 |
|---|---|---|
| GitHub Copilot（VS Code） | コマンドパレットを開き、Chat: Install Plugin From Source を実行して、https://github.com/mattpocock/skills を入力 |
あり、毎日更新 |
| Claude Code | 公式プラグインマーケットプレイス claude-plugins-official から mattpocock-skills をインストール |
あり、デフォルトで有効 |
| Codex | まず mattpocock/skills のプラグインマーケットプレイスを追加し、その後プラグインをインストール |
あり、起動時に更新 |
| Copilot CLI | mattpocock のプラグインマーケットプレイスからインストール |
autoUpdate: true を一度設定すれば自動更新 |
| Gemini CLI | engineering と productivity の2つのディレクトリを個別にインストール | なし、コマンドを再実行する必要あり |
| Cursor、OpenCode、Windsurf、Devin、Amp、Pi など | skills.sh | なし、手動で更新 |
VS Code ユーザーなら、最も簡単にインストールできます。Ctrl+Shift+P（macOS の場合は Cmd+Shift+P）を押してコマンドパレットを開き、Chat: Install Plugin From Source と入力します。Enter キーを押したら、リポジトリの URL を貼り付けてください。ターミナルを使いたい場合は、以下の公式インストールコマンドをそのまま実行できます。
- Claude Code：
claude plugin install mattpocock-skills@claude-plugins-officialを実行します。デフォルトで自動更新されます。 - Codex：まず
codex plugin marketplace add mattpocock/skillsを実行し、続けてcodex plugin add mattpocock-skills@mattpocockを実行します。起動のたびに自動更新されます。 - GitHub Copilot CLI：まず
copilot plugin marketplace add mattpocock/skillsを実行し、続けてcopilot plugin install mattpocock-skills@mattpocockを実行します。 - Gemini CLI：
gemini skills install https://github.com/mattpocock/skills.git --path skills/engineeringとgemini skills install https://github.com/mattpocock/skills.git --path skills/productivityをそれぞれ実行します。自動更新には対応していないため、更新する場合はこの2つのコマンドを再実行してください。 - その他のエージェント（skills.sh）：
npx skills@latest add mattpocock/skills -a cursorを実行します。cursorは、利用するエージェントに応じてopencode、devin、windsurf、amp、piなどに置き換えてください。-aを付けなければ、エージェントを自分で選択できます。更新するにはnpx skills@latest updateを実行し、新しいスキルが追加された場合はaddをもう一度実行してください。 - 特定のスキルだけをインストールする場合：
npx skills@latest add mattpocock/skills --skill=<name>を実行し、<name>をスキル名に置き換えてください。
Copilot CLI では、~/.copilot/settings.json を一度開き、次の設定を追加する必要があります。{"extraKnownMarketplaces": {"mattpocock": {"source": {"source": "github", "repo": "mattpocock/skills"}, "autoUpdate": true}}}
この設定は、GitHub リポジトリ mattpocock/skills を提供元とする mattpocock のプラグインマーケットプレイスを登録し、自動更新を有効にするものです。公式の説明によると、この設定はドキュメントの形式に沿って記述されていますが、まだ実際に実行した人はいません。
プラグインと skills.sh は、どちらか一方を選んでください。プラグインは自動更新される読み取り専用パッケージですが、skills.sh は編集可能なファイルをプロジェクトにコピーします。両方をインストールすると、各スキルが2つずつ配置されてしまいます。skills.sh を使う場合、インストーラーがインストールするスキルを尋ねてきたら、setup-matt-pocock-skills にチェックを入れてください。
特定のスキルだけをインストールする場合は、依存関係にも注意が必要です。grill-me は grilling を呼び出すだけなので、grilling も一緒にインストールしてください。tdd は codebase-design に依存しており、そのインターフェース設計の用語を使って seam について話し合います。
ここまでできていれば成功です：エージェントのチャット欄で / を入力し、候補一覧に grill-me、tdd、setup-matt-pocock-skills が表示され、それぞれ1つずつだけ表示されていれば完了です。
ステップ 2：対話ボックスで /setup-matt-pocock-skills を実行する
このスキルセットをリポジトリで初めて使うときは、まず Agent の対話ボックスに /setup-matt-pocock-skills と入力します。すると、次の3つについて順番に質問されます。使用する issue tracker（GitHub、GitLab、ローカルファイル、または自分で説明する方法）、チケットのトリアージに使うラベル、生成したドキュメントの保存先です。
実際の状況に合わせて回答すれば大丈夫です。迷ったらローカルファイルを選んでおけば、あとから変更できます。厳密には、/grill-me はリポジトリに依存しないため、この設定は省略してもかまいません。ただし、/tdd などのエンジニアリング系スキルを使う場合は、先に設定しておくのがおすすめです。設定はリポジトリごとに1回だけ行えば十分です。
ここまでできれば完了です：3つの質問に答え終わり、Agent から設定が完了したと伝えられ、今後ドキュメントがどこに保存されるかを把握できていればOKです。
ステップ 3：grill-me と tdd で適切なモデルを選ぶ
公式ドキュメントでは、質問の段階は多くのスキルよりもモデルの性能に大きく左右されると説明されています。grilling では、「システムがどう壊れるか」に関するモデル自身の知識が頼りになります。そのため、利用できる中で最も高性能なモデルを使いましょう。一方、実装時は主にそれまでの文脈に沿って作業するため、比較的安価なモデルでも対応できます。
| 段階 | モデルに求められること | おすすめの使い方 |
|---|---|---|
| /grill-me での質問 | モデル自身のエンジニアリング知識に依存するため、高性能なほど的確な質問ができる | 手元で使える最も高性能なモデルを使う。たとえば Claude Opus 5.5 |
| /tdd での実装 | 主に、すでに構築された文脈に沿って作業する | より安価なモデルに切り替えてもよい |
| 接続方法 | Claude Code や Codex で、段階に応じてモデルを切り替える | APIYI apiyi.com の APIキー1つで複数のモデルに接続する |
Claude Code や Codex で共通のインターフェースを設定するには、次のようにします。
- Claude Code：まず、2つの環境変数を設定します。
ANTHROPIC_BASE_URLにhttps://api.apiyi.com（APIYI の共通インターフェース）を、ANTHROPIC_AUTH_TOKENに自分の APIキーを指定します。その後、claudeを実行して起動し、対話ボックスで/modelを使ってモデルを切り替えます。 - Codex：
~/.codex/config.tomlを開き、model = "<モデルID>"とmodel_provider = "apiyi"の2行を記述します。次に[model_providers.apiyi]セクションを追加し、その下にname = "APIYI"、base_url = "https://api.apiyi.com/v1"、env_key = "APIYI_API_KEY"の3行を記述します。モデルIDはコンソールに表示されているものを使ってください。
項目名はツールのバージョンによって変わる可能性があります。具体的な設定については、ツールの公式ドキュメントと docs.apiyi.com を確認してください。
🎯 モデル選びのヒント：質問の段階ではできるだけ高性能なモデルを使い、実装時により安価なモデルへ切り替えましょう。APIYI apiyi.com の APIキー1つで Claude Code や Codex のモデルを切り替えられるので便利です。ただし、APIYI が解決するのはモデル呼び出しの部分であり、grill-me や tdd といったスキルそのものを置き換えるものではありません。
ここまでできれば完了です：対話ボックスで現在のモデルを確認し（Claude Code では /model を使用）、質問の段階で選んだ高性能モデルが使われていることを確かめてください。
第 4 歩：「クーポンの検証」要件を /grill-me で明確にする
新しいセッションを開き、Agent がすでに計画を作成したセッションは使わないでください。また、plan mode もオフにします。plan mode では Agent が急いで計画を作ろうとしますが、このステップでは質問を繰り返してもらう必要があります。入力欄に /grill-me 注文フローにクーポンの検証を追加したい と入力して、Enter キーを押します。
grill-me は Agent が自動で呼び出すものではなく、入力したときだけ起動します。要件を「設計ツリー」に分解し、前提条件がすべて決まった質問を、各ラウンドでまとめて尋ねます。質問には番号と推奨回答が付いていて、「yes」と返すだけで推奨案を採用できるよう、意図的に表現が工夫されています。やり取りは、たとえば次のようになります。
❓ Q1 – クーポンの有効期限はいつの時点で判定するか：注文時、それとも決済完了時ですか？
➡️ 推奨：注文時です。決済中にクーポンが突然無効になるのを避けられます。❓ Q2 – 割引の適用条件となる購入金額に送料を含めるか？
➡️ 推奨：含めません。商品小計だけを対象にします。❓ Q3 – 1つの注文で使えるクーポンは最大何枚か？
➡️ 推奨：1枚です。
ここでよくある失敗は、すべての質問に「同意」と答えてしまうことです。それでは Agent が作った計画に承認印を押しただけで、自分では何も決めていません。よりよい返答は、たとえば次のように、選択や判断を交えることです。
Q1 は yes。Q2 は同意しません。うちのキャンペーンルールでは送料も含めます。Q3 はわかりません。運営に確認が必要なので、まずは1枚で進めてください。
次のラウンドでは、これらの回答を踏まえて「送料を含める場合、送料割引クーポンと定額割引クーポンを併用できるか」のような質問が出てきます。リポジトリ内の事実を調べる必要がある場合は、Agent が自分でサブ Agent に調査を依頼し、あなたに尋ねるべきではありません。公式ドキュメントによると、4ラウンドで合計40問以上になるのは珍しくありません。
次の状態になれば成功です：
– 質問がラウンドごとに提示され、各質問に番号と推奨回答が付いている。「yes」と答えれば推奨案を採用できる
– 後半の質問が、前の回答を明確に踏まえている
– 少なくとも一度は反対意見を伝えるか、「わからない」と真剣に答えている
– 最後に、双方の合意内容を確認するよう Agent が求める。確認するまでは作業を始めず、ファイルも一切変更しない
ステップ 5：/tdd を使い、テストを1つずつ書く
同じセッションを続けて使いましょう。そうすれば、ここまでに作ったコンテキストが残っています。必要なら、より低コストのモデルに切り替えてから、/tdd 先ほど確認したルールに従ってクーポン検証を実装してと入力します。
すぐにテストを書き始めるのではなく、まずテスト対象となるインターフェース境界（seam）の候補を示し、あなたの確認を待ちます。たとえば、候補 A の validateCoupon(coupon, order, now) は純粋関数で、ルールのロジックをテストできますが、注文処理との連携はテストできません。候補 B の注文サービス checkout() なら連携もテストできますが、実行に時間がかかります。候補の名前しか示されない場合は、それぞれの seam で何を検出でき、何を見落とすのかを確認してください。ここでは候補 A を選びます。
以下は、TypeScript と Vitest を使った最初のテストの例です。あくまで説明用で、このスキルは特定の言語やテストフレームワークに限定されません。
- テストファイル：
coupon.test.ts。vitestからitとexpectを、./couponからvalidateCouponをインポートします - テスト名：ユーザーは期限切れのクーポンを使用できない
- 渡すクーポン：
{ code: "SAVE10", minSubtotal: 100, expiresAt: new Date("2026-10-01") }。つまり、100元以上の購入で使え、10月1日に期限切れになります - 渡す注文：
{ subtotal: 120 }。小計は120元です - 現在時刻：
new Date("2026-10-22")。関数内で現在時刻を取得するのではなく、引数として渡します。こうすれば、いつ実行しても結果が変わりません - 期待する結果：
expect(result).toEqual({ ok: false, reason: "expired" })。つまり、検証に失敗し、その理由は期限切れです
まずテストを実行すると、validateCoupon がまだ存在しないため失敗します。次に Agent は、そのテストを通すために必要な最小限のコードだけを書きます。たとえば、now >= coupon.expiresAt なら期限切れとして返す処理です。テストが成功してから、次のテスト（たとえば「小計が条件に満たない場合は拒否する」）を書きます。期待値にはルールから導いた具体的な値を使い、テスト名には内部関数の呼び出しではなく、ユーザーができることを記述してください。
現在の tdd は「レッド→グリーン」のみで、リファクタリングの段階はありません。この段階は2026年6月に削除されました。Agent がほとんど実行しなかったためで、リファクタリングは /code-review に任されています。スキルの説明には今も red-green-refactor と書かれていますが、これは既知の問題です。それでも、この表現でスキルを呼び出せます。モックを使うのは、外部 API、時刻、乱数などのシステム境界に限り、自分のモジュールはモックしないでください。
次の状態になれば成功です：
– テストファイルを書く前に seam の候補を示し、確認を待つ
– 一度にテストを1つだけ書き、まず失敗させてから成功させ、その後に次のテストを書く。「先にテストをまとめて書き、その後にコードをまとめて書く」ことがない
– 内部関数の名前を変えても、テストが失敗しない
grill-me、tdd などのスキルを使うタイミングとトラブルシューティング一覧
つまずく原因は、使い方がわからないからではなく、使う場面を間違えているからということがよくあります。次の表を保存しておけば、状況に応じてスキルを選べます。
| 状況 | 使うスキル | 説明 |
|---|---|---|
| アイデアがまだ漠然としていて、コードに関係するとは限らない | /grill-me | リポジトリは不要で、ファイルも作成しません。ビジネス上の意思決定や文章作成にも使えます |
| リポジトリ内のコードを変更し、用語や意思決定を記録しておきたい | /grill-with-docs | 同じ質問の進め方で、GLOSSARY.md と ADR を更新します |
| 作業量が多く、1回のセッションでは終わらない | /wayfinder | issue tracker に意思決定のチケットマップを作成し、順番に解決します |
| 入力と出力が明確な動作を実装したい | /tdd | ビジネスロジック、リクエストとレスポンスの契約、データ変換、バリデーションに適しています |
| spec やチケットがすでにあり、一通り実行したい | /implement | 決められた seam に沿って /tdd を進め、コミット前に /code-review を実行します |
どのスキルを使えばよいか迷ったら、/ask-matt と入力してください。状況に合ったスキルを提案してくれます。実際に使っていて遭遇する問題の多くは、次の表で対処できます。
| 症状 | よくある原因 | 対処法 |
|---|---|---|
| 質問が多く、100問以上に及ぶ | 範囲が広すぎる、またはコンテキストがいっぱいになり、質問の質が下がっている | まず Agent に作業を小さく分割させてから、個別に grill する |
| すぐに終わり、自分はずっと「同意」としか言っていない | 回答が受け身すぎる | 積極的に反論し、範囲の逸脱を指摘し、わからないことは正直に「わからない」と伝える |
| 何度質問を書き換えても答えられない | 操作感など、「会話だけでは答えが出ない」問題である | 質問をいったん止め、/prototype で使い捨てのプロトタイプを作ってみる |
| テストの境界を決められない | 候補となる seam の名前を並べただけになっている | それぞれの seam で何を検出できるのか、何を見落とすのか、どのくらい遅くなるのかを確認する |
| テストを追加する前に実装を書いてしまう | モデルのデフォルトの振る舞い | 重要な切り出し部分は実行状況を見守り、気づいたら「まず失敗させる」段階に戻す |
| ブラウザテストが終わりなく繰り返される | 機能がまだ存在しないのに、先にエンドツーエンドテストを書いている | ブラウザテストは動作が通るようになってから書く、と CLAUDE.md に明記する |
| テストが実装をそのまま写しただけになっている | 設定や接着コードには、独立した正解となる比較対象がない | こうした変更には tdd を使わず、ルールを CLAUDE.md に記載する |
| 各スキルが2つずつ表示される | プラグインと skills.sh の両方からインストールしている | どちらか一方をアンインストールする |
mattpocock/skills よくある質問 FAQ
Q1：約30万スターなら、効果も確実に高いということですか？
いいえ。スター数が示すのは注目度であり、あなたのプロジェクトで実際に効果があるかどうかではありません。作者は数十年にわたるエンジニアリング経験をもとにしていると説明していますが、現時点では、効率向上を示す第三者の評価データはありません。最も確実なのは、この記事の各ステップにある受け入れ基準をもとに、自分のリポジトリで実際に試してみることです。
Q2：Claude CodeやCodexなどのツールでしか使えませんか？
いいえ。公式に挙げられているのは動作確認済みのインストール方法だけです。記載のないAgentでも、skills.shを使い、`-a`で指定するか、対話形式で選択すれば利用できます。READMEにも、これらのスキルはあらゆるモデルで使え、実体はMarkdownで書かれたスキルの説明だと記載されています。
Q3：grill-meで質問に答えたあと、別のセッションを開いてコードを書いたほうがいいですか？
いいえ。質問を通じて築かれたコンテキストこそ、最も価値のある情報です。公式では、同じセッションのまま続けて /to-spec に仕様を作成させることを推奨しています。この記事の簡単な例では、同じセッションでそのまま /tdd に引き継いでいます。
Q4：一度に質問される数が多いと感じます。1回に1つだけ質問するよう変更できますか？
できます。グローバルな `CLAUDE.md` に `When grilling, ask one question at a time.` と追記するだけです。ただし、質問をまとめて行うと、判断できる項目を一度にすべて確認できます。変更するかどうか決める前に、まずは何回か試してみるのがおすすめです。
Q5：tddの説明にはred-green-refactorとありますが、実際にはリファクタリングしないのはなぜですか？
リファクタリングの段階は2026年6月に意図的に削除されましたが、説明はまだ更新されていません。これは既知の未解決課題です。現在の流れは「レッド→グリーン」で、リファクタリングは /code-review に任せます。実装とレビューを別々のセッションで行うほうが、より効果的です。
Q6：質問の段階と実装の段階で、異なるモデルを使いたい場合、手軽な方法はありますか？
この記事のステップ3で紹介している設定方法を使い、Claude CodeまたはCodexで共通インターフェースを設定できます。APIYI apiyi.com のAPIキー1つで、質問の段階ではClaude Opus 5.5を使い、実装時にはより手頃なモデルに切り替えられます。APIYIが担うのはモデル呼び出しだけなので、スキルは通常どおりインストールできます。
Q7：tddに向いていない変更には、どんなものがありますか？
設定、接続処理、グルーコード、型注釈、単純なCRUDの転送処理などは、独立した正解と照らし合わせにくく、テストが実装をそのまま書き写しただけになりがちです。公式も、現時点のスキルには「TDDで進める価値があるか」を判断する機能がないと認めています。その判断は自分で行う必要があります。迷ったときは、まずAPIYI apiyi.com で軽量モデルを使い、Agentに変更の入力と観測可能な出力を列挙させてみましょう。列挙できない場合は、tddを使わないでください。
mattpocock/skills の重要ポイントとまとめ
重要ポイント
- 質問してから書く：まず
/grill-meで要件をすり合わせ、その後/tddでテストを1つずつ実装します - インストール方法はどちらか一方を選ぶ：プラグインと skills.sh の両方をインストールすると、各スキルが2つずつ表示されます
- 依存関係を忘れない：個別にインストールする場合、
grill-meにはgrilling、tddにはcodebase-designが必要です - 積極的に回答する：反論したり「わからない」と伝えたりしましょう。何でも「同意」するのは、最もよくある失敗です
- まず seam を確認する：
tddはテストの境界を先に列挙して、あなたの確認を待ってから、リファクタリングを含めずに Red→Green で進めます - モデルを使い分ける：質問には最も高性能なモデルを使い、実装ではモデルのグレードを下げられます。APIYIなら1つのAPIキーで切り替えられます
まとめ
mattpocock/skills の価値は、約30万のスター数ではなく、「まず要件をすり合わせ、次に小さく検証する」という2つのエンジニアリングの基本を、繰り返し実行できるスキルにしている点にあります。この記事で紹介した5つのステップ、つまりインストール、setupの実行、モデルの選択、/grill-me での要件確認、そして /tdd で最初のテストをRedからGreenにするところまで試せば、この方法が自分のプロジェクトに合うか判断できます。
質問する段階と実装する段階で異なるモデルを使いたい場合は、APIYI（apiyi.com）を利用すれば、1つのAPIキーでClaude CodeやCodexのモデルを切り替えられます。あとは実際の要件で何度か練習し、積極的に回答することが大切です。
参考資料
- GitHub – mattpocock/skills：READMEとすべてのSKILL.mdを掲載したリポジトリ
- リンク：
github.com/mattpocock/skills -
説明：インストール方法、スキル一覧、更新履歴はここで確認できます
-
AI Hero – Skills ドキュメント：
grill-meやtddなどのスキルに関する公式ドキュメント - リンク：
aihero.dev/skills -
説明：「It’s working if」の受け入れ基準チェックリストや、よくある質問を掲載しています
-
skills.sh – mattpocock/skills：ほかのエージェント向けの汎用インストールページ
- リンク：
skills.sh/mattpocock/skills - 説明：Cursor、OpenCode、Windsurfなどのツールに適しています。更新は手動で行う必要があります
著者：APIYI 技術チーム
技術に関するお問い合わせ：APIYI（apiyi.com）のトップページからお気軽にお問い合わせください。詳しい接続情報は、ドキュメントセンター（docs.apiyi.com）をご覧ください。
