메뉴
Design stable interfaces that are hard to misuse. Use when defining contracts, module boundaries, or public APIs.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | design |
| description | Design stable interfaces that are hard to misuse. Use when defining contracts, module boundaries, or public APIs. |
Design interfaces that are hard to misuse, easy to extend, and stable under change. Applies to API contracts, module boundaries, config schemas, and any surface where components interact.
Define the interface before implementing it. The schema is the contract — implementation follows.
All observable behaviors of your system will be depended on by somebody, regardless of what you promise in the contract. Every public behavior becomes a de facto commitment. Be deliberate about what you expose.
Extend interfaces by adding optional fields rather than changing existing ones. Changing a field's type or removing it breaks consumers silently. Adding is safe; modifying is not.
When different behaviors carry different intent, prefer separate variants or schemas over a single shared shape with conditionally meaningful fields.
Trust internal code. Validate at system boundaries — API payloads, config files, external inputs. Don't scatter validation deep inside the call stack.
Follow established project conventions consistently. When no convention exists, prefer explicit and descriptive over terse and clever.
architecture-review for boundary and dependency integritysecurity-review for trust-boundary risk reviewCreate and update AGENTS.md project rules. Use when authoring or amending the cross-tool conventions agents must follow.
Write forward-looking startup instructions for the next session, then reset context to save costs. Use when the context is getting long or before switching focus.
Run pre-release checks, pick the version bump, and cut the release. Use when ready to tag and release.
Create and maintain a specification that states what to build, not how. Use when writing a spec, editing requirements, or defining acceptance criteria.
Run all review dimensions against a diff or a path. Use when reviewing a feature branch before merge, reviewing someone else's PR, or auditing a file path.
Create or update project documentation. Use when creating architecture docs, runtime docs, reference docs, or design documents that explain what the system does.