---
name: workflow-composer
description: 요구사항 발견, 연구·실험, 디버깅, UI/Figma 구현이 한 요청에 섞여 있을 때 사용합니다. 단일 분류를 강제하지 않고 모듈을 조합하되, 제품·기능은 PRD·기술 스펙 승인 흐름으로, 연구 가설은 별도 사전등록 실험 흐름으로 보내며, 버그는 요청 증상과 직접 관련된 변경 범위를 별도 승인받은 뒤 수정합니다.
---

# 워크플로우 컴포저

## 출력 언어

사용자가 출력 언어를 명시적으로 지정하면 해당 언어를 사용합니다. 지정하지 않으면 이 스킬이 만드는 모든 사용자 대상 출력, 문서, 프롬프트, 보고서, 계획, 스펙 및 기타 산출물을 한국어로 작성합니다. 제목, 섹션, 레이블, 표, 체크리스트, 다이어그램과 템플릿에도 같은 언어를 사용합니다. 코드, 명령어, 파일 경로, 식별자, API 이름, 모델 ID, 프로토콜 이름과 필수 고유명사는 번역하지 않습니다.

## 라우팅

| 단서 | 적용 모듈 |
| --- | --- |
| 배경, 목표, 제품·기능 요구사항, 조사와 계획 | `requirements-to-spec` → `prd-writer` → `technical-spec-writer` |
| 연구 가설, benchmark, ablation, 학습·평가 실험, 결과 문서화 | `research-experiment-workflow` |
| 증상, 오류, 로그, 재현, "안 된다" | `bug-report-to-fix` |
| Figma 링크, 화면, 디자인, 시각 자료 | `figma-flow-to-implementation` |

한 요청에 여러 단서가 있으면 필요한 모듈을 함께 적용합니다. 단일 유형을 고르라고 사용자에게 되묻지 않습니다.

## 공통 흐름

1. 사용자가 부딪힌 순서대로 작업 단위를 식별합니다.
2. 제품·기능 요청은 조사한 뒤 PRD를 제시하고, 다음 단계를 막는 열린 질문을 문서 링크와 함께 대화에 먼저 제시합니다. 별도 승인과 질문 답변 후 기술 스펙을 제시하며, 같은 게이트를 다시 통과한 뒤 `start-implementation-thread`로 구현을 인계합니다.
3. 연구·실험 요청은 가설과 비교 계약을 조사해 사전등록 계획을 제시하고, 별도 승인 후 실행 단위로 인계하며, 원시 산출물에서 결과와 교훈을 기록합니다.
4. 버그 수정 요청은 원인을 먼저 조사하고 요청 증상과 직접 관련된 원인 및 필수 변경 범위를 제시한 뒤 별도 승인받아 수정·검증합니다.
5. 조사 중 발견한 별도 버그, 독립 리팩터링과 새 기능은 수정 전에 범위 확장 승인을 받습니다.
6. UI 요청은 `figma-flow-to-implementation`의 문서 확인과 구현 승인 흐름을 따릅니다.
7. 한 요청에 여러 모듈이 섞이면 각 모듈의 승인 상태를 분리해 기록하고, 한 모듈의 승인을 다른 모듈로 확대하지 않습니다.
8. 모든 구현·수정 작업은 최초 요청과 실행 승인을 분리합니다. 변경 범위와 검증을 제시하고 뒤이은 별도 구현 승인 메시지를 받은 다음 실행합니다.

## 질문 순서

저장소·공식 자료로 답할 수 있는 내용은 먼저 조사합니다. 사용자 판단이 필요한 질문만 사용자가 제시한 작업 순서대로 묻습니다. 한 답으로 여러 모듈이 풀리면 중복 질문을 만들지 않습니다.

문서 기반 단계 전환을 막는 질문은 문서 안에만 남기지 않습니다. 문서 링크와 질문 전문·선택지·권장안·영향을 대화에 제시한 뒤 `권장안대로 승인` 또는 질문별 직접 답변을 받습니다. 사용자가 문서를 먼저 승인했더라도 미제시·미응답 질문이 있으면 승인은 보존하고 질문을 먼저 처리합니다. 일반 `승인`을 권장안 선택으로 확대하지 않습니다.

열린 질문이 모두 해결되어 승인·취소만 남으면 `../../references/workflow-confirmation-ui.md`에 따라 버튼형 승인 카드를 사용합니다. 한 모듈의 승인 카드는 다른 모듈의 승인으로 확대하지 않습니다.

## 보조 문서

제품·기능에는 `prd-writer`와 `technical-spec-writer`를 순서대로 적용합니다. 연구·실험에는 PRD나 기술 스펙 대신 `research-experiment-workflow`의 계획·결과 문서를 사용합니다. `audit-technical-spec`은 사용자가 요청하거나 보안·데이터·호환성·배포처럼 실패 비용이 큰 계약에만 추가합니다.

## 핵심 규칙

- 사실, 추정, 조건, 결정, 열린 질문과 제외 방향을 분리합니다.
- 제품·기능은 PRD와 기술 스펙을 차례로 제시하고 각 단계 뒤 별도 메시지로 승인받습니다.
- 제품·기능의 다음 단계를 막는 열린 질문은 문서 링크와 함께 대화에 제시하고 답을 받은 뒤에만 전환합니다.
- 연구·실험은 사전등록 계획을 제시한 뒤 별도 메시지로 실행 승인받고, 결과를 본 뒤 계획을 소급 변경하지 않습니다.
- 버그 수정 요청은 관련 원인을 읽기 전용으로 조사한 뒤 변경 범위 승인 게이트를 거쳐 수정·검증합니다.
- 버그 수정 요청을 관련 없는 버그, 선택적 리팩터링과 새 기능의 수정 권한으로 확대하지 않습니다.
- 외부·비가역 행동의 승인은 해당 행동 직전에 받습니다.
- 최초 요청에 적힌 미래형 구현 의사를 PRD나 기술 스펙 승인으로 간주하지 않습니다.
- `이 방식으로 하죠` 같은 방향 채택 표현을 파일 수정·실행 승인으로 간주하지 않습니다.
- `구현해줘`, `고쳐줘`, `바로 진행해줘` 같은 최초 실행 요청도 범위 제시 뒤의 별도 승인으로 간주하지 않습니다.