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. 마지막 보고

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

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

첫 단계에 투입할 명령 예시:

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

6. 금지 사항

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

Más de este repositorio

mismo repositorio

debug

zaffre001/unity-claude-template

버그 리포트·예외·오작동을 만났을 때 에이전트가 직접 소스코드를 읽고 추적·재현해 원인을 짚는 툴 사용 지침. 사용자에게 "브레이크포인트 걸어 주세요 / 플레이해 보세요"를 시키지 않는다.

2026-05-1317

lsp-setup

zaffre001/unity-claude-template

Claude Code 의 LSP 툴이 Unity 프로젝트의 `.cs` 를 인식하도록 OmniSharp 를 설치·연결하는 자동 설정 스킬. `No LSP server available for file type: .cs` 응답을 받았거나, 처음 세팅할 때 에이전트가 자동 호출한다.

2026-05-1317

make-asset

zaffre001/unity-claude-template

Unity 어셋(UGUI 프리팹 / 파티클 / 프리미티브 placeholder 모델 / SVG 작성 → Unity Vector Graphics 로 렌더·임포트한 아이콘 스프라이트)을 Claude Bridge 기반으로 제작. 외부 래스터라이저(ImageMagick/rsvg) 불필요. 사용자 요구가 모호하면 샘플 이미지·링크를 요구하고, 어떤 종류(UI/파티클/아이콘/모델)를 만들지 선택지로 제시. 에이전트가 게임 프로토타이핑 중 자산이 부족할 때 자동으로 호출해도 되는 스킬.

2026-05-1317

zaffre001/unity-claude-template

기획·스펙·규칙에 비추어 구현을 평가하는 툴 사용 지침. 사용자에게 "플레이해 보고 문제 있나 말해 달라"를 시키지 않고, 에이전트가 LSP 로 소스를 읽고 Bridge 로 실행해 스스로 합격·불합격을 판정한다.

2026-05-1317

run

zaffre001/unity-claude-template

Unity 플레이어를 빌드하고 실행하거나(`mac|win|linux|webgl|android|ios`), Editor GUI를 띄우거나(`editor`), 큐에 쌓인 ClaudeBridge 커맨드를 헤드리스로 일괄 실행(`bridge`)합니다. 빌드 산출물은 프로젝트 상위 `builds/{label}-{branch}-{shortsha}[-dirty]-{target}-{timestamp}/`에 저장. 인자 없으면 현재 OS로 빌드.

2026-05-1317

self-update

zaffre001/unity-claude-template

현재 세션에서 습득한 지식을 5개 계층(RULES / knowledge / domain / CLAUDE / skills / local) 중 가장 적합한 곳으로 승격 제안합니다. 아키텍트 승인 후 반영.

2026-05-1317

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, 카메라

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

_Core ← _UI, _Combat, _Rendering

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

단계 수의 기준:

단일 영역·소규모 변경: 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. 마지막 보고

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

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

첫 단계에 투입할 명령 예시:

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

6. 금지 사항

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

design

Skill: /design (Design Decomposition Instruction)

1. 원칙

2. 입력 처리

3. 분해 절차

4. 아티팩트 생성

파일 구조

README.md 템플릿

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

5. 마지막 보고

6. 금지 사항

Más de este repositorio

Skill: /design (Design Decomposition Instruction)

1. 원칙

2. 입력 처리

3. 분해 절차

4. 아티팩트 생성

파일 구조

README.md 템플릿

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

5. 마지막 보고

6. 금지 사항

Más de este repositorio

`README.md` 템플릿

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

`README.md` 템플릿

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