Menú
Map a chosen solution into places, affordances, consequences, stores, and wiring.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Prepare relevant planning artifacts, including optional statechart and Dumplink context, for agent implementation work without overloading context.
Collaboratively shape a problem and compare solution directions before implementation.
Create a framing document from notes, messages, or conversation transcripts.
Reconcile an attached image, screenshot, wireframe, mockup, whiteboard, or hand-drawn sketch with existing frame, shaping, and breadboard artifacts. Use when a user drops in a visual, says "see this sketch" or "we are missing something," asks what the visual changes, or wants visual evidence incorporated without silently changing requirements, scope, or the selected shape.
Turn a selected stateful portion of a breadboard into a transition table and Mermaid statechart without changing the breadboard's authority.
Reflect on a breadboard by syncing it to implementation and finding design smells.
| name | breadboarding |
| description | Map a chosen solution into places, affordances, consequences, stores, and wiring. |
Use this skill when the team needs to understand how a chosen solution behaves, where the user is, what they can do there, and what hidden system consequences matter.
Produce a legible system map that shows:
The tables are the source of truth. Mermaid diagrams are optional visualizations for humans.
Breadboarding serves three common functions:
Use this when you do not yet understand how an existing system works in concrete detail.
Input:
Output:
Use this when shaping has already produced mechanisms and you need to detail them into concrete affordances and wiring.
Input:
Output:
Often you need both: existing affordances that remain, plus new affordances from the chosen shape. Breadboard them together so the full story is visible.
Hand-drawn or whiteboard breadboards use a visual stacking format rather than tables. The same concepts still apply: places, affordances, wiring, and hidden system consequences.
If the visual is being compared with an existing selected shape or breadboard and may change behavior or scope, use the sketch-reconciliation skill first. Translate only accepted deltas into the canonical breadboard tables.
Common visual conventions:
How to read one:
Breadboarding is a lightweight UI shorthand.
It separates what users can interact with in the interface from what happens in the code or design system underneath.
The places act like interface endpoints or bounded states. The affordances show what the user can do there. The wiring explains what happens between what the user sees.
Because it uses words instead of pictures, and because the important things are the components and their connections, you can quickly play out an idea and judge whether the sequence of actions actually serves the use case.
A breadboard is mainly about:
It is not mainly a service graph.
If the diagram starts to read like:
then it is probably too implementation-heavy.
Prefer wording that stays tied to product behavior, such as:
rather than internal decomposition such as:
A place is a bounded context of interaction. It is where someone is, in practical terms, because it determines what they can do next.
Examples:
Ask:
The simplest test for whether something is a different place: can you interact with what is behind it?
When a control changes state, ask whether everything changed or only a subset while the surroundings stayed the same.
When a mode changes the whole perceptual context — for example read mode vs edit mode — model it as a different place.
Examples:
PLACE: CMS Page (Read Mode)PLACE: CMS Page (Edit Mode)If a state changes what the user can do next or what they can see, consider representing it as its own place.
Examples:
Do not hide important user-visible states inside only non-UI affordances.
Places are first-class elements in the model and should get IDs such as P1, P2, P3.
Use place IDs so navigation wires can point to places directly.
Use subplaces when a place contains a distinct widget or section that needs its own local scope.
Examples:
P2.1P2.2Subplaces help show what is in scope inside a larger place without pretending it is a separate top-level destination.
When a nested place has many internal affordances and would clutter the parent, use a place reference.
Pattern:
_letter-browser_settings-panelThe reference appears in the parent place as a UI affordance and wires to the full place definition elsewhere.
Affordances are the things that can be acted upon or that produce effects.
Use these prefixes:
U for user-facing affordancesN for non-UI/code affordancesS for stores or stateP for placesKeep non-UI affordances close to product-relevant consequences.
Containment and wiring are different relationships.
The Place column answers: where does this affordance live? The Wires Out and Returns To columns answer: what does it trigger and where does its output go?
Wiring explains behavior.
Track two kinds:
A good breadboard should help answer:
When an affordance causes navigation, wire to the place itself, not to an affordance inside that place.
Good:
N1 → P2Less useful:
N1 → U7When a hidden rule can lead to different user-visible outcomes, represent that split in the breadboard.
Examples:
| ID | Place | Description |
|---|---|---|
| P1 | Search page | Main search experience |
| ID | Place | Component | Affordance | Control | Wires Out | Returns To |
|---|---|---|---|---|---|---|
| U1 | P1 | search | input field | type | → N1 | — |
| ID | Place | Component | Affordance | Control | Wires Out | Returns To |
|---|---|---|---|---|---|---|
| N1 | P1 | search | query handler | call | → N2 | — |
| ID | Place | Store | Description |
|---|---|---|---|
| S1 | P1 | results | Search results array |
database, logic, or handler stuff.Some things are just implementation mechanisms and should not get their own node unless they are truly meaningful at breadboard level.
Examples often better omitted:
If a UI affordance displays data, the breadboard should show where that data comes from.
If a non-UI affordance has no Wires Out and no Returns To, something is probably missing or the affordance may not deserve its own row.
If a hidden consequence affects external state, represent that state as a store when it matters.
Examples:
A store belongs where its data enables behavior, not merely where it gets written.
Resolvers, APIs, and database behavior are not just floating infrastructure. When they are part of the story of how the product works, model them as a place with their own affordances and stores.
| Element | ID pattern | Meaning |
|---|---|---|
| Place | P1, P2 | bounded context of interaction |
| Subplace | P2.1, P2.2 | scoped area inside a larger place |
| Place reference | _name | detached nested place reference |
| UI affordance | U1, U2 | something the user can see or interact with |
| Non-UI affordance | N1, N2 | hidden mechanism with meaningful identity |
| Store | S1, S2 | state that is written and read |
| Chunk | freeform | collapsed subsystem in a larger diagram |
| Relationship | Meaning | Where captured |
|---|---|---|
| Containment | affordance belongs to a place | Place column |
| Wires Out | control flow | Wires Out column |
| Returns To | data flow / visible consequence | Returns To column |
Chunking collapses a subsystem into a single node in the main diagram when it has one clear entry, one clear output, and too many internals to keep the main view readable.
Use chunking when:
A chunk should have its own separate detailed view when needed.
---
planning: true
shaping: true
---
# [Project] — Breadboard
## Places
[table]
## UI Affordances
[table]
## Non-UI Affordances
[table]
## Stores
[table]
## Notes
- [important constraints, open questions, or assumptions]
A Mermaid diagram is optional. The tables are the source of truth.
If you add a diagram:
For teaching or walkthrough diagrams, you may add numbered workflow step annotations to guide the reader through the main path.
Slice only after the breadboard is concrete enough that you can group affordances into demoable vertical increments.
Before proposing slices, optionally run the kickoff grouping pass from the shaping skill:
Use those groups as the raw material for slice boundaries.
A vertical slice is a group of UI and non-UI affordances that does something demo-able.
Every slice must end in visible, demo-able UI. A slice without an observable output is a horizontal layer, not a vertical slice.
Produces: line for each slice.Slice order is not intuitive. Sequence slices with two passes, in order.
Map which slices depend on other slices.
A slice depends on another when it requires affordances, data structures, routes, or stores that the other slice produces.
Start with slices that have no dependencies and work upward through the causal chain. This gives you the minimum valid ordering — constraints you cannot violate.
Among slices that are valid starting points, ask: which has the biggest unknown?
An unknown is something where you do not yet know if it is feasible, how it works, or how long it will take.
Move the slice with the biggest unknown as early as possible. This creates the most time to resolve the hard problem before it becomes a crisis.
Start by identifying what is routine and familiar. What remains are the unknowns.
The final sequence is:
A slice is done when it produces the output the next slice needs as input — not when it is abstractly complete.
Before finalizing each slice boundary, look at what comes immediately after it in the sequence.
Ask: what does the next slice need in order to start?
The current slice must deliver exactly that — no more, no less.
This prevents two common failure modes:
When writing the demo statement for each slice, include what it produces for the next slice to consume.
Use this format:
Produces: [what this slice outputs for the next slice]If you cannot name what the slice produces for the next one, the slice boundary may be wrong.
When the breadboard implies more than 9 slices, cut — do not compress.
Compressing forces slices that are too large to demo a single mechanism. Cutting removes mechanisms from the current cycle entirely.
Present cut candidates explicitly. Do not silently merge or omit them.
Use this format:
The human decides what gets cut. This is an appetite decision. The breadboard's job is to make the trade-off visible, not to make the call.
When a slice is cut, add a Cut section at the bottom of the slice summary with a one-line reason. Do not delete it. Deferred work is different from rejected work.
Cutting is also available later at implementation gates. If a slice runs long or reveals unexpected complexity, a later slice can be cut rather than extending the timeline.