agentforce-d360-analyze

What the source does

• FilesystemDeclared1 observation
• NetworkDeclared3 observations
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 154bf6698c29 · 23 Oct 2026Report an issue or request a re-scan

• Publisherforcedotcom GitHub organizationOwner of the repository this skill is read from
• Source folderforcedotcom/sf-skills/skills/agentforce-d360-analyzeThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict154bf6698c29A new audit runs when the source changes
• Repository statusNot archivedLast push 1 day ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Data Cloud 360° view of a single Agentforce session. TRIGGER when user asks to trace, inspect, summarize, or describe a specific Agentforce session by session id (Agent Session UUID `019d...` or MessagingSession id…

---
name: agentforce-d360-analyze
description: "Data Cloud 360° view of a single Agentforce session. TRIGGER when user asks to trace, inspect, summarize, or describe a specific Agentforce session by session id (Agent Session UUID `019d...` or MessagingSession id `0Mw...`). Also triggers on session discovery — find/list/search sessions by time, agent, channel, outcome, or conversation text — when the user has no session id yet. DO NOT TRIGGER for design-time architecture questions (use agentforce-architecture-analyze instead) or for runtime perf/latency/SLO questions that require platform telemetry beyond Data Cloud."
metadata:
  version: "1.0"
  domains: ["Agentforce", "Data 360"]
  minApiVersion: "66.0"
  relatedSkills:
    - "agentforce-architecture-analyze"
  cliTools:
    - tool: ["python3"]
      semver: ">=3.10.0"
    - tool: ["sf"]
      semver: ">=2.0.0"
---

# agentforce-d360-analyze — Data Cloud 360° session view

Hierarchical session reconstruction from Data Cloud STDM + GenAI DMOs for one Agentforce session. Three stages — fetch → assemble → render. Typical wall-clock: ~10–30s for a ~15-turn session.

The pipeline is **DC-only**: it reads runtime audit rows that Data Cloud has materialized. It is **not** a runtime-availability tool — see "DC-only blind spot" below for what this skill cannot answer.

## If the user hasn't given enough to proceed

When invoked with no session id AND no discovery criteria, print this block **verbatim** — do not paraphrase, do not pre-run any script. Trigger condition: the input is empty OR contains no session-id shape (neither a UUID nor a `0Mw...` messaging id) AND no discovery expression (no time phrase / `--agent` / `--channel` / `--outcome` / `--grep` / verbs like "find" / "list").

> Which session should I pull from Data Cloud, and in which org?
>
> I need:
> - **Session id** — either an Agent Session UUID (`019db7f6-...`) or a MessagingSession id (`0Mw...`, 15/18 chars).
>   - **No session id?** — Tell me what you remember and I'll find it: how recent (e.g. "last 2 hours", "today", a date), which agent, which channel (Messaging / Builder / Voice), how it ended (escalated, user ended, transferred, timed out), or a phrase from the conversation. I'll show matching sessions as a numbered list — you pick one, I pull it.
> - **Org alias** — for `sf` CLI auth (the alias you configured with `sf org login`).
>
> Artifacts land in `~/.vibe/data/agentforce-d360-analyze/<org_id15>/<agent>__<ver>/<session_id>/` (override per-script with `--data-dir <path>`).

## Session id forms — UUID or MessagingSession id

Both forms are accepted on `--session`:

| Form | Example | Resolution |
|---|---|---|
| Agent Session UUID | `019dface-0000-7000-8000-000000000002` | Pass-through |
| MessagingSession id (`0Mw` prefix) | `0MwTESTMSG12345AAA` | Resolved via `resolve_session.py` — live DC lookup on first fetch, disk-first thereafter |

**Multi-match is real.** One MessagingSession id can map to multiple Agent Session UUIDs. On multi-match the resolver prints every candidate and exits non-zero; the user re-invokes with a specific UUID.

Artifacts always land under `~/.vibe/data/agentforce-d360-analyze/<org_id15>/<agent>__<ver>/<session_id>/` (default; overridable per-script with `--data-dir <path>`) — the messaging id is a lookup key only, never a directory name. The dominant agent (first in `sorted(agents_observed)`) names the `<agent>__<ver>/` segment.

## Resolving the script prefix

`<SKILL_DIR>` = the absolute path to **this skill's own directory** (the folder holding this
`SKILL.md`); resolve it from the skill path in context and substitute it below. Runtimes
install skills in different places (`~/.claude/skills/`, `~/.vibe/skills/`, a plugin cache, a
project `.claude/skills/`), so the block also probes the known install roots at runtime and
uses the first that actually contains this skill's scripts. An exported `SKILL_ROOT` wins.

```bash
_skill=agentforce-d360-analyze
for _c in "${SKILL_ROOT:-}" "<SKILL_DIR>" \
          "${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/skills/$_skill}" \
          "${VIBES_SKILLS_DIR:+$VIBES_SKILLS_DIR/$_skill}" \
          "$HOME/.claude/skills/$_skill" "$PWD/.claude/skills/$_skill" \
          "${PLUGIN_ROOT:-$HOME/.vibe/skills}/$_skill"; do
  [ -n "$_c" ] || continue
  # Some stagers (ADK eval) nest the bundled files under <skill>/artifacts/.
  for _r in "$_c" "$_c/artifacts"; do
    [ -f "$_r/scripts/fetch_dc.py" ] && { SKILL_ROOT="$_r"; break 2; }
  done
done
[ -f "${SKILL_ROOT:-}/scripts/fetch_dc.py" ] || { echo "$_skill: scripts not found — set SKILL_ROOT to this skill's directory" >&2; exit 1; }
prefix="$SKILL_ROOT/scripts"
```

Every subsequent invocation in this doc uses `"$prefix/..."`.

## Session discovery (no id yet)

When the user doesn't have a session id, run `discover_sessions.py` against the STDM session DMO. Prints a numbered picker; user picks one; proceed with the chosen UUID.

```bash
python3 "$prefix/discover_sessions.py" [--org <alias>] [filters...]
```

**`--org` is optional.** "My org", "our org", or no alias at all means the sf CLI default target org — omit `--org` and the script uses `sf config get target-org`. Pass `--org <alias>` only when the user names an alias. If no default is set the script exits with "no --org given and no default target org set"; relay its `sf config set target-org <alias>` hint and ask the user for an alias.

**Filters** (all optional): `--since <expr>` (default last 24h; accepts "last 2 hours", "today", ISO dates), `--agent <api-name>`, `--channel <Messaging|Builder|Voice>`, `--outcome <USER_ENDED|ESCALATED|TRANSFERRED|TIMEOUT|NOT_SET>`, `--grep <substring>` (conversation text), `--tz <IANA>`, `--limit <N>` (default 20).

**Output**: markdown table with `#`, `UUID`, `Start (UTC)`, `Agent`, `Channel`, `Duration`, `Outcome`. User replies with a number; proceed with that UUID.

## Pipeline — three stages

```text
fetch_dc.py     →  24 dc.<name>.json + dc._session_manifest.json 

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/forcedotcom/sf-skills
git -C sf-skills checkout 154bf6698c29

Works in

1. 2026-10-23
   ✓SAFE B 89 / 100

   first audit · source 154bf6698c29

Questions about agentforce-d360-analyze

• github.com/forcedotcom/sf-skills/tree/main/skills/agentforce-d36 — the audited source at commit 154bf6698c29 and every finding aboveObserved · 23 Oct 2026

Spotted something wrong? Report a correction · Methodology