---
name: rice-strats
description: >-
  RICE-score RHAISTRAT or RHOAISTRAT Feature tickets in Jira. Researches each ticket's
  description, strategy attachments, review docs, linked RFEs, and comments, then sets
  Reach/Impact/Confidence/Effort fields and posts a justification comment. Use this skill
  whenever the user wants to set RICE scores, prioritize strats, score features, rank
  RHAISTRAT tickets, or says things like "RICE score these tickets", "set RICE for
  RHAISTRAT-XXXX", "prioritize these strats", "score the children of RHAISTRAT-XXXX",
  or provides a list of RHAISTRAT/RHOAISTRAT ticket keys to be scored. Also use when the
  user mentions "RICE" in the context of Jira strategy tickets.
---

# RICE Scoring for RHAISTRAT/RHOAISTRAT Features

Score Jira strategy Feature tickets using the RICE prioritization framework. Each ticket
gets deep research (description, attachments, linked RFEs, comments, strategy review
results) before scores are set, ensuring scores reflect actual evidence rather than
surface-level summaries.

## Reference Files

Read these before scoring:
- `references/rice-rubric.md` — Full RICE rubric with scoring scales and guidance
- `references/jira-fields.md` — Jira custom field IDs, API examples, dropdown option IDs
- `references/agent-prompt-template.md` — Template for dispatching parallel scoring agents

## Input Formats

The user may provide tickets in several ways:

1. **Explicit list**: `RHAISTRAT-1745, RHAISTRAT-1746, RHAISTRAT-1747`
2. **Parent ticket**: "Score the children of RHAISTRAT-1312"
3. **Single ticket**: "RICE score RHAISTRAT-1745"
4. **Mixed**: "Score RHAISTRAT-1745 through 1750"

When given a parent ticket, fetch its children via the Jira search API:
```bash
curl -s -u "$JIRA_USER:$JIRA_TOKEN" "$JIRA_SERVER/rest/api/3/search/jql" \
  -H "Content-Type: application/json" \
  -d '{"jql": "parent = RHAISTRAT-XXXX ORDER BY key ASC", "fields": ["summary","status","issuetype","customfield_10862","customfield_10836","customfield_10838","customfield_10637","customfield_10864"], "maxResults": 50}'
```

## Workflow

### Step 1: Discover and Triage

1. Resolve the full list of tickets to score (expand parent references, parse ranges)
2. Fetch basic info for all tickets in the set — summary, current RICE scores, status
3. Separate into two groups:
   - **Already scored**: Tickets that have all 4 RICE fields populated
   - **Needs scoring**: Tickets missing any RICE field
4. Report the triage to the user:
   - How many tickets total, how many already scored, how many need scoring
   - List the already-scored tickets with their current RICE values as calibration data
   - List the tickets that need scoring

### Step 2: Build Calibration Data

Collect RICE scores from all already-scored sibling tickets (under the same parent). These
serve as calibration anchors so new scores are positioned consistently relative to existing
ones. Format as:

```
- RHAISTRAT-XXXX (Summary): R=X, I=X, C=XX%, E=X, RICE=X.X
```

Sort by RICE score descending. This calibration table is included in every agent prompt.

### Step 3: Research and Recommend Scores

**For 1-2 tickets**: Research inline — fetch the full ticket, analyze it, and produce
recommended scores. No sub-agents needed.

**For 3+ tickets**: Use parallel sub-agents. Read `references/agent-prompt-template.md`
for the template. For each ticket:

1. Build the agent prompt by filling in the template:
   - `{{TICKET_KEY}}` — the Jira key
   - `{{CALIBRATION_TABLE}}` — the calibration data from Step 2
2. Dispatch via the Agent tool with `run_in_background: true`
3. Wait for all agents to complete
4. Collect results

Each agent independently:
- Fetches the full ticket (description, attachments, links, comments)
- Downloads and reads strategy and review attachments
- Checks linked RFEs for approval status, priority labels, customer evidence
- Reads all comments for reviewer feedback and strategy review scores
- Applies the RICE rubric
- Reports back with recommended R, I, C, E values and detailed justification

Agents do NOT write to Jira in this step — they only research and recommend.

### Step 4: Present for Approval

After all agents report back, present the recommendations to the user for review:

1. Show a consolidated summary table of recommended scores:

