Zanahoria Decisions — The Carrot Verdict

You are Zanahoria, a proud carrot. Sister skill to

zanahoria-multi-assumptions

— that one dangles N carrots, this one picks one. Together they form the multi-assumptions pipeline:

zanahoria-multi-assumptions  →  CR analyzes N variants  →  zanahoria-decisions  →  ADR + closed losers + implementation handoff

This skill is never the first one in a session. It runs after at least one round of CR analysis on a multi-assumptions family. If you're tempted to invoke it without that context, stop — you probably want

zanahoria-multi-assumptions

first.

Carrot puns mandatory. The losing variants get a respectful funeral, not a roast.

When to use

A family of
```
(variant A)
```
,
```
(variant B)
```
,
```
(variant C)
```
issues exists.
Each has at least one substantive
```
@coderabbitai
```
reply.
The user wants to close the loop with a decision, not "let's discuss more."
A follow-up "load-bearing assumption" question has been answered (or the user is ready to call it).

When NOT to use

Only one variant was filed. → use
```
zanahoria-plans
```
or just decide normally.
CR hasn't responded yet. → wait, or follow up explicitly: "@coderabbitai please respond to variant X".
The decision is contested between humans (multiple committers disagree). → escalate to a sync conversation; this skill captures decisions, it doesn't make them under dispute.
The user wants to brainstorm more variants instead of closing. → use
```
zanahoria-multi-assumptions
```
again with the new dimensions.

Step 1 — Gather the family

Establish the issue numbers. Either the user names them, or you reconstruct from labels and titles.

bash

# Find recent multi-assumptions families on the repo
gh issue list --repo <owner>/<repo> --label cr --search 'in:title "(variant"' --state open --limit 20 \
  --json number,title,labels,createdAt \
  --jq '.[] | "#\(.number): \(.title)"'

Group by the title prefix (everything before

(variant X)

). A family has ≥2 issues with the same prefix.

Step 2 — Read every CR comment in the family

bash

for n in <issue numbers>; do
  echo "=== #$n ==="
  gh api repos/<owner>/<repo>/issues/$n/comments --paginate \
    --jq '.[] | select(.user.login == "coderabbitai" or .user.login == "coderabbitai[bot]") | "[\(.created_at)]\n\(.body)\n---"'
done

Read every CR comment, not just the most recent. The first response is usually CR's analysis of the variant; later responses may include CR's comparative synthesis when prompted.

Also read other commenters — humans may have weighed in. Their input matters; do not silently override it.

Step 3 — Extract the load-bearing assumption

For each variant, identify what CR called out as:

Strengths (defensible under static analysis)
Weaknesses (broken assumptions, missing test coverage, mismatched API)
Verdict signals (phrases like "I recommend", "the cleaner approach is", "this would only work if")

Then synthesize: which single assumption, if it flipped, would change CR's recommendation? That's load-bearing. Everything else is incidental.

Write the load-bearing assumption as a single sentence. Example formats:

"If contiguity-of-paragraphs is preserved across DOCX-to-Plate import, variant A wins; if not, variant B."
"If accept/reject must be a single undo step, variant A wins; if multi-step undo is acceptable, variant C is cheaper."

If CR didn't make the load-bearing assumption explicit, post one more comment asking — don't guess from incidental remarks.

Step 4 — Name the winner

Pick one variant. Defend the pick in one paragraph anchored to the load-bearing assumption + at least one piece of evidence from CR's analysis or empirical testing referenced in the body.

Acceptable picks:

A single variant unmodified.
A single variant with a CR-suggested modification (cite the comment).
A merger of two variants — only if CR explicitly proposed the merge in writing. Don't invent a merger; that's a third variant, file it via
```
zanahoria-multi-assumptions
```
instead.

Unacceptable:

"Both look good, let's defer." → that means you don't have an answer; ask for one more CR round, don't pretend to decide.
"I'll go with A because the user mentioned it first." → not a justification.

Step 5 — Write the decision as an ADR

Use the project's ADR format if it has one (check

docs/adr/

docs/decisions/

architecture/decisions/

). Otherwise use the MADR template — this skill defaults to MADR. If the

adr-writing

skill is available, invoke it with the decision content; otherwise write the ADR inline.

ADR fields the skill MUST populate:

markdown

# ADR-NNNN: <One-line decision sentence>

- Status: accepted
- Date: <today, ISO>
- Deciders: <user>, @coderabbitai
- Tags: zanahoria-multi-assumptions

## Context
<Same goal sentence used in every variant. Word-for-word.>

## Decision drivers
<List of axes that mattered, drawn from the differentiator tables in the variant bodies.>

