تشغيل أي مهارة في Manus بنقرة واحدة

executable-breadboards

النجوم٣

التفرعات١

آخر تحديث١٣ يوليو ٢٠٢٦ في ١٧:٥٩

Convert a selected breadboard slice into a buildable, testable handoff artifact with examples, fixtures, expected outputs, edge cases, and acceptance tests.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

mattlane66

mattlane66/planning-skills-for-agents-and-humans

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

SKILL.md

readonly

name	executable-breadboards
description	Convert a selected breadboard slice into a buildable, testable handoff artifact with examples, fixtures, expected outputs, edge cases, and acceptance tests.

Executable Breadboards

Use this skill when the user has a selected slice and wants to hand it to a coding agent or engineer with much less ambiguity.

An ordinary breadboard is a thinking artifact.

An executable breadboard is a building artifact.

This skill prepares the build handoff. It does not implement code.

Goal

Turn the selected slice of a breadboard into a plain-language build contract with:

relevant structure
interface contracts
example starting data
example runs
expected outputs
edge cases
acceptance tests
open decisions the agent must not invent

Use this when

Use this after a breadboard and slice selection when the next move is implementation preparation.

Good signals:

the slice is selected
the demo path is known
field-level guessing would cause rework
the agent needs fixtures or examples to test against
the UI, state, or side effects need concrete expected results
multiple agents or layers must stay aligned

Do not use this during early shaping when the team is still deciding what the feature should be.

Inputs

Use whichever artifacts are available:

frame
shaping doc
selected breadboard
selected slice
interface contract candidates or separate interface contracts
known UI expectations
known data examples
known branches or edge cases
implementation constraints

Default behavior

Identify the selected slice.
Pull only the breadboard places, affordances, stores, wires, states, and rules needed for that slice.
Include interface contracts for meaningful boundary crossings.
Create concrete example starting data or fixtures.
Write one happy-path example run.
Write important edge-case runs.
Name expected user-visible results, state changes, and side effects.
Write acceptance tests in plain language or Gherkin-style prose.
Flag open decisions instead of inventing them.
Stop after producing the executable breadboard.

Output format

[Project] — Executable Breadboard

Source references

Breadboard artifact:
Selected slice:
Interface contract artifact, if split out separately:

Selected slice

ID	Slice	Demo path	Produces	Explicit exclusions
SLICE-01	...	...	...	...

Relevant breadboard structure

Places

Affordances

Stores and state

Rules

Interface contracts

ID	Trigger / Wire	From	To	Input shape	Output shape	Branches / errors	Open decisions
C1	...	...	...	...	...	...	...

Example starting data / fixtures

Example runs

Run 1 — Happy path

Given:

When:

Then:

Expected user-visible result:

Expected state changes:

Expected side effects:

Edge cases

Case	Starting condition	Action	Expected result	Test needed?
E1	...	...	...	yes/no

Acceptance tests

Given ...
When ...
Then ...

Open decisions the agent must not invent

Verification target

Relationship to other artifacts

Breadboard = structure of the solution.

Interface contract = what crosses a boundary.

Executable breadboard = structure plus examples, fixtures, expected outputs, edge cases, and tests.

Context packet = the exact subset handed to the build agent.

Acceptance test guidance

Acceptance tests should prove behavior, not implementation style.

Prefer:

Given a published argument with one claim
When the user adds an objection to that claim
Then the objection appears under that claim
And the argument status becomes contested
And the activity log includes Objection added

Avoid:

naming internal functions unless the user already selected them
over-specifying database tables during planning
asserting framework-specific mechanisms too early

Agent handoff guidance

When an implementation agent receives an executable breadboard, it should:

restate the selected slice
list the fixtures or starting data it will use
identify the interface contracts that must be preserved
identify tests implied by the example runs
flag missing decisions before coding
implement only the selected slice
stop and propose a planning update if implementation reality conflicts with the artifact

Do not

convert every ordinary breadboard into an executable breadboard automatically
create production schemas or test files during planning unless explicitly asked
invent missing field names, enum values, nullability, edge cases, or expected outputs
expand beyond the selected slice
treat the executable breadboard as more authoritative than the user's latest explicit instruction

المزيد من هذا المستودع

نفس المستودع

feed-planning-context

mattlane66/planning-skills-for-agents-and-humans

Prepare relevant planning artifacts, including optional statechart and Dumplink context, for agent implementation work without overloading context.

2026-07-143

shaping

