Matt Pocock 신규 스킬 4종

개요

Matt Pocock의 최근 강연을 보고 그의 철학과 스킬 설계에 크게 감명받았다.

마침 몇 시간 전에 따끈따끈한 스킬 소개 영상이 추가되어 이를 다뤄보고자 한다.

 

이하 AI가 쓴 내용이고 몇번 더 사용후에 글을 다듬을 예정

 

추가된 스킬은 아래와 같다.

1. /handoff
2. /prototype
3. /review
4. /writing

/handoff와 /prototype은 새로 추가된 안정 스킬이고, /review와 /writing은 아직 in-progress 영역에 있는 실험적 스킬이다.
그리고 /writing은 하나의 스킬 파일이 아니라 writing-fragments, writing-beats, writing-shape 세 개로 나뉜다.

유튜브 : https://youtu.be/DNqsMXH6Eog?si=tTp7z2T3dMDu_APN

원문 저장소: https://github.com/mattpocock/skills

---

/handoff: 컨텍스트를 다른 에이전트에게 넘기는 스킬

원문 경로: skills/productivity/handoff/SKILL.md

---
name: handoff
description: Compact the current conversation into a handoff document for another agent to pick up.
argument-hint: "What will the next session be used for?"
---

Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save it to a path produced by `mktemp -t handoff-XXXXXX.md` (read the file before you write to it).

Suggest the skills to be used, if any, by the next session.

Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.

If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.

라인별 설명

앞의 metadata는 이 스킬이 언제 호출되어야 하는지 정의한다.
핵심 단어는 Compact와 another agent다.
단순 요약이 아니라, 새 컨텍스트를 가진 다른 에이전트가 바로 이어서 일할 수 있게 현재 대화를 압축하는 것이 목적이다.

mktemp -t handoff-XXXXXX.md는 이 문서가 영구 산출물이 아니라는 뜻이다.
PRD나 ADR처럼 오래 보존할 문서가 아니라, 컨텍스트 창 사이를 건너가기 위한 임시 전달 문서다.

read the file before you write to it는 도구 제약을 고려한 문장이다.
Claude Code 계열 도구에서는 읽지 않은 파일에 쓰려 할 때 문제가 생길 수 있다.
스킬 안에 이런 사소한 제약을 직접 넣어 두면 agent가 환경 차이에 덜 흔들린다.

Suggest the skills to be used는 내용만 넘기지 말고 작업 방식까지 넘기라는 의미다.
다음 세션이 /prototype으로 이어가야 하는지, 계속 grilling을 해야 하는지, /review로 검증해야 하는지 알려 주는 것이다.

Do not duplicate content already captured...는 handoff 문서가 새로운 진실의 원천이 되는 것을 막는다.
이미 PRD, ADR, issue, diff에 있는 내용은 복사하지 않고 참조만 해야 한다.
그래야 나중에 같은 결정이 여러 문서에서 어긋나지 않는다.

영상에서 설명한 맥락

영상에서 /handoff는 단순한 요약 도구가 아니라 “컨텍스트 창을 갈아타는 기술”로 설명된다.
Matt가 말한 문제 상황은 이렇다.

긴 grilling session이나 planning session을 하고 있다.
이미 6만 토큰 정도를 썼고, 아직 대화의 방향과 긴장감이 살아 있다.
그런데 중간에 코드로만 확인할 수 있는 질문이 생긴다.
예를 들어 상태 모델을 직접 밀어 보거나, 작은 프로토타입을 만들어야 하는 순간이다.

이때 원래 세션 안에서 그대로 프로토타입을 만들면 문제가 생긴다.
컨텍스트 창을 더 많이 쓰게 되고, 원래 세션이 하던 일의 집중도도 흐려진다.
설계 검증을 하던 대화가 갑자기 구현 대화로 바뀌고, 다시 돌아왔을 때 이전의 의도와 톤을 잃기 쉽다.

/handoff는 이 문제를 해결한다.
현재 세션의 내용을 임시 문서로 압축하고, 그 문서를 새 에이전트에게 넘긴다.
새 에이전트는 독립된 컨텍스트 창에서 프로토타입이나 버그 수정을 진행한다.
원래 세션은 계속 planning이나 grilling에 집중할 수 있다.

영상에서 특히 강조되는 말은 “content만 넘기는 것이 아니라 vibe와 intent도 넘겨야 한다”는 점이다.
handoff 문서가 단순 회의록이면 부족하다.
다음 에이전트가 어떤 태도로 이어가야 하는지까지 알아야 한다.

예를 들어 원래 세션이 사용자의 기획을 집요하게 검증하는 grilling session이었다면, handoff 문서에도 그 사실이 들어가야 한다.
그래야 새 세션이 갑자기 친절한 구현 모드로 바뀌지 않는다.
반대로 새 세션의 목적이 “이 상태 모델을 터미널 프로토타입으로 확인하는 것”이라면, 다음 세션은 /prototype의 logic branch를 쓰라고 제안해야 한다.

사용 사례

첫 번째 패턴은 fire-and-forget이다.
긴 설계 세션 중에 작은 버그나 별도 작업을 발견했을 때, 지금 흐름을 끊지 않고 새 에이전트에게 넘기는 방식이다.

/handoff 현재 planning session은 유지하고, 새 세션에서는 로그인 redirect 버그만 수정할 것

이 경우 handoff 문서는 다음 내용을 담아야 한다.

• 발견한 버그의 증상
• 관련 파일이나 diff
• 원래 세션에서 이 작업을 분리하는 이유
• 새 세션이 수정 후 남겨야 할 결과

두 번째 패턴은 DIY sub-agent다.
자동 sub-agent를 쓰는 대신, 사용자가 직접 새 터미널과 새 컨텍스트 창을 연다.
이 방식의 장점은 새 에이전트가 자기만의 전체 컨텍스트 창을 쓸 수 있다는 점이다.
또 새 에이전트가 필요하면 다시 sub-agent를 부르거나, 작업을 마친 뒤 원래 세션으로 다시 handoff할 수 있다.

/handoff 다음 세션은 예약 취소 상태 머신을 프로토타입으로 검증하고, 결과만 원래 planning session으로 되돌릴 것

