Team-MINO-Android: Skill for Claude Code

mino-spec — SDD Spec 단계

입력

이 스킬을 호출한 메시지에서 /mino-spec 뒤에 사용자가 입력한 텍스트가 곧 기능 설명이다.

$ARGUMENTS

위 자리에 $ARGUMENTS가 문자 그대로 보이더라도, 그 내용은 항상 이 대화 안에 있다 — 스킬을 호출한 사용자 메시지를 그대로 기능 설명으로 삼는다. 따라서 기능 설명을 다시 말해 달라고 요청하지 않는다. 예외는 사용자가 인자 없이 빈 커맨드만 입력한 경우뿐이다.

스펙 문서 작성 가이드라인 요약

• 사용자가 무엇을 필요로 하는지, 그리고 왜 필요한지에 집중한다.
• 어떻게 구현할지는 다루지 않는다(기술 스택, API, 코드 구조 없음).
• 개발자가 아니라 비즈니스 이해관계자를 위해 작성한다.
• 명세 안에 체크리스트를 삽입하지 않는다. 그것은 별도의 커맨드가 담당한다.

섹션 별 요구사항

• 필수 섹션: 모든 기능에 대해 반드시 작성해야 한다
• 선택 섹션: 해당 기능과 관련 있을 때만 포함한다
• 적용되지 않는 섹션은 통째로 제거한다("N/A"로 남기지 않는다)

입력 프롬프트 유의사항

사용자 프롬프트로부터 이 명세를 작성할 때:

1. 합리적으로 추정한다: 맥락, 업계 표준, 일반적 패턴을 사용해 빈틈을 채운다
2. 테스터처럼 생각한다: 모호한 요구사항은 모두 "테스트 가능하고 명확한가" 체크리스트 항목에서 실패해야 한다

버전 규칙

spec.md 헤더의 버전은 MAJOR.MINOR.PATCH 시맨틱 버저닝을 따른다. 신규 작성은 항상 1.0.0이다.

개정 시 등급 판단 기준은 이미 갈라져 나간 하위 문서(plan.md·tasks.md)가 영향을 받는가이다.

• MAJOR: 확정된 요구사항의 경계가 바뀌는 변경. 요구사항 항목(FR-·UX-)의 삭제·의미 변경, 유저 시나리오의 재정의, §3 범위의 축소·확대 등 설계를 다시 해야 하는 경우.

• MINOR: 기존 항목을 유지한 채 늘어나는 변경. 새 요구사항·엣지 케이스·가정 추가, [TBD]로 남겨둔 항목의 확정.

• PATCH: 의미를 바꾸지 않는 개선. 표현 명확화, 오타 수정, 근거 링크 갱신.

• 등급이 모호하다면, 확정하기 전에 근거를 제시한다.

• 버전을 올릴 때는 최종 수정일을 오늘 날짜로 갱신한다.

• MAJOR·MINOR로 올릴 때는 같은 {SPEC_DIR}의 plan.md·tasks.md 존재 여부를 확인해, 재실행이 필요하다는 사실을 완료 보고에 포함한다.

헤더의 기준 PRD 버전은 spec 자신의 버전과 별개다. 실행할 때마다 읽어 들인 docs/prd/business-context.md 헤더의 버전으로 갱신하며, PRD가 없는 프로젝트면 없음으로 둔다. spec 개정 등급이 PATCH여도 이 값은 이번 실행에서 읽은 값으로 맞춘다. 이 값이 PRD 개정 때 어느 spec이 뒤처졌는지 판정하는 유일한 근거이므로 비워 두지 않는다.

작업 순서

1. feature 결정 · 작업 디렉터리 생성

1. 입력에서 feature-name 후보를 뽑는다. 기능을 대표하는 유니크한 이름이며, 한국어 입력이어도 이름은 영문 kebab-case(소문자·숫자·하이픈)로 만든다.
2. docs/specs/{feature-name}의 존재 여부로 신규 작성인지 개정인지를 가른다. 이 갈래는 이후 모든 단계에서 그대로 이어진다.
3. 확인 게이트 — 갈래에 맞는 승인을 사용자에게 받는다(AskUserQuestion). 승인 전에는 어떤 파일·디렉터리도 만들거나 고치지 않는다.
   • 신규 작성: 후보 이름을 제시하고 승인을 받는다. 이름은 이후 모든 단계의 산출물 경로가 되므로, 모델이 매번 새로 지어내 흔들리는 것을 여기서 막는다.
   • 개정: 같은 이름의 디렉터리가 이미 있다는 사실을 알리고, 기존 feature의 개정인지 이름 충돌인지 확인한다. 이름 충돌이면 다른 이름을 받아 신규 작성으로 되돌아간다. 개정이 맞으면 위 "버전 규칙"으로 판정한 등급(MAJOR·MINOR·PATCH)과 그 근거를 함께 제시해 승인을 받는다 — 등급이 하위 문서(plan.md·tasks.md)의 재작업 범위를 결정하므로 모델이 혼자 정하지 않는다.
4. {SPEC_DIR} = docs/specs/{feature-name} 을 mkdir -p로 확보한다. 이 feature의 spec.md와 이후 단계의 모든 문서가 이 디렉터리 아래에 들어간다.