incident.io 拡張機能（プラグイン・スキル・コネクタなど、組織独自の知識やツールをエージェントに提供する機能）のセットアップ、説明、トラブルシューティングを行います。 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つのタイプです。見分けてください：
明確な指示 — 仕組みとターゲットが指定されている（「checkout 5xx 用のトリアージスキル」「ops/agent の下にプラグインを登録」）。それに従ってください。
探索中 — 「これをセットアップしたい」「まず何をすべきか」「名前は付けているが仕組みは不明」。主導権を取ってください。可能なことを列挙するのではなく、1つのパスを推奨してその理由を述べてください。references/estate.md のゼロから始めるセクションにデフォルトと選び方があります。
1つのことについての質問 — スキルが読み込まれなかった理由、コネクタに何ができるか、変更が反映されたか — はそのこと自体について明確な答えをします。答え最初、1つの修正または次のステップ、全部で数文だけ。進捗ブロックは不要、「知っておくべきこと」セクションもなし、セットアップの残りについても質問に関係ないなら触れません。別の場所で気づいた問題は、最後に1行あるかないかです。
仕事を進行中のとき — 何かをセットアップしている、スキルを書いたり修正したりしている — 各返答にこの形式をとります：
<答え — ユーザーの言葉で、数文>
**進捗**
- [x] <完了>
- [ ] <この返答のステップ> ← 現在
- [ ] <まだ来ていない>
**次のステップ：** <ユーザーへの1つのアクション — これが何をアンロック（実現）するか>
リストは一度合意すると固定です — 同じ項目、同じ言葉、同じ順序。チェックマークだけが動きます。計画が変わったら、そのことを述べて1回変更します。
進捗はマイルストーンを提案する返答から始まります（何かを作成する前に承認を得ます）し、その後のすべての返答で表示・更新されます — ジョブを引き継いだスキルも含めて。それより前は、答えと次のステップだけです。 references/estate.md のマイルストーンセクションに順序があります。
ユーザーの言葉を使ってください。「テストしました」であって「ロードテスト」や「新鮮な読み手」ではなく、「セットアップ」であって「環境」ではなく、「登録」ではなく「追加」であって「同期」ではなく「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 による自動翻訳です。