design

name	design
description	기획 내용(자연어 또는 Notion 링크)을 받아 영역별 단계로 분해한 작업 계획 아티팩트를 design/{slug}/ 폴더에 생성합니다. 각 단계는 다음 에이전트가 그대로 실행할 수 있는 독립 프롬프트입니다.

Skill: /design (Design Decomposition Instruction)

당신은 프로젝트의 '설계자'입니다. 기획을 실행 가능한 단계로 분해하고, 각 단계를 독립적으로 실행 가능한 에이전트용 프롬프트 파일로 저장합니다.

중요: 이 스킬은 계획만 만듭니다. 코드를 직접 작성하지 않습니다. 구현은 각 단계의 에이전트가 /task-start로 수행합니다.

---

1. 원칙

• 한 단계 = 한 영역(어셈블리). 여러 어셈블리를 동시에 건드리는 단계는 만들지 않는다.
• 영역 교차가 필요하면 쪼갠다. UI가 Core 데이터를 쓰면, Core에서 인터페이스를 먼저 정의하는 단계를 앞에 둔다.
• 인터페이스 우선. 다음 단계가 참조할 심볼의 시그니처는 이전 단계에서 확정한다.
• 범위는 좁게, 경계는 명확히. 각 단계는 "어느 파일, 어느 심볼, 어느 시그니처"까지 명시한다.
• 추측 금지. 파일 경로는 grep으로 확인한다. 확인 불가능하면 {TODO: verify} 마크한다.

---

2. 입력 처리

• 자연어 기획: 그대로 요약.
• Notion 링크: WebFetch로 본문을 가져온다. 접근 실패 시(사설 페이지 등) 아키텍트에게 본문 붙여넣기를 요청한다.
• 혼합: 링크 + 보충 설명이 같이 오면 둘을 병합해 원문으로 간주한다.

---

3. 분해 절차

STEP A — 목표 파악
기획이 무엇을 만드는지 한 문장으로 요약한다.

STEP B — 영역 매핑
CLAUDE.md §2 어셈블리 구조를 먼저 확인한다. 현재 존재하는 어셈블리:

• _Core (Project.Core) — 데이터 구조, 공통 유틸, 인터페이스
• _UI (Project.UI) — 화면, HUD, 메뉴
• _Combat (Project.Combat) — 게임 로직, 전투, AI
• _Rendering (Project.Rendering) — 셰이더, VFX, 카메라

필요한 영역이 기존 어셈블리에 없으면(예: 넷코드) 새 어셈블리 추가를 README.md에 제안하되, 실제 .asmdef 생성은 별도 단계로 분리한다. RULES.md RULE-01(Domain Reload)을 유발하지 않도록 주의.

STEP C — 의존성 그래프
영역 간 호출 방향을 그린다. 기본은 _Core가 루트인 단방향:

_Core ← _UI, _Combat, _Rendering

역방향 의존은 인터페이스·이벤트 버스를 _Core에 두는 방식으로 풀어낸다.

STEP D — 단계화 (topological sort)
의존성 그래프를 위상 정렬한다. 같은 영역 안에서도 "데이터 모델 → 로직 → UI 연결" 순으로 쪼갤 수 있으면 쪼갠다.

단계 수의 기준:

• 단일 영역·소규모 변경: 1~2 단계
• 영역 2개 교차: 3~5 단계
• 영역 3개 이상 또는 신규 어셈블리 포함: 6~10 단계

의심스러우면 쪼갠다. 큰 단계 하나보다 작은 단계 여러 개가 낫다.

STEP E — 각 단계의 계약 확정
단계마다 다음을 채운다:

• 생성/수정 파일 경로
• 핵심 심볼 이름과 시그니처
• 선행 단계 산출물 의존성
• 완료 판정 기준 (grep·컴파일로 확인 가능한 것 위주)

---

4. 아티팩트 생성

경로: design/{slug}/
slug는 기획 제목에서 파생한 kebab-case 이름. 필요 시 날짜 프리픽스 (예: inventory-system, 2026-05-matchmaking).

폴더가 이미 존재하면 덮어쓰지 말고 {slug}-v2 등으로 새로 만든다. 기존 계획을 보존하기 위함.

파일 구조

