mattpocock/to-spec

이 스킬은 현재 대화 컨텍스트와 코드베이스 이해를 바탕으로 명세를 생성합니다. 사용자에게 인터뷰하지 말고, 이미 알고 있는 내용만 종합하세요.

이슈 트래커와 triage 레이블 어휘가 사전에 제공되어 있어야 합니다. 그렇지 않은 경우, 사용자에게 /setup-matt-pocock-skills를 실행하라고 안내하세요.

프로세스

1. 아직 탐색하지 않았다면, 저장소를 탐색하여 코드베이스의 현재 상태를 이해하세요. 명세 전체에 프로젝트 도메인 용어집의 용어를 사용하고, 해당 영역과 관련된 ADR을 존중하세요.

2. 기능을 테스트할 지점(seam)을 스케치하세요. 기존 지점을 새 지점보다 우선시하세요. 가능한 가장 높은 지점을 사용하세요. 새 지점이 필요한 경우, 가능한 가장 높은 지점에서 제안하세요. 코드베이스 전체에 지점이 적을수록 좋습니다. 이상적인 개수는 하나입니다.

사용자에게 이러한 지점이 기대치와 일치하는지 확인하세요.

3. 아래 템플릿을 사용하여 명세를 작성한 후, 프로젝트 이슈 트래커에 게시하세요. 추가 triage 없이 ready-for-agent triage 레이블을 적용하세요.

문제 설명

사용자가 직면한 문제를 사용자 관점에서 설명합니다.

해결 방안

사용자 관점에서 문제에 대한 해결 방안을 설명합니다.

사용자 스토리

긴 번호 목록의 사용자 스토리입니다. 각 사용자 스토리는 다음 형식을 따라야 합니다:

1. <행위자>로서, 나는 <기능>을 원합니다, 그래서 <혜택>을 얻을 수 있습니다.

<사용자-스토리-예시>

1. 모바일 뱅킹 고객으로서, 나는 내 계좌의 잔액을 확인할 수 있기를 원합니다, 그래서 지출에 대해 더 나은 결정을 내릴 수 있습니다. </사용자-스토리-예시>

이 사용자 스토리 목록은 매우 광범위해야 하며 기능의 모든 측면을 다루어야 합니다.

구현 결정 사항

내려진 구현 결정 사항 목록입니다. 여기에는 다음이 포함될 수 있습니다:

• 빌드/수정될 모듈
• 수정될 해당 모듈의 인터페이스
• 개발자의 기술적 설명
• 아키텍처 결정
• 스키마 변경
• API 계약
• 특정 상호 작용

특정 파일 경로나 코드 스니펫은 포함하지 마세요. 빠르게 구식이 될 수 있습니다.

예외: 프로토타입이 코드 스니펫을 생성하여 결정 사항을 산문보다 더 정확하게 인코딩하는 경우(상태 머신, 리듀서, 스키마, 타입 형태), 관련 결정 사항 내에 인라인으로 포함하고 프로토타입에서 왔음을 간략히 언급하세요. 작동하는 데모가 아닌 결정에 중요한 부분만 남기세요. 중요한 부분만 간추리세요.

테스트 결정 사항

내려진 테스트 결정 사항 목록입니다. 다음을 포함하세요:

• 좋은 테스트의 기준에 대한 설명 (외부 동작만 테스트하고 구현 세부 사항은 테스트하지 않음)
• 테스트될 모듈
• 테스트의 선례 (즉, 코드베이스 내 유사한 유형의 테스트)

범위 외 항목

이 명세의 범위를 벗어나는 사항들에 대한 설명입니다.

추가 노트

기능에 대한 추가 노트입니다.