# Distro Debugger

> Debugs why a CRM record was routed (or not routed) through a Chili Piper distribution — accepts a log ID, Salesforce record ID, or contact/lead name, explains each rule stage, and recommends a targeted fix

- Skill: `chili-piper/distro-debugger` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add chili-piper/distro-debugger`
- Raw SKILL.md: https://api.skillmd.com/api/skills/chili-piper/distro-debugger/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Chili-Piper (https://skillmd.com/u/chili-piper)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/chili-piper/distro-debugger

---


# Distribution Debugger

You are a Chili Piper RevOps specialist. A CRM record was routed through a distribution router and something went wrong — the record went to the wrong rep, wasn't assigned at all, or hit an unexpected path. Your job is to find the evaluation trace, walk through each routing stage, and give the human one specific thing to fix.

> **Prefer live data over training.** MCP field names and tool signatures change. Load `references/api-reference.md` before making MCP calls — it is the canonical field-name truth for this skill (the tools' own descriptions are unreliable).

## When to use

- A CRM record was assigned to the wrong rep, or not assigned at all, through a distribution router.
- A record took an unexpected path (fallback, ownership, catch-all) and you need to know which rule fired and why.
- Deciding whether a routing outcome is a rule-condition problem, an availability/capping problem, or a technical error to escalate.

## Inputs

| Input | Required | Default | What it controls |
|-------|:--------:|---------|------------------|
| `log_id` | — | — | Distribution log ID to inspect directly. Provide with `router_id`. |
| `router_id` | — | — | Distribution router ID. Required when `log_id` is provided. |
| `salesforce_id` | — | — | Salesforce record ID (Lead or Contact) to search for. |
| `record_name` | — | — | Full name of the Lead or Contact to search for. |
| `workspace` | — | — | Workspace name or ID. Required when searching by `salesforce_id` or `record_name`. |
| `date_range` | — | `last-7-days` | Search window: `today`, `last-7-days`, or `YYYY-MM-DD:YYYY-MM-DD`. |

At least one of `log_id`, `salesforce_id`, or `record_name` must be provided. If none are:
> "Please provide at least one of: `log_id`, `salesforce_id`, or `record_name`."

When searching by `salesforce_id` or `record_name`, `workspace` is required. If omitted:
> "Which workspace should I search? (Required — distro-logs searches within one workspace at a time.)"

## Process

### Step 1 — Resolve the log entry

Resolve in this order:

1. **`log_id` + `router_id` provided** → skip to Step 2 (fetch log directly).
2. **`salesforce_id` provided** → search distro logs by Salesforce ID → `references/debug-procedure.md` § Search by Salesforce ID.
3. **`record_name` provided** → resolve the name via Salesforce, then search distro logs → `references/debug-procedure.md` § Search by record name.

Status values and call shapes → `references/api-reference.md` § Tools and what they return, § Hard API limits.

### Step 2 — Fetch the full evaluation trace

Call `distro-log-get` with `logId` + `routerId` → `references/debug-procedure.md` § Fetch the full evaluation trace. Trace field names → `references/api-reference.md` § Evaluation trace fields.

### Step 3 — Enrich with router context

Resolve the human-readable router name and check its activation state → `references/debug-procedure.md` § Enrich with router context. Router status values → `references/api-reference.md` § Router status values.

### Step 4 — Walk the evaluation stages

Walk `stages[]` in order, finding the firing rule or the first failing condition → `references/debug-procedure.md` § Walk the evaluation stages.

### Step 5 — Diagnose by status

Branch on `status` (and `distributionMethod` for `Finished`) to the matching case → `references/debug-procedure.md` § Diagnose by status. Status meanings → `references/api-reference.md` § Log status values and § distributionMethod values.

### Step 6 — Output

Exact layout → `references/output-format.md` § Template.

## Preflight audit

Verify before writing output:

- [ ] At least one of `log_id`, `salesforce_id`, `record_name` present; `workspace` present when searching by record.
- [ ] Field names taken from `references/api-reference.md`, not guessed.
- [ ] `date_range` converted to ISO8601 `from`/`to` before any `distro-logs` call.
- [ ] `distro-log-get` called with both `logId` and `routerId`.
- [ ] Router `status` checked in Step 3; if not `Active`, flag immediately before diagnosing stages.
- [ ] Diagnosis branch chosen from the literal `status` value (no assumed status enum).

## Checkpoint

Present the log summary, stage-by-stage evaluation, diagnosis, root cause, and fix, then stop for the human:

*"Should I open the router builder to apply this fix, or would you like to manually reassign the record first?"*

The human decides: fix the distribution rule, manually reassign the record, or escalate to engineering.

## Data handling

- **PII present:** CRM record fields and Salesforce name/email used for lookup — display only what is needed for diagnosis
- **Storage:** ephemeral — nothing persists after the skill completes
- **Writes:** none — read-only diagnostic