Imported from PranavNagrecha/Salesforce-Intelligence (.claude/skills/architect-async-and-events/SKILL.md). Install upstream with npx skills add PranavNagrecha/Salesforce-Intelligence --skill architect-async-and-events. Copyright stays with the author.

Architect async and events

Overview

This skill is the v2.8 EXTENSION to the architect persona's integration-topology skill (architect-integration-topology). Where v1.5 ships the declared integration tier (integration_map, event_subscribers, the async / API-surface property booleans), v2.8 adds the async-deep tier covering four categories v1.5 EXCLUDED:

1. Change Data Capture (CDC) subscription detection. v1.5's event_subscribers is scoped to Platform Events (__e suffix on the ApiName); CDC events use a different name pattern ({ObjectName}ChangeEvent for standard objects, {Object}__ChangeEvent for custom objects). v2.8's sfi.cdc_subscribers recognizes both shapes via name pattern.
2. Async chain depth analysis. v1.5 emits one-hop dispatchesAsync edges (Queueable / Schedulable / Batchable / @future caller → job). v2.8's sfi.async_chain_depth walks the transitive chain — a job that queues another job that queues another job, surfacing the depth, every branch point, and any cycles.
3. Scheduled job catalog. v1.5 detects System.schedule(name, cron, instance) invocations but does not promote the schedule itself to a first-class catalog surface. v2.8's sfi.scheduled_job_catalog walks every ApexClass with isSchedulable: true AND every dispatchesAsync edge with dispatchMechanism: 'schedule', producing the cron-driven topology in one shot.
4. OutboundMessage promotion. v1.3 left WorkflowRule <outboundMessages> as dangling-by-design references. v2.8 promotes each entry to a real OutboundMessage node (the new v2.8 ComponentType), so the admin can catalog every SOAP outbound destination separately from the WorkflowRule that fires it.

Plus a fifth, unified surface:

5. Endpoint catalog. sfi.endpoint_catalog returns every URL the org touches in one structured response — inbound (REST exposes synthetic ids) + outbound (OutboundMessage endpointUrl + ExternalDataSource endpoint + NamedCredential url). This is the URL-axis sibling of sfi.integration_map (which surfaces NODES + their wiring) and sfi.outbound_message_catalog (which surfaces ONE category in depth).

The boundary that matters for architects: v2.8 does NOT probe, validate, or confirm any endpoint URL. The cataloged URLs are verbatim from metadata XML or Apex source — runtime registration (a NamedCredential resolved via custom metadata at runtime) may carry a stored URL that differs from the actual production destination. The architect verifies separately.

The CDC boundary, stated accurately (two older claims here were overtaken by shipped work — do not repeat them):

• CDC SUBSCRIBER detection is name-pattern only. The tool recognizes {Object}ChangeEvent / *__ChangeEvent shapes on triggers, classes and Flows. That half of the disclosure still holds.
• Per-channel filter expressions ARE extracted. A dedicated platformEventChannelMember extractor reads *.platformEventChannelMember-meta.xml and emits the member node plus a references edge carrying the declared filterExpression verbatim. cdc_subscribers surfaces them as channelMembers[] (memberId, channelId, channelType, selectedEntity, filterExpression). The real boundary is narrower: the filterExpression is the DECLARED XML text, NOT runtime filter EVALUATION — which records actually flow through the channel needs record-level data the vault does not hold. Confidence is declared.
• Apex EventBus.subscribe(...) remains invisible FOR CDC. The Apex scanner does now resolve static EventBus.subscribe channel args into a listensTo edge — but it is gated on the __e suffix, so Platform Events are covered and CDC *ChangeEvent channels are deliberately SKIPPED. For CDC the "programmatic registration is invisible" disclosure still holds verbatim; for Platform Events (sfi.event_subscribers) it no longer does.

