菜单
Architecture Decision Record(ADR)를 작성한다. 기술적 결정사항, 설계 선택, 트레이드오프를 문서화하여 나중에 "왜 이렇게 했지?"를 알 수 있게 한다. 다음 상황에서 반드시 이 스킬을 사용한다: - "ADR 써줘", "결정사항 문서화해줘", "이 결정 기록해줘" - 기술 방향 선택 후 ("A 대신 B 쓰기로 했어") - 설계 논의가 끝났을 때 - 나중에 이 결정이 왜 내려졌는지 설명이 필요할 것 같을 때 - "/adr" 직접 호출 ARGUMENTS: 결정 내용 또는 결정 번호 (없으면 대화에서 추출)
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
새 Spring Boot 서비스를 api-gateway + auth-api 에코시스템에 연결한다. auth-api 클라이언트 등록 → Gateway 라우팅 추가 → 서비스에 econo-passport 연동 → 동작 확인까지 한 번에 처리. 다음 상황에서 반드시 이 스킬을 사용한다: - "새 서비스 Gateway에 연결해줘", "새 서비스 auth 연동" - "서비스 등록해줘", "Gateway 뒤에 붙여줘" - "/register-service" 직접 호출 - 새 Spring Boot 서비스가 추가되고 인증이 필요할 때 ARGUMENTS: 서비스명, 서비스 경로(선택), 업스트림 URL(선택) 예: "EEOS-BE /Users/mando/study/eeos/EEOS-BE/eeos"
이 스킬은 사용자가 "PR 생성해줘", "PR 만들어줘", "pull request 생성", "pr 올려줘", "/git-pr" 등을 요청할 때 호출된다. 현재 브랜치의 커밋을 원격으로 push하고, `.github/PULL_REQUEST_TEMPLATE.md`를 채워 GitHub Pull Request를 생성한다.
신규 기능을 개발할 때 정책 문서 → 코드 → 테스트 순서로 작성한다. ADR은 기술적 결정에만 사용하고, 기능 정책은 docs/features/ 에 작성한다. 다음 상황에서 반드시 이 스킬을 사용한다: - "기능 추가해줘", "기획부터 해봐", "설계해봐" - 새로운 API 엔드포인트 또는 도메인 규칙이 생길 때 - "/new-feature" 직접 호출 ARGUMENTS: 기능 이름 또는 요구사항 (없으면 대화에서 추출)
AI 에이전트의 액션 스페이스, 도구 정의, 관측(Observation) 포맷을 설계·최적화해 작업 완수율을 높일 때 사용한다.
로컬 개발, 컨테이너 보안, 네트워킹, 볼륨 전략, 멀티 서비스 오케스트레이션을 위한 Docker 및 Docker Compose 패턴.
브랜치 전략, 커밋 컨벤션, 머지 vs 리베이스, 충돌 해결, 협업 개발 모범 사례를 포함하는 Git 워크플로 패턴. 모든 규모의 팀에 적용 가능하다.
| name | adr |
| description | Architecture Decision Record(ADR)를 작성한다. 기술적 결정사항, 설계 선택, 트레이드오프를 문서화하여 나중에 "왜 이렇게 했지?"를 알 수 있게 한다. 다음 상황에서 반드시 이 스킬을 사용한다: - "ADR 써줘", "결정사항 문서화해줘", "이 결정 기록해줘" - 기술 방향 선택 후 ("A 대신 B 쓰기로 했어") - 설계 논의가 끝났을 때 - 나중에 이 결정이 왜 내려졌는지 설명이 필요할 것 같을 때 - "/adr" 직접 호출 ARGUMENTS: 결정 내용 또는 결정 번호 (없으면 대화에서 추출) |
결정사항을 ADR 문서로 남긴다. 나중에 합류하는 팀원이나 미래의 자신이 "왜 이렇게 됐지?"를 이해할 수 있게 하는 것이 목표.
docs/adr/ 디렉토리를 읽어 가장 최근 번호를 확인한다:
ls docs/adr/ | sort | tail -5
다음 번호를 사용한다. (없으면 0001부터 시작)
ARGUMENTS 또는 대화 맥락에서 다음을 파악한다:
명확하지 않은 부분이 있으면 작성 전에 질문한다.
파일명: docs/adr/{번호}-{kebab-case-제목}.md
예: docs/adr/0003-use-postgresql-over-mysql.md
# ADR-{번호}: {제목}
- **상태:** Accepted | Proposed | Deprecated | Superseded by ADR-{번호}
- **결정일:** YYYY-MM-DD
- **결정자:** {팀/사람}
---
## 배경
[이 결정이 필요하게 된 이유. 어떤 문제가 있었나?]
---
## 결정
**[한 문장으로 핵심 결정]**
[상세 설명]
---
## 근거
[왜 이 선택을 했는가. 비교표가 있으면 좋음]
---
## 결과
### 긍정적 영향
- ...
### 제약 사항 / 주의사항
- ...
### 재검토 조건 (선택)
[언제 이 결정을 다시 검토해야 하나?]
---
## 관련 문서
- [링크]
| 상태 | 의미 |
|---|---|
Proposed | 논의 중, 아직 확정 안 됨 |
Accepted | 결정 완료, 현재 적용 중 |
Deprecated | 더 이상 권장하지 않지만 코드는 남아있음 |
Superseded by ADR-{번호} | 이후 ADR이 이 결정을 대체함 |
작성 후 스스로 체크: