Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use when a large feature, story, plan, or spec idea needs to be split into small vertical slices with the Hamburger Method. This should trigger for requests such as Split this oversized story; Find the smallest useful slice; Break this feature into vertical slices; Apply the Hamburger Method; Turn this broad plan into tracked slices. Part of Plinth Toolkit
.claude/skills/jabrena-052-design-hamburger-method/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 30% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 62% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 53% | 0% |
| case-08 | ✗→✓ | ▲ Improved | -3% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 4% | 0% |
Guide Java teams through the Hamburger Method for splitting oversized work into small, valuable, end-to-end vertical slices. This is an interactive SKILL.
What is covered in this Skill?
Split oversized work into vertical slices that deliver observable value, not isolated horizontal technical tasks.
references/052-design-hamburger-method.md before applying the methodRead references/052-design-hamburger-method.md, then restate the large feature, story, plan, or spec idea and why ordinary implementation task decomposition would be too broad, risky, or horizontal.
Identify 3-6 functional or workflow layers needed for observable value. For each layer, generate 4-5 implementation or quality options ordered from the simplest acceptable choice to richer choices.
Ask: "If this had to ship tomorrow, what would be the smallest useful version?" Use the answer to remove options that are too costly, redundant, irreversible, or unnecessary for early learning.
Select one option from each relevant layer to create the smallest useful end-to-end vertical slice. Explain the user-visible value, validation signal, and why rejected layer options wait for later slices.
Propose follow-up vertical slices that incrementally improve quality, automation, robustness, reach, observability, operational behavior, or supported workflows without turning them into isolated technical layers.
Check every slice for value, size, testability, deliverability, and issue-tracking suitability. Route implementation planning through 041-planning-plan-mode, spec-level changes through 042-planning-openspec, GitHub issue work through 043-planning-github-issues, Jira work through 044-planning-jira, and Azure DevOps work through 045-planning-azure-devops.
For detailed guidance, examples, and constraints, see references/052-design-hamburger-method.md.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-07 | pass→pass | 18,738 | 19,544 | +4% | 1 | 1 | 0% | 2,817 | 3,786 | +34% | 0 | 0 | — |
case-01 | fail→pass | 21,223 | 21,285 | +0% | 1 | 1 | 0% | 3,195 | 4,154 | +30% | 0 | 0 | — |
case-02 | fail→pass | 21,472 | 27,941 | +30% | 1 | 1 | 0% | 3,375 | 5,458 | +62% | 0 | 0 | — |
case-03 | fail→pass | 18,171 | 21,825 | +20% | 1 | 1 | 0% | 2,752 | 4,205 | +53% | 0 | 0 | — |
case-04 | pass→fail | 19,493 | 19,768 | +1% | 1 | 1 | 0% | 2,927 | 3,731 | +27% | 0 | 0 | — |
case-05 | pass→pass | 17,596 | 19,453 | +11% | 1 | 1 | 0% | 2,948 | 3,698 | +25% | 0 | 0 | — |
case-06 | pass→pass | 9,324 | 11,968 | +28% | 1 | 1 | 0% | 1,574 | 2,743 | +74% | 0 | 0 | — |
case-08 | fail→pass | 22,230 | 17,199 | -23% | 1 | 1 | 0% | 3,360 | 3,261 | -3% | 0 | 0 | — |
case-09 | fail→pass | 15,874 | 10,655 | -33% | 1 | 1 | 0% | 2,227 | 2,309 | +4% | 0 | 0 | — |
case-10 | pass→pass | 16,067 | 20,189 | +26% | 1 | 1 | 0% | 2,349 | 3,822 | +63% | 0 | 0 | — |
case-11 | pass→pass | 15,748 | 20,128 | +28% | 1 | 1 | 0% | 2,301 | 3,850 | +67% | 0 | 0 | — |
case-12 | pass→pass | 15,490 | 17,175 | +11% | 1 | 1 | 0% | 2,163 | 3,506 | +62% | 0 | 0 | — |
case-13 | pass→pass | 17,167 | 13,124 | -24% | 1 | 1 | 0% | 2,299 | 2,541 | +11% | 0 | 0 | — |
case-14 | fail→pass | 12,883 | 4,659 | -64% | 1 | 1 | 0% | 1,745 | 1,519 | -13% | 0 | 0 | — |
case-15 | fail→pass | 15,788 | 8,136 | -48% | 1 | 1 | 0% | 2,409 | 1,929 | -20% | 0 | 0 | — |
case-16 | fail→pass | 15,292 | 9,567 | -37% | 1 | 1 | 0% | 2,334 | 2,200 | -6% | 0 | 0 | — |
case-17 | fail→pass | 17,162 | 10,496 | -39% | 1 | 1 | 0% | 2,466 | 2,224 | -10% | 0 | 0 | — |
case-18 | pass→pass | 15,588 | 13,607 | -13% | 1 | 1 | 0% | 2,213 | 2,871 | +30% | 0 | 0 | — |
case-19 | fail→pass | 8,676 | 7,961 | -8% | 1 | 1 | 0% | 1,353 | 1,965 | +45% | 0 | 0 | — |
case-20 | fail→pass | 17,280 | 18,622 | +8% | 1 | 1 | 0% | 2,517 | 3,658 | +45% | 0 | 0 | — |
case-21 | fail→pass | 16,144 | 20,532 | +27% | 1 | 1 | 0% | 2,422 | 4,059 | +68% | 0 | 0 | — |
case-22 | fail→fail | 15,398 | 3,828 | -75% | 1 | 1 | 0% | 2,216 | 1,347 | -39% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +50 percentage points is the difference between those two pass rates over the 22 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.