이 스킬은 현재 대화 컨텍스트와 코드베이스 이해를 바탕으로 스펙을 생성합니다. 사용자에게 인터뷰하지 말고, 이미 알고 있는 내용만 종합하세요.
이슈 트래커와 트라이지 라벨 어휘는 미리 제공되어야 합니다. 제공되지 않은 경우, 사용자에게 /setup-matt-pocock-skills를 실행하라고 안내하세요.
프로세스
-
아직 탐색하지 않았다면, 저장소를 탐색하여 코드베이스의 현재 상태를 이해하세요. 스펙 전체에서 프로젝트의 도메인 용어집 어휘를 사용하고, 작업 중인 영역의 ADR을 존중하세요.
-
기능을 테스트할 지점(Seam)을 스케치하세요. 기존 지점을 새 지점보다 우선시하세요. 가능한 가장 높은 지점을 사용하세요. 새 지점이 필요한 경우, 가능한 가장 높은 지점에서 제안하세요. 지점이 적을수록 좋으며, 이상적인 수는 하나입니다.
사용자가 이러한 지점이 자신의 기대와 일치하는지 확인하세요.
-
아래 템플릿을 사용하여 스펙을 작성한 후 프로젝트 이슈 트래커에 게시하세요.
ready-for-agent트라이지 라벨을 적용하세요. 추가 트라이지는 필요하지 않습니다.
문제 설명
사용자가 직면한 문제를 사용자 관점에서 설명합니다.
해결 방안
문제에 대한 해결 방안을 사용자 관점에서 설명합니다.
사용자 스토리
사용자 스토리의 긴 번호 목록입니다. 각 사용자 스토리는 다음 형식이어야 합니다:
- <행위자>로서, 나는 <기능>을(를) 원한다. 그래서 <이점>을(를) 얻을 수 있다.
<사용자-스토리-예시>
- 모바일 뱅킹 고객으로서, 나는 내 계좌의 잔액을 볼 수 있기를 원한다. 그래서 지출에 대해 더 정보에 기반한 결정을 내릴 수 있다. </사용자-스토리-예시>
이 사용자 스토리 목록은 매우 광범위해야 하며 기능의 모든 측면을 다루어야 합니다.
구현 결정
내려진 구현 결정 목록입니다. 여기에는 다음이 포함될 수 있습니다:
- 빌드/수정될 모듈
- 수정될 모듈의 인터페이스
- 개발자의 기술적 설명
- 아키텍처 결정
- 스키마 변경
- API 계약
- 특정 상호 작용
특정 파일 경로나 코드 스니펫을 포함하지 마세요. 이는 빠르게 구식이 될 수 있습니다.
예외: 프로토타입이 산문보다 더 정확하게 결정을 인코딩하는 스니펫(상태 머신, 리듀서, 스키마, 타입 형태)을 생성한 경우, 관련 결정 내에 인라인으로 포함하고 프로토타입에서 비롯되었음을 간략히 언급하세요. 작동하는 데모가 아닌, 결정이 풍부한 부분만 추리고 중요한 부분만 남기세요.
테스트 결정
내려진 테스트 결정 목록입니다. 다음을 포함하세요:
- 좋은 테스트의 조건 설명 (외부 동작만 테스트하고 구현 세부 사항은 테스트하지 않음)
- 테스트할 모듈
- 테스트의 선례 (즉, 코드베이스 내 유사한 유형의 테스트)
범위 외
이 스펙의 범위를 벗어나는 사항에 대한 설명입니다.
추가 참고 사항
기능에 대한 추가 참고 사항입니다.