이렇게 하면 작업 흐름이 두 갈래로 나뉜다.

1. 원래 세션은 기획 검증의 흐름을 유지한다.
2. 새 세션은 프로토타입에만 집중한다.
3. 새 세션이 얻은 결론을 다시 원래 세션으로 가져온다.

세 번째 패턴은 handoff back이다.
새 세션에서 프로토타입을 돌려 보고 배운 내용을 다시 원래 맥락으로 돌려주는 것이다.

프로토타입 결과, 예약 취소 상태는 user_cancelled와 system_cancelled를 분리해야 한다.
이 결론을 원래 grilling session으로 handoff하자.

이 흐름에서 /handoff는 단방향 요약이 아니다.
작업 컨텍스트 사이를 오가는 왕복 장치다.

어떻게 활용하나

긴 planning session 중간에 별도 작업을 분리할 때 쓴다.

/handoff 다음 세션은 예약 취소 상태 머신 프로토타입만 다룰 것

좋은 handoff 문서에는 지금까지의 결정, 아직 남은 질문, 관련 산출물 경로, 다음 세션에서 쓸 스킬 추천이 들어가야 한다.

특히 다음 항목은 빠지면 안 된다.

• 지금 세션이 어떤 성격이었는지: planning, grilling, implementation, review 등
• 다음 세션의 초점이 무엇인지
• 다음 세션이 하지 말아야 할 일이 무엇인지
• 이미 존재하는 산출물은 어디에 있는지
• 다음 세션이 끝나면 무엇을 돌려줘야 하는지

---

/prototype: 코드를 버리기 위해 만드는 스킬

/prototype은 본체 SKILL.md와 branch 설명 파일 두 개로 구성된다.

• skills/engineering/prototype/SKILL.md
• skills/engineering/prototype/LOGIC.md
• skills/engineering/prototype/UI.md

---

prototype/SKILL.md 원문 발췌

---
name: prototype
description: Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".
---

# Prototype

A prototype is **throwaway code that answers a question**. The question decides the shape.

## Pick a branch

- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper.
- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.

The two branches produce very different artifacts — getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.

## Rules that apply to both

1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.

...

3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is _checking_, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name.
4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast and then delete it.
5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
6. **Delete or absorb when done.** When the prototype has answered its question, either delete it or fold the validated decision into the real code — don't leave it rotting in the repo.

## When done

The _answer_ is the only thing worth keeping from a prototype. Capture it somewhere durable (commit message, ADR, issue, or a `NOTES.md` next to the prototype) along with the question it was answering. If the user is around, that capture is a quick conversation; if not, leave the placeholder so they (or you, on the next pass) can fill in the verdict before deleting the prototype.

prototype/SKILL.md 설명

가장 중요한 문장은 A prototype is throwaway code that answers a question이다.
이 스킬은 production code를 만들기 위한 스킬이 아니다.
결정하기 전에 모르는 점을 코드로 확인하기 위한 스킬이다.

branch 선택도 핵심이다.
상태 모델이나 비즈니스 로직을 확인하려면 LOGIC.md로 가고, 화면의 느낌과 정보 구조를 확인하려면 UI.md로 간다.
이 구분을 틀리면 프로토타입 전체가 낭비된다.

공통 규칙은 모두 같은 실패를 막는다.
AI가 프로토타입을 “대충 만든 production code”로 오해하는 실패다.
테스트도 조금 있고, 추상화도 조금 있고, 실제 DB도 조금 붙어 있는 코드는 프로토타입이 아니다.
그런 코드는 나중에 버리기 어렵고, 검증되지 않은 설계가 코드베이스에 남는다.

The answer is the only thing worth keeping도 중요하다.
프로토타입에서 남길 것은 코드가 아니라 답이다.
그 답은 commit message, ADR, issue, NOTES.md 같은 오래 남는 곳에 적어야 한다.

영상에서 설명한 맥락

영상에서 /prototype은 AI engineering에서 특히 중요한 기술로 설명된다.
이유는 AI agent에게 바로 구현을 맡기기 전에, 우리가 아직 모르는 설계 결정을 먼저 드러내야 하기 때문이다.

Matt는 prototype을 research나 spike에 가깝게 본다.
즉 “이게 최종 코드가 될 것인가?”가 아니라 “이 방향으로 가도 되는가?”를 확인하기 위한 코드다.

여기서 중요한 표현은 throwaway prototype이다.
프로토타입은 버릴 것을 전제로 만든다.
이 전제가 없으면 AI는 프로토타입을 점점 production code처럼 만들기 시작한다.
테스트를 붙이고, 추상화를 넣고, 데이터베이스를 붙이고, 나중에 확장할 수 있는 구조를 만든다.
그러면 빠르게 배워야 할 코드가 오히려 부담스러운 코드가 된다.

영상에서 말하는 /prototype의 좋은 점은 UI에만 갇히지 않는다는 것이다.
사람들은 prototype이라고 하면 보통 화면 mockup을 떠올린다.
하지만 이 스킬은 UI prototype과 logic prototype을 분리한다.

UI prototype은 “이 화면이 어떻게 보여야 하는가?”를 확인한다.
logic prototype은 “이 상태나 비즈니스 규칙이 실제 케이스를 버틸 수 있는가?”를 확인한다.

이 구분은 실제 작업에서 중요하다.
질문이 다른데 같은 형태의 프로토타입을 만들면 잘못된 결론을 얻는다.
상태 모델을 확인해야 하는데 UI만 만들면 예쁘지만 쓸모없는 결과가 나온다.
반대로 화면 밀도를 골라야 하는데 terminal app을 만들면 사용자의 취향과 제품의 느낌을 판단할 수 없다.

사용 사례

첫 번째 사용 사례는 vague concept을 코드로 눌러 보는 것이다.
말로는 대충 알겠지만 실제로 맞는지 모르겠는 설계가 있을 때 쓴다.

/prototype 이 알림 설정 모델이 사용자별, 팀별, 프로젝트별 override를 제대로 표현할 수 있는지 확인하고 싶다.

