메뉴
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.