Breadboard

Create an inspectable map of how a product workflow works. Let the reader enter through a story or requirement, follow the relevant actions and handoffs, and find the responsible code and proof.

Use the repository's existing breadboard owner and renderer when present. Otherwise use the bundled viewer, derived from Unity Surfaces #1957. Read the format before authoring its JSON and the viewer contract before rendering. The bundled viewer needs Node.js 22 or newer and no installed packages or Unity checkout.

Establish the map

Identify the actor, starting situation, goal and observable outcome. Bound the workflow by that outcome. Read the owning instructions, accepted requirements and any supplied description, walkthrough, sketch or recording. Ask only for material product intent that those sources cannot establish.

Before reading implementation to discover, check or clarify behavior, complete this prerequisite. It applies to new maps, review fixes, added stories and requirements, and maintenance after a change.

1. Load product-description. In Claude Code, invoke the Skill tool with {"skill":"product-description"}. In a host without a skill loader, read the complete linked SKILL.md through the filesystem. A name, catalogue description or link in this file does not load the method. If the skill cannot be loaded or read, report that dependency as blocked before investigating behavior.
2. Read that skill's references/product-kinds.md and references/document-template.md, then apply its discovery method to the requested workflow. Use an existing product description where available and investigate missing or uncertain behavior from the owning code and tests.
3. Carry the findings into the map's stories, requirements and gaps, retaining links to the description, sources and verification. Keep source-derived findings distinct from runtime observations.

This loads the behavioral method for the current breadboard task. It does not require a full description repo or authorize additional commits, delegation or product execution. Layout-only changes that preserve behavioral claims do not require this discovery pass.

Choose the representation the task needs. An existing-behavior map follows code. A proposed map follows stated intent and labels unimplemented parts. A comparison keeps both visible. Code establishes implemented behavior; accepted requirements establish intended behavior. Preserve a discrepancy instead of silently changing either authority.