이 경우 좋은 결과는 “코드가 완성됐다”가 아니다.
좋은 결과는 “project override보다 user override가 우선이어야 한다”거나 “mute 상태는 별도 상태가 아니라 rule로 계산해야 한다” 같은 판단이다.

두 번째 사용 사례는 AFK agent에게 구현을 맡기기 전의 준비다.
영상에서는 front-end를 잘 만들게 하는 가장 좋은 방법 중 하나가 prototyping이라고 말한다.
AI가 화면을 만들 수는 있지만, 무엇이 좋아 보이는지에 대한 취향 판단은 사람이 해줘야 한다.

/prototype 대시보드 첫 화면을 3가지 완전히 다른 레이아웃으로 만들어 줘. 내가 하나를 고른 뒤 실제 구현은 그 방향으로 맡길게.

이 흐름에서는 prototype session이 design decision을 만든다.
그 다음 implementation session은 이미 정해진 방향을 구현한다.

세 번째 사용 사례는 handoff와 연결된다.
긴 planning session 중간에 prototype이 필요해졌다면, 원래 세션에서 바로 만들지 않고 /handoff로 새 세션을 열어 /prototype을 실행한다.

/handoff 다음 세션은 결제 상태 모델을 logic prototype으로 검증할 것

이렇게 하면 원래 planning session은 흐름을 잃지 않고, prototype session은 독립된 컨텍스트에서 마음껏 실험할 수 있다.

---

prototype/LOGIC.md 원문 발췌

# Logic Prototype

A tiny interactive terminal app that lets the user drive a state model by hand. Use this when the question is about **business logic, state transitions, or data shape** — the kind of thing that looks reasonable on paper but only feels wrong once you push it through real cases.

## When this is the right shape

- "I'm not sure if this state machine handles the edge case where X then Y."
- "Does this data model actually let me represent the case where..."
- "I want to feel out what the API should look like before writing it."
- Anything where the user wants to **press buttons and watch state change**.

If the question is "what should this look like" — wrong branch. Use [UI.md](UI.md).

## Process

### 1. State the question

Before writing code, write down what state model and what question you're prototyping. One paragraph, in the prototype's README or a comment at the top of the file. A logic prototype that answers the wrong question is pure waste — make the question explicit so it can be checked later, whether the user is watching now or returning to it AFK.

...

### 3. Isolate the logic in a portable module

Put the actual logic — the bit that's answering the question — behind a small, pure interface that could be lifted out and dropped into the real codebase later. The TUI around it is throwaway; the logic module shouldn't be.

The right shape depends on the question:

- **A pure reducer** — `(state, action) => state`. Good when actions are discrete events and state is a single value.
- **A state machine** — explicit states and transitions. Good when "which actions are even legal right now" is part of the question.
- **A small set of pure functions** over a plain data type. Good when there's no implicit current state — just transformations.
- **A class or module with a clear method surface** when the logic genuinely owns ongoing internal state.

Pick whichever shape best fits the question being asked, *not* whichever is easiest to wire to a TUI. Keep it pure: no I/O, no terminal code, no `console.log` for control flow. The TUI imports it and calls into it; nothing flows the other direction.

This is what makes the prototype useful past its own lifetime. When the question's been answered, the validated reducer / machine / function set can be lifted into the real module — the TUI shell gets deleted.

### 4. Build the smallest TUI that exposes the state

Build it as a **lightweight TUI** — on every tick, clear the screen (`console.clear()` / `print("\033[2J\033[H")` / equivalent) and re-render the whole frame. The user should always see one stable view, not an ever-growing scrollback.

Behaviour:

2. **Read one keystroke (or one line)** at a time, dispatch to a handler that mutates state.
3. **Re-render** the full frame after every action — don't append, replace.

...

Give the user the run command. They'll drive it themselves; the interesting moments are when they say "wait, that shouldn't be possible" or "huh, I assumed X would be different" — those are the bugs in the _idea_, which is the whole point. If they want new actions added, add them. Prototypes evolve.

## Anti-patterns

- **Don't generalise.** No "what if we wanted to support X later." The prototype answers one question.
- **Don't blur the logic and the TUI together.** If the reducer / state machine references `console.log`, prompts, or terminal escape codes, it's no longer portable. Keep the TUI as a thin shell over a pure module.
- **Don't ship the TUI shell into production.** The shell is optimised for being driven by hand from a terminal. The logic module behind it is the bit worth keeping.

prototype/LOGIC.md 설명

logic prototype은 상태 모델을 손으로 밀어 보는 도구다.
문서로는 그럴듯하지만 실제 케이스를 넣어 보면 이상해지는 문제에 잘 맞는다.

예를 들어 결제 상태가 있다고 하자.

Created -> Authorized -> Captured -> Refunded

문서로는 단순하지만, 직접 눌러 보면 질문이 생긴다.

• 부분 환불은 어떤 상태인가?
• capture 전에 취소하면 무엇이 되는가?
• 실패한 capture는 다시 시도할 수 있는가?
• user cancellation과 system cancellation은 같은가?

Isolate the logic in a portable module은 이 파일에서 가장 중요한 지시다.
TUI는 버릴 껍데기지만, 검증된 reducer나 state machine은 실제 코드로 옮길 수 있어야 한다.
그래서 로직 안에 console.log, prompt, terminal escape code가 들어가면 안 된다.

영상에서 logic prototype은 “paper에서는 멀쩡해 보이지만 실제 케이스를 밀어 넣으면 이상해지는 것”을 찾기 위한 도구로 설명된다.
상태가 시간에 따라 변하고, 사용자의 행동에 따라 엔티티가 바뀌는 경우가 대표적이다.

예를 들어 데이터베이스 안의 주문, 예약, 결제, 티켓, 세션 같은 엔티티는 대부분 상태를 가진다.
처음에는 pending, confirmed, cancelled 정도면 충분해 보인다.
하지만 실제 액션을 넣어 보면 문제가 나온다.

• 결제는 성공했는데 예약 확정이 실패하면?
• 사용자가 취소했는지 시스템이 취소했는지 구분해야 하면?
• 부분 취소나 부분 환불이 가능하면?
• 관리자 override가 들어오면 기존 상태 전이를 건너뛰어도 되는가?

