바이브 코딩 중인 내가 쓰는 Agent Skills - 260611

AI 코딩 에이전트 스킬 치트시트

자주 쓰는 숏컷

LazyCodex 기본 루틴 (토큰 주의)

1. /init-deep
   → 프로젝트 구조를 AI가 이해하게 만들기

2. $ulw-plan "MagicOnion room/ready/start stage flow 구현 계획"
   → 바로 코드 짜지 말고 계획부터 만들기

3. 계획 검토
   → shared / server / client 경계가 맞는지 확인

4. $start-work <plan-name>
   → 계획대로 구현

5. $ulw-loop "계획의 검증 항목을 acceptance gate로 확인해.
이미 수행된 검증은 근거를 확인하고, 누락/실패/불확실 항목은 실행 후 수정해.
server dotnet test, shared contract 영향, Unity 컴파일 영향, 
room join-ready-start 수동 시나리오를 포함해."
   
   $ulw-loop "Room ready/start stage flow 구현 결과를 검증해. 서버 dotnet test, shared contract 영향 확인, Unity 컴파일 영향, room join-ready-start 수동 시나리오를 확인하고 실패하면 수정해."
   → 끝났다고 말만 하지 말고 실제 검증까지 반복

6. $omo:review-work (중요 시) 또는 $requesting-code-review

---

Superpowers + Codex 기본 루틴

1. Superpowers brainstorming 또는 짧은 PLAN.md
   → 목표, 성공 기준, 예외 케이스, 테스트 계획 정리

2. PLAN.md 생성
   → 구현 기준을 파일로 고정

3. Codex /goal
   → PLAN.md 기준으로 끝까지 구현

4. OMO 도구로 LSP/build/test 확인
   → 아래 섹션 참조
   
5. Codex /review 또는 requesting-code-review
   → 구현 결과 리뷰

6. 필요하면 improve-codebase-architecture
   → 구조 개선

4. OMO 도구로 LSP/build/test 확인

구현이 끝나면 OMO 도구로 LSP/build/test 검증까지 진행해 줘.

1. OMO LSP 확인
- 변경한 파일 전체의 diagnostics를 확인해 줘.
- 새로 추가하거나 변경한 public API, DTO, interface, handler, service method의 references를 확인해 줘.
- unresolved symbol, type mismatch, namespace/import 누락, interface 구현 누락, 호출부 깨짐이 있으면 수정해 줘.

2. Build 확인
- 이 프로젝트의 표준 build 명령을 확인해서 실행해 줘.
- 표준 build 명령이 명확하지 않으면 package/script/solution/config 파일을 보고 가장 좁은 관련 build 명령을 선택해 줘.
- build 실패 시 첫 번째 원인부터 수정하고 다시 실행해 줘.

3. Test 확인
- 변경 범위와 관련된 테스트를 먼저 실행해 줘.
- 그 다음 가능하면 해당 모듈/패키지/솔루션의 표준 테스트 명령을 실행해 줘.
- public contract, shared schema, API boundary를 바꿨다면 계약/통합 테스트도 추가로 실행해 줘.
- 테스트 실패 시 첫 번째 실패 원인부터 수정하고 다시 실행해 줘.

4. 최종 보고
다음 항목을 포함해 줘:
- OMO LSP diagnostics 결과
- references 확인 결과
- 실행한 build 명령과 결과
- 실행한 test 명령과 결과
- 실패해서 수정한 항목
- 실행하지 못한 검증과 이유
- 남은 리스크

---

PR 리뷰

[조직/PR 제목](PR 링크)를 리뷰해 줘.

사용할 흐름:
- github:github로 PR metadata/diff 확인
- superpowers:requesting-code-review 관점으로 리뷰

PR 리뷰 코멘트 반영

github:gh-address-comments로 [조직/PR 제목](PR 링크)의 unresolved review comments를 확인해 줘.

먼저 해 줘:
- actionable / non-actionable / already addressed로 분류
- 파일/행 기준으로 묶기
- 바로 고칠 것과 답변만 남길 것을 나누기

아직 코드는 수정하지 말고, 어떤 코멘트를 처리할지 목록부터 보여 줘.

---

0. 스킬 명령어 요약

LazyCodex

명령어/스킬	설명
/init-deep	프로젝트 구조를 읽고 AGENTS.md 기반 프로젝트 메모리를 만든다.
$ulw-plan	코드 수정 전에 실행 계획을 먼저 작성한다. 제품 코드는 건드리지 않는다.
$start-work	작성된 계획 체크리스트를 따라 실제 구현을 진행한다.
$ulw-loop	테스트, 빌드, 검증이 끝날 때까지 반복해서 작업한다.
review-work	구현 결과를 버그, 설계, 테스트, 누락 요구사항 관점에서 리뷰한다.
remove-ai-slops	AI가 만든 티 나는 코드, 장황한 코드, 과한 방어 코드를 정리한다.
frontend-ui-ux	프론트엔드 화면의 UI/UX 품질을 개선한다.
programming	TypeScript, Rust, Python, Go 등에서 언어별 코딩 규칙을 엄격하게 적용한다.
LSP	정의 이동, 참조 검색, 심볼 탐색, rename, 진단을 활용한다.
AST-grep	문자열이 아니라 코드 구조 기준으로 검색/치환한다.
rules	AGENTS.md, rules, instruction 파일의 프로젝트 규칙을 적용한다.
comment-checker	수정 후 리뷰 코멘트나 피드백이 반영됐는지 확인한다.

Codex

명령어	설명
/goal <목표>	긴 작업 목표를 설정하고 Codex가 그 목표를 기준으로 계속 작업하게 한다.
/goal	현재 설정된 목표를 확인한다.
/goal pause	현재 목표 진행을 일시 중지한다.
/goal resume	중지한 목표를 다시 진행한다.
/goal clear	현재 목표를 제거한다.
/review	현재 변경사항을 리뷰한다.

Superpowers

스킬	설명
brainstorming	구현 전에 목표, 사용자, 성공 기준, 예외 케이스를 정리한다.
writing-plans	구현 계획을 문서로 만든다.
subagent-driven-development	여러 관점의 하위 에이전트로 설계, 테스트, 품질을 검토한다.
test-driven-development	테스트를 먼저 만들고 구현을 진행한다.
requesting-code-review	구현 후 코드 리뷰를 요청한다.
finishing-a-development-branch	브랜치 마무리 전 테스트, 정리, 커밋 상태를 점검한다.
improve-codebase-architecture	기능 구현 후 코드베이스 구조, 모듈 경계, 의존성 방향을 개선한다.

gstack

명령어	설명
/office-hours	제품 방향, 문제 정의, 기능 범위를 점검한다.
/plan-ceo-review	제품/비즈니스 관점에서 계획을 리뷰한다.
/plan-eng-review	엔지니어링 관점에서 계획을 리뷰한다.
/review	구현 결과를 리뷰한다.
/qa	QA 관점에서 동작을 점검한다.
/ship	배포/릴리즈 전 마무리 점검을 한다.

---

0.5. 작업 시작 전 먼저 할 일: Work Sizing

AI에게 바로 구현을 맡기기 전에 먼저 작업 크기를 분류한다.

• Small: 단일 파일/단일 모듈 수정. 계약 변경 없음.
  → 바로 Codex + OMO 검증
• Medium: 한 서브시스템 구현. 여러 파일 수정 가능하지만 경계 변경은 작음.
  → Superpowers brainstorming 또는 짧은 PLAN.md → Codex /goal → /review
• Large: shared/server/client, Stage/Snapshot, 세션 수명주기처럼 여러 경계를 지나는 작업.
  → /init-deep 필요 여부 확인 → $ulw-plan → 계획 검토 → $start-work → 구체적인 $ulw-loop
• Boundary: DTO, ResultCode, Hub/Service 인터페이스, Snapshot 의미, ProtocolVersion/SchemaVersion을 바꾸는 작업.
  → 구현량이 작아도 Large처럼 취급. 먼저 계약 영향 분석 후 계획 작성.

상황별 추천

• 요구사항이 애매하다
  → Superpowers brainstorming
• 구현 기준이 이미 PLAN.md로 고정돼 있다
  → Codex /goal
• 코드베이스 구조 파악이 먼저 필요하다
  → /init-deep
• shared/server/client 경계를 건드린다
  → $ulw-plan
• 구현 후 버그/설계/테스트 누락을 보고 싶다
  → requesting-code-review 또는 review-work
• PR 리뷰 코멘트를 처리해야 한다
  → github:gh-address-comments
• CI가 깨졌다
  → github:gh-fix-ci
• 제품 방향이나 MVP 범위가 애매하다
  → gstack /office-hours

---

1. LazyCodex를 쓸 때의 결론

LazyCodex는 Codex를 그냥 코드 작성 AI로 쓰는 게 아니라,

프로젝트를 읽고 → 계획하고 → 구현하고 → 검증하는 개발 에이전트 워크플로우

로 바꿔주는 도구다.

큰 게임 서버/클라 프로젝트처럼 shared / server / client 경계가 있고, 구조 파악이 중요한 프로젝트에 잘 맞는다.

추천 흐름은 이렇다.

1. /init-deep
   → 프로젝트 구조를 AI에게 이해시키기

2. $ulw-plan "MagicOnion room/ready/start stage flow 구현 계획"
   → 바로 구현하지 말고 계획부터 만들기

3. 계획 검토
   → shared / server / client 경계가 맞는지 확인

4. $start-work <plan-name>
   → 계획대로 구현

5. $ulw-loop "테스트 통과와 동작 검증까지 마무리"
   → 끝났다고 말만 하지 말고 실제 검증까지 반복

한 줄로 정리하면:

LazyCodex는 큰 코드베이스에서 “계획 없는 구현”을 막고, 계획 기반으로 구현과 검증까지 밀어붙이게 해주는 도구다.

---

2. Codex /goal은 언제 쓰나?

/goal은 Codex에게 오래 걸리는 작업 목표를 걸어둘 때 쓴다.

좋은 사용 예시는 이렇다.

/goal Implement PLAN.md.
Add tests for Join, Leave, Disconnect, RoomFull, Ready, Start cases.
Run dotnet test until all tests pass.
Do not change public API unless PLAN.md explicitly requires it.
Stop when tests pass and summarize changed files, validation commands, and remaining risks.

/goal은 목표가 명확하고, 테스트 기준이 있고, 구현을 끝까지 밀어붙이면 되는 상황에 좋다.

예를 들면:

- Room Join 구현
- Ready Toggle 구현
- Stage Start 구현
- 테스트 추가
- 빌드 에러 수정
- 리팩터링 계획 실행

반대로 설계가 애매한 상태에서 바로 /goal을 쓰면 방향을 잘못 잡을 수 있다.

이럴 때는 먼저 PLAN.md를 만들고 /goal을 쓰는 게 좋다.

brainstorming → PLAN.md → /goal → /review

---

3. Superpowers는 언제 쓰나?

Superpowers는 AI에게 개발 방법론을 강제하는 스킬 묶음에 가깝다.

특히 brainstorming은 구현 전에 생각을 정리할 때 좋다.

Use brainstorming.
I want to implement room ready/start flow.
Help me define success criteria, edge cases, and tests.
Do not write code yet.
Produce a PLAN.md draft.

subagent-driven-development는 매번 쓸 필요 없다.

작은 기능은 이렇게 가면 충분하다.

brainstorming → PLAN.md → /goal → /review

하지만 아래처럼 리스크가 큰 기능은 subagent-driven-development를 쓰는 게 좋다.

