태스크 가져오기

개요

get-tasks는 승인된 PRD를 실행 가능한 태스크 세트로 변환합니다. 각 태스크는 자체 파일에 기록되며, 단일 집중 세션에 맞게 크기가 조정되고, 의존성 순서로 정렬되며, 수용 기준, 유효성 검사 단계, 차단 목록 및 롤백 절차와 함께 제공됩니다.

이것이 자체 스킬로 존재하는 이유: PRD는 계획이 아닙니다. PRD는 시스템이 무엇을 하고 왜 하는지를 설명합니다. 작업 순서, 병렬로 구축할 수 있는 항목, 위험한 부분이 있는 위치 또는 슬라이스가 완료되었음을 증명하는 방법에 대해서는 아무것도 말하지 않습니다. PRD를 바로 코드로 전환하면 영웅적인 단일 패스 변경이나 중간에 중단되는 임의의 순서가 생성됩니다.

get-tasks는 누락된 계층을 제공합니다. PRD를 읽고, 실제 의존성 구조를 매핑하고, 작업을 수직 슬라이스로 자르고, 각 슬라이스를 에이전트(또는 인간)가 전체 PRD를 다시 읽지 않고도 집어들 수 있는 독립형 아티팩트로 작성합니다.

이 스킬은 세 가지 소스에서 비롯됩니다:

의존성 우선 분해 및 수직 슬라이싱 — 의존성 그래프를 구축하고, 수평이 아닌 수직으로 슬라이스하며, 각 태스크의 크기를 조정하고, 체크포인트를 배치합니다. 이것이 순서를 올바르게 만듭니다.
유효성 검사 중심 실행 — 모든 태스크는 "테스트 통과"뿐만 아니라 여러 유효성 검사 유형에 걸쳐 어떻게 검증될 것인지를 선언하고, 단계가 실패할 경우 재계획 절차를 수행합니다.
차단 에지 및 트레이서 불릿 — 각 태스크는 무엇이 자신을 차단하는지 명시적으로 명시하므로, 차단자가 완료된 모든 태스크는 즉시 시작할 수 있습니다.

출력은 태스크 파일 디렉토리입니다: tasks/<name>/task-01.md, task-02.md 등, 의존성 순서로 번호가 매겨지며, tasks/<name>/plan.md가 이를 인덱싱합니다. 차단 태스크는 낮은 번호를 받습니다.

이 스킬의 범위

get-tasks는 의도적으로 포괄적입니다. 여러 협소한 스킬이 각각 부분적으로 수행했던 것을 흡수하여, 사용자가 승인된 PRD에서 추적 가능한 실행 계획으로 이동하는 데 하나의 스킬만 필요하도록 합니다. 여기의 모든 것은 해당 단일 작업에 관련이 있습니다:

우려사항	처리 위치
PRD 읽기 및 약속 추출	1단계
의존성 구조 및 순서	2단계
수직 슬라이싱 및 트레이서 불릿	3단계
광범위한 리팩터(확장, 마이그레이션, 축소)	3단계
태스크별 명세	4단계
크기 조정 및 분할 규칙	5단계
체크포인트 및 게이트	5단계
병렬화 분류	병렬화 분류법
사람이 읽을 수 있는 계획 요약, 리스크, 결정	6단계
추적기 대 파일 대상	태스크 목록 대상
쓰기 전 사용자 승인	7단계
아티팩트 쓰기, 동기화 및 검증	8단계
실패 처리 및 재계획	태스크 실패 시 재계획

길이는 의도적입니다. 길이가 요점입니다: 이러한 사항 중 하나라도 암시적으로 남겨두는 분해는 완료된 것처럼 보이지만 실제로는 완료되지 않은 태스크를 생성합니다. 템플릿으로 건너뛰고 싶다면 대신 2, 3, 5단계를 읽으십시오 — 분해가 실제로 실패하는 곳입니다.

