---
name: analyze
description: Read-only pattern analysis of change requests. Produces a triage report; does NOT edit files or run git.
arguments: []
---
You are doing a read-only pattern analysis of change requests for a PinAppAI
project. Do NOT edit any files. Do NOT touch git. Your output is a written
triage report.

If the user mentioned a CR-type filter (e.g. "include rejected too",
"only /changes/ decisions") or a focus keyword (e.g. "only navbar
stuff") in their message, honor it when building the tool-call
arguments below.

**Default `include` = `['comment', 'change_requested']`.** Why both:

  - `comment` covers free-form widget pins ("make this red", "shorter
    please") — the iteration-loop's primary input. These are kind=comment
    feedbacks; Phase 6.5 dual-writes each into a CR.
  - `change_requested` covers /changes/-page items the reviewer flagged
    with a rewrite. These are kind=decision feedbacks.

Both are "the reviewer wants this changed" — semantically equivalent
for triage purposes. Excluding `comment` (the old default) silently
omits most actionable items in the iteration-loop world.

Skip `rejected` by default — those are rollback actions handled by
`/pinappai:apply`'s revert branch, not pattern analysis. Skip `approved` —
no action needed.

{{include: _shared/project-resolution.md}}

# Step 1 — Gather

Call `get_review_summary({project: "<resolved slug>"})`.

Then `analyze_patterns({project: "<resolved slug>", include: ["comment", "change_requested"], ai_clusters: "auto"})`
(adjust `include` if the user requested otherwise above).

If the response includes an `ai_clustering_hint` (sampling not available),
spend a small amount of reasoning to apply that hint inline against the
deterministic groupings before proceeding.

# Step 2 — Drill into top 3 clusters

For each of the top 3 clusters (highest confidence × CR count), call
`get_change_request({id: ...})` on 1-2 representative CRs to read full body
and `related[]` context.

# Step 3 — Synthesize per cluster

For each cluster, write a SINGLE merged action that addresses ALL the
non-contradicting CRs in it. The merge rules:

- A `suggested_text` rewrite that's *shorter* than the original satisfies
  any "make it shorter" comment on the same selector — combine them.
- A style/structural CR ("make it red", "move below the CTA") is
  independent of any text rewrite — combine them additively.
- Two CRs with mutually-exclusive demands (e.g. "more formal" + "casual",
  "blue" + "red", "show this" + "hide this") on the same selector are
  CONFLICTS, not a merge. Do NOT pick one — defer them to the Conflicts
  section below and have the merged action describe only the part that
  *all* CRs in the cluster agree on (often nothing — that's fine).

# Step 4 — Output the triage report (markdown)

```
## Cluster summary
- N total clusters across M change requests
- Confidence breakdown: X high, Y medium, Z low

## Top clusters (in priority order)
### Cluster N: [Label]
- **Affected**: <selectors>, <pages>, <reviewer count>
- **Root cause hypothesis**: <from your reasoning>
- **Sample CRs**: bullet list with one-line summaries
- **Merged action**: a single change addressing every non-contradicting
  CR in this cluster (per Step 3 merge rules). 1-3 lines max.
- **Effort estimate**: small / medium / large

## Outliers
Standalone CRs that didn't cluster.

## Conflicts to resolve
CRs that target the same selector with mutually-exclusive intent.
Resolve before running `/pinappai:apply`. Format:
- `<selector>` — CR `<id>` ("<short summary>") vs CR `<id>` ("<short summary>").
  Recommendation: <pick one + reason, or "merge into a third option that
  satisfies neither extreme">.

If no conflicts, write "None — all clustered CRs are complementary."

## Recommended next step
Suggest /pinappai:apply (proceed) or "Resolve conflicts first"
when the Conflicts section is non-empty.
```

This is a report, not a plan. Don't propose code changes here.

{{include: _shared/output-language.md}}