메뉴
이 저장소에서 큰 기능 설계나 정책 변경을 시작하기 전에 AGENTS.md, CONTEXT.md, docs/adr, docs/history, 실제 코드를 근거로 요구사항을 질문하고 도메인 용어와 아키텍처 결정 및 작업 이력을 문서화할 때 사용한다.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | grill-with-docs |
| description | 이 저장소에서 큰 기능 설계나 정책 변경을 시작하기 전에 AGENTS.md, CONTEXT.md, docs/adr, docs/history, 실제 코드를 근거로 요구사항을 질문하고 도메인 용어와 아키텍처 결정 및 작업 이력을 문서화할 때 사용한다. |
루트 AGENTS.md 규칙을 전제로 사용한다.
CONTEXT.md로 프로젝트 glossary를 유지하고, 필요한 경우 ADR로 결정 배경을 남긴다.docs/history/0001-feature-slug/PLAN.md 형식의 작업 이력, API 계약, 도메인 규칙과 충돌하지 않게 한다.AGENTS.md와 관련 CONTEXT.md, CONTEXT-MAP.md, docs/adr/*, docs/history/0001-feature-slug/PLAN.md 형식의 PLAN이 있는지 먼저 확인한다.대부분의 저장소는 단일 컨텍스트를 가진다.
/
├── CONTEXT.md
├── docs/
│ ├── adr/
│ └── history/
└── src/
루트에 CONTEXT-MAP.md가 있으면 여러 컨텍스트가 있는 저장소로 본다. 이 경우 map은 각 컨텍스트의 CONTEXT.md와 context-specific docs/adr/ 위치를 가리킨다.
파일은 필요할 때만 만든다. CONTEXT.md가 없으면 첫 용어가 확정될 때 만들고, docs/adr/는 첫 ADR이 필요할 때, docs/history/는 작업 계획이나 PLAN을 남길 때 사용한다.
CONTEXT.md: 이 앱에서 쓰는 용어의 정확한 의미를 담는 용어 정의서다. 같은 단어라도 사람마다 해석이 달라질 수 있는 표현을 프로젝트 기준으로 고정한다.CONTEXT-MAP.md: 도메인 간 관계나 bounded context 경계가 중요해질 때만 사용한다. 현재 저장소에 없으면 억지로 만들지 않는다.docs/adr/: 시스템 구조 설계 시 내린 결정의 기록을 둔다. 개발자들이 근거를 가지고 토론한 뒤 결정한 아키텍처/정책 선택을 남긴다.docs/history/: 작업 시 사용한 PLAN 파일, PRD, 구현 계획, 진행 이력처럼 특정 작업의 기록을 둔다. 디렉터리는 0001-feature-slug처럼 4자리 번호와 하이픈 slug를 사용한다.구현 절차, 상세 API 스펙, 일회성 작업 TODO는 CONTEXT.md가 아니라 docs/history/0001-feature-slug/PLAN.md에 둔다.
단순 네이밍, 작은 리팩터링, AGENTS.md에 이미 있는 규칙 반복은 ADR로 남기지 않는다.
0001-기능명-slug 형식으로 작성한다.docs/adr/로 분리한다.CONTEXT.md glossary와 충돌하는 경우docs/history/0001-feature-slug/PLAN.md 또는 ADR과 다른 방향의 요구사항이 들어온 경우CONTEXT.md나 ADR이 없으면 바로 만들지 말고, 먼저 갱신 후보를 제안한다.이 저장소에서 신규 기능 개발, 기존 기능 리팩토링, 버그 수정, API 변경, 도메인 정책 변경을 수행할 때 설계 문서화, Red-Green-Refactor 테스트 작성, 구현, 관련 테스트와 전체 테스트 검증, 배포/PR 확인까지 자연스럽게 이어가도록 사용하는 워크플로우 스킬이다.
이 저장소에서 브랜치 변경 내역을 바탕으로 프로젝트 PR 본문 형식에 맞춰 요약, 상세 작업 내용, 참고사항을 작성할 때 사용한다.
이 저장소에서 변경 내용을 바탕으로 프로젝트 커밋 메시지 규칙에 맞는 커밋 메시지를 만들거나, staged 변경을 확인해 적절한 Type과 제목을 정리할 때 사용한다.
이 저장소에서 신규 기능 개발, 기능 수정, PRD 작성, API 변경, 스케줄러/Redis/FCM/외부 API 연동 작업을 할 때 latency, availability, error rate 관점의 SLO 영향을 점검하고 필요한 metric, 테스트, 운영 확인 항목을 정리할 때 사용한다.
이 저장소에서 기능 요청, 정책 변경, API 변경, 앱 요구사항을 docs/history/{0001}-{기능명-slug}/PLAN.md 형식의 PRD 또는 구현 계획으로 정리할 때 사용한다.
이 저장소에서 controller, service, repository, Redis, integration 테스트를 작성하거나 수정할 때 사용한다. TDD red-green-refactor 흐름, 어노테이션 선택, fixture 사용, nested 테스트 구조, DisplayName 규칙, 현재 코드베이스의 테스트 패턴을 다룬다.