```
| Ticket | Feature | R | I | C | E | RICE | Notes |
|--------|---------|---|---|---|---|------|-------|
| RHAISTRAT-XXXX | Summary | X | X | XX% | X | X.X | Key rationale |
```

2. For each ticket, include a brief justification summary (key evidence, calibration
   context, any re-scoring triggers)
3. Ask the user to approve, adjust, or skip each ticket:
   - **Approve**: Scores will be submitted as-is
   - **Adjust**: User provides modified values (e.g., "change 1748 Impact to 8")
   - **Skip**: Ticket will not be updated in Jira

Do NOT proceed to Step 5 until the user explicitly approves. If the user adjusts any
scores, recalculate the expected RICE score and confirm the adjusted values before
submitting.

### Step 5: Submit to Jira

After user approval, submit the approved scores:

1. For each approved ticket, set all 4 RICE fields via the Jira API:
   ```bash
   curl -s -u "$JIRA_USER:$JIRA_TOKEN" -X PUT "$JIRA_SERVER/rest/api/3/issue/RHAISTRAT-XXXX" \
     -H "Content-Type: application/json" \
     -d '{"fields":{"customfield_10862": REACH, "customfield_10836": IMPACT, "customfield_10838": {"id":"CONFIDENCE_ID"}, "customfield_10637": EFFORT}}'
   ```
2. Post a "RICE SCORE JUSTIFICATION:" comment using ADF format with the rationale table
3. Verify the auto-calculated RICE score matches expectations: (R x I x C) / E

If 3+ tickets are approved, submit in parallel using sub-agents (one per ticket). Each
agent sets fields, posts the comment, and verifies.

### Step 6: Verify and Report

After all approved tickets are submitted:

1. Fetch current RICE scores for all tickets in the set (both previously scored and newly scored)
2. Present a consolidated summary table ranked by RICE score:

```
| Rank | Ticket | Feature | R | I | C | E | RICE |
|------|--------|---------|---|---|---|---|------|
| 1 | RHAISTRAT-XXXX | Summary | X | X | XX% | X | X.X |
```

3. Highlight patterns:
   - Which tickets score highest and why (high value/low effort quick wins)
   - Which are dragged down by high effort or low confidence
   - Dependencies between tickets (e.g., ticket A unblocks ticket B)
   - Tickets where scores could change based on pending investigations

## Scoring Principles

These are learned from scoring ~20 RHAISTRAT tickets. They prevent common mistakes.

### Calibrate, don't score in isolation
Every score should be justified relative to sibling tickets. "R=8 because this affects a
similar user population to RHAISTRAT-1533 (Chat Persistence, R=8)" is better than "R=8
because it affects many users." Siblings under the same Outcome share a user population,
so their scores should form a coherent ranking.

### Trust strategy reviews over original estimates
Strategy attachments often include original PM sizing estimates (S/M/L/XL). Strategy
review comments frequently revise these — sometimes dramatically. When the review
recommends a different size, trust the review. It reflects multi-reviewer assessment
including engineering delivery leads.

### Confidence reflects evidence quality, not feature importance
A must-do feature can still be 50% confidence if the technical approach is unvalidated
or upstream dependencies are unresolved. Confidence measures how certain you are about
Reach and Impact estimates, not how much you want the feature to ship.

### Effort captures coordination cost
A feature touching 5 teams at E=5 is different from a single-team feature at E=5. Both
are valid — the multi-team version has coordination overhead, while the single-team
version has deep technical complexity. Read strategy reviews for team counts and
dependency chains.

### Flag re-scoring triggers
When a score is suppressed by uncertainty (low confidence due to an unresolved spike, or
high effort due to an unvalidated dependency), note in the justification comment what
would change the score. "If the OGX spike confirms native support, effort drops from 5
to 3, raising RICE from 3.75 to 6.25." This makes scores actionable.

## Error Handling

- **Ticket not found**: Report the error and continue with remaining tickets
- **RICE fields already set**: Skip unless user explicitly asks to re-score
- **API auth failure**: Check that JIRA_USER and JIRA_TOKEN env vars are set. Suggest the user run `! export JIRA_TOKEN=<token>` if missing
- **No attachments**: Score based on description, linked RFEs, and comments alone. Note reduced confidence in the justification
- **Effort = 13**: Flag to the user — this means the feature must be broken down before it can be meaningfully scored