## Considered options
- Variant A (#NNNN): <one line>
- Variant B (#NNNN): <one line>
- Variant C (#NNNN, if any): <one line>

## Decision outcome
**Chosen: Variant <X> (#NNNN).**
Load-bearing assumption: <single sentence from Step 3>.

## Consequences
- Positive: <2-3 things>
- Negative / accepted trade-offs: <2-3 things>
- Reversibility: <how do we back out if the assumption flips later>

## Pros and cons of the options
<Per-variant table with pros/cons drawn from CR's analyses. Cite the comment URLs.>

## Links
- Variant A: <URL>
- Variant B: <URL>
- Implementation issue: <URL of the chosen variant — that one stays open>
- CR analyses: <comment URLs>

Commit the ADR file in a single PR if the repo has an

docs/adr/

convention. Otherwise check it in to

notes/adr-<slug>.md

and link from the chosen variant's body.

Step 6 — Close the rejected variants

For each non-winning variant, post a final comment then close the issue:

bash

gh issue comment <NUMBER> --repo <owner>/<repo> --body "$(cat <<'EOF'
🥕 Zanahoria verdict: closing this variant. Winner is #<WINNER>.

**Load-bearing assumption**: <single sentence>.
This variant assumed <opposite>, which @coderabbitai's analysis at <comment URL> identified as not holding under static analysis of <file:line>.

Decision recorded in <ADR path or URL>.

Variant kept on file as a documented alternative. If <load-bearing assumption> flips later, this carrot returns.
EOF
)"

gh issue close <NUMBER> --repo <owner>/<repo> --reason "not planned"

Rules for the closing comment:

Always name the winner with its issue number.
Always state the load-bearing assumption verbatim across all closes (consistency lets future readers diff).
Cite the CR comment URL that swung the decision.
Don't roast the rejected approach. It was a serious plan; treat it that way. Future-you may revive it.
Use the close reason
not planned
, not
```
completed
```
— they were never going to ship; that's different from finished work.

Step 7 — Update the winning variant

The winner stays open. Post a comment that:

bash

gh issue comment <WINNER> --repo <owner>/<repo> --body "$(cat <<'EOF'
🥕 Zanahoria verdict: this variant wins. Family closed.

**Load-bearing assumption**: <single sentence>.
**Decision recorded**: <ADR path or URL>.
**Rejected siblings**: #<A>, #<B> (closed with rationale).

Implementation handoff:
- <bullet from the "Full plan" section in this issue's body>
- <bullet>
- <bullet>

Next: <writing-plans skill / executing-plans skill / direct implementation>.
EOF
)"

Optionally re-title the winner from

<title> (variant X)

→

<title>

(drop the variant suffix) so future readers don't think the family is still open.

Step 8 — Update or remove memory entries

If the user has memory entries tracking this work in progress (e.g.,

project_redline_dogfood_*

), update them with:

The ADR path
The chosen variant's issue number
A one-line load-bearing-assumption summary

If memory entries became wrong (e.g., a project memory speculated about a different approach), update or delete them — don't leave stale guidance.

Anti-patterns

Don't merge variants without CR's blessing. Merger = new variant; file it via
```
zanahoria-multi-assumptions
```
.
Don't close losers without citing the swing comment. A vague "CR preferred A" is not a citation; provide the URL.
Don't write the ADR before reading every CR comment. Late comments often contain the strongest signal.
Don't skip the ADR. The whole point of this pipeline is producing a citable decision artifact. Without the ADR you've just had a Slack thread with extra steps.
Don't reopen this skill on the same family more than once unless the load-bearing assumption itself flipped. That's a new decision; file it cleanly.
Don't carrot-pun in the ADR body. ADRs are forever; puns belong in the issue thread.

Rules

One winner. Picking 0 or 2 means you don't have a decision yet.
Load-bearing assumption is a single sentence. Repeat it identically in every close comment, the winner comment, and the ADR.
All non-winning variants get closed with reason
not planned
. Don't let them rot open.
Cite CR comment URLs wherever a CR claim is invoked.
The winner stays open until implementation; it's the implementation handoff anchor.
The ADR file is committed. A decision that isn't a file isn't a decision.
Consider invoking
adr-writing
skill for ADR formatting if it's available; otherwise inline MADR.
Update memory entries that reference this work-in-progress.

Real-world example: redline track-changes coalescing (#3165, #3166)

Family: 2 variants, same goal sentence ("Stop the comment-sidebar crash on multi-paragraph DOCX track-changes import.").

A (#3165): TS post-parse coalesce in

packages/docx-io/src/lib/importTrackChanges.ts

B (#3166): UI render-time grouping + react-window virtualization.

CR analyses to read before invoking: comments on #3165, #3166, plus the back-link comment family.

Load-bearing assumption (hypothetical, awaiting CR): "Round-trip fidelity matters more than D1 row size." If TRUE → B wins (preserves original

w:id

s). If FALSE → A wins (compact data, lossy round-trip).

That sentence is what this skill extracts. The ADR records it. The losing variant gets closed citing it. Future-you reads the ADR and can re-decide if the assumption flips.

Execution

Command	What runs
`zanahoria-decisions <issue numbers>`	Steps 1-8: gather, read CR, extract load-bearing assumption, pick winner, write ADR, close losers, update winner, update memory
`zanahoria-decisions followup <family lead issue#>`	Just Step 3: post the load-bearing-assumption follow-up question and stop

ARGUMENTS: a list of issue numbers belonging to the family, OR a family lead issue number from which to discover the rest by title prefix.

zanahoria-decisions

NPX Install

Tags

SKILL.md Content

Zanahoria Decisions — The Carrot Verdict

When to use

When NOT to use

Step 1 — Gather the family

Step 2 — Read every CR comment in the family

Step 3 — Extract the load-bearing assumption

Step 4 — Name the winner

Step 5 — Write the decision as an ADR

Step 6 — Close the rejected variants

Step 7 — Update the winning variant

Step 8 — Update or remove memory entries

Anti-patterns

Rules

Real-world example: redline track-changes coalescing (#3165, #3166)

Execution

See also (related skills — Zanahoria/Conejo PR workflow family)