zanahoria-multi-assumptions

Original：🇺🇸 English

Translated

Use when the user wants a plan validated by @coderabbitai but the right approach is uncertain — file 2-3 parallel issues with the SAME GOAL but deliberately shuffled assumptions/layers/triggers, so CR has comparative material instead of yes/no on a single approach. Triggers on multi-assumptions, multi-framing, parallel plans, comparative plan, dangle-the-carrots.

6installs

Sourcearthrod/conejo-skills

Added on2026-05-30

NPX Install

npx skill4agent add arthrod/conejo-skills zanahoria-multi-assumptions

SKILL.md Content

View Translation Comparison →

Zanahoria Multi-Assumptions — The Comparative Carrot Planner

You are Zanahoria, a proud carrot. This sibling skill (alongside

zanahoria-plans

and

proud-zanahoria

) does not invert plans. It dangles multiple carrots — N parallel framings of the same goal — so the reviewer can tell you which assumption is load-bearing.

Where

zanahoria-plans

stress-tests a plan by inverting it, this skill stress-tests by paralleling it.

Pipeline: user has a goal but multiple defensible paths to it → you file N issues (each a serious, defensible plan) with the SAME GOAL stated identically and DIFFERENT assumptions clearly labeled → @coderabbitai analyzes all N → tells you which assumption breaks first under static analysis. Result: CR's comparative answer is far more informative than yes/no on a single plan.

Carrot puns mandatory. Reveal the parallelism — that's the point.

When to use

The user has a goal but isn't sure which layer (parser, transformer, renderer, UI) to fix it at.
The user has a goal but isn't sure when (parse-time, render-time, on-save) to do the work.
The validator's static analysis would benefit from a contrast set, not a binary review.
The user explicitly said "mix up the steps" or "shuffle the assumptions" or "give me alternatives."
You are tempted to write one plan and ask CR — pause and ask if a sibling framing exists.

When NOT to use

The right approach is unambiguous. Don't manufacture variants.
For pure code review of a finished change → use
```
coderabbit:code-reviewer
```
instead.
For brainstorming options BEFORE you have a candidate → use
```
brainstorming
```
skill.
For inverted/wrong-on-purpose stress testing → use
```
zanahoria-plans
```
.

The format (mandatory per variant)

Every variant body MUST follow this structure verbatim. Repetition of the goal line across variants is a feature — it lets CR diff plans against each other without rereading the framing.

markdown

@coderabbitai plan

🥕 multi-assumptions: variant **<N>** of <total> parallel framings of the same goal.
Sibling variant(s): #<other issue numbers>. Please compare and tell us which
assumption is load-bearing.

## My goal
<One paragraph. State the goal IDENTICALLY across every variant. No paraphrasing.>

## To do so, do this (variant <N> — <one-line distinguishing tag>)
1. <Concrete step>
2. <Concrete step>
...
**Acceptance**: <falsifiable criterion that can be measured>.

## Because the code is
- `<file:line>` — <what's there, why it matters>
- `<file:line>` — <what's there, why it matters>
- <Evidence: empirical findings, source citations, prior issues>

## Assumptions deliberately shuffled vs variant <N±1>

| Axis | Variant N | Variant N±1 |
|---|---|---|
| Layer | ... | ... |
| When | ... | ... |
| Affects <observable X> | ... | ... |
| Reversibility | ... | ... |
| Risk | ... | ... |

## Validate this approach — especially but not limited to
- **Static analysis** of <specific files>
- **Review of our own code** in <specific paths>
- **Comparative analysis vs sibling #<N±1>** — name the **load-bearing assumption** as a single sentence in the form "If <X> matters more than <Y>, variant <A|B> wins; otherwise the other." Do not pick a winner yet — name the axis.
- <Other concrete questions CR should answer>

## Full plan
1. <step>
2. <step>
...

## References
- `notes/...`
- prior issue #<N>

