deep-comparison-analysis

Produce a rigorous pros-and-cons comparison of two technical options and converge on a conclusion. This skill is a comparison-analysis discipline — addressing the three common distortions: mixing variables while comparing, getting pulled off course by external arguments, and assessing advantages in isolation from project scale. The methodology is generic and not tied to any scenario or stack; it can be referenced as the comparison-analysis kernel of tech-selection-convergence (that one defines "what to compare / what to produce"; this skill defines "how to compare rigorously").

When to use

• The user asks "X vs Y, which is better / compare them / why X and not Y / what is the essential difference"
• Candidates are listed in a selection round and need rigorous comparison rather than a list of pros and cons
• The comparison has slipped into dispute with each side holding its line (usually a sign of mixed variables or external arguments)
• It can also be explicitly invoked by tech-selection-convergence during its "scheme comparison" stage

When NOT to use

• Arguing for a single option
• Pure factual lookups
• Open-ended discussion that does not need to converge

Core question: why comparisons get distorted

Three high-frequency distortion patterns, each addressed by one step of this skill's six-step discipline:

Methodology (six steps)

① Split variables

Break all differences between the two options into independent dimensions and list them one by one; do not compare them mixed.

• Typical trap: comparing "batching" and "encoding" together as a single axis; conflating "tooling cost" with "runtime performance".
• Test: for each dimension, can you answer "this difference is attributable to X" without depending on another dimension?

② Compare fairly with controls

Hold all other variables fixed and vary only one at a time; for each difference, mark its true attribution (a "difference attribution" column).

• Bad (unfair): Option A = single send, Option B = batched + binary, with both "batching" and "encoding" changed at once → you cannot see each one's contribution.
• Good (fair): first fix "batching" (both batched) and compare only "encoding"; then fix "encoding" and compare only "batching".
• A fair comparison table must have a "difference attribution" column stating which variable each row's difference comes from.

③ Strip external arguments

Remove non-essential arguments and keep only the technology's intrinsic differences. Four common categories to strip:

What remains after stripping is the real intrinsic difference between the two options.

④ Find the essential difference

Once external arguments are stripped, what is the irreducible difference left? It is often surprisingly thin — one field, one tag, one constant.

• Condense the essential difference into a single sentence: "The two essentially are ____".
• If you cannot condense it to one sentence, ① and ② are not done yet.

⑤ Scale calibration

Place every "advantage" against the project's actual scale: is it a decisive advantage or rounding error?

• Give a quantitative judgment: take the advantage's absolute magnitude (bytes / s, ms / s, KB of memory) and place it against this project's frequency / data volume / link bandwidth — can it even be measured?
• Example: a 100-byte message at 50 Hz, saving 50 bytes = 2.5 KB/s — rounding error next to a video-grade link, but possibly decisive on a low-power wireless link.
• The same "advantage" can flip from decisive to negligible with a different scale, and vice versa. "Better" detached from scale is meaningless.

⑥ Converge honestly

Concede when you should. If one option is strictly better under the current premises (a fixed scale, a fixed data shape, a correct implementation), say so directly; do not force a recommendation for consistency.

• Test: if you flip the premise (e.g., "the data never changes"), does the conclusion also flip? If yes → the conclusion depends on the premise; just state the premise clearly, no need to dodge.
• Anti-pattern: previously recommended A, analysis now shows B is better, so you manufacture reasons for A to avoid "flip-flopping".

Output template

# X vs Y comparison analysis

## 1. Difference dimensions (split variables)
| Dimension | X | Y | Difference attribution (which variable) |
|-----------|---|---|-----------------------------------------|
| ... | ... | ... | encoding / batching / tooling / ... |

## 2. Fair comparison (with controls)
[fixed variable = ?, only varying ?]
| Metric | X | Y | Attribution |
|--------|---|---|-------------|
| ... | ... | ... | ... |

## 3. External arguments stripped
- Stripped: wrong way of writing / future expansion / current convenience / bandwagon
- Remaining intrinsic difference: ...

## 4. Essential difference (one sentence)
The two essentially are ____.

## 5. Scale calibration
| Advantage | Absolute magnitude | Under this project's scale | Verdict |
|-----------|---------------------|---------------------------|---------|
| ... | ... | ... | decisive / rounding error |

## 6. Converged conclusion
Premise: <data shape / scale / implementation assumptions>
Conclusion: <under this premise, X/Y which is better, or equivalent>
Flip condition: <what changed premise would flip the conclusion>

Relationship to other skills

• Referenced by tech-selection-convergence: during its "scheme comparison" stage, it links to this skill as the analysis kernel for "how to compare rigorously"; that one defines "what to compare" (5 dimensions) and "what to produce" (three decision documents). The discipline content lives only in this skill, avoiding duplication and update drift.
• Distinguished from industry-practice-survey: this skill is "compare two of your own options and converge on one" (do I pick A or B); if the goal is to survey external mature industry implementations to borrow (not to compare your own options), see industry-practice-survey — it owns "how others do it, for reference (adopt consensus / avoid shortcomings / make explicit where to surpass)"; this skill owns "do I pick A or B". Selection comparison goes here; industry survey-and-borrow goes there.
• Complementary to comm-link-debugging: the latter is the methodology for "comm link troubleshooting and localization"; this skill is the methodology for "comparison and convergence".

Practice reference (optional, as an appendix example)

The methodology is fully generic. If a project already contains a complete case of "rigorously comparing two technical options and converging" (e.g., comparing two data serialization formats, two async runtimes, two storage schemes), it can be referenced as an appendix example — walk the six steps over that concrete comparison. But the methodology does not depend on any case existing.