이 스킬이 하지 않는 일: 코드를 작성하지 않고, 태스크를 실행하지 않으며, PRD를 대체하지 않습니다. 하나의 문서를 문서 세트로 변환합니다.

사용 시기

다음 경우에 이 스킬을 사용하십시오:

PRD, 명세 또는 요구사항 문서가 존재하고 작업을 실행 가능한 태스크로 전환해야 하는 경우
사용자가 "get tasks", "breakdown PRD", "pecah jadi task", "bikin task list" 또는 "이것을 태스크로 전환해"라고 말하는 경우
태스크가 시작하기에는 너무 커서 분해가 필요한 경우
범위를 추정하거나, 작업을 정렬하거나, 병렬로 실행할 수 있는 항목을 찾아야 하는 경우
소수의 파일 이상에 영향을 미치는 무언가를 구현하려고 하고 태스크 목록이 존재하지 않는 경우

사용하지 말아야 할 경우:

PRD가 아직 존재하지 않는 경우 — 먼저 get-prd를 실행한 후 다시 오십시오
변경 사항이 어떤 기준으로든 단일 태스크인 경우(하나의 파일, 하나의 명백한 편집) — 그냥 수행하십시오
tasks/에 완전한 태스크 분해가 이미 존재하고 구현할 준비가 된 경우 — 태스크를 순서대로 실행하는 것으로 직접 진행하십시오

프로세스

get-tasks는 9단계로 실행됩니다. 각 단계에는 종료 조건이 있습니다. 종료 조건이 충족되지 않은 단계를 넘어 진행하지 마십시오.

0. PRD 찾기             -> 소스 문서는 무엇인가?
1. 읽기 및 추출         -> PRD가 우리에게 약속하는 것은 무엇인가?
2. 의존성 그래프        -> 무엇이 무엇에 의존하는가?
3. 수직 슬라이스        -> 수평 계층이 아닌 트레이서 불릿
4. 각 태스크 작성       -> 태스크당 하나의 파일, 완전히 명세됨
5. 순서, 크기, 체크포인트 -> 순서, 크기 및 검증 게이트
6. 계획 문서 작성       -> 태스크를 인덱싱하는 사람이 읽을 수 있는 요약
7. 사용자에게 질문      -> 세분성, 차단 에지, 병합 또는 분할
8. 쓰기 및 검증         -> 디스크의 파일, 동기화된 할 일, 녹색 검증기

태스크 분해를 위한 보편적 원칙

자연어 페이싱: 파일 이름, git 용어 및 코드 토큰은 표준(task-01.md, branch, commit, TDD)으로 유지하면서 분해 및 대화형 요약을 사용자가 사용하는 언어(인도네시아어 또는 영어)로 제시하십시오.
자율 실행 준비: tasks/<feature>/task-*.md에 생성된 각 태스크 파일은 완전히 자체 포함되어야 합니다. 모든 코딩 에이전트는 해당 단일 태스크 파일만 읽고, 어떤 파일을 편집해야 하는지, 어떤 테스트를 실행해야 하는지, 어떤 완료 정의가 충족되어야 하는지 추측 없이 알 수 있어야 합니다.
수평 계층보다 수직 슬라이스: 종단 간 검증할 수 없는 경우 순수하게 "백엔드 설정" 또는 "프론트엔드 설정"인 태스크를 고립되어 생성하지 마십시오. 각 태스크가 테스트 가능한 가치를 제공하도록 수직으로 슬라이스하십시오(예: "UI 트리거가 있는 SKU 엔드포인트 저장 및 쿼리").

계획은 읽기 전용입니다. 0~7단계는 문서와 질문을 생성하며 코드를 생성하지 않습니다. 해당 단계 동안 소스 파일을 생성, 편집 또는 삭제하지 마십시오. tasks/ 아래에 태스크 파일을 작성하는 것은 사용자가 승인하기 전에 허용되는 유일한 파일 시스템 변경입니다. 작업을 분해하는 동안 버그를 수정하거나 함수를 추가하는 자신을 발견하면 중단하십시오: 이는 승인 후 구현에 속하며, 아직 작성하지 않은 태스크에 속합니다.

0단계: PRD 찾기

다른 작업을 수행하기 전에 소스 문서를 찾으십시오.

관례 우선. get-prd는 docs/prd/<name>.md에 저장합니다. 먼저 거기를 찾으십시오.
그런 다음 더 넓은 검색. docs/prd/가 비어 있으면 사용자가 명명한 PRD를 찾으십시오. 이슈 본문이나 붙여넣은 요구사항 문서를 수락하십시오 — 스킬은 형식에 구속되지 않으며, 1단계의 추출만 PRD 섹션 이름을 가정합니다.
후보가 두 개 이상인 경우 추측하지 마십시오. 나열하고 어떤 것이 이 작업을 관장하는지 물어보십시오.
없는 경우 중단하고 그렇게 말하십시오. 요구사항을 발명하지 마십시오. 사용자를 전체 인터뷰-투-PRD 패스인 get-prd로 안내하십시오.

작업 중인 정확한 경로를 기록하십시오. 이후의 모든 단계가 이를 참조합니다.

다중 모듈 이니셔티브의 경우 PRD가 모듈 ID별로 분할된 경우(docs/prd/identity.md, docs/prd/billing.md), 이 분해가 어떤 모듈을 다루는지 확인하십시오. 모듈당 하나의 분해, 기능 맵이 선언한 빌드 순서대로.

종료 조건: 단일 소스 문서가 식별되고 해당 경로가 기록됩니다.

1단계: 읽기 및 추출

PRD를 전체적으로 읽으십시오. 그런 다음 분해를 추진하는 자료를 명시적으로 추출하십시오:

PRD 섹션	추출할 내용
목표	모든 태스크가 궁극적으로 제공하는 최종 상태
사용자 스토리	작동해야 하는 관찰 가능한 동작, 후보 수용 기준
기술 결정	모듈, 인터페이스, 스키마 변경, 계약 — 이는 태스크 간의 실제 경계를 정의합니다
프로젝트 구조	아티팩트가 위치하는 곳, 이는 "영향을 받을 파일"을 제한합니다
명령	각 태스크가 인용할 구체적인 검증 명령
테스트 전략	여기서 좋은 테스트로 간주되는 것과 테스트가 속한 위치
경계	항상 / 먼저 물어보기 / 절대 안 함 — 절대 안 함 항목은 모든 태스크에 대한 하드 제약이 됩니다
범위 외	명시적 비목표; 여기서 어떤 것도 태스크가 되지 않음
성공 기준	최종 게이트; 마지막 체크포인트가 이에 대해 검증합니다

규칙:

아직 슬라이싱을 시작하지 마십시오. 먼저 추출, 그 다음 분해. 읽으면서 슬라이싱하면 문서를 읽은 순서에 의해 형성된 태스크가 생성됩니다.
모호한 항목을 확인 가능한 진술로 변환하십시오. PRD가 "대시보드가 빨라야 한다"고 말하면 태스크의 수용 기준은 숫자이며, PRD가 숫자를 제공하지 않았다면 조용히 선택하는 대신 차단 사항으로 표면화하십시오.
갭을 표시하십시오. 필요한 섹션이 누락되었거나 비어 있으면 이름을 지정하십시오. 누락된 테스트 전략은 모든 태스크의 검증 블록이 나중에 발명된다는 것을 의미합니다. 지금 제기하십시오.
요구사항을 절대 발명하지 마십시오. PRD가 말하지 않으면 그것은 태스크가 아닙니다.

종료 조건: 추출 테이블이 채워지고 갭이 사용자에게 제기되었습니다.

2단계: 의존성 그래프 매핑

단일 태스크를 작성하기 전에 무엇이 무엇에 의존하는지 매핑하십시오. 이는 순서를 결정하고 가장 비용이 많이 드는 실수 유형(생산자가 존재하기 전에 소비자를 구축하는 것)을 방지하는 단계입니다.

그래프를 그리십시오. 구체적으로, 추상적이지 않게:

데이터베이스 스키마
    |
    +-- API 모델 및 타입
    |       |
    |       +-- API 엔드포인트
    |       |       |
    |       |       +-- 프론트엔드 API 클라이언트
    |       |               |
    |       |               +-- UI 컴포넌트
    |       |
    |       +-- 검증 로직
    |
    +-- 시드 데이터 및 마이그레이션

규칙:

에지는 생산자에서 소비자를 가리킵니다. 화살표는 "대상이 먼저 소스가 필요함"을 의미합니다.
사이클이 없습니다. 두 개가 서로를 필요로 하면 하나의 태스크이거나, 둘 사이의 인터페이스가 먼저 자체 태스크로 정의되어야 합니다.
인터페이스는 경계입니다. 두 태스크가 계약(타입, 엔드포인트 모양, 스키마)에서 만나면 이전 태스크에서 계약을 정의하고 이후 태스크에서 소비하십시오. 두 태스크가 독립적으로 발명하도록 절대 두지 마십시오.
프런티어를 찾으십시오. 프런티어는 모든 차단자가 완료된 모든 태스크입니다. 지금 시작할 수 있는 것입니다. 선형 체인의 경우 프런티어는 하나의 태스크 너비입니다. 넓은 프로젝트의 경우 여러 개일 수 있습니다.
병렬 기회와 하드 시퀀스를 명명하십시오. 독립적인 슬라이스는 병렬로 실행될 수 있습니다. 마이그레이션, 공유 상태 변경 및 동일한 계약을 건드리는 모든 것은 순차적이어야 합니다.

종료 조건: 의존성 그래프가 존재하며, 명확한 프런티어가 있고 사이클이 없습니다.

3단계: 수직으로 슬라이스하기

작업을 트레이서 불릿으로 자르십시오: 기능이 필요로 하는 모든 계층을 통과하는 좁지만 완전한 경로입니다.

수평 슬라이싱은 기본적인 실수입니다. 깔끔해 보이고 마지막 태스크까지 실행 가능한 것을 생성하지 않습니다:

나쁨 (수평):
태스크 1: 전체 데이터베이스 스키마 구축
태스크 2: 모든 API 엔드포인트 구축
태스크 3: 모든 UI 컴포넌트 구축
태스크 4: 모든 것을 연결

태스크 3이 끝나면 아무것도 작동하지 않습니다. 아무도 데모할 수 없습니다. 태스크 1의 잘못된 가정은 태스크 4에서 발견됩니다.

수직 슬라이싱은 모든 단계에서 작동하는 소프트웨어를 생성합니다:

좋음 (수직):
태스크 1: 사용자가 계정을 생성할 수 있음 (등록을 위한 스키마 + API + UI)
태스크 2: 사용자가 로그인할 수 있음 (인증을 위한 스키마 + API + UI)
태스크 3: 사용자가 태스크를 생성할 수 있음 (생성을 위한 스키마 + API + UI)
태스크 4: 사용자가 태스크 목록을 볼 수 있음 (목록 보기를 위한 쿼리 + API + UI)

좋은 슬라이스 규칙:

동작이 필요로 하는 모든 계층을 자릅니다 — 데이터, 로직, 인터페이스, 테스트.
자체적으로 데모 가능하거나 검증 가능합니다. 어떻게 작동하는지 확인할 수 있는 방법을 설명할 수 없다면 슬라이스가 아닙니다.
하나의 집중 세션에 맞습니다 — 대략 하나의 새로운 컨텍스트 창.
구조가 아닌 동작을 전달합니다. "사용자 테이블 추가"는 슬라이스가 아닙니다. "사용자가 등록할 수 있음"이 슬라이스입니다.

광범위한 리팩터는 예외입니다. 광범위한 리팩터는 전체 코드베이스에 걸쳐 영향을 미치는 하나의 기계적 변경(열 이름 변경, 공유 심볼 타입 변경)이므로 어떤 수직 슬라이스도 녹색으로 착지할 수 없습니다. 트레이서 불릿으로 강제하지 마십시오. 확장, 마이그레이션, 축소로 순서를 정하십시오:

확장 — 아무것도 깨지지 않도록 이전 형태 옆에 새 형태를 추가하십시오.
마이그레이션 — 호출 사이트를 블래스트 반경(패키지당, 디렉토리당)별로 배치로 이동하고, 각 배치는 이전 형태가 여전히 존재하므로 배치 간 빌드를 녹색으로 유지하면서 확장에 의해 차단되는 자체 태스크입니다.
축소 — 호출자가 더 이상 없으면 이전 형태를 삭제하고, 모든 마이그레이션 배치에 의해 차단되는 태스크에서 삭제하십시오.

배치조차 단독으로 녹색을 유지할 수 없는 경우 동일한 순서를 유지하지만 최종 통합 및 검증 태스크를 모두 차단하는 통합 브랜치를 공유하도록 하고, 여기서 녹색이 약속됩니다.

종료 조건: 모든 작업이 정확히 하나의 태스크에 속하며, 모든 태스크가 수직 슬라이스이거나 선언된 광범위한 리팩터 단계입니다.

4단계: 각 태스크 작성

각 태스크를 자체 파일로 작성하십시오. 항상 파일당 하나의 태스크 — 모든 태스크가 포함된 단일 결합 문서는 절대 안 됩니다.

출력 경로: tasks/<name>/task-NN.md, 여기서 <name>은 PRD의 이름과 일치합니다(따라서 docs/prd/billing.md의 PRD는 tasks/billing/task-01.md를 생성). 의존성 순서로 01부터 번호를 매기십시오 — 차단자는 낮은 번호를 받습니다.

태스크 파일 템플릿:

# 태스크 NN: <짧은 설명적 제목>

**소스:** docs/prd/<name>.md — <이 태스크가 구현하는 PRD 섹션>

**구축할 내용:** 이 태스크가 작동하게 하는 종단 간 동작, 사용자 관점에서. 계층별 구현 목록이 아닙니다. 사용자나 호출자가 관찰할 수 있는 동작으로 설명할 수 없으면 태스크를 재구성하십시오.

## 수용 기준

- [ ] <구체적이고 테스트 가능한 조건>
- [ ] <구체적이고 테스트 가능한 조건>

모든 기준은 태스크를 작성하지 않은 사람이 확인할 수 있어야 합니다. "올바르게 작동함"은 기준이 아닙니다. "사용자가 이메일과 비밀번호로 등록하고 대시보드로 리디렉션됨"이 그렇습니다.

## 검증

- [ ] 테스트 통과: <리포지토리의 집중 테스트 명령 또는 먼저 작성할 새 테스트>
- [ ] 빌드 성공: <리포지토리의 빌드 명령>
- [ ] 출력 일치: <존재해야 하는 예상 패턴 또는 아티팩트>
- [ ] 회귀 없음: <전체 스위트 또는 관련 하위 집합>
- [ ] 품질 및 보안: <입력 검증, 인증 경계, 다음을 따름>
- [ ] 오방향 검증: 로직 정확성, 경계 조건, 오류 처리, 성능/규모, 보안이 각각(시간이 허락하는 한) 확인됨

## 차단 목록

> [ ] <이 태스크가 완료되기 전에 존재해야 하는 것>
> [ ] <다른 의존성>

## 롤백 절차

1. <변경 사항을 되돌리기 위한 단계>
2. <이전 안정 상태로 복원>

## 참고 사항

<구현 중인 사람에게 유용한 컨텍스트 또는 결정 기록>

5단계: 순서, 크기, 체크포인트

각 태스크의 순서를 결정하고 적절한 크기인지 확인하며 체크포인트를 정의하십시오.