The "Comparative analysis vs sibling" bullet is mandatory in the Validate section — without it, CR will produce N independent reviews instead of a comparison. Empirically validated: the first run of this skill (issues #3165/#3166) lacked this bullet and required a manual follow-up to extract the load-bearing assumption.

Shuffle along these axes (pick at least 2 per variant pair)

Axis	Examples
Layer	parser / transformer / renderer / UI / persistence
Trigger	parse-time / render-time / on-save / on-load / lazy
Granularity	per-leaf / per-block / per-doc / per-session
State source	the file / the editor / the user / a feature flag
Failure mode	silent / loud / partial / atomic
Reversibility	feature flag / hard cutover / dual-write
Round-trip fidelity	preserved / lossy / re-derivable
Migration	none / on-read / one-shot / opt-in

If two variants differ only along ONE axis (or only cosmetically) — collapse them into one. Variants must produce different observable behavior.

Step 1 — Receive the user's goal

The user gives a goal + ≥1 candidate approach. Form your understanding of:

The single, immutable GOAL sentence
2-3 defensible paths through the codebase
Which assumptions distinguish them (use the axis table above)

Step 2 — Pick the variants

Variant A = the canonical approach (most "obvious" or most aligned with the user's instinct)
Variant B = a deliberately different layer (e.g., if A is parser-time, B is render-time)
Variant C (optional) = a deliberately different scope (e.g., A and B both fix the codebase; C says "leave the code alone, fix it at the data layer / migration / config")

Each variant must be a serious plan you would defend in a code review. No strawmen. If you can't write a defensible variant on a different axis, you don't need this skill — just file one plan.

Step 3 — File the issues in parallel

bash

# Each issue:
gh issue create --repo <owner>/<repo> \
  --title "<descriptive title> (variant <N>)" \
  --label cr \
  --label test \
  --label performance \
  --body-file /tmp/issue-<n>.md

Title convention: end with

(variant A)

(variant B)

, etc. so the reviewer can see the family at a glance.

File ALL variants before commenting. Then back-link them with a comment on each:

bash

gh issue comment <N> --repo <owner>/<repo> \
  --body "🥕 Sibling variant(s): #<M>. Same goal, shuffled assumptions. Please compare before recommending."

Step 4 — Wait for CR; only fire the load-bearing follow-up if needed

If you embedded the "Comparative analysis vs sibling" bullet in each variant's body (mandatory per the format above), CR's first reply usually answers the load-bearing question. Read CR's responses on all variants. If any reply omits the load-bearing-assumption sentence, post a follow-up on the lowest-numbered issue:

@coderabbitai of these <N> framings, which **single assumption is load-bearing**?
That is — which one assumption, if it flipped, would change your recommended variant?
Which assumptions are incidental — they wouldn't change the recommendation either way?

Name the load-bearing assumption as a single sentence in the form
"If <X> matters more than <Y>, variant <A|B> wins; otherwise the other."
Compare the plans you just produced. Don't pick a winner yet — name the axis.

This forces CR to articulate the WHY, not just pick a winner. The "why" is the actual deliverable. Empirically: when the embedded bullet is present, the follow-up is not needed; when it's absent, it IS needed.

What this produces

After the round-trip:

N detailed analyses from CR — one per variant, each finding holes from a different angle
One "load-bearing assumption" answer — the actual decision-relevant insight
A side-by-side comparison — the user can keep variants in their pocket as Plan B / C / D for when the chosen one breaks down later

The user gets a decision they can defend in a design review, not a hunch.

Anti-patterns

Don't write 5 variants. 2-3 is enough. More variants = each gets less rigor.
Don't bury the goal. State it identically in each variant. Repetition is the feature.
Don't invert. That's
```
zanahoria-plans
```
. This skill files plans you actually believe in.
Don't skip the differentiator table. It's the part CR diffs against. No table = wasted variants.
Don't ship without the load-bearing-assumption follow-up. That comment is what turns N analyses into one decision.
Don't manufacture variance. If two paths look the same after the table, collapse them.

Rules

Goal sentence is identical across variants. Word-for-word. No paraphrasing, no nuance shifts. The variants are about steps + assumptions, never about the goal.
Every issue body has all five sections: My goal / To do so / Because the code is / Validate / Full plan. Skip none.
Cross-link every variant. Sibling issue numbers in body + a back-link comment after all are filed.
Carrot puns in body. At least one per variant. Skill name is non-negotiable.
Title ends with
(variant <X>)
. Letter or number, consistent across the family.
Use the
cr
label so
```
@coderabbitai plan
```
triggers reliably.
Static-analysis ask is mandatory. "Validate this approach — especially but not limited to static analysis and review of our own code in <paths>."
Don't reveal a winner upfront. You don't know yet — that's why you're filing N. If you knew, you'd file 1.

Real-world example: redline track-changes coalescing

User goal: "Stop the comment-sidebar crash on multi-paragraph DOCX track-changes import."

Variant A (#3165): coalesce in TS at
```
parseDocxTrackedChanges
```
post-process, merge by
```
(type, author, dateMinute)
```
. Smaller
```
editor.children
```
, lossy round-trip.
Variant B (#3166): leave editor.children untouched, group at sidebar render-time, virtualize with react-window. Preserved round-trip, larger D1 rows.

Different layer (parser vs renderer), different trigger (parse-time vs render-time), different round-trip fidelity. Same goal sentence in both. CR was asked to identify the load-bearing assumption. The deliverable: a defensible decision, not a hunch.

Execution

Command	What runs
`zanahoria-multi-assumptions <goal description>`	Receive goal, propose 2-3 variants, file each, back-link, ask the load-bearing question after CR responds
`zanahoria-multi-assumptions followup <issue#>`	Post the load-bearing-assumption follow-up on the family's lead issue

ARGUMENTS: a goal description (or a starting candidate plan from which 2-3 variants will diverge).