name	domain-planning
description	Sossbar 도메인 배치 및 파일 구조 계획 스킬. planner 에이전트가 feature 요청을 받아 어디에 무엇을 만들지 결정할 때 사용.

도메인 배치 & 계획 수립

코드베이스 탐색 순서

.claude/references/folder-architecture.md 읽기 (배치 규칙 파악)
features/{관련 도메인}/ 탐색 (기존 패턴 파악)
shared/ 탐색 (재사용 가능한 컴포넌트/훅 파악)
유사한 기존 feature의 파일 구조 참조

도메인 배치 결정 트리

새 코드가...
├── 특정 도메인에만 쓰임? → features/{domain}/
├── 2개 이상 도메인에서 실제로 쓰임? → shared/
└── 라우팅/페이지? → app/{route}/page.tsx (로직은 features/로)

도메인 목록 (Layer 0 → 2):

Layer	도메인	비고
0	`auth`	인증, 세션, 헤더, useMe
1	`profile`, `project`	auth에 의존 가능
2	`review`, `spectrum`, `tag`, `notifications`	Layer 1 이하에 의존 가능

reputation — 사용하지 않음
mypage — 별도 feature 없음, app/(protected)/personal/page.tsx에서 각 feature 조합
spectrum — features/spectrum/ (협업 성향 스펙트럼)

파일 배치 규칙 (features/{domain}/ 내부)

flat 파일 구조를 사용한다. api/, hooks/, types/ 폴더를 만들지 않는다.

유형	위치	예시
React 컴포넌트	`components/`	`profile-card.tsx`
fetcher + queryOptions + mutationFn	`[domain].api.ts`	`profile.api.ts`
useQuery / useMutation 훅	`[domain].hooks.ts`	`profile.hooks.ts`
TypeScript 타입 + Zod infer	`[domain].types.ts`	`profile.types.ts`
Zod 스키마	`[domain].schemas.ts`	`profile.schemas.ts`
상수	`[domain].constants.ts`	`project.constants.ts`
순수 유틸	`[domain].lib.ts`	`profile.lib.ts`
도메인 진입점	`index.ts`	외부 공개 심볼만 re-export

계획서 품질 기준

파일별 책임이 단일하고 명확한가
타입/인터페이스가 구체적으로 정의되어 있는가
구현 순서가 의존성을 위반하지 않는가 (타입 → API → 훅 → 컴포넌트)
implementer가 파일을 열지 않고도 무엇을 만들지 알 수 있는가

Más de este repositorio

mismo repositorio

frontend-design-principles

JECT-Study/Sossbar-4th-Client

MUST READ for all code authoring. 코드를 작성·구조화·리뷰할 때 항상 이 원칙을 판단 기준으로 삼는다. 응집도·결합도·의존성·추상화·인터페이스·비즈니스 로직 분리·DRY·YAGNI·네이밍·레이어 의존성 방향 — 모든 설계 결정의 근거가 여기에 있다. 요청이 설계 관련이든 구현 관련이든 상관없이 적용한다.

2026-07-012

gitflow

JECT-Study/Sossbar-4th-Client

Sossbar Git Flow 워크플로우 실행 스킬. "이슈 만들어줘", "브랜치 만들어줘", "PR 만들어줘", "feature 시작해줘", "hotfix 시작해줘", "작업 시작해줘", "이슈 번호 {N}으로 브랜치 만들어줘", "커밋하고 PR 올려줘" 등 Git Flow 관련 작업 요청이면 반드시 이 스킬을 사용할 것. 이슈 생성 → 브랜치 생성 → PR 생성의 전체 워크플로우 또는 개별 단계도 처리한다.

2026-07-012

code-validation

JECT-Study/Sossbar-4th-Client

Sossbar 코드 품질 검증 스킬. guardian 에이전트가 구현된 코드의 타입, 린트, 아키텍처 규칙을 검증하고 수정할 때 사용.

2026-06-272

feature

JECT-Study/Sossbar-4th-Client

Sossbar feature 구현 오케스트레이터. "~기능 만들어줘", "~컴포넌트 추가해줘", "~페이지 구현해줘", "~훅 만들어줘", "~API 연동해줘", "~도메인에 추가해줘", "기능 구현해줘", "feature 추가" 등 새 기능 구현 요청이면 반드시 이 스킬을 사용할 것. "다시 해줘", "수정해줘", "보완해줘", "이전 결과 개선해줘" 등 재실행 요청에도 트리거된다.

2026-06-272

react-implementation

JECT-Study/Sossbar-4th-Client

Sossbar React/Next.js 구현 패턴 스킬. implementer 에이전트가 컴포넌트, 훅, API 함수, Zod 스키마를 작성할 때 사용.

2026-06-272

도메인 배치 & 계획 수립

코드베이스 탐색 순서

.claude/references/folder-architecture.md 읽기 (배치 규칙 파악)

features/{관련 도메인}/ 탐색 (기존 패턴 파악)

shared/ 탐색 (재사용 가능한 컴포넌트/훅 파악)

유사한 기존 feature의 파일 구조 참조

도메인 배치 결정 트리

새 코드가... ├── 특정 도메인에만 쓰임? → features/{domain}/ ├── 2개 이상 도메인에서 실제로 쓰임? → shared/ └── 라우팅/페이지? → app/{route}/page.tsx (로직은 features/로)

도메인 목록 (Layer 0 → 2):

Layer

도메인

비고

auth

인증, 세션, 헤더, useMe

profile, project

auth에 의존 가능

review, spectrum, tag, notifications

Layer 1 이하에 의존 가능

reputation — 사용하지 않음

mypage — 별도 feature 없음, app/(protected)/personal/page.tsx에서 각 feature 조합

spectrum — features/spectrum/ (협업 성향 스펙트럼)

파일 배치 규칙 (features/{domain}/ 내부)

flat 파일 구조를 사용한다. api/, hooks/, types/ 폴더를 만들지 않는다.

유형

위치

예시

React 컴포넌트

components/

profile-card.tsx

fetcher + queryOptions + mutationFn

[domain].api.ts

profile.api.ts

useQuery / useMutation 훅

[domain].hooks.ts

profile.hooks.ts

TypeScript 타입 + Zod infer

[domain].types.ts

profile.types.ts

Zod 스키마

[domain].schemas.ts

profile.schemas.ts

상수

[domain].constants.ts

project.constants.ts

순수 유틸

[domain].lib.ts

profile.lib.ts

도메인 진입점

index.ts

외부 공개 심볼만 re-export

계획서 품질 기준

파일별 책임이 단일하고 명확한가

타입/인터페이스가 구체적으로 정의되어 있는가

구현 순서가 의존성을 위반하지 않는가 (타입 → API → 훅 → 컴포넌트)

implementer가 파일을 열지 않고도 무엇을 만들지 알 수 있는가