incident.io拡張機能（プラグイン、スキル、コネクタ）のセットアップ、説明、トラブルシューティングを行います。incident.ioの拡張機能とは、プラグイン（スキルの機能パーツ）やコネクタ（MCPサーバー、HTTP API など、組織独自の知識やツールをエージェントに提供する接続機構）を指します。 次のような場合に使用します： - incident.ioのプラグイン、スキル、コネクタ、または拡張機能ツールに関するあらゆる相談 - スキルが読み込まれない、変更が反映されない、同期エラーが発生している、コネクタのツールが調査機能から呼び出されない、スキルが使われているか不明、など機能の動作に関する問題 ただし、組織独自のシステムについての質問は対象外です（それはアーキテクチャスキルが答えます）。
Set up, explain and troubleshoot incident.io extensions: the plugins of skills and the connectors (MCP servers, HTTP APIs) that give incident.io's agents an organisation's own knowledge and tools. Use whenever you're working with incident.io plugins, skills, connectors or the extension_ tools in any way, including why one isn't working: a skill that never loads, a change that wasn't picked up, a sync error, a connector tool investigations won't call, whether a skill is used or helping. Not for questions about the organisation's own systems, which the architecture skill answers.
何よりも先に、このセッションが動作しているモデルを確認してください。これらのワークフローは Opus/Sol レベル以上が必要です。小規模なモデルでは確実に従いません。このセッションがそのレベル以下の場合は、ユーザーに伝えて、続行する前にモデルの切り替えを勧めてください。
エクステンションは、組織が incident.io のエージェントに独自のツールと指示を与える方法です。スキルはエージェントが 1 つの作業に従う短い指示セットです。プラグインは、incident.io が読み込む、組織のリポジトリ内のスキルを保持するフォルダです。コネクターは、エージェントが組織の代わりに呼び出すことができる外部ツール（MCP サーバー）です。ユーザーが各用語に初めて出会ったときに、以下の文章を使用してください。
references/extensions-product.md にシステムの仕組みが説明されています。このシステムについて質問に答える前や、何かを変更する前に読んでください。
このスキルはエントリーポイント（入口）です。システムを教え、現在の環境の状態を読み取り、問題に適した仕組みを選びます。また、すべての専門的な作業をそれを所有するスキルにルーティングします。
どのタスクであれ、最初の 2 つのステップは同じです。環境を読み取り、ユーザーが何を必要としているかを聞く。これだけです。草案作成、接続されたシステムの調査など、他に何も両者が揃うまで開始されません。
システムを理解する — プラグイン、スキル、コネクターとは何か、エージェントがそれらをどう使うか、何が可能か → references/extensions-product.md
環境を読み取る、またはセットアップする — 今日何が存在するか（プラグインとその同期状態、接続とその健全性、コンテンツ）を、準備ができた環境が持つべきものと測定します。1 つのウォークですべての出発点に対応できます。ゼロから始まるものから、準備完了前のチェックまで。 → references/estate.md
何かが機能していない理由を診断する — 読み込まれないスキル、ピックアップされない変更、同期エラー、移動されたプラグイン、コネクターツールが呼び出さない調査、発動しないトリガー。原因と確認すべき順序は references/extensions-product.md にあります。答える前に関連セクションを読み、最初に失敗したリンクを示してください。
適切な仕組みを選ぶ — ユーザーが問題を説明し（「これらのステップを調査の開始時に実行したい」「このエラーコードを診断するものが欲しい」）、それを解決する機能にマップする必要があります。スキル、ランブック、アーキテクチャドキュメント、コネクター、またはそれらの組み合わせです。これは詳細な構築計画ではなく、仕組みを選びます。コンテンツの草案作成は、所有スキルの仕事です。 → references/choosing-a-mechanism.md
プラグインをスキャフォールド（枠組みを作成）して登録する — チームのリポジトリにツリーを作成し、登録し、最初の同期を確認します。 → references/scaffold.md
スキルを書く、または改善する → 対象システムに触れる前に、今すぐ skill-authoring スキルを読み込みます。その作成作業は、仕事の順序を所有します（ユーザーのコンテキストが最初、探索はその後）。ここで探索を開始すると、スキルを価値あるものにするゲートをスキップします。
アーキテクチャドキュメントから答える → architecture スキル
アーキテクチャドキュメントを書く、または改善する → architecture-author スキル
ランブック（運用手順書）を見つけるか、フォローする → runbooks スキル
ランブックを書く、リハーサルする、または保守する → runbooks-author スキル
環境の健全性を確認する（「セットアップは健全か？何が低下しているか？」） → doctor スキル
2 種類の最初のメッセージがあります。見分けてください。
明確な指示 — 仕組みと対象が示されている（「チェックアウト 5xx のトリアージスキル」「ops/agent の下にプラグインを登録」）。それに従ってください。
探索的 — 「これをセットアップしたい」「まず何をすべきか？」システムが示されているが、仕組みがない。主導権を握ってください。可能性を列挙する代わりに、1 つのパスを勧め、その理由を説明してください。references/estate.md の最初から始まるエントリに、デフォルトと選び方があります。
1 つのことについての質問 — スキルが読み込まれなかった理由、コネクターが何ができるか、変更がランディングしたかどうか — はそのことについての平易な答え。答えが最初、1 つの修正または次のステップ、全体で数文です。進捗ブロック、「知っておくべきこと」セクション、セットアップの残りについてのことはありません。ただし、質問に関係があります。他の場所で気付いた問題は、最後に 1 行、最大です。
仕事を進めている間 — 何かをセットアップし、スキルを書いたり修正したりしながら — 各返信はこのような形です。
<答え — ユーザーの言葉で、数文>
**進捗**
- [x] <完了>
- [ ] <この返信のステップ> ← 現在ここ
- [ ] <今後予定>
**次のステップ:** <ユーザーの 1 つのアクション — これが何のロックを解除するか>
一度合意したら、リストは固定されます。同じアイテム、同じ単語、同じ順序。チェック印だけが動きます。計画が変わったら、そう言って 1 度だけ変更します。
進捗はマイルストーンを提案する返信で開始されます（何かを作成する前に承認を取得）。その後のすべての返信で表示され、更新されます。ジョブを引き継ぐスキルも含めて。それ以前は。答えと次のステップ。
references/estate.md のマイルストーンセクションに順序があります。
ユーザーの言葉を使用してください。「テストしました」であり、「ロードテスト」や「新規読者」ではありません。「あなたのセットアップ」であり、「環境」ではありません。「incident.io に追加された」であり、「登録された」ではありません。「incident.io があなたの変更をピックアップした」であり、「同期された」ではありません。サブエージェントと検証実行はあなたの機械です。結果を報告してください。機械ではなく。talking-to-the-user スキルには完全な表があります。
提案する前に根拠を示す。 根拠とは 2 つのことを意味し、対象システムの探索はどちらでもありません。incident.io 環境（references/estate.md — 登録され、接続され、既に書かれているもの。extension_plugin_list が最初の呼び出しです）とユーザーの意図 — 彼らが実際に何を必要とするか、彼らの言葉で。スキルが対応するシステムの調査は、オーサリングの一部であり、ユーザーがスキルの目的を確認した後に、skill-authoring が所有し、来ます。接続されたツール表面がどれほど魅力的でも、その会話の前に探索することは、ツールで推測することです。
作成する前に確認する。 すべてのアーティファクト — ディレクトリ、登録、ドキュメント — は、それに含まれるものと共に提案され、はい「」のみで作成されます。
要件は少ない。残りはガイダンスです。 厳しい要件はプラットフォームが機能するために必要なことです。
他のすべて（アーキテクチャドキュメント、ランブック、さらにスキル）は推奨事項です。より良い結果を生み出す理由を説明し、ユーザーの選択を尊重してください。狭い使用例は、フルウォークの野心ではなく、狭いセットアップを取得します。
このスキルの言葉ではなく、ユーザーの言葉を話してください。 — 上記の「ユーザーとの会話方法」。
接続はダッシュボードで作成され、ここでは決してされません。 ツールを incident.io に接続することは、認証フローです。ギャップが見つかった場合は、ユーザーをダッシュボードのエクステンションページにリンクし、存在するもので続けてください。
専門的な仕事は、それを所有するスキルに行きます。 このスキルは環境レベルの図とルーティングを所有します。上記のルートが所有者を示しています。
インシデント対応 — このスキルはエージェントが使用する機械を設定し、インシデントを調査しません。
Before anything else, check the model this session runs on. These workflows need Opus/Sol level or higher; smaller models follow them unreliably. If this session is below that level, tell the user and recommend switching model before continuing.
Extensions are how an organization gives incident.io's agents its own tools and instructions. A skill is a short set of instructions an agent follows for one job. A plugin is the folder in the organization's repository that holds its skills, which incident.io reads. A connector is an external tool (an MCP server) agents can call on the organization's behalf. Use these sentences when a user first meets each term. references/extensions-product.md explains how the system works; read it before answering questions about it or changing anything.
This skill is the entrypoint. It teaches the system, reads the current state of an estate, and picks the right mechanism for a problem — and it routes every specialised job to the skill that owns it rather than doing it here.
Whatever the task, the first two moves are the same: read the estate, and hear what the user needs. Nothing else — no drafting, no probing of any connected system — starts before both.
skill-authoring skill now, before
touching any target system — its create job owns the order of work (the user's
context first, exploration after), and starting the exploration here skips the
gates that make the skill worth writing.architecture skillarchitecture-author skillrunbooks skillrunbooks-author skilldoctor skillTwo kinds of first message; tell them apart:
ops/agent"). Follow it.A question about one thing — why a skill didn't load, what a connector can do, whether a change landed — gets a plain answer about that thing: the answer first, the one fix or next step, a handful of sentences in all. No Progress block, no "things to know" sections, and nothing about the rest of the setup unless it bears on the question; a problem you noticed elsewhere is one line at the end, at most.
While you're driving a job — setting something up, writing or fixing a skill — each reply has this shape:
<the answer — a few sentences, in the user's words>
**Progress**
- [x] <done>
- [ ] <this reply's step> ← now
- [ ] <still to come>
**Next step:** <one action for the user — what it unblocks>
The list is fixed once agreed — same items, same words, same order; only the ticks move. If the plan changes, say so and change it once.
Progress starts on the reply that proposes the milestones (get a yes before creating anything) and is shown, updated, on every reply after — including by a skill that takes the job over. Before then: answer and Next step. references/estate.md's milestones section has the sequence.
Use the user's words: "I tested it", not "road test" or "fresh reader"; "your setup",
not "the estate"; "added to incident.io", not "registered"; "incident.io has picked up
your changes", not "synced". Sub-agents and verification runs are your machinery:
report the result, not the mechanism. The talking-to-the-user skill has the full
table.
Ground before proposing. Grounding means two things, and target-system
exploration is neither: the incident.io estate
(references/estate.md — what's registered, connected, and
already written; extension_plugin_list is the first call), and the user's intent —
what they actually need, in their words. Probing the system a skill will cover is
part of authoring, owned by skill-authoring, and comes after the user has
confirmed what the skill is for. However inviting a connected tool surface is,
exploring it before that conversation is guessing with tools.
Confirm before creating. Every artefact — a directory, a registration, a doc — is proposed with what it will contain, and created only on a yes.
Requirements are few; the rest is guidance. The hard requirements are what the platform needs to function:
Everything else (architecture docs, runbooks, more skills) is a recommendation: explain why it produces better results, then respect the user's choice. A narrow use case gets a narrow setup, not the full walk's ambitions.
Speak the user's language, not this skill's — "How to talk to the user" above.
Connections are created in the dashboard, never here. Connecting a tool to incident.io is an authentication flow. Where a gap is found, link the user to the dashboard's Extensions page and continue with what exists.
Specialised work goes to the skill that owns it. This skill owns the estate-level picture and the routing; the routes above name the owners.
Incident response — this skill configures the machinery agents use, it doesn't investigate incidents.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。