slice

Name: slice
Author: thoughtbot

15stars1forks

How to install slice?

thoughtbot/rails-consultant/slice

$npx -y skills add thoughtbot/rails-consultant --skill slice

Installs into the current project.

Summary

Turn a feature into well-defined, independently shippable slices — whether it's an epic that needs breaking apart or a single story that needs sharpening into a job story

Files · 1

View on GitHub

SKILL.md

1	## Phase 1: Understand the Work
2
3	If no feature is specified, open with:
4
5	"What are you building? Describe the feature or capability — big or small."
6
7	Wait for their answer before proceeding.
8
9	Once the feature is known, ask three things — conversationally, not as a form:
10
11	"Before we slice this, I need to understand it. Three things:
12
13	Who is this for — specifically? Not 'users', but which person, in which moment, with which need.
14
15	What does done look like? When this ships, what can that person do that they can't do today?
16
17	What's the part you're least sure about — technically, or in terms of what the user actually needs?"
18
19	Wait for their answers. Listen for: vagueness about the user (a sign the scope isn't understood), vagueness about done (a sign it will expand), and what they flag as uncertain (that's where the risk lives).
20
21	If their answers are vague, ask one follow-up before moving on. Do not proceed to slicing on work you don't understand.
22
23	---
24
25	## Phase 2: Shape the Slices — Socratically
26
27	Based on the size and complexity of the feature, take one of two paths. Do not announce which path you're taking — just follow the one that fits.
28
29	### Path A: The feature is already small
30
31	If the feature is a single, focused piece of work, help them sharpen it into a well-defined job story. Read `~/.claude/skills/slice/examples/job-stories.md` for the job story format. Guide them with:
32
33	- "What's the specific situation the user is in when they need this? Not just 'using the app' — what moment triggers the need?"
34	- "What do they want to do in that moment — and why does it matter to them?"
35	- "How would you know this is done? What can the user do that they couldn't before — something you could demonstrate in 30 seconds?"
36
37	Push on scope:
38
39	- "Is this actually one thing, or are you sneaking two things in? Could any part of this ship on its own?"
40	- "Is there a simpler version that still solves the user's problem in that moment?"
41
42	Push on acceptance criteria:
43
44	- "How would you verify this actually works? What are the specific things you'd check — the happy path, the edge cases, the error states?"
45	- "If you handed this to someone who's never seen the feature, what checklist would they need to confirm it's done?"
46
47	If pushing reveals that the feature is actually multiple slices, switch to Path B.
48
49	### Path B: The feature is large
50
51	Guide them to find the slices themselves, one question at a time.
52
53	Start here:
54
55	"What's the absolute minimum a user would need to get any value from this at all — the smallest thing that's real, not a prototype?"
56
57	This is the walking skeleton (thoughtbot / XP). It's almost always smaller than they think. Read `~/.claude/skills/slice/examples/full-stack-slices.md` to understand the principle: cut vertically through the stack, not horizontally. Push on it:
58
59	- "Could a user actually do something with that, or is it just plumbing?"
60	- "Is that one slice, or are you combining two things that could ship separately?"
61	- "If you shipped only that, what feedback could you get from a real user?"
62
63	Once the first slice is clear, work outward:
64
65	- "What's the next most important thing — not the next most obvious thing to build, but the next most valuable to the user?"
66	- "What's the riskiest assumption — the thing that, if you're wrong, changes everything? Should that be a slice?"
67	- "Is there anything in here that only exists to support another feature, not the user? That's probably not a slice."
68	- "Which slices depend on each other, and which are actually independent?"
69
70	As each slice takes shape, push on acceptance criteria:
71
72	- "How would you verify this slice works? What specific things would you check — happy path, edge cases, error states?"
73	- "If you handed this to someone who's never seen the feature, what checklist would they need to confirm it's done?"
74
75	Keep pushing until they've named the full set. Validate each slice against two tests — ask them:
76
77	1. "Can this ship independently — could it go to production on its own without the others?"
78	2. "Can a user or stakeholder see the value — is this end-to-end, or is it a layer?"
79
80	If a slice fails either test, it's either too big or it's not a slice.
81
82	---
83
84	## Phase 3: Deliverable
85
86	### For a single slice
87
88	Produce a job story. Read `~/.claude/skills/slice/examples/job-stories.md` for the format:
89
90	---
91
92	[Short name]
93	When [specific situation the user is in], I want [what they need to do] so [the outcome that matters to them].
94	Ships when: [The observable behavior that marks it done — what a user can do, not what the code does.]
95	Acceptance criteria:
96
97	- [ ] [Specific, verifiable condition — the happy path]
98	- [ ] [Edge case or boundary condition]
99	- [ ] [Error st

People who liked this also viewed

6 picks

Type

hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026262k37k
request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026165k181k
analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026161k507
explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026161k507
ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026149k181k

slice

15stars1forks

View on GitHub

How to install slice?

thoughtbot/rails-consultant/slice

$npx -y skills add thoughtbot/rails-consultant --skill slice

Installs into the current project.

Summary

Turn a feature into well-defined, independently shippable slices — whether it's an epic that needs breaking apart or a single story that needs sharpening into a job story

Files · 1

View on GitHub

SKILL.md

1	## Phase 1: Understand the Work
2
3	If no feature is specified, open with:
4
5	"What are you building? Describe the feature or capability — big or small."
6
7	Wait for their answer before proceeding.
8
9	Once the feature is known, ask three things — conversationally, not as a form:
10
11	"Before we slice this, I need to understand it. Three things:
12
13	Who is this for — specifically? Not 'users', but which person, in which moment, with which need.
14
15	What does done look like? When this ships, what can that person do that they can't do today?
16
17	What's the part you're least sure about — technically, or in terms of what the user actually needs?"
18
19	Wait for their answers. Listen for: vagueness about the user (a sign the scope isn't understood), vagueness about done (a sign it will expand), and what they flag as uncertain (that's where the risk lives).
20
21	If their answers are vague, ask one follow-up before moving on. Do not proceed to slicing on work you don't understand.
22
23	---
24
25	## Phase 2: Shape the Slices — Socratically
26
27	Based on the size and complexity of the feature, take one of two paths. Do not announce which path you're taking — just follow the one that fits.
28
29	### Path A: The feature is already small
30
31	If the feature is a single, focused piece of work, help them sharpen it into a well-defined job story. Read `~/.claude/skills/slice/examples/job-stories.md` for the job story format. Guide them with:
32
33	- "What's the specific situation the user is in when they need this? Not just 'using the app' — what moment triggers the need?"
34	- "What do they want to do in that moment — and why does it matter to them?"
35	- "How would you know this is done? What can the user do that they couldn't before — something you could demonstrate in 30 seconds?"
36
37	Push on scope:
38
39	- "Is this actually one thing, or are you sneaking two things in? Could any part of this ship on its own?"
40	- "Is there a simpler version that still solves the user's problem in that moment?"
41
42	Push on acceptance criteria:
43
44	- "How would you verify this actually works? What are the specific things you'd check — the happy path, the edge cases, the error states?"
45	- "If you handed this to someone who's never seen the feature, what checklist would they need to confirm it's done?"
46
47	If pushing reveals that the feature is actually multiple slices, switch to Path B.
48
49	### Path B: The feature is large
50
51	Guide them to find the slices themselves, one question at a time.
52
53	Start here:
54
55	"What's the absolute minimum a user would need to get any value from this at all — the smallest thing that's real, not a prototype?"
56
57	This is the walking skeleton (thoughtbot / XP). It's almost always smaller than they think. Read `~/.claude/skills/slice/examples/full-stack-slices.md` to understand the principle: cut vertically through the stack, not horizontally. Push on it:
58
59	- "Could a user actually do something with that, or is it just plumbing?"
60	- "Is that one slice, or are you combining two things that could ship separately?"
61	- "If you shipped only that, what feedback could you get from a real user?"
62
63	Once the first slice is clear, work outward:
64
65	- "What's the next most important thing — not the next most obvious thing to build, but the next most valuable to the user?"
66	- "What's the riskiest assumption — the thing that, if you're wrong, changes everything? Should that be a slice?"
67	- "Is there anything in here that only exists to support another feature, not the user? That's probably not a slice."
68	- "Which slices depend on each other, and which are actually independent?"
69
70	As each slice takes shape, push on acceptance criteria:
71
72	- "How would you verify this slice works? What specific things would you check — happy path, edge cases, error states?"
73	- "If you handed this to someone who's never seen the feature, what checklist would they need to confirm it's done?"
74
75	Keep pushing until they've named the full set. Validate each slice against two tests — ask them:
76
77	1. "Can this ship independently — could it go to production on its own without the others?"
78	2. "Can a user or stakeholder see the value — is this end-to-end, or is it a layer?"
79
80	If a slice fails either test, it's either too big or it's not a slice.
81
82	---
83
84	## Phase 3: Deliverable
85
86	### For a single slice
87
88	Produce a job story. Read `~/.claude/skills/slice/examples/job-stories.md` for the format:
89
90	---
91
92	[Short name]
93	When [specific situation the user is in], I want [what they need to do] so [the outcome that matters to them].
94	Ships when: [The observable behavior that marks it done — what a user can do, not what the code does.]
95	Acceptance criteria:
96
97	- [ ] [Specific, verifiable condition — the happy path]
98	- [ ] [Edge case or boundary condition]
99	- [ ] [Error st

People who liked this also viewed

6 picks

Type