---
name: app-orchestrator
description: 신규 앱 개발, 기능 추가, 버그 수정, 리팩토링의 전체 사이클을 계획하고 필요한 스킬을 연결해 진행한다. 사용자가 개발 작업을 기획부터 구현·검증·필요한 배포까지 맡기거나 기존 개발 흐름의 재개를 요청할 때 사용한다. 단일 분야의 검토만 요청하면 해당 단계 스킬을 우선한다.
---

# 앱 개발 오케스트레이터

작업의 규모와 현재 프로젝트 상태에 맞춰 필요한 단계를 선택한다. 새 앱과 기존 앱에 같은 흐름을 사용하되, 이미 있는 결정과 결과를 재사용한다.

## 시작과 재개

1. 대상 저장소, 사용자 요청, 적용되는 프로젝트 지침, 작업 트리와 기존 계획·구현 상태를 확인한다. 스킬이 설치된 폴더와 대상 앱의 폴더를 구분한다.
2. 신규 개발·기능 추가·버그 수정·리팩토링 중 작업 성격과 요청된 완료 범위를 파악한다. 기존 대화에서 결정한 내용과 실행 권한을 유지한다.
3. `project-conventions`로 관련 규칙과 출처·누락을 조회한다. 이미 확인한 규칙은 변경 여부만 살피고, 첫 조회에서 모든 미정 정책을 일괄 질문하지 않는다.
4. [단계 전달·진행 기록 규약](references/workflow-contract.md)을 읽고 기존 기록을 찾는다. 없으면 작업 규모에 맞는 기록을 시작한다. 기존 앱의 변경·재개이거나 실행 깊이가 불분명하면 [작업별 경로와 정합성 기준](references/routing.md)을 읽는다.
5. 경로를 짧게 설명한 뒤 작업을 진행한다. 결과에 큰 영향을 주는 미확정 사항만 질문하고, 독립적으로 가능한 작업은 계속한다.

## 단계 선택

| 단계 스킬 | 선택 기준 | 생략·축소 기준 |
| --- | --- | --- |
| `kickoff` | 목표·범위·완료 조건 구체화가 필요함 | 이미 명확하면 기존 내용을 확인하고 연결 |
| `experience-design` | 사용자 흐름·화면·상태·조작 방식이 바뀜 | 사용자 경험 변화가 없으면 근거를 남기고 생략 |
| `technical-design` | 구조·계약·데이터·의존성 또는 구현 순서 결정이 필요함 | 작은 변경은 짧은 구현·검증 계획으로 축소 |
| `implement` | 코드·설정·문서 변경이 필요함 | 설계·리뷰만 요청한 작업이면 실행하지 않음 |
| `verify` | 결과가 요청과 맞는지 확인함 | 깊이를 조절하되 미검증 사항을 통과로 표시하지 않음 |
| `release` | 패키징·배포·배포 준비가 완료 범위에 포함됨 | 구현까지만 요청했다면 생략 |

기술 제약을 알아야 UX를 결정할 수 있으면 기술 검토를 먼저 수행한다. CI 준비는 기술 설계와 구현에서 다루고, 릴리스에서 실제 결과를 확인한다.

## 프로젝트 규칙 설정 시점

기존 규칙 조회 → 필요한 kickoff → 필요한 정책 설정 → 설계·구현 순서로 연결한다. 킥오프 결과가 이미 있으면 재사용하고, 관련 미정 정책이 있으면 `project-conventions`로 선택·기록한다. 정책은 기존 기준·이번 확정·명시한 기본값·미정·조건부 연기·해당 없음으로 구분해 전달받는다.

관련 작업 전에 필요한 핵심 정책이 미정이면 그 작업을 보류하고 독립적인 조사·설계를 진행한다. 스택이 정해져야 채울 검사 명령은 기술 설계에서, 아직 범위 밖인 운영 배포 규칙은 해당 배포를 다룰 때 정한다. 연기 조건이 도래했는지 단계 진입 전에 확인한다.

TDD·확인 방식·수치 목표는 명시적으로 채택한 프로젝트 정책을 적용한다. 외부 레퍼런스의 강한 규칙을 자동 채택하거나 이 묶음의 가벼운 기본안으로 기존 정책을 낮추지 않는다. 규칙·범위가 바뀌면 관련 항목만 재검토하고 전체 인터뷰를 반복하지 않는다.

## 스킬 연결

- 작업의 전문 분야나 외부 지침 선택이 필요하면 [작업 성격별 스킬 연결 기준](references/skill-routing.md)을 읽는다. 같은 구현 단계라도 UI·API·데이터 전환·디버깅은 필요한 지침이 다르다.
- 이 묶음의 스킬 이름과 실제 설치 환경의 식별자를 대조한다. 로컬 원본은 `skills/` 아래 각 폴더이며, 같은 플러그인에서는 이 파일 기준 `../<skill-name>/SKILL.md`에 있다.
- 현재 에이전트가 제공하는 호출 방식으로 실행한다. 별도 호출 기능이 없으면 해당 `SKILL.md`와 필요한 참고 자료를 읽고 그 지침에 따라 직접 수행한다. 스킬 이름을 셸 명령으로 실행하지 않는다.
- 전문 스킬·플러그인이 있으면 역할과 가용성을 확인해 연결한다. 존재하지 않는 도구를 호출했다고 보고하지 않는다. 필요한 도구가 없으면 가능한 대체 방법을 쓰거나 해당 단계의 차단 조건을 기록한다.
- 단계에는 목표, 관련 규칙·합의한 도메인 용어·공유 기술 결정, 앞 단계의 결과·근거, 미해결 사항만 전달한다. 관계없는 모든 문서를 매번 읽히지 않는다.
- 단계 완료 후 출력과 완료 근거를 확인하고 진행 기록을 갱신한다. 필수 단계의 차단을 생략으로 바꾸지 않는다.

## 반복과 완료

요구사항·설계·코드가 바뀌면 영향을 받는 결정과 검증을 다시 확인한다. 요구에 연결되지 않은 작업, 작업이 없는 필수 요구, 실제 코드와 완료 표시의 차이를 확인한다. 현재 코드에서 관찰한 동작과 의도한 요구사항을 구분한다. 같은 실패를 반복할 때는 원인·입력을 재검토하고, 외부 차단이 확인되면 반복 시도 대신 조건을 명시한다.

완료는 요청된 범위의 조건을 확인했을 때 판단한다. 변경 내용, 검증 근거, 생략 이유와 남은 문제를 요약한다. 업로드·심사 대기·실제 출시 상태를 구분하고, 실행하지 않은 작업을 완료로 보고하지 않는다.