순서:

태스크 순서는 2단계의 의존성 그래프에 의해 결정됩니다. 그래프의 순차적 처리는 태스크 번호를 생성합니다:

차단 태스크는 차단 해제된 태스크보다 먼저 번호가 매겨집니다.
병렬 태스크는 동일한 번호 체계 내에서 함께 그룹화됩니다(예: task-02와 task-03이 모두 차단 해제되고 병렬로 실행될 수 있음).
태스크가 너무 많으면(> 10) 추가 그룹화가 필요할 수 있습니다. 이 경우 tasks/<name>/phase-1/task-01.md와 같이 하위 디렉토리를 생성하십시오.

크기:

각 태스크는 단일 집중 세션에 맞아야 합니다. 대략 2-4시간의 작업과 같습니다. 태스크가 너무 크면:

수용 기준이 너무 많은 조건 또는 너무 광범위한 조건을 가지고 있는지 확인하십시오.
태스크를 더 작은 슬라이스로 분할하십시오.
리팩터가 필요한 경우 확장-마이그레이션-축소 모델을 사용하십시오.

너무 작은 태스크는 단일 수용 기준으로 스스로를 정당화할 수 없습니다. 이전 또는 다음 태스크와 병합을 고려하십시오.

체크포인트 및 게이트:

체크포인트는 진행 상황의 중간 지점입니다. 게이트는 태스크가 완료되었음을 증명하는 최종 수용 기준입니다.

각 태스크에 대해 체크포인트를 배치하십시오:

첫 번째 체크포인트: 처음으로 녹색이 되는 것 — 실패한 테스트가 통과하는 것.
중간 체크포인트: 구현이 완료될 때.
최종 게이트: 태스크의 모든 수용 기준이 충족됨.

성공 기준은 PRD의 성공 기준에 대해 최종 게이트를 검증합니다.

병렬 분류:

각 태스크를 다음 중 하나로 분류하십시오:

P (병렬): 다른 태스크와 독립적으로 실행 가능.
S (순차): 차단 태스크 완료 후 실행해야 함.
B (차단): 많은 다른 태스크를 차단하는 핵심 태스크(낮은 번호가 매겨져야 함).

이를 태스크 파일에 명시적으로 기록하고 계획 문서에 요약하십시오.

종료 조건: 모든 태스크에 순서, 크기, 체크포인트 및 병렬 분류가 할당되었습니다.

6단계: 계획 문서 작성

실행 안내자 역할을 하는 사람이 읽을 수 있는 계획 문서를 작성하십시오.

출력 경로: tasks/<name>/plan.md

# 실행 계획: <PRD 이름>

**소스:** docs/prd/<name>.md

## 개요

<태스크 세트가 달성하는 내용에 대한 간략한 요약>

## 의존성 그래프

<텍스트 또는 키릴 기반 의존성 그래프>

## 태스크 목록

| # | 제목 | 분류 | 예상 시간 | 차단기 |
|---|---|---|---|---|
| 01 | <제목> | P/S/B | <추정> | <없음 또는 목록> |

## 병렬 기회

<병렬로 실행할 수 있는 태스크와 그 방법>

## 리스크 및 결정

<알려진 리스크 및 주요 결정>

## 성공 기준

<PRD의 성공 기준이 어떻게 충족되는지>

종료 조건: plan.md가 작성되고 태스크 목록과 일치합니다.

7단계: 사용자에게 질문

태스크를 쓰기 전에 사용자에게 다음을 확인하십시오:

세분성: 태스크가 올바른 크기인가요? 너무 크거나 작습니까?
차단 에지: 의존성 그래프가 올바른가요?
병합 또는 분할: 태스크를 병합하거나 분할해야 합니까?
누락된 항목: 어떤 태스크가 빠졌습니까?
범위 외 항목: 범위 외로 표시된 항목이 태스크에 포함되어서는 안 됩니다.

