메뉴
Create an Architecture Decision Record (ADR) in docs/adr/. Describe the decision and context, or have a conversation to refine it.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | adr |
| description | Create an Architecture Decision Record (ADR) in docs/adr/. Describe the decision and context, or have a conversation to refine it. |
| argument-hint | <decision-title-or-description> |
| allowed-tools | Read, Write, Glob, Bash |
Create an Architecture Decision Record for: $ARGUMENTS
docs/adr/ for existing ADRs and determine the next sequential number (zero-padded to 3 digits).docs/adr/NNN-slug.md where slug is a lowercase, hyphenated summary (max 5 words).# ADR-NNN: Title
## Status
Accepted
## Context
Why this decision came up. What forces are at play — constraints, requirements, trade-offs.
Keep it concise but complete enough that a newcomer understands the problem.
## Decision
What we decided. State it as a fact, not a proposal.
## Consequences
What follows — both positive and negative. Be honest about trade-offs.
Use bullet points prefixed with **Positive:**, **Negative:**, or **Trade-off:**.
docs/adr/ doesn't exist, create it.Superseded by ADR-NNN.Use whenever writing, modifying, or reviewing tests in this project. Defines the expected style for unit tests and API controller (slice / narrow integration) tests. Stack-agnostic — examples are in Kotlin, but principles apply to any language/framework.
Use when writing any new code or feature to enforce the TDD red-green-refactor cycle.
Use whenever writing, modifying, or reviewing UI tests in React projects. Defines naming, structure, query priority, render conventions, and mocking patterns for component and hook tests. Framework-agnostic on the component library; assumes React + Testing Library + a modern test runner (Vitest or Jest). Inherits the high-level principles from [[testing]].
Clean Architecture conventions — Vaughn Vernon-shaped folder structure (aggregate-per-package on the write side, peer query/ folder on the read side, application/ holding UseCases not Services), dependency rules, design patterns, repository conventions, and code conventions. Invoke this skill when you need to know where layers live, what can import what, or how to structure production code.
HTTP / REST boundary rules — controller shape, REST URL design, request/response modeling, validation ownership, status codes, HTTP semantics, idempotency. Stack-agnostic. Invoke this skill when designing or reviewing a new HTTP endpoint, modeling request/response DTOs or error payloads, choosing HTTP methods or status codes, or drawing the line between input-format validation and domain rule enforcement.
CQRS conventions — when to split write side (Repository + UseCase) from read side (Query). Invoke when planning a new port, deciding whether a UseCase is needed, naming a port, shaping a read model, choosing where to place it, or evaluating whether a class is a pass-through middleman. Stack-agnostic — example is in Kotlin.