Menu
Create an Architecture Decision Record (ADR) in docs/adr/. Describe the decision and context, or have a conversation to refine it.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
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.
| 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.