사용자가 승인하면 8단계로 진행하십시오. 그렇지 않으면 피드백을 통합하고 필요한 경우 다시 질문하십시오.

종료 조건: 사용자가 태스크 목록을 승인했습니다.

8단계: 쓰기 및 검증

태스크 파일을 디스크에 쓰고 동기화하고 검증하십시오.

쓰기: tasks/<name>/ 디렉토리를 생성하고 각 태스크에 대해 task-NN.md를 기록하십시오.
동기화: plan.md를 업데이트하여 최종 태스크 목록과 일치하도록 하십시오.
검증: 생성된 각 파일을 읽고 템플릿과 일치하는지, 수용 기준이 명확한지, 종료 조건이 충족되었는지 확인하십시오.
보고: 태스크 파일 요약, 총 태스크 수, 병렬 기회 및 알려진 리스크를 사용자에게 제공하십시오.

종료 조건: 모든 태스크 파일과 plan.md가 디스크에 존재하고 검증이 통과했습니다.

태스크 실패 시 재계획

태스크 실행 중 실패가 발생하면:

중단: 현재 태스크를 중지하십시오.
분석: 무엇이 실패했는지 확인하십시오(수용 기준이 충족되지 않음, 차단 해제된 의존성, 기술적 문제).
재계획: 다음 중 하나를 수행하십시오:
- 태스크를 수정하십시오(수용 기준 또는 접근 방식 조정).
- 태스크를 분할하십시오(나중에 해결할 부분을 별도의 태스크로 분할).
- 차단기를 추가하십시오(실패의 근본 원인을 해결하는 이전 태스크를 추가).
사용자에게 알리십시오: 무슨 일이 일어났는지와 업데이트된 계획을 설명하십시오.
태스크 파일 업데이트: 변경 사항을 반영하도록 태스크 파일을 수정하십시오.

이 프로세스는 태스크 번호 재지정 없이 태스크 사이의 추가 단계로 간주되어야 합니다.

태스크 목록 대상

기본적으로 태스크는 파일로 생성됩니다(tasks/<name>/task-*.md). 사용자는 대신 할 일 추적기(예: GitHub Issues, Linear, Jira)로 출력을 요청할 수 있습니다. 이 경우:

지원되는 추적기 목록을 사용자에게 제공하십시오(GitHub Issues, Linear, Trello 등).
각 태스크를 해당 추적기에 적절한 형식으로 생성하십시오.
tasks/<name>/plan.md에 추적기 참조를 첨부하십시오.
태스크가 파일 기반인 경우와 동일한 콘텐츠 구조를 유지하십시오.

최종 참고 사항

get-tasks는 경량이지만 포괄적으로 설계되었습니다. 프로세스를 충실히 따르면 결과 태스크가 명확하고 실행 가능하며 성공 가능성이 높아집니다.

기억하십시오: 좋은 태스크 분해는 구현 시간을 절약하고 오해를 방지하며 작업이 원활하게 진행되도록 합니다. PRD를 코드로 전환하는 데 시간을 투자할 가치가 있습니다.

이 스킬에 대한 질문이나 개선 제안이 있으면 저장소에 이슈를 열어 주십시오.

rizqinrr/get-tasks

get-tasks란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서

태스크 가져오기

개요

이 스킬의 범위

사용 시기

프로세스

태스크 분해를 위한 보편적 원칙

0단계: PRD 찾기

1단계: 읽기 및 추출

2단계: 의존성 그래프 매핑

3단계: 수직으로 슬라이스하기

4단계: 각 태스크 작성

5단계: 순서, 크기, 체크포인트

6단계: 계획 문서 작성

7단계: 사용자에게 질문

8단계: 쓰기 및 검증

태스크 실패 시 재계획

태스크 목록 대상

최종 참고 사항

Individual skills in this repo

rizqinrr/get-prd

관련 스킬

steipete/bluebubbles

steipete/eightctl

steipete/blucli

steipete/bear-notes

steipete/camsnap

steipete/gifgrep