---
name: multi-agent-complaint-analysis
description: "Customer-complaint triage. Ingests complaints (paste, csv/xlsx/txt/json file, Jira issue, Confluence URL), fetches Graylog evidence per trx/conversation id, correlates read-only against the selected client + BFF repos; per complaint: client/bff root cause + fix plan + dev prompt, or core routing recommendation, or insufficient-evidence. Report only, no dev chaining. Use when customer-reported errors need layer triage."
user-invocable: true
argument-hint: "[\"<run-name>\"] [--file <path>] [<jira-id | jira-url | confluence-url> ...]"
metadata:
  language: en
---

# multi-agent-complaint-analysis - Customer Complaint Triage

**Input**: $ARGUMENTS (optional run name, optional `--file <path>`, optional Jira ids / Confluence URLs; remaining free text = pasted complaints)

Triage of customer-reported errors across the layers the team owns. Per complaint: Graylog evidence by trx/conversation id, read-only repo correlation, and a verdict. Core failures get a routing recommendation to the backend core team, never a fix analysis. **Independent and read-only**: no branches, worktrees, commits, PRs, or dev chaining - the run ends at the report.

## When to use

- A batch of customer complaints / store reviews / support tickets needs to be mapped to responsible layers (ios / android / web / mobile-bff / web-bff vs backend core)
- Production error reports carry trxId / conversationId values worth pulling from Graylog
- The team needs a forwardable routing record for core-side failures

## Key rules

- Graylog is the primary evidence in this command (deliberate departure from the dev pipeline's advisory-only rule); a failed fetch degrades that complaint to `insufficient-evidence`, never halts the run.
- Ids are never guessed: complaints without trx/conv ids trigger a supply-or-skip prompt.
- Complaint text is redacted at intake (email / phone / card / national-id shapes and 6-character reservation or order reference codes); raw PII never reaches state or any output.
- Core is a residual classification, not a repo: no core-repo grepping, no fix speculation.
- Client/bff verdicts carry a development handoff: a fix plan referencing the existing architecture (`file:line` reuse-first steps) plus a fenced English dev prompt ready for the dev pipeline or a Jira description. The command still never runs dev itself.
- Output default is Local file; Confluence / Jira are posted only on request. Never closes or transitions issues.

## Flow

| Phase | Action |
|---|---|
| 0. Intake | Run name + account picker + repo multi-select + layer-tag confirmation + multi-source complaint ingestion (`lib/parse-complaints.sh`) + id confirmation loop |
| 1. Graylog | Per-complaint `lib/fetch-graylog.sh --trx/--conv`; credential/host failure degrades and continues |
| 2. Correlate | Extract signals (endpoints, error codes, exceptions, source services) from Graylog hits; read-only grep across selected repos |
| 3. Triage | Verdict per complaint: `client:<layer>` / `bff:<layer>` (citations + fix plan grounded in the existing architecture + ready-to-run dev prompt) or `core` (routing recommendation) or `insufficient-evidence` |
| 4. Draft | Render 8-section report, humanizer pass, punctuation gate |
| 4.5 Output picker | Local file (default) / Confluence page / Jira comment (asked only after the draft exists) |
| 5. Dispatch | `validate-complaint-doc.mjs` gate, write/post, verdict-count summary. **Stop.** |

Pickers route through `lib/ask-choice.sh` per the picker contract.

## Detailed implementation

Full steps: the Claude-side command doc for `complaint-analysis` (same phase structure and locked decisions).
Report template: `complaint-analysis-template.md` (8 sections; routing section required per core verdict).
State schema: `schemas/complaint-analysis-spec.schema.json`.
Report gate: `scripts/validate-complaint-doc.mjs` (front-matter, sections, verdict tokens, routing entries, punctuation, redaction-leak scan).