自分が使っているプラグイン内のスキル（incident.io のエージェントやコーディング用エージェントが読み込む機能）を作成・改善できます。 次のような場合に使用: スキルを書く、編集する、または何らかの形でレビューするとき。新しいスキルの作成、利用フィードバックやレビュー指摘に基づく改善、良いスキルの条件についての相談など、スキルに関連するあらゆる場面で活用できます。
Create and improve the skills in your own plugins — the ones incident.io's agents and your coding agents load. Use whenever you're writing, editing, or reviewing a skill in any way: creating one, improving one from usage feedback or a review brief, or asking what makes a good skill.
スキルとは、エージェント（AI が複数の判断を自動的に行うプログラム）が従う指示のことです。トリガー説明（発動条件の説明）を持つ SKILL.md ファイルと、必要に応じて読み込まれるリファレンスで構成されています。スキルはプラグイン（組織が incident.io に同期し、コード作成用エージェントにもインストールできるリポジトリ）内に存在します。このスキルは、スキルが選ばれ、実行され、役に立つようにするための作成技法を担当しており、実際の使用からシップ済みスキルを改善するループも管理します。incident.io は各実行（1 つのエージェントが 1 度スキルを使う）を記録して事後的に評価し、そのフィードバックが改善ジョブを駆動します。
作成 — ユーザーのプラグインに新しいスキルを作成する: 具体的なトリガー例で絞り込み、既に同じジョブを担当するものがないか確認し、フォーマットに従って下書きし、登録して、公開する。→ references/create.md
改善 — 実績に基づいて既存スキルを編集する: improve.md の読み取り修正を適用した使用フィードバックを読み、テーマごとに修正し（既に評価された強みを壊さない）、セッションが記録された問題に対して修正を検証し、公開して、確認する。→ references/improve.md
両方のジョブとも、下書きの前に同じ 2 つのファイルを読み込みます:
フォーマットは「これは有効か?」に答え、what-works は「これは実行されるか?」に答えます。references/example.md はこれらの両方を実装した具体例を示しています。ルールを増やすより目標の姿を知りたい場合はこれを読んでください。
さらに条件付きの参考資料もあります:
references/triage-skills.md — スキルが incident.io の調査によって到達すべき場合はこれを読んでください。調査では、インシデントの開始時間内にインシデントのシステムまたは署名を管理するインストール済みスキルを使用します。自動化された呼び出し元向けに作成する場合、3 つの点が変わります: 名前と説明がすべての選別を行い、手順は無人で実行されて確認する者がおらず、その結果は人へのレポートではなく他の誰かの証拠になります。
ユーザーのスキルは自分たちのプラグイン（組織が incident.io に接続するリポジトリ）に属し、このプラグインには含めません。このプラグインは作成上の判断を担当し、ユーザーのコンテンツはユーザーのものです。ユーザーがまだプラグインを持たない場合、プラグイン設定は extensions スキルのジョブです。そちらへ案内してから、最初のスキル作成に戻ってください。
編集はセッションがある場所で行われます: プラグインのリポジトリのチェックアウト（通常のケース — 変更はチームのレビュー流れに乗る）、またはセッションがリポジトリに到達できない場合は完成したファイルをユーザーに手渡す方法です。ユーザーが指定しなかったプラグインには絶対に書き込まないでください。
ランブック（トラブルシューティング手順書）とアーキテクチャドキュメント — これらは独自のフォーマットを持つコンテンツで、このプラグイン内の runbooks、runbooks-author、architecture、architecture-author スキルが担当しています。スキルは人のための知識ではなく、エージェント向けの指示です。また、すべてのプラグインを一度にレビューすること（「わたしたちのスキルは健全か?」）は doctor スキルのジョブで、このスキルは 1 度に 1 つのスキルに、そのスキルについての実績に基づいて取り組みます。
ユーザーの言葉で話す。このスキルの言葉ではなく。 ユーザーはこのファイルを読んでいないかもしれません。何をしているか素直に説明しましょう。ジョブを進めている間、各返答はこの形になります — 単発の質問には素直な答え:
<答え — ユーザーの言葉で数文>
**進捗**
- [x] <完了>
- [ ] <この返答のステップ> ← 今ここ
- [ ] <まだ来ていない>
**次のステップ:** <ユーザーへの 1 つの行動 — これが何をアンロックするか>
リストは一度合意したら固定です — 同じ項目、同じ言葉、同じ順序。チェックマークだけが動きます。計画が変わったら、そう言ってから一度だけ変更してください。
セッションの早い段階で合意されたプログレスリスト（このスキルまたは引き継いだスキルによるもの）は、各返答で表示・更新されます。まだリストがない場合は、スキルのスコープが合意されたときに 1 つを提案してください。ユーザーの言葉を使ってください: 「テストしました」ではなく「ロードテスト」、「your setup」ではなく「the estate」、「incident.io があなたの変更を取得しました」ではなく「synced」など。サブエージェントと検証実行は動作メカニズムです: 結果を報告し、メカニズムではなく。talking-to-the-user スキルが完全な表を持っています。
作成したコンテンツに署名を付ける。 作成または編集したすべてのスキルは、フロントマター（ファイルの先頭部）にこのプラグインのバージョンを含め、incident.io がこのワークフローを通じて来たスキルがどれかを判定できるようにしてください。incident.io MCP サーバーのスキルツールを通じてこのスキルをロードした場合は、"mcp" と書いてください: ディスク上の自分たちのマニフェストはなく、見られる plugin.json は作業中のリポジトリに属しています。それ以外は、このプラグインのマニフェスト plugin.json からバージョンを読んでください（Claude Code では ${CLAUDE_PLUGIN_ROOT}、それ以外は このスキルのフォルダの 2 つ上のディレクトリ）— メモリから入力しないでください。マニフェストが読めない場合は "unknown" と書き、ユーザーに知らせてください。フォーマットは format.md の provenance stamp section にあります。
A skill is instructions your agents follow: a SKILL.md with a triggering description, plus references it loads on demand. It lives in a plugin — a repository your organization syncs into incident.io and can also install into coding agents. This skill owns the authoring craft — what makes a skill get selected, followed, and helpful — and the loop that improves a shipped skill from real usage: incident.io records each load (one agent using the skill once) and assesses it retrospectively, and that feedback drives the improve job.
Both jobs load the same two files before drafting: references/format.md — the structural rules (anatomy, descriptions as triggers, environment-neutral tool and datasource naming, registration) — and references/what-works.md — what the best-performing skills share, from incident.io's own estate and the assessment of real usage. Format answers "is this valid"; what-works answers "will this get followed". references/example.md shows both applied to one worked skill — read it when you want the target picture rather than more rules.
One further reference is conditional: references/triage-skills.md — read it when the skill should be reached for by incident.io's investigations, which use installed skills that own an incident's system or signature in its opening minutes. Authoring for an automated caller changes three things: the name and description do all of the selecting, the procedure runs unattended with nobody to ask, and its findings become someone else's evidence rather than a report to a person.
The user's skills belong in their own plugin — a repository their organization
connects to incident.io — never in this one. This plugin carries the authoring
judgment; their content stays theirs. When the user has no plugin yet, plugin setup
is the extensions skill's job — route there, and come back to create the first skill.
Editing happens wherever the session is: in a checkout of the plugin's repository (the common case — changes ride the team's review flow), or by handing the user finished files when the session can't reach the repository. Never write into a plugin the user didn't point you at.
Runbooks and architecture docs — those are content with their own formats, owned by
the runbooks, runbooks-author, architecture and architecture-author skills in
this plugin; a skill is instructions for an agent, not knowledge for a person. And reviewing all your
plugins at once ("are our skills healthy?") is the doctor skill's job — this skill
works one skill at a time, from evidence about that skill.
Speak the user's language, not this skill's. The user may not have read this file; say what you're doing plainly. While you're driving a job, each reply has this shape — a one-off question gets a plain answer:
<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.
A progress list agreed earlier in the session (by this skill or the one that handed
over) is shown, updated, on every reply; where none exists yet, propose one when the
skill's scope is agreed. Use the user's words: "I tested it", not "road test" or
"fresh reader"; "your setup", not "the estate"; "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.
Stamp what you write. Every skill you create or edit carries this plugin's
version in its frontmatter, so incident.io can tell which skills came through this
flow. If you loaded this skill through the incident.io MCP server's skill tools, write
"mcp": there is no manifest of ours on disk, and a plugin.json you can see belongs
to the repo you're working in. Otherwise read the version from this plugin's manifest,
plugin.json at the plugin root — ${CLAUDE_PLUGIN_ROOT} in Claude Code, otherwise
two directories above this skill's folder — and never type it from memory. If the
manifest can't be read, write "unknown" and tell the user. The format is in
format.md's provenance stamp section.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。