이런 질문은 문서만 보고는 잘 드러나지 않는다.
terminal app에서 직접 키를 눌러 상태를 바꿔 보면 “이 액션이 이 상태에서 가능하면 안 되는데?” 같은 순간이 나온다.
영상에서 말한 것처럼, 바로 그 순간이 아이디어의 버그를 발견하는 순간이다.

logic prototype을 쓸 때는 처음부터 질문을 좁혀야 한다.

Question: 이 예약 상태 모델은 결제 실패, 사용자 취소, 시스템 만료, 관리자 강제 확정을 모호함 없이 표현할 수 있는가?

질문이 이렇게 좁혀지면 prototype의 범위도 자연스럽게 정해진다.
멋진 UI도 필요 없고, 실제 DB도 필요 없다.
사용자가 액션을 누르고 상태가 바뀌는 것을 보면 된다.

---

prototype/UI.md 원문 발췌

# UI Prototype

Generate **several radically different UI variations** on a single route, switchable from a floating bottom bar. The user flips between variants in the browser, picks one (or steals bits from each), then throws the rest away.

If the question is about logic/state rather than what something looks like — wrong branch. Use [LOGIC.md](LOGIC.md).

## Two sub-shapes — strongly prefer sub-shape A

A UI prototype is much easier to judge when it's **butting up against the rest of the app** — real header, real sidebar, real data, real density. A throwaway route on its own is a vacuum: every variant looks fine in isolation. Default to sub-shape A whenever there's a plausible existing page to host the variants. Only reach for sub-shape B if the prototype genuinely has no nearby home.

### Sub-shape A — adjustment to an existing page (preferred)

The route already exists. Variants are rendered **on the same route**, gated by a `?variant=` URL search param. The existing data fetching, params, and auth all stay — only the rendering swaps. This is the default; pick it unless there's a specific reason not to.

...

## Process

### 1. State the question and pick N

Default to **3 variants**. More than 5 stops being radically different and starts being noise — cap there.

### 2. Generate radically different variants

Variants must be **structurally different** — different layout, different information hierarchy, different primary affordance, not just different colours. Three slightly-tweaked card grids isn't a UI prototype, it's wallpaper. If two drafts come out too similar, redo one with explicit "do not use a card grid" guidance.

### 3. Wire them together

Create a single switcher component on the route:

```tsx
// pseudo-code — adapt to the project's framework
const variant = searchParams.get('variant') ?? 'A';
return (
  <>
    {variant === 'A' && <VariantA {...data} />}
    {variant === 'B' && <VariantB {...data} />}
    {variant === 'C' && <VariantC {...data} />}
    <PrototypeSwitcher variants={['A','B','C']} current={variant} />
  </>
);
```

For sub-shape A (existing page): keep all the existing data fetching above the switcher; only the rendered subtree changes per variant.

### 4. Build the floating switcher

Behaviour:

