菜单
Turn selected breadboard wires or slices into plain-language contracts for boundary-crossing data exchanges.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 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.
Map a chosen solution into places, affordances, consequences, stores, and wiring.
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.
| name | interface-contracts |
| description | Turn selected breadboard wires or slices into plain-language contracts for boundary-crossing data exchanges. |
Use this skill when a selected slice or breadboard wire crosses a meaningful boundary and the agent needs exact data-shape clarity before implementation.
This skill prepares planning context only. It does not write production schemas or code unless the user explicitly asks to move into implementation preparation.
Produce a plain-language contract that makes boundary-crossing data exchanges explicit enough for an implementation agent to build and test without inventing field names, nullability, enum values, or error cases.
An interface contract is boundary detail.
An executable breadboard is the build handoff for a selected slice: structure plus interface contracts, fixtures, example runs, expected outputs, edge cases, and tests.
Use this skill separately when boundary detail is complex enough to deserve its own artifact. Otherwise, the contract table can live directly inside an executable breadboard.
Use this after a breadboard or selected slice when the work depends on data moving across a meaningful boundary:
Do not create contracts for every internal helper or tiny function. Use this where the exchange is part of the product behavior or where multiple agents, layers, or systems need to stay aligned.
Use whichever inputs are available:
C1, C2, or CONTRACT-01.| ID | Boundary | Why this contract matters | Related breadboard IDs | Related slice |
|---|---|---|---|---|
| C1 | ... | ... | U1 -> N1 | V1 |
Trigger / wire
From
To
Input shape
Output shape
Branches / errors
Open decisions
Verification target
When the contract is still embedded in a breadboard or executable breadboard, use this table:
| ID | Trigger / Wire | From | To | Request / Input Shape | Response / Output Shape | Branches / Errors | Open Decisions |
|---|---|---|---|---|---|---|---|
| C1 | U1 -> N1 | UI | API | user_id: string; items: array | order_id: string; status: pending | missing item, invalid quantity | Should promo codes be nullable or omitted? |
Name the two parts exchanging data.
Include field names, types when known, required vs optional, arrays or nested objects, IDs and references, nullable fields, and units such as cents instead of dollars.
Include the success response, user-visible result, state written or updated, and fields the next slice depends on.
Name the non-happy paths the implementation must handle.
Examples: missing required field, invalid enum value, duplicate record, permission denied, unavailable external service, or partial import success.
List decisions that should not be invented by the implementation agent.
Examples: whether missing optional values are omitted or null, allowed status values, money units, or who owns the canonical ID.
Use this only when moving from planning into implementation preparation:
Turn this plain-language interface contract into the smallest useful formal contract for the selected slice. Use OpenAPI 3.1, JSON Schema, TypeScript types, validators, or tests only if useful for the current implementation step. Before writing code, report decisions that are fully specified, decisions that are missing, assumptions you would otherwise have to invent, and tests that would prove the implementation satisfies the contract. Do not invent missing field names, nullability, enum values, or error cases. Flag them.