design/{slug}/
├── README.md                  ← 전체 요약, 아키텍처 결정, 단계 목록, 의존성 그래프
├── step-01-{area}-{topic}.md  ← 첫 단계 에이전트 프롬프트
├── step-02-{area}-{topic}.md
└── step-NN-{area}-{topic}.md

{area}는 소문자 어셈블리 이름(core, ui, combat, rendering), {topic}는 kebab-case 짧은 주제.

---

README.md 템플릿

# {기획 제목}

## 한 줄 요약
{한 문장}

## 원문
{자연어 기획 원문 또는 Notion 링크 + 요약}

## 아키텍처 결정
- {결정 1}: {왜}
- {결정 2}: {왜}

## 터치 영역
| 영역 | 어셈블리 | 역할 |
|---|---|---|
| Core | Project.Core | {역할} |
| UI | Project.UI | {역할} |

## 의존성 그래프
\`\`\`
Project.Core.FishData → Project.Combat.PlayerFish → Project.UI.HUD
\`\`\`

## 단계
1. [step-01-core-data.md](step-01-core-data.md) — Core: 데이터 모델 정의
2. [step-02-combat-logic.md](step-02-combat-logic.md) — Combat: 로직 구현
3. ...

## 병렬 실행 가능성
- step-01 완료 후 step-02와 step-03 병렬 가능 (서로 독립)
- step-04는 step-02, step-03 모두 완료 후 실행

---

step-NN-{area}-{topic}.md 템플릿 (다음 에이전트가 그대로 실행할 프롬프트)

# Step {NN}: {제목}

- **영역:** `_{Area}` (Project.{Area})
- **선행 단계:** step-{NN-1} 완료 필요 ({산출물})
- **후행 단계:** step-{NN+1}에서 이 단계의 {심볼}을 사용

---

## 목적
{이 단계가 해결하는 것 — 한 문단}

---

## 에이전트 실행 지침

`/task-start`를 먼저 호출해 범위를 확정한 뒤, 아래 지시를 수행한다.

### 생성/수정 파일
- `Assets/Scripts/_{Area}/{File}.cs` — {생성|수정}
- `Assets/Scripts/_{Area}/{File2}.cs` — {생성|수정}

### 핵심 심볼
\`\`\`csharp
namespace Project.{Area}
{
    public interface I{Name}
    {
        {signature1}
        {signature2}
    }
}
\`\`\`

### 선행 산출물 의존성
- `Project.Core.I{Foo}` — step-01에서 정의됨
- 없으면 "없음"으로 명시

### 제약
- RULES.md RULE-{N} 준수 ({간단 요약})
- 어셈블리 간 역방향 의존 금지
- {기타 제약}

### 완료 판정
- [ ] `grep -rn "I{Name}" Assets/Scripts/_{area}/` 로 정의 확인
- [ ] `dotnet build` 또는 Unity 컴파일 통과
- [ ] {추가 체크}

### 예상 커밋 메시지
\`\`\`
feat({area}): {한 줄 요약}
\`\`\`

---

## 금지 사항
- 이 단계의 범위를 벗어난 다른 어셈블리 파일을 수정하지 않는다.
- 인터페이스 시그니처를 임의로 바꾸지 않는다. 필요하면 아키텍트에게 보고하고 계획을 업데이트한다.

---

5. 마지막 보고

아티팩트 생성을 마친 뒤 아키텍트에게 다음을 보고한다:

1. 생성된 폴더 경로: design/{slug}/
2. 총 단계 수와 영역별 분포 (예: "총 5단계 — Core 2개, UI 1개, Combat 2개")
3. 병렬 실행 가능한 단계 쌍
4. 첫 단계에 투입할 명령 예시:

   cat design/{slug}/step-01-*.md | claude
   

---

6. 금지 사항

• 코드를 직접 작성하지 않는다. 이 스킬은 계획만 만든다.
• 여러 영역을 한 단계에 몰아넣지 않는다. 의심스러우면 쪼갠다.
• 추측한 파일 경로를 그대로 쓰지 않는다. grep으로 확인하지 못한 경로는 {TODO: verify} 마크한다.
• 아키텍트 승인 없이 새 어셈블리를 생성하지 않는다. 제안만 README.md에 남기고 별도 단계로 분리한다.