- Clicking an arrow updates the URL search param (use the framework's router — `router.replace` on Next, `navigate` on React Router, etc) so the variant is shareable and reload-stable.
- Hidden in production builds — gate on `process.env.NODE_ENV !== 'production'` or an equivalent check, so a stray prototype merge can't ship the bar to users.

### 5. Hand it over

Surface the URL (and the `?variant=` keys). The user will flip through whenever they get to it. The interesting feedback is usually **"I want the header from B with the sidebar from C"** — that's the actual design they want.

### 6. Capture the answer and clean up

Once a variant has won, write down which one and why (commit message, ADR, issue, or a `NOTES.md` next to the prototype if running AFK and the user hasn't responded yet). Then:

- **Sub-shape A** — delete the losing variants and the switcher; fold the winner into the existing page.

## Anti-patterns

- **Variants that differ only in colour or copy.** That's a tweak, not a prototype. Real variants disagree about structure.
- **Promoting the prototype directly to production.** The variant code was written under prototype constraints (no tests, minimal error handling). Rewrite it properly when you fold it in.

prototype/UI.md 설명

UI prototype의 핵심은 radically different UI variations다.
색만 다른 세 개의 카드 UI를 만드는 것이 아니다.
정보 구조, 레이아웃, 주요 액션의 위치가 달라야 한다.

또 하나 중요한 문장은 butting up against the rest of the app이다.
빈 페이지에 UI를 만들면 대부분 그럴듯해 보인다.
하지만 실제 앱의 header, sidebar, auth, data fetching, 화면 밀도와 부딪히면 문제가 보인다.

?variant=를 쓰는 이유도 실용적이다.
variant가 reload-stable하고 shareable해진다.
그리고 floating switcher를 production build에서 숨기라는 지시는 프로토타입 장치가 사용자에게 노출되는 사고를 막는다.

영상에서 UI prototype은 사람이 taste를 적용하기 위한 장치로 설명된다.
AI agent는 화면을 만들 수 있지만, 무엇이 좋은 화면인지 판단하는 능력은 제품의 맥락과 사람의 취향에 크게 의존한다.
그래서 사람이 중간에 앉아 variant를 직접 보고 고르는 과정이 필요하다.

특히 영상에서는 “A안의 어떤 부분과 B안의 어떤 부분을 섞는다”는 흐름이 나온다.
이게 UI prototype의 실제 가치다.
세 가지 안 중 하나를 그대로 고르는 것이 아니라, 여러 variant를 보면서 디자인 트리를 내려간다.

예를 들어 설정 화면을 만든다고 하자.

• A안은 정보 밀도가 좋다.
• B안은 sidebar 구조가 좋다.
• C안은 header action 배치가 좋다.

이때 최종 결정은 “B안으로 간다”가 아닐 수 있다.
“B안의 sidebar를 쓰고, A안의 정보 밀도를 가져오고, C안의 header action을 섞는다”가 더 좋은 결론일 수 있다.

이런 판단은 AFK agent 혼자 하기 어렵다.
그래서 prototype은 구현 전의 human-in-the-loop design session이 된다.

UI prototype을 요청할 때는 다음처럼 말하는 편이 좋다.

/prototype 기존 /settings 화면 안에서 알림 설정 UI를 3가지 variant로 보여 줘.
각 variant는 정보 구조가 달라야 하고, 단순 색상 차이는 피했으면 좋겠다.

좋은 피드백은 다음처럼 구체적이어야 한다.

B안의 왼쪽 탐색 구조는 좋다.
하지만 A안처럼 각 설정의 현재 상태가 한눈에 보여야 한다.
C안의 저장 버튼 위치는 유지하자.

이 정도까지 결정되면 이후 구현 에이전트는 훨씬 명확한 방향을 갖고 작업할 수 있다.

---

/writing: fragments, beats, shape로 나누는 글쓰기 스킬

영상에서는 이 묶음을 tripart writing skill이라고 설명한다.
저장소에서는 세 개의 in-progress 스킬로 나뉜다.

• skills/in-progress/writing-fragments/SKILL.md
• skills/in-progress/writing-beats/SKILL.md
• skills/in-progress/writing-shape/SKILL.md

영상에서 이 묶음은 아직 완성된 도구라기보다 실험 중인 글쓰기 workflow로 소개된다.
목표는 “AI로 좋은 글을 쓰는 과정”을 세 단계로 쪼개는 것이다.

첫 번째는 fragments다.
아직 글의 구조를 정하지 않고, 나중에 글에 들어갈 수 있는 문장, 주장, 장면, 불평, 농담, 반쯤 떠오른 생각을 모은다.

두 번째는 beats다.
모아 둔 fragments 중에서 어떤 길로 글을 전개할지 고른다.
한 번에 전체 글을 쓰지 않고, 다음에 갈 수 있는 방향을 몇 개 제안하고 사용자가 고른다.

세 번째는 shape다.
이미 있는 재료와 흐름을 바탕으로 최종 글의 형태를 잡는다.
어떤 문단이 필요한지, 리스트가 나은지, 표가 나은지, 문장이 AI처럼 들리지는 않는지 확인한다.

이 구조의 핵심은 AI가 처음부터 완성본을 쓰지 못하게 막는 것이다.
좋은 글은 보통 처음부터 목차와 결론이 정해져서 나오지 않는다.
흩어진 관찰이 쌓이고, 그중 일부가 경로를 만들고, 마지막에 독자가 읽을 수 있는 모양으로 정리된다.

---

writing-fragments/SKILL.md 원문 발췌

---
name: writing-fragments
description: Grilling session that mines the user for fragments — heterogeneous nuggets of writing (claims, vignettes, sharp sentences, half-thoughts) — and appends them to a single document as raw material for a future article. Use when the user wants to develop ideas before imposing structure, or mentions "fragments", "ideate", or "raw material" for writing.
---

<what-to-do>

Run a grilling session that produces fragments. Interview the user relentlessly about whatever they want to write about. Do not impose phases, outlines, or structure — that is explicitly out of scope.

As fragments emerge from either side of the conversation, append them to a single markdown file. The user will be editing this file during the session; always re-read it before writing so their edits are preserved.

Capture fragments from the very first thing the user says, including the initial prompt.

</what-to-do>

<supporting-info>

## What is a fragment

A fragment is any piece of text that might survive into the final article. It must be _readable by the author_ — the author can tell what it means — but it does not need to define its terms or be comprehensible to a cold reader. The bar is "is this a piece of good writing?", not "is this a self-contained argument?"

Fragments are deliberately heterogeneous. Examples of what could be a fragment:

- A sharp sentence you'd want to deploy somewhere but don't yet know where.
- A claim with a one-line justification.
- A vignette: a thing that happened, a code snippet, a scenario, an analogy.
- A half-thought: "something about how X feels like Y, work this out later."
- A quote, a piece of dialogue, an overheard line.
- A list of related observations that hang together by feel.
- A complaint, a confession, a punchline.

The novelist's diary is the model: years of unstructured noticings that later get mined for raw material. Fragments are noticings.

## File format

Fragments are separated by a horizontal rule (`\n---\n`). No headings inside the body. No tags. No order beyond the order they were added.

## Writing rhythm

Before every write: re-read the file from disk. The user may have edited, reordered, or deleted fragments between turns — preserve their changes. Never overwrite the file; only append (or, if the user asks, edit a specific fragment in place).

The user can say "cut the last one", "rewrite that one sharper", "merge those two" at any time. Treat those as first-class instructions.

</supporting-info>

writing-fragments 설명

이 스킬은 AI가 너무 빨리 구조화하는 문제를 막는다.
초기 단계에서는 outline, phase, structure를 만들지 않는다.
대신 최종 글에 살아남을 수 있는 fragment를 모은다.

fragment는 cold reader에게 완전히 이해될 필요가 없다.
작성자가 나중에 알아보고 쓸 수 있으면 된다.
이 기준이 중요한 이유는 아직 독자를 설득하는 단계가 아니라 재료를 모으는 단계이기 때문이다.

<what-to-do>와 <supporting-info>를 나눈 것도 눈에 띈다.
실제로 해야 할 지시는 위에 두고, fragment의 정의와 파일 포맷은 supporting info로 낮춘다.
prompt 안에서 우선순위를 분리하는 구조다.

영상에서는 fragments를 작가의 긴 journal에 비유한다.
작가들은 몇 년 동안 일기나 노트에 관찰, 장면, 문장, 대화, 사적인 생각을 쌓아 둔다.
그 조각들이 나중에 거의 원형 그대로 이야기나 글에 들어가기도 한다.

writing-fragments는 AI를 그 journal을 같이 쓰는 상대로 만든다.
사용자는 생각을 대충 말하거나 받아쓰기하고, AI는 그 안에서 나중에 살아남을 만한 조각을 뽑아 markdown 파일에 쌓는다.

이 단계에서 중요한 것은 정리하지 않는 것이다.
너무 빨리 구조를 만들면 생각이 작아진다.
예를 들어 “AI agent를 잘 쓰는 법”에 대해 쓰고 싶다고 했을 때, 바로 다음과 같은 목차를 만들면 글이 평범해질 가능성이 높다.

1. AI agent란 무엇인가
2. AI agent의 장점
3. AI agent 사용 팁
4. 결론

fragments 단계에서는 이런 목차를 만들지 않는다.
대신 다음처럼 살아 있는 조각을 모은다.

AI agent를 잘 쓰는 사람은 명령을 잘하는 사람이 아니라, 작업을 잘게 나누는 사람이다.

컨텍스트 창은 메모리가 아니라 작업실에 가깝다. 한 작업실에서 모든 일을 하려 하면 금방 어질러진다.

프로토타입은 코드를 남기기 위해서가 아니라, 결정을 남기기 위해서 만든다.

이 조각들은 아직 서로 연결되어 있지 않아도 된다.
중요한 것은 나중에 글에 들어갈 수 있는 밀도를 가진 문장을 확보하는 것이다.

---

writing-beats/SKILL.md 원문 발췌

---
name: writing-beats
description: Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.
---

<what-to-do>

Then run a beat-by-beat journey:

1. Write 2–3 candidate **starting beats**, drawn from the raw material. Each is a different entry point into the article. Show the user the beats before writing it to the article file. The user picks one. Preview what beats that might lead to once written - as if the user is seeing a little way down the path.
2. Once the user picks a starting beat, write **only that beat** to the article file. A beat may be one sentence or several paragraphs — whatever that beat naturally is. Stop there.
3. Re-read the article file from disk. Then offer 2–3 candidate **next beats** — different directions the journey could pivot to from where the article now stands.
4. Loop steps 2–4 until the article reaches a natural end.

</what-to-do>

<supporting-info>

## What is a beat

A beat is one move in the journey. It does one thing — sets a scene, lands a point, asks a question, drops an aside, twists the angle. Then it stops, leaving the reader at a place where the next beat can pivot.

If a "beat" needs five paragraphs and three subheadings, it's not a beat — it's two beats glued together. Split it.

## Writing one beat

Once a beat is picked, write _that beat only_ to the article file. Do not write the next beat.

## Ending the journey

The article ends when the journey is complete — not when the pile is empty. Most piles will have leftover fragments that don't make it in. That is fine; that is the point of having more raw material than you need.

## Writing rhythm

- Append one beat at a time. Never write ahead.
- If the user edits a previous beat substantially, let it change what comes next.

</supporting-info>

writing-beats 설명

이 스킬은 AI가 한 번에 전체 글을 쏟아내는 문제를 막는다.
사용자는 starting beat를 고르고, agent는 그 beat만 쓴 뒤 멈춘다.
그 다음 다음 beat 후보를 다시 제안한다.

핵심은 write only that beat다.
멈춰야 사용자가 개입할 수 있다.
AI가 글의 다음 방향까지 마음대로 써 버리면 choose-your-own-adventure 구조가 사라진다.

또 하나 중요한 문장은 The article ends when the journey is complete — not when the pile is empty다.
raw material을 다 쓰는 것이 목표가 아니다.
글의 여정이 끝나면 남는 fragment가 있어도 끝내야 한다.

영상에서 beats는 “많은 가능한 경로 중 하나를 찾아가는 과정”으로 설명된다.
fragments가 충분히 쌓이면, 그 조각들을 모두 쓰는 것이 문제가 아니다.
어떤 순서로 독자를 데려갈 것인지가 문제가 된다.

이때 AI가 한 번에 전체 초안을 써 버리면 사용자는 중간 경로를 고를 기회를 잃는다.
문장은 매끄러울 수 있지만, 글의 방향이 사용자의 감각과 달라질 수 있다.

writing-beats는 이 문제를 줄인다.
먼저 시작점 후보를 2-3개 보여 준다.
사용자가 하나를 고르면 그 beat만 쓴다.
그 다음 다시 현재 글을 읽고, 다음에 갈 수 있는 후보를 2-3개 보여 준다.

예를 들어 이 글을 beats로 만든다면 시작점 후보는 이렇게 나올 수 있다.

Beat A: skills 저장소가 7만 스타를 넘긴 현상에서 시작한다.
Beat B: handoff라는 작은 스킬이 왜 컨텍스트 관리의 핵심인지에서 시작한다.
Beat C: AI agent를 잘 쓰는 핵심은 더 긴 프롬프트가 아니라 작업 단위 설계라는 주장으로 시작한다.

사용자가 Beat B를 고르면 글은 handoff에서 출발한다.
그러면 다음 beat 후보는 prototype으로 넘어갈 수도 있고, context window 문제를 더 파고들 수도 있고, DIY sub-agent 패턴으로 갈 수도 있다.

이 방식의 장점은 사용자가 글의 방향을 계속 선택한다는 점이다.
AI는 문장을 생산하지만, 글의 여정은 사용자가 고른다.

---

writing-shape/SKILL.md 원문 발췌

---
name: writing-shape
description: Take a markdown file of raw material and shape it into an article through a conversational session — drafting candidate openings, growing the piece paragraph by paragraph, arguing about format (lists, tables, callouts, quotes) at each step. Use when the user has a pile of notes, fragments, or a rough draft and wants help turning it into something publishable.
---

<what-to-do>

The user has passed (or will pass) a markdown file of raw material. Treat it as the input pile — anything from a tidy list of fragments to a wall of unstructured prose to a transcript. The format does not matter. Read it end-to-end before doing anything else.

Then run a shaping session that produces a separate article document. Do not edit the raw material file — it is read-only to this skill.

</what-to-do>

<supporting-info>

## The loop

1. **Read the pile.** Read the input file in full. Form a sense of what's in it.
2. **Draft 2–3 candidate openings.** Each opening should imply a different thesis or angle for the article. Show all of them. Force the user to pick or compose a hybrid. The chosen opening defines what the rest of the article must do.
3. **Grow paragraph by paragraph.** After the opening lands, ask "given this opening, what does the reader need to hear next?" Pull material from the pile to answer. Argue about whether the next beat is a paragraph, a list, a table, a callout, a quote, a code block. Each format choice should be deliberate and defensible.

## Conversational feel

This is a grilling session inverted. In ideation, the question was "what are you actually noticing?" Here it's "what is this article actually arguing, and in what order does the reader need to hear it?" Push back. Refuse to let weak transitions slide. If a paragraph doesn't earn its place, cut it.

Specific moves to keep using:

- "What does this paragraph do for the reader that the previous one didn't?"
- "If I cut this, what breaks?"
- "Is this prose, or should it be a list? Why prose?"
- "This sentence is doing two jobs — split it or pick one."
- "The opening promised X. We've drifted to Y. Either re-thread it or change the opening."

## Pulling from the pile

Treat the raw material as a quarry, not a script. Pull a fragment, rework it to fit the surrounding paragraph, and place it. A fragment may be split across multiple paragraphs, merged with another, or paraphrased. The pile's job is to be mined; the article's job is to read as one voice.

## Format arguments to actually have

When choosing how to render a beat, weigh these tradeoffs out loud with the user, not silently:

- **Prose vs. list.** Prose carries argument; lists carry parallel items. If items aren't truly parallel, prose is better. If they are, a list is faster to scan.
- **Table vs. repeated structure.** If the same shape repeats 3+ times with the same fields, a table. Otherwise prose with bold leads.
- **Quote vs. paraphrase.** Quote when the original wording is the point. Paraphrase when only the idea matters.
- **Code block vs. inline code.** Multi-line, runnable, or illustrative → block. Single token or identifier → inline.

## Out of scope

- Editing the raw material file.

</supporting-info>

writing-shape 설명

writing-shape는 글쓰기의 마지막 단계에 가깝다.
raw material file은 읽기만 하고, 별도의 article document를 만든다.

이 스킬의 핵심은 opening을 먼저 고르게 하는 것이다.
opening은 글의 thesis나 angle을 암시한다.
한 번 opening을 고르면, 그 이후 글은 그 opening이 만든 약속을 지켜야 한다.

형식 선택을 조용히 처리하지 말라는 지시도 좋다.
prose, list, table, callout, quote, code block은 단순한 꾸밈이 아니다.
형식은 글의 논증 방식이다.

영상에서는 writing shape를 final pass에 가까운 과정으로 설명한다.
글이 너무 AI처럼 들리지 않는지, 구조가 맞는지, 전체 흐름이 제대로 잡혔는지 다시 보는 단계다.

이 스킬이 흥미로운 이유는 “글을 다듬는다”를 단순 문장 교정으로 보지 않는다는 점이다.
문단 하나하나가 글에서 어떤 일을 하는지 묻는다.
이 문단이 앞 문단이 하지 못한 일을 하는가?
없애면 무엇이 깨지는가?
opening이 약속한 주장에서 벗어나지는 않았는가?

또한 형식 선택을 대화의 주제로 끌어올린다.
AI는 종종 비교가 나오면 표를 만들고, 항목이 나오면 리스트를 만든다.
하지만 좋은 글에서는 형식이 자동으로 정해지면 안 된다.

예를 들어 다음 둘은 같은 내용을 전혀 다르게 전달한다.

Prose:
handoff는 단순 요약이 아니라 작업의 의도를 넘긴다. 그래서 다음 에이전트는 무엇을 해야 하는지만이 아니라 어떤 태도로 이어가야 하는지도 알게 된다.

List:
- handoff는 내용을 넘긴다.
- handoff는 의도를 넘긴다.
- handoff는 다음 세션에서 쓸 스킬을 제안한다.

prose는 주장을 밀고 가는 데 좋고, list는 병렬 항목을 빠르게 보여 주는 데 좋다.
어느 쪽이 좋은지는 문맥에 따라 다르다.
writing-shape는 이 판단을 AI가 혼자 하지 못하게 하고, 사용자와 함께 결정하게 만든다.

/writing 계열 사용 사례

아직 생각이 흩어져 있으면 writing-fragments부터 쓴다.

/writing-fragments drafts/agent-skills/fragments.md

이미 조각은 많고 글의 경로를 찾고 싶으면 writing-beats를 쓴다.

/writing-beats fragments.md -> index.md

초안이나 raw material이 있고 게시 가능한 글로 만들고 싶으면 writing-shape를 쓴다.

/writing-shape memo.md -> index.md

세 스킬은 이어서 써도 되고, 따로 써도 된다.
이미 fragments가 충분하다면 beats부터 시작할 수 있다.
이미 대략의 초안이 있다면 shape만 써도 된다.

---

/review: Standards와 Spec을 분리해서 보는 코드 리뷰 스킬

원문 경로: skills/in-progress/review/SKILL.md

해석에 필요한 원문 발췌는 다음이다.

---
name: review
description: Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
---

# Review

Two-axis review of the diff between `HEAD` and a fixed point the user supplies:

- **Standards** — does the code conform to this repo's documented coding standards?
- **Spec** — does the code faithfully implement the originating issue / PRD / spec?

Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.

## Process

### 1. Pin the fixed point

Whatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`, etc. Don't be opinionated; pass it through. If they didn't specify one, ask: "Review against what — a branch, a commit, or `main`?" Don't proceed until you have it.

Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.

### 2. Identify the spec source

Look for the originating spec, in this order:

...

3. A PRD/spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".

### 3. Identify the standards sources

Anything in the repo that documents how code should be written. Common locations:

- `CLAUDE.md`, `AGENTS.md`
- `CONTRIBUTING.md`
- `docs/adr/` (architectural decisions are standards)
- `.editorconfig`, `eslint.config.*`, `biome.json`, `prettier.config.*`, `tsconfig.json` (machine-enforced standards — note them but don't re-check what tooling already checks)

Collect the list of files. The **Standards** sub-agent will read them.

### 4. Spawn both sub-agents in parallel

**Standards sub-agent prompt** — include:

- The brief: "Read the standards docs. Then read the diff. Report — per file/hunk where relevant — every place the diff violates a documented standard. Cite the standard (file + the rule). Distinguish hard violations from judgement calls. Skip anything tooling enforces. Under 400 words."

**Spec sub-agent prompt** — include:

- The brief: "Read the spec. Then read the diff. Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."

### 5. Aggregate

Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings — the two axes are deliberately separate so the user can see them independently.

End with a one-line summary: total findings per axis, and the worst single issue (if any) flagged.

## Why two axes

A change can pass one axis and fail the other:

- Code that follows every standard but implements the wrong thing → **Standards pass, Spec fail.**
- Code that does exactly what the issue asked but breaks the project's conventions → **Spec pass, Standards fail.**

Reporting them separately stops one axis from masking the other.

review 설명

이 스킬의 핵심은 코드 리뷰를 두 축으로 분리하는 것이다.

첫 번째 축은 Standards다.
이 코드는 저장소의 문서화된 기준을 따르는가?

두 번째 축은 Spec이다.
이 코드는 원래 issue, PRD, spec이 요구한 것을 구현했는가?

이 둘은 다른 질문이다.
코드가 깔끔해도 요구사항을 잘못 구현할 수 있다.
반대로 요구사항은 맞췄지만 프로젝트의 설계 규칙을 깨뜨릴 수 있다.

그래서 원문은 두 sub-agent를 병렬로 실행하라고 한다.
각각 다른 렌즈로 diff를 보고, 마지막에만 side by side로 합친다.
그리고 결과를 merge하거나 rerank하지 말라고 한다.
두 축이 섞이면 한쪽의 성공이 다른 쪽의 실패를 가릴 수 있기 때문이다.

영상에서 설명한 맥락

영상에서 /review는 많은 사람이 기다렸지만 만들기 어려웠던 스킬로 소개된다.
generic code review skill이 어려운 이유는 모든 저장소의 기준이 다르기 때문이다.

어떤 팀은 작은 함수와 명시적인 타입을 선호한다.
어떤 팀은 프레임워크 convention을 강하게 따른다.
어떤 팀은 ADR로 의존 방향을 제한한다.
어떤 팀은 테스트 구조나 파일 배치에 강한 규칙을 둔다.

그래서 단순히 “코드 리뷰해 줘”라고 하면 리뷰가 너무 일반적이 된다.
AI가 자기 기준으로 코드를 평가하기 쉽다.
하지만 좋은 리뷰는 해당 repo의 standards를 기준으로 해야 한다.

동시에 standards만 보면 빠지는 것이 있다.
코드가 저장소 기준을 잘 지켜도 원래 issue나 PRD가 요구한 것을 놓칠 수 있다.

반대로 spec만 보면 다른 문제가 생긴다.
요구사항은 맞췄지만 repo의 구조적 기준을 깨뜨릴 수 있다.
예를 들어 기존 아키텍처에서는 UI layer가 data access layer를 직접 호출하면 안 되는데, spec에는 그 규칙이 적혀 있지 않을 수 있다.

그래서 영상에서는 두 축을 병렬로 본다고 설명한다.

• Standards: diff가 repo의 coding standards를 따르는가?
• Spec: diff가 원래 issue나 PRD를 충실히 구현했는가?

이 구분이 /review의 핵심이다.

사용 사례

첫 번째 사용 사례는 PR을 올리기 전 자체 리뷰다.

/review main

이 요청은 현재 브랜치와 main의 merge-base 이후 diff를 대상으로 리뷰하라는 뜻이다.
결과는 standards와 spec으로 분리되어야 한다.

두 번째 사용 사례는 AFK agent가 만든 변경을 검증하는 것이다.
AI agent가 issue를 구현한 뒤, 사람이 바로 코드를 읽기 전에 /review로 두 축을 먼저 확인할 수 있다.

/review origin/main

이때 standards 쪽에서는 다음을 볼 수 있다.

• AGENTS.md에 적힌 작업 규칙을 어겼는가?
• ADR의 의존 방향을 깨뜨렸는가?
• repo의 테스트 배치나 파일 구조 convention을 벗어났는가?

spec 쪽에서는 다음을 본다.

• issue가 요구한 empty state가 빠졌는가?
• PRD에 있던 edge case가 구현되지 않았는가?
• 요구하지 않은 설정이나 동작이 추가되었는가?

세 번째 사용 사례는 큰 refactor 이후의 안전 확인이다.
refactor는 기능 요구사항보다 standards 축에서 문제가 많이 나온다.
동작은 그대로지만 repo convention이나 모듈 경계를 깨뜨릴 수 있기 때문이다.

/review refactor-start

좋은 결과는 다음처럼 나뉜다.

## Standards
문서화된 아키텍처 규칙, 코드 스타일, 파일 구조 기준 위반

## Spec
원래 issue, PRD, refactor goal과 비교했을 때 빠진 것 또는 벗어난 것

이렇게 분리하면 리뷰의 감정 소모도 줄어든다.
“코드가 별로다”가 아니라 “이건 standards 축의 문제다”, “이건 spec 축의 문제다”라고 말할 수 있기 때문이다.

---

 

정리

이번 changelog의 네 묶음은 모두 작업을 작게 나누는 방법이다.

/handoff는 컨텍스트 창을 작업 단위로 나눈다.
/prototype은 모호한 설계를 코드로 눌러 보되, 답만 남기고 코드는 버린다.
/writing은 AI가 너무 빨리 완성본을 쓰지 못하게 하고, fragment에서 shape까지 사람과 함께 이동한다.
/review는 코드 기준과 요구사항 충족을 분리해서 검토한다.

공통점은 “AI에게 일을 맡긴다”가 아니다.
AI가 따라야 할 작업 방식을 작은 protocol로 만든다는 점이다.

바로 적용한다면 다음 순서가 좋다.

1. 긴 설계 세션 중간에는 /handoff로 새 컨텍스트를 만든다.
2. 상태 모델과 UI 결정은 /prototype으로 먼저 만져 본다.
3. 글은 바로 완성하지 말고 fragments -> beats -> shape로 나눈다.
4. 구현 리뷰는 standards와 spec을 분리해서 본다.

AI agent를 잘 쓰는 방법은 더 똑똑한 모델을 기다리는 것만이 아니다.
작업을 어떤 단위로 나누고, 어떤 피드백 루프를 만들고, 어떤 산출물만 남길지 정하는 것이다.
이번 changelog의 스킬들은 그 감각을 꽤 실용적인 형태로 보여 준다.

---