prd-to-trd
/spec-flow:prd-to-trd <prd-path> [--apply]
PRD 1건을 kebab-case 컴포넌트 슬러그 6~8개로 쪼개고 F-# / D-# / NF-# 항목마다 담당 TRD 를 지정한다. --apply 가 쓰는 것은 8개 절의 헤더와 안내 문구뿐 — 본문을 AI 가 대신 채우지 않는다.
spec-flow skills
제품 스펙과 실제 작업 사이를 양방향으로 오가는 스킬 6개 — PRD 를 TRD 로, TRD 를 이슈로 내려보내고, 이미 머지된 PR 과 이미 동작하는 기능에서 스펙을 역산합니다. 모호한 UI 요청은 구현 전에 화면 주문서로 되묻습니다. 스킬마다 설명서 1건이 있고, ui-order 를 뺀 다섯 개는 사용 예시도 있습니다.
정방향 — 스펙에서 작업으로
PRD─▶ 컴포넌트별 TRD─▶ 사람이 채운다─▶ Epic / Feature / Task 이슈
역방향 — 만들어진 것에서 스펙으로
예외 PR─▶ SSOT 추적 이슈 기존 기능─▶ 재사용 가능한 AI 프롬프트
기본값은 계획 파일이지 GitHub 이 아닙니다 —
prd-to-trd 와 trd-to-issues 는 --dry-run 이 기본이라 plan 파일 하나를 쓰고 멈춥니다. 사람이 그 파일을 고친 뒤 --apply 로 다시 부르면 Step 4 가 원문이 아니라 편집된 plan 을 되읽습니다. 실행 중간에 물어보는 프롬프트는 없습니다 — 리뷰 표면은 plan 파일뿐입니다.
1스킬 6개
trd-to-issues
/spec-flow:trd-to-issues <trd-path>... [--apply]
채워진 TRD 를 Epic → Feature → Task 3단으로 분해하고, Task 마다 “AC 3개 이하 · 단위 테스트 가능 · 독립 커밋 가능” 기준을 건다. 기준을 못 넘긴 항목은 더 쪼개거나 plan 에 분해 실패로 적힌다.
pr-to-ssot-issue
/spec-flow:pr-to-ssot-issue <PR#> --reason "<text>"
PRD/TRD 없이 지나간 예외 PR 을 역산해 8개 절짜리 SSOT 추적 이슈 1개로 남긴다. --reason 은 10자 이상 필수이고, 원본 PR 은 읽기 전용이다 — gh pr edit / comment / review 를 부르지 않는다.
reverse-engineering-analysis
/spec-flow:reverse-engineering-analysis "<feature>" [out-dir]
기존 기능 하나를 라이브러리 · 데이터 흐름 · 파일 맵으로 뜯어 analysis.md 를 쓴다. 그 문서의 핵심은 요약이 아니라 다른 프로젝트에 그대로 붙여넣을 수 있는 AI 구현 프롬프트이며, 그래서 프로젝트 고유 경로를 남기지 않는다.
claude-to-codex
/spec-flow:claude-to-codex <phase-doc> [refs...]
Claude 가 쓴 phase 문서를 Codex 가 원본 없이 실행할 수 있는 명령형 문서로 고쳐 docs/ai/phases/codex/ 에 쓴다. 원본은 건드리지 않고, 분할은 기본이 아니라 문서화된 트리거가 걸릴 때만 번호 슬라이스로 나눈다.
ui-order
/spec-flow:ui-order "<UI request>"
“버튼 만들어줘”, “폰에서도 되게” 같은 모호한 UI 요청을 바로 구현하지 않고, 빠진 결정을 묻는 질문 최대 5개와 기본값을 채운 화면 주문서 초안으로 먼저 답한다. 질문이 곧 최종 출력이라 실행 중간에 멈추지 않는다. 파일은 --setup --apply 때만, 프로젝트 CLAUDE.md 의 표식 블록 안에만 쓴다. --check 는 기존 프런트엔드 코드를 읽기 전용으로 점검한다.
2세 방향
파이프라인 위의 다섯 개를 가르는 기준은 주제가 아니라 파이프라인 위에서 어느 쪽으로 움직이는가입니다.
내려간다 — prd-to-trd → trd-to-issues
둘은 이어지지만 맞물려 돌지는 않는다. 앞은 빈 8개 절 스캐폴드까지만 만들고 멈추고, 뒤는 이미 채워진 TRD 에서 시작한다. 그 사이의 빈칸을 채우는 것은 사람의 몫이고, 그 공백이 이 파이프라인의 설계다.
올라온다 — pr-to-ssot-issue · reverse-engineering-analysis
이미 존재하는 것에서 스펙을 역산한다. 앞은 기록의 공백을 메운다 — 워크플로를 건너뛴 PR 을 추적 이슈로 되돌린다. 뒤는 지식의 공백을 메운다 — 동작하는 기능을 다른 곳에서 재현할 프롬프트로 바꾼다.
옆으로 간다 — claude-to-codex
같은 층에 머문 채 실행자만 바꾼다. 문서를 분해하지 않고 다시 쓴다 — 위로도 아래로도 움직이지 않으니 파이프라인 단계가 아니라 번역기에 가깝다.
각 카드의 “실제 산출물” 링크는 만들어낸 예시가 아니라 이 저장소가 자기 자신에게 이 스킬들을 돌린 결과입니다 — 지금 보고 있는 이 문서 사이트의 PRD 를 examples/prd-to-trd/ 에서 TRD 8건으로 쪼개고, 그 중 링크 검증 TRD 를 Codex 용 phase 문서로 옮겼고, 이 저장소의 CI 워크플로를 역분석했습니다.