There is no isCdcEnabled property. Nothing in packages/*/src writes it — no extractor, no enricher, no graph-build step. The producer-side question ("is this object enabled for CDC?") is answered by sfi.event_topology: cdcEntities[] lists the entities a PlatformEventChannelMember SELECTS (that selection IS the enablement declaration), each carrying the channel it is bound onto and the declared filterExpression. An empty cdcEntities quotes the manifest coverage row, so it reads as a CHECKED zero or as NOT CHECKED — never as a bare "no CDC". Do not call sfi.get_component on a CustomObject and read properties.isCdcEnabled — it will be undefined for every object in every vault, and an undefined read as "not CDC-enabled" is a fabricated negative.

The v2.8 chainAsync non-persistence: the transitive chain edge is composed AT QUERY TIME by sfi.async_chain_depth. The architect cannot query sfi.get_edges for chainAsync — only this tool surfaces the transitive shape. State this when explaining why a chain-walk question can't be answered via get_edges directly.

The cron expression is NOT available on the vault plane at all. There is no parsedCron, no rawCronExpression, and no cron parser (cron-parser is not a dependency of this repo). scheduled_job_catalog declares two cron-shaped fields — cronExpressions[] on an entry and cronExpression on each scheduledByCalls[] row — and BOTH are read defensively against a producer that does not exist: the Apex scanner's System.schedule(name, cron, new X()) regex captures only the CLASS NAME and discards the cron argument, and the dispatchesAsync edge it emits carries { dispatchMechanism, offset, length } and nothing else. So cronExpressions is [] and cronExpression is null on every entry in every vault today. Read an empty cron as "cron UNAVAILABLE on this plane", never as "this job has no schedule".

When to fire

Fire this skill on async / event / scheduled-job / outbound-message / endpoint-catalog phrasing. Concrete triggers:

CDC subscription shape

• "Who subscribes to CDC events on Account?" / "What's the CDC topology for Account?" — Use sfi.event_topology with { "objectApiName": "Account" }.
• "What change-data-capture subscribers do we have?" / "Audit our CDC subscribers." — Use sfi.event_topology with { "filter": "cdc" }.
• "Who listens to AccountChangeEvent?" — Same; the event-name pattern is recognized.

sfi.cdc_subscribers is a retired back-compat alias. It is not advertised under the default core profile and is not directly invokable there — reach it, if you must, through sfi.run_analysis { name: 'sfi.cdc_subscribers' }. Prefer sfi.event_topology.

Async chain depth shape

• "What's the async chain depth from ApexClass:AccountIndexer?" / "Walk the async chain rooted at this Queueable." — Use sfi.async_chain_depth with rootApexClassId: 'ApexClass:AccountIndexer'.
• "How deep does this Queueable chain go?" — Same; default maxDepth: 10.
• "Are there cycles in our async dispatch graph?" / "Show me where Queueables enqueue themselves." — Use sfi.async_chain_depth on each suspected root; surface the cyclesDetected[] array.

Scheduled job shape

• "Show me every scheduled job in this org." / "Audit our cron-driven Apex." / "What runs on a schedule?" — Use sfi.scheduled_job_catalog.
• "What's the cron for NightlyAccountsRefresh?" / "Decode this scheduled job." — This is an HONEST GAP on the vault plane: the cron string is not extracted (see above). sfi.scheduled_job_catalog can tell you the class is Schedulable and which classes call System.schedule on it; it cannot tell you the expression. Say so, and offer sfi.live_scheduled_jobs (opt-in live plane) — it reads the actual CronTrigger.CronExpression, State, and NextFireTime from the org.

Outbound message shape

• "What outbound messages does this org send?" / "Catalog our SOAP outbound messages." — Use sfi.outbound_message_catalog.
• "What's the outbound destination from Account workflow rules?" — Use sfi.outbound_message_catalog with objectFilter: 'Account'.
• "Which WorkflowRule fires Notify_Marketing_Automation?" — Same; the catalog entry surfaces invokedByWorkflowRules.

Unified endpoint catalog shape

• "Show me every URL this org touches." / "Give me the endpoint inventory." / "Audit our endpoint footprint." — Use sfi.endpoint_catalog.

When NOT to fire

Defer to another skill when:

• The user asks "what subscribes to Account_Change__e?" (a Platform Event, __e suffix). That's v1.5's sfi.event_subscribers shape; defer to architect-integration-topology. CDC and Platform Events are separate axes.
• The user asks for the broad integration map ("draw me our integration map", "what auth providers / named credentials / external data sources do we have"). That's v1.5's sfi.integration_map; defer to architect-integration-topology.
• The user asks for one-hop async dispatch info ("what calls enqueueJob(new AccountIndexer())?", "find every @future method"). v1.5 covers one-hop; defer to architect-integration-topology. v2.8's sfi.async_chain_depth is for the TRANSITIVE walk specifically.
• The user asks "what breaks if I disable this trigger?" That's v2.3 what-if; defer to developer-impact-and-reachability → sfi.what_if_disable_trigger.
• The user asks for code-level reachability ("where is AccountIndexer reachable from?"). That's v2.7 sfi.call_graph over callsApex edges; defer to developer-impact-and-reachability. sfi.async_chain_depth walks dispatchesAsync only.
• The user wants live data ("how many times did NightlyAccountsRefresh run last week?"). v2.8 is offline; the Tooling API gap means the actual scheduled job registration is invisible. Tell the user to query Setup → Scheduled Jobs.
• The user names an Experience Cloud / Sites surface. v2.8 doesn't cover that; v1.5's boundary applies.

The cascade

Five tools, five distinct surfaces. Pick the right entry point.

1. sfi.event_topology — the event plane (Platform Events + CDC)

Start here for anything event-shaped. One call returns the org's Platform Events with their declared eventType / publishBehavior and their publishers, subscribers and channel bindings; the entities whose Change Data Capture stream a PlatformEventChannelMember SELECTS (that selection IS the enablement declaration); the channels carrying both; the events the org NAMES but the vault never retrieved; and a coverage block naming the counts all of the above were computed under.

{}                                   // the whole event plane
{ "filter": "cdc" }                  // only the CDC half
{ "objectApiName": "Contact" }       // is CDC enabled for Contact?

Two boundaries to surface verbatim, because they are the ones a reader gets wrong: an empty cdcEntities list quotes the manifest coverage row, so it reads as a CHECKED zero or as NOT CHECKED — never as a bare "no CDC"; and a permission grant naming a *ChangeEvent entity is NOT CDC enablement (those entities exist on every org), so it appears only under referencedNotRetrieved.

sfi.cdc_subscribers below is a RETIRED back-compat alias: still dispatchable by name, no longer advertised. Prefer event_topology.

1b. sfi.cdc_subscribers (retired alias) — CDC subscribers only

Walks listensTo edges WHOSE TARGET MATCHES the CDC name pattern: {ObjectName}ChangeEvent for standard objects, *__ChangeEvent for custom objects.

{ "sObjectFilter": "Account" }   // narrow to one object
{}                                // every CDC-subscribed object

When sObjectFilter is supplied, resolves the synthetic ChangeEvent id from the filter (e.g., Account → AccountChangeEvent; Order__c → Order__ChangeEvent) and scans incoming listensTo edges for that single event. When omitted, walks every CustomObject whose apiName matches the CDC name pattern and aggregates their incoming listensTo edges.

Subscribers are restricted to ApexTrigger, ApexClass, Flow — the three v1.5 R3 listensTo producers.

Do not fire this by choice — sfi.event_topology returns the same CDC facts alongside the platform-event half. It survives only for callers that already name it. The disclosure it carries applies to both: CDC subscription detection recognizes by NAME PATTERN only, and programmatic EventBus.subscribe(...) registration is INVISIBLE.

There is no properties.isCdcEnabled flag on CustomObject — the signal has zero producers in the codebase, so reading it returns undefined for every object. The producer-side question ("is this object bound onto a change-event channel?") belongs to sfi.event_topology's cdcEntities[]. This alias returns the same binding as channelMembers[], where a member whose selectedEntity is the object IS the declared CDC binding, with its channelId / channelType / filterExpression. An empty channelMembers[] means no *.platformEventChannelMember-meta.xml bound the object in the retrieved metadata — not proof CDC is off.

2. sfi.async_chain_depth — transitive dispatchesAsync walk

BFS from rootApexClassId over outgoing dispatchesAsync edges. Each edge is recorded as a (fromId, toId, depth) tuple so the renderer can draw the chain.

{ "rootApexClassId": "ApexClass:AccountIndexer", "maxDepth": 10 }

The depth cap is 10. Chains deeper than 10 hops are TRUNCATED (the truncated flag flips true). This is the v2.8 honesty axis — runtime async chains can be arbitrarily long, but the v2.8 contract caps the static walk to keep the answer bounded.

Cycle detection: a frontier node whose id was already visited flips cyclesDetected: true. The walk does NOT abort on cycles — it continues to surface every reachable node — but the flag is the honest signal that the chain has a loop. The most common cycle is the self-enqueueing Queueable (AccountIndexer.execute() ending with System.enqueueJob(new AccountIndexer()) for chunking).

Branch points: a class with more than one outgoing dispatchesAsync edge to DIFFERENT targets is a branch. The response surfaces every class with branchCount >= 2 in the branchPoints array.

Note the chainAsync non-persistence: the transitive chain edge is composed AT QUERY TIME; it's NOT in the graph. State this when the user asks why the chain doesn't show up in sfi.get_edges.

3. sfi.scheduled_job_catalog — cron-driven Apex topology

Walks the graph for two distinct signals:

1. ApexClass nodes with properties.isSchedulable === true. These are classes implementing the Schedulable interface; they are schedule-CAPABLE but not necessarily currently scheduled (the actual schedule lives in CronTrigger / AsyncApexJob, which v2.8 does NOT query in the offline path).
2. dispatchesAsync edges with properties.dispatchMechanism === 'schedule'. The v1.5 R3 producer's System.schedule(...) call sites the Apex scanner detected; each edge names the target class plus the caller.

{}

Catalog is per-class — one entry per Schedulable class. Classes that are Schedulable but lack any System.schedule(...) call site surface with empty scheduledByCalls[] arrays (they exist on disk as Schedulable but no Apex source actually schedules them — usually scheduled via the UI or external tooling).

Surface the verbatim honesty axis: scanning for System.schedule(...) invocations is heuristic; the actual runtime schedule lives in the CronTrigger / AsyncApexJob Tooling API surface and is invisible to the offline DX-source scanner. A class flagged "schedulable" may NOT be currently scheduled — the schedule is a runtime registration.

An entry's cronExpressions[] is empty and every scheduledByCalls[].cronExpression is null — always, in every vault. The scanner never captures the cron argument. Surface that as an availability gap, not a finding:

This catalog names the Schedulable classes and the System.schedule call sites that reference them. The cron EXPRESSION itself is not extracted — the scanner captures the scheduled class, not the schedule string. For the actual expression, next fire time, and whether the job is currently registered at all, use sfi.live_scheduled_jobs (opt-in live plane, reads CronTrigger).

Also surface likelyUnscheduled when it is true, with its own meaning: a System.schedule() call site that lives ONLY inside an @isTest class does not schedule anything at runtime.

4. sfi.outbound_message_catalog — SOAP outbound destination catalog

Walks the OutboundMessage node family v2.8 promotes from WorkflowRule dangling references into real nodes.

{}                              // every OutboundMessage
{ "objectFilter": "Account" }   // narrow to one parent object

Each catalog entry carries:

• Identity (id, apiName, name).
• Four endpoint properties (endpointUrl, includeSessionId, useDeadLetterQueue, integrationUser).
• fields[] (the SOAP body's payload shape — array of field API names in source order).
• Parent CustomObject id.
• invokedByWorkflowRules[] — every WorkflowRule with an <actions> reference to this outbound message (the v1.3 reference shape preserved by the v2.8 promotion).

Surface the URL-not-probed disclosure: the endpoint URL is captured verbatim — v2.8 does NOT probe the URL, does NOT validate the destination exists, and does NOT confirm the message is actually invoked at runtime. The architect verifies destination reachability separately.

5. sfi.endpoint_catalog — unified URL inventory

The URL-axis composite. Composes four categories into one response:

{}

Takes no arguments. Each entry carries endpointKind discriminator, direction, sourceComponentId, and url.

Use this when the architect asks the URL-centric question ("show me every URL"); use sfi.integration_map (v1.5) when they ask the topology question ("how is this org wired"); use sfi.outbound_message_catalog when they want the per-message invokers.

Surface the verbatim disclosure: URLs are captured verbatim — v2.8 does NOT probe, does NOT validate, and does NOT confirm any destination exists or is reachable. Runtime registrations (e.g., a NamedCredential resolved via custom metadata at runtime) may carry a stored URL that differs from the actual production destination.

Honesty axes

v2.8 universal — URL not validated (verbatim)

v2.8 captures endpoint URLs verbatim from metadata XML and Apex source. v2.8 does NOT probe any URL, does NOT validate the destination exists, and does NOT confirm the integration is actually invoked at runtime. Runtime registrations (e.g., a NamedCredential resolved via custom metadata at runtime) may carry a stored URL that differs from the actual production destination. The architect verifies destination reachability separately.

sfi.cdc_subscribers — name-pattern detection (verbatim)

CDC subscription detection here recognizes by NAME PATTERN only. The recognized shapes are {ObjectName}ChangeEvent (for standard objects) and *__ChangeEvent (for custom objects with the __c suffix replaced). The programmatic EventBus.subscribe(...) registration path is invisible for CDC — the scanner's subscribe heuristic is gated on the __e Platform Event suffix and skips *ChangeEvent channels. Per-member filter expressions in *.platformEventChannelMember-meta.xml ARE extracted and surface in channelMembers[].filterExpression — but as DECLARED XML text, never as runtime evaluation of which records actually flow.

channelMembers is also the CDC ENABLEMENT signal: a member that selects a Change Event means CDC is on for that object even when no code subscribes. An empty subscribers[] with a non-empty channelMembers[] is "enabled, no modeled subscriber", NOT "CDC unused."

sfi.async_chain_depth — depth cap + heuristic edges (verbatim)

The walk is capped at depth 10. Chains deeper than 10 hops are truncated; the truncated flag flips true and any frontier-at-depth-10 nodes are NOT walked further. The underlying dispatchesAsync edges are produced by the v0.3 Apex scanner; reflective async dispatch (Type.forName(...).newInstance()) and helper-wrapper dispatch are invisible to the scanner, so the walked chain may UNDERSTATE the real runtime chain depth.

The chainAsync transitive edge is NOT persisted to the graph — v2.8 composes it at query time. The architect cannot query sfi.get_edges for chainAsync; this tool is the only surface.

sfi.scheduled_job_catalog — Tooling API gap (verbatim)

Scanning for System.schedule(...) invocations is heuristic; the actual runtime schedule lives in the CronTrigger / AsyncApexJob Tooling API surface and is invisible to the offline DX-source scanner. A class flagged Schedulable may NOT be currently scheduled — the schedule is a runtime registration. Conversely, a class with no System.schedule(...) call site may still be scheduled via the Salesforce UI or external tooling; surface as "schedulable but no detected scheduling call" in the response.

sfi.scheduled_job_catalog — cron is UNAVAILABLE on this plane

There is no cron-parse-failure disclosure, because there is no cron parser and no cron producer. cronExpressions[] is [] and each scheduledByCalls[] row's cronExpression is null on every entry in every vault — the Apex scanner's System.schedule(name, cron, new X()) regex captures the CLASS NAME and discards the cron argument. Say "cron UNAVAILABLE on this plane"; never "this job has no schedule", and never quote a cron string this tool did not return. The live CronTrigger registration is a Tooling-API fact, outside the offline vault.

sfi.outbound_message_catalog — URL-not-probed (verbatim)

The endpoint URL is captured verbatim — v2.8 does NOT probe the URL, does NOT validate the destination exists, and does NOT confirm the message is actually invoked at runtime. The architect verifies destination reachability separately.

sfi.endpoint_catalog — universal URL disclaimer (verbatim)

URLs are captured verbatim across four categories (inboundApis, outboundMessages, externalDataSources, namedCredentials). v2.8 does NOT probe, does NOT validate, and does NOT confirm any destination exists or is reachable.

Worked example

User: "Walk the async chain from ApexClass:AccountIndexer. How deep does it go?"

Claude's flow:

1. Classify → async chain depth shape.
2. Fire sfi.run_analysis with { "name": "sfi.async_chain_depth", "args": { … } } with { "rootApexClassId": "ApexClass:AccountIndexer" } (the input key is rootApexClassId; componentId / rootId are accepted aliases). Note the INPUT key and the OUTPUT key differ — the response echoes rootClassId / rootFlowId.
3. Receive (illustrative):

{
  "data": {
    "rootClassId": "ApexClass:AccountIndexer",
    "rootFlowId": null,
    "maxDepth": 4,
    "truncated": false,
    "cyclesDetected": true,
    "branchPoints": [
      { "classId": "ApexClass:AccountIndexer", "branchCount": 2 }
    ],
    "chains": [
      { "fromId": "ApexClass:AccountIndexer", "toId": "ApexClass:AccountIndexer", "depth": 1, "dispatchMechanism": "queueable", "confidence": "declared", "note": "self-enqueue (chunking pattern)" },
      { "fromId": "ApexClass:AccountIndexer", "toId": "ApexClass:AccountIndexNotifier", "depth": 1, "dispatchMechanism": "queueable", "confidence": "declared" },
      { "fromId": "ApexClass:AccountIndexNotifier", "toId": "ApexClass:EmailSender", "depth": 2, "dispatchMechanism": "future", "confidence": "heuristic" },
      { "fromId": "ApexClass:EmailSender", "toId": "ApexClass:EmailLogger", "depth": 3, "dispatchMechanism": "queueable", "confidence": "declared" },
      { "fromId": "ApexClass:EmailLogger", "toId": "ApexClass:RetryHandler", "depth": 4, "dispatchMechanism": "queueable", "confidence": "declared" }
    ],
    "disclosure": "The walk is capped at depth 10... [URL-not-validated + chain-depth verbatim disclosure]"
  }
}

4. Respond:

Async chain from ApexClass:AccountIndexer:

• Max depth: 4 (maxDepth; truncation: false).
• Branch points: 1 (the root, ApexClass:AccountIndexer, has 2 outgoing dispatchesAsync edges).
• Cycles: cyclesDetected: true — a self-enqueue at the root (chunking pattern). Note the field is a BOOLEAN, not a list: the walker reports THAT a cycle exists, not which nodes formed it. Find the cycle yourself by looking for a chains[] edge whose fromId === toId, or a repeated pair.

Chain edges (5):

Depth	From	To	Mechanism	Confidence
1	ApexClass:AccountIndexer	ApexClass:AccountIndexer	queueable (self)	declared
1	ApexClass:AccountIndexer	ApexClass:AccountIndexNotifier	queueable	declared
2	ApexClass:AccountIndexNotifier	ApexClass:EmailSender	future	heuristic
3	ApexClass:EmailSender	ApexClass:EmailLogger	queueable	declared
4	ApexClass:EmailLogger	ApexClass:RetryHandler	queueable	declared

The chunking self-enqueue at the root is the textbook Queueable pattern (processes one batch, then enqueues itself for the next batch) — NOT a bug. The walker reports it as a cycle of length 1 for completeness.

The depth-2 edge from AccountIndexNotifier to EmailSender is confidence: heuristic (the @future dispatch mechanism). The v0.3 Apex scanner heuristically tags @future callers; verify the actual call site before treating as authoritative.

Important v2.8 boundaries (verbatim disclosure):

• The walk is capped at maxDepth: 10; chains deeper than 10 would surface truncated: true but yours fits within 4.
• The dispatchesAsync edges are produced by the v0.3 Apex scanner. Reflective async dispatch (Type.forName(...).newInstance()) and helper-wrapper dispatch are INVISIBLE. If your chain has a hop via a custom AsyncDispatcher.enqueue(...) helper, the chain depth here may UNDERSTATE reality.
• The chainAsync transitive edge is NOT persisted to the graph — v2.8 composes it at query time. You can't query sfi.get_edges for chainAsync; this tool is the only surface.

Follow-up suggestions:

1. To see the one-hop dispatch sources from ApexClass:AccountIndexer (who enqueues IT?), use sfi.get_edges with edgeType: 'dispatchesAsync', direction: 'in'.
2. To audit all scheduled jobs in this org (a sibling concern), run sfi.run_analysis with { "name": "sfi.scheduled_job_catalog", "args": { … } }.
3. To check if EmailLogger or RetryHandler end up calling out to an external system, follow up with sfi.endpoint_catalog and cross-reference the outboundMessages / namedCredentials arrays.

The response leads with the depth + branch + cycle summary, surfaces the chain edges as a table with per-edge dispatchMechanism + confidence, calls out the self-enqueue chunking pattern explicitly (distinguishing it from a "real" cycle), and appends the verbatim v2.8 disclosure with the depth-cap + reflective-dispatch + chainAsync non-persistence notes.

Anti-patterns

See also

• architect-integration-topology — for v1.5's declared integration tier. Use that skill for integration_map, event_subscribers (Platform Events, __e suffix), and one-hop async dispatch via the v1.5 property booleans. v2.8 EXTENDS but does not replace; the two skills are complementary.
• architect-impact-analysis — for "what breaks if I delete this ExternalDataSource / NamedCredential / outbound message". v0.2's sfi.get_impact walks every incoming edge; v2.8 surfaces the cataloged URL but doesn't predict the impact.
• developer-impact-and-reachability — for sfi.call_graph (transitive callsApex walk) and sfi.what_if_disable_trigger (what-if disabling a trigger that subscribes to a Platform Event or CDC channel). sfi.async_chain_depth walks the dispatchesAsync axis specifically; sfi.call_graph walks the callsApex axis.
• admin-documentation-generators — for the v2.5 architecture- overview generator that COMPOSES sfi.integration_map + the v2.8 endpoint catalog into one document. The doc surfaces both axes; this skill is the deep drill-in.

Verification

Before sending a response, confirm:

• I classified the question into one of the five shapes (CDC subscribers / async chain depth / scheduled jobs / outbound messages / unified endpoint catalog) and fired the right tool.
• For CDC questions, I verified the user's event reference is a CDC name pattern ({Object}ChangeEvent / *__ChangeEvent), NOT a Platform Event (*__e). I re-routed to architect-integration-topology if it's a Platform Event.
• I surfaced the verbatim per-tool disclosure (URL-not- validated, name-pattern detection for CDC, depth-cap of 10, Tooling API gap for cron registration).
• I did NOT read parsedCron, rawCronExpression, isCdcEnabled, or maxDepthObserved — none of those exist, and an absent signal read as a negative finding is the exact failure this skill is supposed to prevent.
• For async_chain_depth results, I surfaced maxDepth, truncated, cyclesDetected (a BOOLEAN), and branchPoints[], and walked chains[] with per-edge edgeType / async / depth. I did not report a maxDepthObserved or a cyclesDetected[] list — neither exists.
• For self-enqueue cycles in async_chain_depth, I called out the chunking pattern explicitly rather than treating it as a defect.
• For scheduled_job_catalog entries I stated that the cron EXPRESSION is unavailable on the vault plane (it is never extracted), rather than reporting an empty cronExpressions[] as "this job has no schedule" — and I pointed at sfi.live_scheduled_jobs for the real registration.
• For outbound_message_catalog entries, I cited each invokedByWorkflowRules[] reference with its canonical id.
• For endpoint_catalog results, I split the response by direction (inbound vs outbound) and endpointKind.
• I cited every canonical id in backticks (ChangeEvent:AccountChangeEvent, ScheduledJob:NightlyAccountsRefresh, OutboundMessage:Lead.Notify_Marketing, ApexClass:, Flow:, etc.).
• I did NOT confuse Platform Events with CDC events, did NOT treat empty results as "no topology" without surfacing the invisibility disclosure, and did NOT treat the chainAsync non-persistence as a bug.
• When the question was about v1.5's broader integration surface (auth providers, named credentials, OData sources generally), I deferred to architect-integration-topology cleanly.

Grounding & routing (shared contract). For a vague or broad ask, call sfi.route_question first — in the default hybrid mode it returns a meaning-ranked toolCandidates shortlist (which YOU pick from) plus a suggested plane and a route hint (and whether to sfi.resolve a name first). Default tool profile is core: only the core spine (including sfi.live_consent) is directly invokable. For every other sfi.* analysis, call sfi.run_analysis with { "name": "sfi.<tool>", "args": { … } } (or follow route_question.invoke, which already wraps non-core steps). Optional: sfi.describe_analysis first when args are unclear. Every org fact must come from an sfi.* tool call, cited by its canonical id — never from memory. Build the answer only from what the tools returned, then pass it through sfi.synthesize_answer, which flags any hallucinatedIds (canonical ids no tool produced). Full cascade: using-sf-intelligence.