incident.ioの組織カタログ機能です。これはサービスやチーム、コンポーネント、顧客、ユーザーなど、組織が管理するあらゆるもの（のタイプと個別データ）、それらの属性、およびそれらの間のつながりを記録したものです。 次のような場合に使用します： - これらの情報を何らかの方法で参照する場合全般 - 単純な検索を行う場合（「チェックアウト機能は誰が管理していますか？」「Atlasとは何ですか？」「サーチ機能に依存しているものは何ですか？」「プラットフォームチームのメンバーは誰ですか？」など） - 設定値を変更する前や案件をエスカレーション（引き上げ）する前に、データの一意のIDを確認する場合 **重要：** カタログまたはチームに関する最初のツール呼び出しの前に、あらかじめ本スキルを読み込んでください。各ツールが返す未加工のデータと相互参照を、本スキルを使って正しく照合し、つながりを追跡するためです。 **対象外：** オンコール（当番）スキルで扱う勤務シフト表の管理、または「システムの内部的な仕組み」に関する情報（アーキテクチャドキュメントなど）は、このスキルの対象ではありません。ただしそうしたシステムについても、最初はこのカタログで主体を確認します。
The organisation's catalog in incident.io: its types and entries (services, teams, components, customers, users and whatever else it models), their attributes, and the references between them. Use whenever you're working with any of these in any way, including plain reads ("who owns checkout?", "what is Atlas?", "what depends on search?", "who's in the platform team?") and finding an entry's ID before setting a field or escalating. Load it before the first catalog or team tool call: the tools return raw entries and references, and this skill says how to prove a match and walk a reference. Not for schedule rotas and shifts (the on-call skill), nor how a system works internally (architecture docs, but ground the subject here first).
カタログは、組織が自分自身を構造化した地図です。タイプ（サービス、チーム、顧客など）がそれぞれ属性スキーマを持ち、エントリ（検索インデクサー、データプラットフォームなど）がそれらの属性の値を保有しています。別のエントリを参照する属性は名前 (ID)の形で表示され、括弧内のIDがジャンプ先です。カタログは絶対的な情報源です。会話やインシデント（事象）の文脈がカタログと異なる場合、カタログが正しく、その旨をお伝えします。
type_nameで区別されます：
Custom["…"] — 組織が独自に定義したタイプで、組織に関する質問に最適なことが多いです。まずこれを検索しますが、エントリが手動で追加されたと仮定してはいけません。EscalationPath（呼び出し経路）、Schedule（スケジュール）、User（ユーザー）、AlertPriority（アラート優先度）など）— incident.ioが管理するリソースです。チームはネイティブではなく、通常はCustom["Team"]という組織定義型に存在するため、チーム名を推測するのではなくteam_listとteam_showを使用してください。個人の連絡先（メールアドレスや電話番号）はそのユーザーエントリに保存されています。ユーザーを解決してからエントリを読んでください。GitHubRepository（GitHub リポジトリ）、PagerDutyService（PagerDuty サービス）、SlackChannel（Slack チャネル）など）— 外部ツールのミラーで、数千のエントリがあることもあります。ユーザーが統合の名前を明示的に挙げた場合だけ検索してください。「取り込みサービス」は組織のサービスエントリを指し、GitHub リポジトリではありません。type_nameはタイプの種類を示しますが、誰がエントリを管理しているかは別です。そのためにはcatalog_type_listからregistry_typeとis_editableを確認してください。registry_typeを持つタイプはincident.ioが管理しており、編集できません。持たないタイプはincident.ioによる同期ではありませんが、catalog-importer（カタログ取り込みツール）やTerraformなどの外部ジョブがAPIを通じて書き込むことがあります。これらのツールからは見えないため、これを「統合同期型でない」と呼びます。属性のmode（形式）はそのフィールドについて説明します。出所に関する質問には、情報源と編集可能性の判定を先に述べ、この留意事項も添えてください。属性のリストやエントリ数は、聞かれない限り省略してください。
incident.ioコネクションのcatalog_type_list、catalog_entry_list、catalog_entry_showツールを直接使用してください。初めて使う前に、各ツールの入力スキーマを確認してください。コネクションが利用できない場合、何が確認できなかったかを述べてください。エントリを作り上げてはいけません。
1回のcatalog_type_list呼び出しで、すべてのタイプが属性スキーマを含めて返されます。会話ごとに最初の検索の前に一度全体像をつかみ、どのタイプが対象を保有できるか、どの属性チェーンが答えに到達するかを計画してください。すべての組織のカタログは独自の構成になっています。ここで示すタイプ名や属性名は例です。推測で型名を指定すると（例えばServiceの代わりにCustom["Service"]を使わない）、何もマッチせず、エントリが存在しないように見えます。
質問に含まれる型ヒントに基づいて検索範囲を決めてください。型が明記されている場合（「チェックアウトサービス」、「課金を担当するチーム」）は、そのタイプとその周辺タイプに絞ります。名前だけの場合（「Atlas とは何ですか？」）は型の手がかりがないため、組織のカスタム型を並行して検索してください。管理型タイプは数が少ないため、その後でネイティブ型や統合型を検索します。単一タイプの検索が正当化されるのは、質問で型が明記された場合だけです。
検索はエントリ名と識別子のみにマッチします。説明や属性値は対象ではありません。ヒットしなかった場合、「検索した型に存在しない」を意味し、「存在しない」ではありません。小さなタイプはエントリが存在しないと結論付ける前に、すべてをリストアップしてください。
**検索ヒットは正確な識別子ではありません。**アラートやフィールド値は、エントリのID、外部ID、別名によってマッチします。タイプのuse_name_as_identifierが真の場合のみ、名前でマッチします。identifierで一致を確認し、そのフラグが偽の場合、表示名をマッチング値として提示しないでください。
不在はタイプ固有です。 catalog_type_listはスキーマを説明するものであり、エントリではありません。サービスの検索では、顧客が同じ名前のエントリを持つかどうかを確認できません。「顧客エントリがマッチしない」と述べる前に、その名前または識別子で顧客を照会してhas_more: falseまでページングしてください。そうでなければ「顧客は確認されなかった」と述べてください。「このサービスへのスキーマリンクがない」ことは「マッチする顧客エントリがない」こととは異なります。
1つの名前が複数のタイプのエントリにマッチする場合（「Atlas」というコンポーネントと「Atlas」というプロジェクト）、両方の候補、それらの型、IDを前に述べてください。それらの間の参照があっても、アラートが名付ける方を証明しません。区別が重要な場合、後から決定するのではなく、アラートまたはその識別子を先に尋ねてください。一方を答えとして見出しにし、もう一方を後から述べてはいけません。
フィルター検索のヒットは、タイプのサイズではありません。検索したタイプ内のマッチと呼んでください。タイプ全体数は、信頼できるカウントまたはフィルターなしで最後までページングしたリストからのみ主張してください。has_more: trueはリストが完全ではないことを意味します。
参照はそれを指すエントリに存在し、ツールはその方向のみを読みます。 すべての関係に関する質問は、「どのタイプのスキーマが属性を保有しているか」と問うことから始めてください。
順方向（対象がその属性を保有する — 「検索インデクサーの所有者は誰ですか？」）：エントリの属性値から名前 (ID)を直接読んでください。対象の完全で切り詰められていない属性が必要な場合、catalog_entry_show <id>を使用してください。
逆方向（他のエントリが対象を指す — 「メッセージバスを呼び出すものは何ですか？」、「データプラットフォームチームが所有するものは何ですか？」）：参照は指すエントリに存在し、対象の送信属性には存在しません。スキーマ内で参照元のタイプと属性IDを見つけ、attribute_filtersでcatalog_entry_listを呼び出してください：[{ "attribute_id": "<参照元属性ID>", "operator": "one_of", "entry_ids": ["<対象ID>"] }]。これは対象のID、外部ID、別名にマッチし、マッチするエントリのみをページングします。不明または廃止された対象はエラーであり、依存関係がないことの証明ではありません。
未割り当てまたは未設定（「所有者がないサービスはどれですか？」）：参照フィルターでoperator: "is_blank"を使用してください。アーカイブされた所有者への参照は名前 (廃止) (ID)と読め、設定済みと見なされるため、is_blankは決して返しません。これらを空のエントリとは別に報告してください。
複合条件（「未割り当てで優先度1のサービス」）：同じattribute_filtersリスト内に属性ごとに1つのフィルターを配置してください。それらはAND結合されるため、手動での交差判定は不要です。
現在の状態のみ、履歴ではない： is_blankまたはis_setスキャンは現在設定されているものだけを表示します。「現在未設定」と述べてください。履歴読み取りなしに「設定されたことがない」と述べてはいけません。
所有者の完全な内訳： 同じ参照属性についてis_blankとis_setの両方をhas_more: falseまでページングしてください。一緒にアクティブなエントリを分割し、カウントがタイプ全体を再度リストアップせずに合計を示します。設定された側では、(廃止)参照を別にリストアップしてください。保存された値が必ずしも有効な所有者であるとは限りません。
マルチホップ（「X がダウンした場合、どの顧客が影響を受けますか？」）：フィルター付き逆ホップを意図的に連鎖させてください。Xの依存関係、次にサービスからそれらを参照するタイプへ。各ホップでスキーマを確認し、チェーンが何を確立し、何を確立しなかったかを述べてください。
カウントだけが必要な場合は、属性フィルターなしでinclude_total_count: trueをリクエストしてください。小さいpage_sizeはそのカウントのためだけに全ページを引き出すのを回避します。カウントはオプションでタイムアウトすることがあります。カウントが不在の場合、合計を主張する前にhas_more: falseまでページングしてください。searchからのカウントはその検索のためだけです。タイプ全体ではありません。
team_show.members.itemsは、設定されたチーム属性のユーザーIDと名前を持つ直接メンバーを保有しています。members.pagination.next_cursorに従い、has_moreが偽になるまで、完全なメンバー一覧を得てください。members.configured: falseは空のチームではありません。これらは直接メンバーであり、子チームを通じて継承したすべてのメンバーではありません。個人のチームについては、その User エントリを見つけ、設定されたチームタイプをone_of属性フィルターでメンバー属性にフィルターしてください。職務経歴書や Slack グループをチームエントリで代用してはいけません。team_show.resources.itemsはチームを指しているカタログエントリではなく、リンクされた運用リソースをリストアップします。空のリストはチームがサービスを所有していないことを決して証明しません。上記の逆参照を使用する前に、その主張を立ててください。
チーム階層については、親参照は子に保存されることを覚えてください。チームから順方向に読むと、その祖先が得られます。子孫については、チームタイプをフィルターしてone_of属性フィルターで親属性に開始チームを指定し、見つかった各チームについて繰り返し、各レベルをhas_more: falseまでページングしてください。開始チームは自分自身の子孫ではありません。その下の異なるチームをIDと共にリストアップしてください。子孫カウントは聞かれた場合のみ、完全なセットから開始チームのIDを除いた後にのみ提供してください。
「サービスまたはコンポーネントのためにページングされるのは誰ですか」はカタログウォークから始まります。スケジュールはサービス所有権ではなく、人とシフトについて知っています。
サービスエントリを見つけ、その所有者参照をたどってください（チームまたはEscalationPathにリンクする属性についてスキーマを確認してください）。
その参照に支えられたチームと経路を述べてください。team_showはチームの経路をリストアップできます。escalation_path_listは名前で検索しますが、同じ名前の経路はそのサービスがそれを使用することの証明ではありません。
所有者参
The catalog is the organisation's structured map of itself: types (Service, Team,
Customer…) each with a schema of attributes, and entries (search-indexer, Data Platform…)
holding values for those attributes. Attributes that reference other entries render as
Name (ID) — the ID in parentheses is how you hop. The catalog is authoritative: when
conversation or incident context disagrees with it, the catalog wins, and you say so.
Three kinds of type, told apart by type_name:
Custom["…"] — org-defined types, often the best match for an organisational
question. Search these first, but do not assume their entries were added by hand.EscalationPath, Schedule, User, AlertPriority…) — incident.io's own
resources. Teams are not native: they live on an org-defined type, usually
Custom["Team"], so use team_list and team_show rather than guessing its name.
Contact details for a person (email, and phone numbers where the org exposes them) live
on their User entry: resolve the person, then read the entry.GitHubRepository, PagerDutyService, SlackChannel…) — mirrors
of other tools, often thousands of entries. Only search these when the user names the
integration; "the ingest service" means the org's Service entry, not its GitHub repo.Where a type's entries come from. type_name tells you which kind a type is, not
who maintains its entries. For that, read registry_type and is_editable from
catalog_type_list. A type with a registry_type is managed by incident.io, as its own
resources or an integration it syncs, and isn't editable. A type without one isn't
synced by incident.io, but an external job such as
catalog-importer or Terraform may still write it through the API, and these tools
can't see that: call it not integration-synced rather than hand-maintained. An
attribute's mode describes that one field. For provenance questions, lead with the
source and editability verdict plus that caveat; omit attribute inventories and entry
counts unless asked.
Use the incident.io connection's catalog_type_list, catalog_entry_list and
catalog_entry_show tools directly. Inspect a tool's input schema before first use.
If the connection is unavailable, say what could not be checked; do not invent an entry.
One catalog_type_list call returns every type with its attribute schema. Orient
once per conversation, before your first search, and plan the whole walk from it: which
types could hold the subject, which attribute chain reaches the answer. Every org's catalog is bespoke — type and attribute names here are
examples, and a guessed type_name (Service instead of Custom["Service"]) matches
nothing and looks like the entry doesn't exist.
use_name_as_identifier is true. Prove a match with identifier, and never offer
the display name as a value that will match when that flag is false.catalog_type_list describes schemas, not entries: a Service
search cannot establish whether Customer has a similarly named entry. Before saying
"no Customer entry matches", query Customer for that name or identifier and page to
has_more: false; otherwise say Customer was not checked. "No schema link to this
service" is different from "no matching Customer entries."has_more: true means the listing is incomplete.The reference lives on the entry that points, and the tools only read that direction. Orient every relationship question by asking: which type's schema holds the attribute?
Name (ID) straight off the entry's attribute value; catalog_entry_show <id> when
you need the target's full, untruncated attributes.catalog_entry_list with attribute_filters:
[{ "attribute_id": "<referencing-attribute-id>", "operator": "one_of", "entry_ids": ["<subject-id>"] }].
It matches the target's ID, external ID and aliases and pages only the matching
entries. An unknown or archived target is an error, not proof it has no dependents.operator: "is_blank" on the stored reference attribute. A reference to an
archived owner reads Name (Archived) (ID) and counts as set, so is_blank never
returns it: report those apart from the empty ones, not as unset.attribute_filters list; they AND together, so no manual intersection.is_blank or is_set scan only shows what is set
now. Say "currently unset"; do not say "never set" without a historical read.is_blank and is_set for the same stored
reference attribute to has_more: false.
Together they partition active entries, so their counts give the total without
listing the entire type again. On the set side, list (Archived) references
separately: a stored value is not necessarily a working owner.For a count alone, request include_total_count: true without an attribute filter;
a small page_size avoids pulling a whole page just for that figure. The count is
optional and can time out; when absent, page to has_more: false before claiming a
total. A count from search is only for that search, not the type.
team_show.members.items holds direct members with user IDs and names from the
configured team attribute. Follow members.pagination.next_cursor until has_more
is false for a full roster; members.configured: false is not an empty team. These
are direct members, not everyone inherited through child teams. For a person's
teams, find their User entry and filter the configured Team type by its members
attribute with a catalog_entry_list one_of attribute filter; don't substitute a
job title or Slack group for a Team entry. team_show.resources.items lists linked
operational resources, not catalog entries pointing at the team: an empty list
never proves the team owns no services. Use the reverse lookup above before making that claim.
For a team hierarchy, remember the parent reference is stored on the child: reading
it forward from a team gives its ancestors. For descendants, filter the Team type
with a one_of attribute filter on the parent attribute for the starting team,
then repeat for each team found, paging each level to has_more: false. The
starting team is not its own descendant: list the
distinct teams below it with IDs. Give a descendant count only if asked,
and only after excluding the starting team's ID from the complete set.
"Who gets paged for a service or component" begins with a catalog walk: schedules know about people and shifts, not service ownership.
EscalationPath).team_show can list a team's paths;
escalation_path_list searches by name, but a similarly named path is not proof that
the service uses it.(Archived), lead with that: the team is archived and
is not a current owner to contact. If the reference does not resolve at all, say so.
Without a live owner, say no path for this service was verified, and send the user
to confirm and update the Owner.
Do not suggest a former parent, lead, successor, default path or platform on-call
unless a read links it to this service.This read skill cannot edit catalog entries or types. Explain the needed change, but do not offer to set Owner or edit a catalog entry. An incident custom-field write through another available tool is a separate action.
Before setting a catalog-typed custom field or escalating: resolve the name to an identifier with a catalog read, and pass the identifier, never the display name — names are ambiguous and case-drifted, and a write against the wrong entry lands on a real incident or pages a real person. If the resolution was fuzzy (several candidates, or a weak match), confirm with the user before the write, not after.
Data Platform (01ABC…)) for anything the user might act
on next — the next step, yours or theirs, needs the ID and shouldn't re-resolve it.原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。