- CombatSession 구조
- Reward 지급 구조
- Redis 매칭 구조
- Reconnect 처리
- DB 트랜잭션 처리
- 서버 권한 검증
- 동시성 처리

이런 작업은 여러 관점에서 먼저 검토하고 구현하는 게 안전하다.

brainstorming → subagent-driven-development → PLAN.md → /goal → /review

---

4. gstack은 언제 쓰나?

gstack은 구현보다 제품 방향과 의사결정 점검에 강하다.

기능을 만들기 전에 “이걸 정말 만들어야 하나?”, “범위가 너무 크지 않나?”, “MVP는 뭔가?”를 따질 때 좋다.

추천 흐름은 이렇다.

/office-hours
→ /plan-ceo-review
→ /plan-eng-review
→ /review
→ /qa
→ /ship

게임 서버 기능처럼 이미 목표가 명확한 경우에는 gstack을 길게 돌릴 필요 없다.

이럴 때는 LazyCodex나 Codex /goal이 더 실용적이다.

목표 명확함 → PLAN.md + /goal
구조 복잡함 → LazyCodex
제품 방향 애매함 → gstack /office-hours
설계 리스크 큼 → Superpowers subagent-driven-development

---

5. 내가 추천하는 최종 루틴

작은 기능

brainstorming → PLAN.md → Codex /goal → /review

예시:

Use brainstorming.
Room Ready Toggle 기능을 구현하려고 한다.
성공 기준, 예외 케이스, 테스트 목록을 정리하고 PLAN.md 초안을 만들어줘.
아직 코드는 수정하지 마.

그다음:

/goal Implement PLAN.md.
Run dotnet test until all tests pass.
Stop when implementation and validation are complete.

---

큰 기능

/init-deep
→ $ulw-plan "기능 구현 계획"
→ 계획 검토
→ $start-work <plan-name>
→ $ulw-loop "테스트와 검증까지 완료"

예시:

/init-deep

$ulw-plan "MagicOnion room/ready/start stage flow 구현 계획.
shared / server / client 경계를 나누고,
상태 전이, 중복 start 방지, disconnect 처리, 테스트 전략까지 포함해줘."

$start-work magic-onion-room-ready-start-stage-flow

$ulw-loop "계획 체크리스트를 모두 완료하고 dotnet test, 빌드, 핵심 시나리오 검증까지 끝내줘."

---

설계가 애매한 기능

brainstorming
→ subagent-driven-development
→ PLAN.md
→ /goal
→ /review

예시:

Use brainstorming first.
Before implementation, review this feature from:
1. server authority
2. concurrency
3. persistence
4. reconnect/disconnect
5. testability

Then produce a PLAN.md with explicit success criteria.
Do not write product code yet.

---

6. 최종 결론

내가 C# 게임 서버를 혼자 맡고 있고 Codex를 주 실행 도구로 쓴다면, 기본값은 이거다.

PLAN.md + /goal

프로젝트가 크고 구조 파악이 필요하면 LazyCodex를 앞에 붙인다.

/init-deep → $ulw-plan → $start-work → $ulw-loop

설계가 애매하면 Superpowers를 쓴다.

brainstorming → subagent-driven-development → PLAN.md

제품 방향이 애매하면 gstack을 쓴다.

/office-hours → /plan-ceo-review → /plan-eng-review

정리하면:

LazyCodex는 큰 코드베이스를 읽히고 계획 기반으로 검증까지 밀어붙일 때 쓴다.
Codex /goal은 PLAN.md 기준으로 오래 구현시킬 때 쓴다.
Superpowers는 설계와 개발 방법론을 강제할 때 쓴다.
gstack은 제품 방향과 의사결정을 점검할 때 쓴다.

제일 중요한 원칙은 하나다.

AI에게 코드를 맡기기 전에, 먼저 무엇을 만들고 어디까지 만들고 어떻게 검증할지를 고정해라.