Breadboard Lab — The Maker Workbench

Total surface: ~4,000+ lines of breadboard-specific logic. The skill's job is to keep those systems coherent.

When To Invoke This Skill

YES — use this skill for:

• Any change to BreadboardView.tsx or files it orchestrates
• Starter shelf / project shelf / exact-part flow changes
• Board health surfacing, issue remediation, focus behavior
• Coach plan logic, overlay, prompts, trust-tier messaging
• Canvas interaction (drop preview, snap, zoom/pan, overlays)
• Bench-pin endpoint wiring for off-board parts
• Sync drift / duplicate wires between schematic and breadboard
• Inventory reconciliation, preflight gating, shopping list
• Part-inspector trust/readiness display
• Anything touching knowledge/breadboard-intelligence.md claims

NO — defer or compose:

The Mandatory 6-Question Breadboard Lens

Every change must answer all six before shipping:

1. Beginner onboarding — Can a first-time user figure out how to start within 5 seconds of opening the tab?
2. Provenance clarity — Does the UI distinguish starter-generic, project-linked, and verified-exact parts unambiguously? (icon + label + color, not color alone)
3. Stash-grounded readiness — Is "can I build this right now?" answered by what the user actually owns, not by design intent?
4. Debugging confidence — Does the change help a user diagnose a real problem on a real board, or does it only add visual density?
5. Cross-view coherence — After this change, does the schematic / validation / inventory / AI guidance still agree with the breadboard?
6. Browser-verified — Is the improvement proven in a real browser at the actual viewport Tyler uses, not just in tests?

If any answer is "no" or "not sure," the change isn't ready.

Mental Model: Five Interlocked Systems

┌──────────────────────────────────────────────────────────────┐
│                    WORKBENCH SHELL                           │
│   Starter Shelf │ Project Shelf │ Stash │ Exact-Part │ Audit │
└────────────┬─────────────────────────────────────┬───────────┘
             │                                     │
             ▼                                     ▼
┌─────────────────────────────┐  ┌──────────────────────────────┐
│     CANVAS EDITING           │  │   TRUST & READINESS          │
│ • Placement + snap preview   │  │ • Fit check (breadboard vs   │
│ • Wire editor (incl. bench   │  │   off-board-only)            │
│   pin endpoint snap)         │  │ • Pin-map confidence          │
│ • DRC overlay                │  │ • Stash truth (have / need)   │
│ • Connectivity overlay       │  │ • Layout quality score        │
│ • Bendable legs + realism    │  │ • Board audit issues          │
└──────────────┬───────────────┘  └──────────────┬───────────────┘
               │                                  │
               ▼                                  ▼
┌──────────────────────────────────────────────────────────────┐
│                     COACH / AI                                │
│  selected-part plan · prompt shaping · prevention-first      │
└─────────────────────────────┬─────────────────────────────────┘
                              ▼
┌──────────────────────────────────────────────────────────────┐
│                   SYNC & PROVENANCE                           │
│  schematic ↔ breadboard nets · dedup · origin labels         │
└──────────────────────────────────────────────────────────────┘

You cannot strengthen one without maintaining the others. Every change touches at least two; verify the interaction.

Canonical Trust Tiers (use these EXACT labels everywhere)

Never flatten these tiers in copy, sorting, filtering, or coach output. A user deciding whether to breadboard a design right now needs to know which parts are verified-exact and which are heuristic.

Standard Workflow

1. Orient — read ./breadboard-architecture-and-entrypoints.md for file map.
2. Classify — which of the 5 subsystems does this request primarily touch?
3. Check if already exists — grep the codebase. Many requested features exist as lib helpers or dormant dialog props that aren't surfaced from BreadboardView.tsx yet.
4. Consult the vault — knowledge/breadboard-intelligence.md lists every verified-board quirk, layout rule, and bench-coach claim. Use mcp__qmd__qmd_vector_search with "breadboard" + topic to find adjacent claims.
5. Design smallest change — keep the 5-subsystem coherence. Reject changes that improve one pillar at the cost of another.
6. Write/update tests — see ./breadboard-testing-and-browser-verification.md. Test the interaction, not the isolated function.
7. Typecheck + standalone test — npm run check must be clean; targeted Vitest must pass.
8. Browser verify — load the tab in the app, exercise the flow, capture evidence.
9. Capture new knowledge — if the work revealed durable product knowledge, route it through inbox/ → /arscontexta:extract → knowledge/.

Reference Files (load as needed)

Related Skills

• frontend-design — styling, cyberpunk theme, responsive
• testing-mastery — framework-level test patterns
• verification-mastery — pre-completion verification
• chromedevtools-mastery — real-browser verification
• project-context — broader ProtoPulse architecture
• arscontexta:extract — when knowledge emerged for the vault