mattlane66/planning-skills-for-agents-and-humans

Collaboratively shape a problem and compare solution directions before implementation.

2026-07-143

framing-doc

mattlane66/planning-skills-for-agents-and-humans

Create a framing document from notes, messages, or conversation transcripts.

2026-07-133

breadboarding

mattlane66/planning-skills-for-agents-and-humans

Map a chosen solution into places, affordances, consequences, stores, and wiring.

2026-07-133

sketch-reconciliation

mattlane66/planning-skills-for-agents-and-humans

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.

2026-07-133

statechart

mattlane66/planning-skills-for-agents-and-humans

Turn a selected stateful portion of a breadboard into a transition table and Mermaid statechart without changing the breadboard's authority.

2026-07-133

name	executable-breadboards
description	Convert a selected breadboard slice into a buildable, testable handoff artifact with examples, fixtures, expected outputs, edge cases, and acceptance tests.

Executable Breadboards

Use this skill when the user has a selected slice and wants to hand it to a coding agent or engineer with much less ambiguity.

An ordinary breadboard is a thinking artifact.

An executable breadboard is a building artifact.

This skill prepares the build handoff. It does not implement code.

Goal

Turn the selected slice of a breadboard into a plain-language build contract with:

relevant structure
interface contracts
example starting data
example runs
expected outputs
edge cases
acceptance tests
open decisions the agent must not invent

Use this when

Use this after a breadboard and slice selection when the next move is implementation preparation.

Good signals:

the slice is selected
the demo path is known
field-level guessing would cause rework
the agent needs fixtures or examples to test against
the UI, state, or side effects need concrete expected results
multiple agents or layers must stay aligned

Do not use this during early shaping when the team is still deciding what the feature should be.

Inputs

Use whichever artifacts are available:

frame
shaping doc
selected breadboard
selected slice
interface contract candidates or separate interface contracts
known UI expectations
known data examples
known branches or edge cases
implementation constraints

Default behavior

Identify the selected slice.
Pull only the breadboard places, affordances, stores, wires, states, and rules needed for that slice.
Include interface contracts for meaningful boundary crossings.
Create concrete example starting data or fixtures.
Write one happy-path example run.
Write important edge-case runs.
Name expected user-visible results, state changes, and side effects.
Write acceptance tests in plain language or Gherkin-style prose.
Flag open decisions instead of inventing them.
Stop after producing the executable breadboard.

Output format

[Project] — Executable Breadboard

Source references

Breadboard artifact:
Selected slice:
Interface contract artifact, if split out separately:

Selected slice

ID	Slice	Demo path	Produces	Explicit exclusions
SLICE-01	...	...	...	...

Relevant breadboard structure

Places

Affordances

Stores and state

Rules

Interface contracts

ID	Trigger / Wire	From	To	Input shape	Output shape	Branches / errors	Open decisions
C1	...	...	...	...	...	...	...

Example starting data / fixtures

Example runs

Run 1 — Happy path

Given:

When:

Then:

Expected user-visible result:

Expected state changes:

Expected side effects:

Edge cases

Case	Starting condition	Action	Expected result	Test needed?
E1	...	...	...	yes/no

Acceptance tests

Given ...
When ...
Then ...

Open decisions the agent must not invent

Verification target

Relationship to other artifacts

Breadboard = structure of the solution.

Interface contract = what crosses a boundary.

Executable breadboard = structure plus examples, fixtures, expected outputs, edge cases, and tests.

Context packet = the exact subset handed to the build agent.

Acceptance test guidance

Acceptance tests should prove behavior, not implementation style.

Prefer:

Given a published argument with one claim
When the user adds an objection to that claim
Then the objection appears under that claim
And the argument status becomes contested
And the activity log includes Objection added

Avoid:

naming internal functions unless the user already selected them
over-specifying database tables during planning
asserting framework-specific mechanisms too early

Agent handoff guidance

When an implementation agent receives an executable breadboard, it should:

restate the selected slice
list the fixtures or starting data it will use
identify the interface contracts that must be preserved
identify tests implied by the example runs
flag missing decisions before coding
implement only the selected slice
stop and propose a planning update if implementation reality conflicts with the artifact

Do not

convert every ordinary breadboard into an executable breadboard automatically
create production schemas or test files during planning unless explicitly asked
invent missing field names, enum values, nullability, edge cases, or expected outputs
expand beyond the selected slice
treat the executable breadboard as more authoritative than the user's latest explicit instruction