Team-MINO-Android: Skill for Claude Code

mino-task — SDD Task 단계

입력

$ARGUMENTS

진행하기 전에 사용자 입력을 반드시 고려해야 한다(비어 있지 않은 경우).

위 자리에 $ARGUMENTS가 문자 그대로 보이더라도, 그 내용은 항상 이 대화 안에 있다 — 스킬을 호출한 사용자 메시지를 그대로 대상 지목으로 삼는다. 인자가 없으면 docs/specs/ 하위 디렉터리 목록을 제시해 대상을 고르게 한다(AskUserQuestion).

분해의 입력은 plan.md이고, spec.md는 커버리지 검증의 기준이다. 사용자가 함께 적은 보충 설명은 분해 순서·크기 판단의 힌트로 쓰되, plan에 없는 작업을 만들지 않는다.

범위 가드 (Scope Guard)

이 스킬의 작업 범위는 {SPEC_DIR}/tasks.md 작성으로 한정한다.

• 이 단계에서는 구현하지 않는다. 애플리케이션 소스, Gradle 스크립트, 리소스, 테스트 파일을 만들거나 고치지 않는다. 기존 코드는 읽기만 한다.
• spec.md·plan.md는 절대 고치지 않는다.
• 규약 문서(docs/conventions/·docs/architecture/)와 헌법을 고치지 않는다. 규약과 설계가 충돌하면 작업 목록으로 봉합하지 말고 보고한다.
• 규약·설계 내용을 작업 항목 본문으로 다시 풀어쓰지 않는다 — 링크와 섹션 번호로 지목한다.

작업 목록 작성 가이드라인 요약

• plan의 어떻게를 무엇을 어떤 순서로로 옮기는 문서다. 설계를 새로 하지 않고, 있는 설계를 빠뜨리지 않는다.
• 독자는 이 문서의 항목 하나를 집어 바로 착수할 수 있는 개발자다. 명확한 작업 시나리오가 정의되어있어야 한다.
• 근거 없는 작업은 만들지 않는다. plan·spec에서 지목할 수 없는 항목이 생기면 그것은 설계 누락이므로 미결사항으로 남긴다.
• 체크박스는 이미 짜인 코드의 기록이다. 이 문서는 SDD 사슬에서 유일하게 실행 상태를 담는 산출물이므로, 다시 쓸 때 그 상태를 잃지 않는 것이 내용의 정확성만큼 중요하다.

개정 시 병합 규칙

기존 tasks.md가 있으면 새 목록을 만들어 갈아끼우지 않고 제자리에서 병합한다.

1. 대조: 새로 도출한 작업 집합과 기존 작업을 하나씩 대조한다. 판단 기준은 ID가 아니라 무엇을 어느 파일에 만드는가이다.
2. 유지: 의미가 그대로인 작업은 ID와 체크 상태를 손대지 않는다. 설명 문구를 다듬는 것은 허용하되, 대상 파일이나 산출물이 달라졌다면 그것은 같은 작업이 아니다.
3. 추가: 새로 생긴 작업은 문서에 존재하는(폐기 섹션 포함) 최대 번호 + 1부터 ID를 부여하고, 속한 Phase의 알맞은 위치에 끼워 넣는다. 문서 순서와 ID 순서가 어긋나는 것은 정상이다.
4. 삭제: 없어진 작업이 미착수(- [ ])면 그냥 지운다. 완료(- [x])면 지우지 말고 "폐기된 작업" 섹션으로 옮긴다 — 이미 코드가 들어갔다는 뜻이므로 폐기 사유와 정리해야 할 범위를 함께 적는다.
5. ID 재사용 금지: 지우거나 폐기한 번호는 다시 쓰지 않는다.
6. 부수 섹션 갱신: 작업 집합이 바뀌었으면 "의존성 및 실행 순서", 병렬 실행 예시, 구현 전략도 함께 맞춘다.

개요(Outline)

1. 셋업 · 신규/개정 판별: {SPEC_DIR}/tasks.md의 존재 여부로 신규 작성인지 개정인지를 가른다. 이 갈래는 이후 모든 단계에서 그대로 이어진다.
   • 신규 작성: 내용을 쓰기 전에 빈 골격부터 디스크에 놓는다. mino-sdd/template/tasks-template.md를 {SPEC_DIR}/tasks.md로 그대로 복사한다(cp). 이 시점의 tasks.md는 플레이스홀더가 남은 껍데기다.
   • 개정: {SPEC_DIR}/tasks.md가 이미 존재하므로 절대 복사하지 않는다. 덮어쓰면 체크 상태가 통째로 소실된다. 기존 내용을 로드해 위 "개정 시 병합 규칙"에 따라 제자리 편집한다.