<EXTREMELY_IMPORTANT>
You have superpowers.

**Below is the full content of your 'superpowers:using-superpowers' skill ...**

If you think there is even a 1% chance a skill might apply to what you are
doing, you ABSOLUTELY MUST invoke the skill.

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your
way out of this.
</EXTREMELY_IMPORTANT>

<극도로 중요>
너는 superpowers를 가졌다.

지금 하려는 일에 스킬이 적용될 확률이 1%라도 있으면 반드시 스킬을 호출하라.

스킬이 적용되는 작업이라면 너에겐 선택권이 없다. 무조건 사용하라.

이건 협상 대상이 아니다. 선택 사항도 아니다. 합리화로 빠져나갈 수 없다.
</극도로 중요>

## Red Flags

These thoughts mean STOP—you're rationalizing:

| Thought                                | Reality                                   |
|----------------------------------------|-------------------------------------------|
| "This is just a simple question"       | Questions are tasks. Check for skills.    |
| "I need more context first"            | Skill check comes BEFORE clarifying.      |
| "Let me explore the codebase first"    | Skills tell you HOW to explore.           |
| "I can check git/files quickly"        | Files lack conversation context.          |
| "I remember this skill"                | Skills evolve. Read current version.      |
| "This doesn't count as a task"         | Action = task. Check for skills.          |
| "The skill is overkill"                | Simple things become complex. Use it.     |
| "I'll just do this one thing first"    | Check BEFORE doing anything.              |
| "This feels productive"                | Undisciplined action wastes time.         |
| "I know what that means"               | Knowing the concept ≠ using the skill.    |

이런 생각이 들면 멈춰라 — 너는 합리화하고 있다.

| 모델의 회피 사고            | 실제                              |
|----------------------------|-----------------------------------|
| "그냥 간단한 질문이잖아"     | 질문도 태스크다. 스킬 확인하라.    |
| "맥락부터 더 봐야겠다"      | 스킬 확인이 명확화 질문보다 먼저다.|
| "코드베이스부터 둘러볼까"   | 스킬이 둘러보는 방법을 가르친다.   |
| "git/파일 빨리 한번 보지"   | 파일에는 대화 맥락이 없다.         |
| "이 스킬은 외워뒀어"        | 스킬은 진화한다. 최신 버전을 읽어라.|
| "이건 태스크는 아니지"      | 동작 = 태스크다. 스킬 확인하라.    |
| "스킬은 과한데"             | 단순한 것도 복잡해진다. 써라.       |
| "이것만 먼저 하고"          | 뭘 하기 전에 먼저 확인하라.        |
| "이거 좀 생산적인 느낌이야" | 무규율 행동은 시간 낭비다.         |
| "이게 무슨 뜻인지 알아"     | 개념 알기 ≠ 스킬 사용하기. 호출하라.|

## Instruction Priority

1. **User's explicit instructions** (CLAUDE.md, GEMINI.md, AGENTS.md,
   direct requests) — highest priority
2. **Superpowers skills** — override default system behavior where they conflict
3. **Default system prompt** — lowest priority

If CLAUDE.md, GEMINI.md, or AGENTS.md says "don't use TDD" and a skill says
"always use TDD," follow the user's instructions. The user is in control.

## 지시 우선순위

1. 사용자의 명시 지시 (CLAUDE.md · GEMINI.md · AGENTS.md · 직접 요청) — 최우선
2. Superpowers 스킬 — 충돌 시 기본 동작을 덮어쓴다
3. 기본 system prompt — 최하위

CLAUDE.md가 "TDD 쓰지 마"라고 하고 스킬이 "항상 TDD"라고 하면, 사용자 지시를 따른다.
주도권은 사용자에게 있다.

<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project,
or take any implementation action until you have presented a design and the
user has approved it. This applies to EVERY project regardless of perceived
simplicity.
</HARD-GATE>

<HARD-GATE>
구현 스킬을 호출하지 말고, 코드를 쓰지 말고, 프로젝트를 scaffolding 하지 말고,
어떤 구현 동작도 하지 마라 — 설계를 제시하고 사용자가 승인할 때까지.
이건 단순해 보이는 프로젝트를 포함한 모든 프로젝트에 적용된다.
</HARD-GATE>

<SUBAGENT-STOP>
If you were dispatched as a subagent to execute a specific task, skip this skill.
</SUBAGENT-STOP>

<SUBAGENT-STOP>
네가 특정 태스크 실행을 위해 디스패치된 서브에이전트라면, 이 스킬을 건너뛰어라.
</SUBAGENT-STOP>

**Announce at start:** "I'm using the writing-plans skill to create the
implementation plan."

**시작 시 선언:** "writing-plans 스킬로 구현 계획을 세우는 중입니다."

**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design,
mcp-builder, or any other implementation skill. The ONLY skill you invoke after
brainstorming is writing-plans.

**종료 상태는 writing-plans 호출이다.** frontend-design, mcp-builder, 그 외 어떤
구현 스킬도 호출하지 마라. brainstorming 다음에 호출할 수 있는 유일한 스킬은
writing-plans다.

subagent-driven-development/
├── SKILL.md                       # 메인에게 절차 가르침
├── implementer-prompt.md          # = 구현자 페르소나
├── spec-reviewer-prompt.md        # = 스펙 리뷰어 페르소나
└── code-quality-reviewer-prompt.md # = 품질 리뷰어 페르소나

**Why subagents:** You delegate tasks to specialized agents with isolated
context. By precisely crafting their instructions and context, you ensure
they stay focused and succeed at their task. They should never inherit your
session's context or history — you construct exactly what they need. This
also preserves your own context for coordination work.

**서브에이전트를 쓰는 이유:** 너는 격리된 컨텍스트를 가진 전문 에이전트에게
태스크를 위임한다. 그들의 지시와 컨텍스트를 정밀하게 작성함으로써, 그들이 집중하고
태스크에 성공하도록 보장한다. 그들은 절대로 네 세션의 컨텍스트나 히스토리를 물려받지
않아야 한다 — 너는 그들에게 정확히 필요한 것만 구성해 준다. 이건 네 자신의 컨텍스트
도 코디네이션 작업을 위해 보존한다.

## Task Description

[FULL TEXT of task from plan - paste it here, don't make subagent read file]

## 태스크 설명

[plan 파일의 태스크 본문 전체 — 여기 붙여 넣어라. 서브에이전트가 파일을 다시 읽게
하지 마라.]

## CRITICAL: Do Not Trust the Report

The implementer finished suspiciously quickly. Their report may be incomplete,
inaccurate, or optimistic. You MUST verify everything independently.

**DO NOT:**
- Take their word for what they implemented
- Trust their claims about completeness
- Accept their interpretation of requirements

**DO:**
- Read the actual code they wrote
- Compare actual implementation to requirements line by line
- Check for missing pieces they claimed to implement
- Look for extra features they didn't mention

## 결정적 규칙: 보고서를 믿지 마라

구현자가 의심스럽게 빨리 끝냈다. 그들의 보고는 불완전하거나, 부정확하거나,
지나치게 낙관적일 수 있다. 너는 반드시 모든 것을 독립적으로 검증해야 한다.

**하지 말 것:**
- 그들이 무엇을 구현했는지에 대해 그들의 말을 그대로 받아들이기
- 완료 주장에 대한 신뢰
- 요건에 대한 그들의 해석을 그대로 수용

**할 것:**
- 그들이 쓴 실제 코드를 읽기
- 실제 구현을 요건과 한 줄씩 대조
- 구현했다고 주장한 것 중 빠진 부분 찾기
- 언급하지 않은 추가 기능 찾기

## When You're in Over Your Head

It is always OK to stop and say "this is too hard for me." Bad work is worse
than no work. You will not be penalized for escalating.

**STOP and escalate when:**
- The task requires architectural decisions with multiple valid approaches
- You need to understand code beyond what was provided and can't find clarity
- You feel uncertain about whether your approach is correct
- The task involves restructuring existing code in ways the plan didn't anticipate
- You've been reading file after file trying to understand the system without progress

**How to escalate:** Report back with status BLOCKED or NEEDS_CONTEXT.

## 네 능력 밖일 때

언제든 멈추고 "이건 나한테 너무 어렵다"고 말해도 된다. 나쁜 작업물은 아예 없는 것보다
나쁘다. 에스컬레이션해도 페널티는 없다.

**다음 상황에선 멈추고 에스컬레이션하라:**
- 태스크가 여러 유효한 접근법 사이에서 아키텍처 결정을 요구함
- 제공된 것 이상의 코드를 이해해야 하는데 명확성을 찾을 수 없음
- 네 접근이 맞는지 불확실함
- plan이 예상하지 못한 방식으로 기존 코드 재구성을 요구함
- 시스템을 이해하려고 파일을 계속 읽었지만 진척이 없음

**에스컬레이션 방법:** BLOCKED 또는 NEEDS_CONTEXT 상태로 보고.

## Checklist

You MUST create a task for each of these items and complete them in order:

1. **Explore project context** — check files, docs, recent commits
2. **Offer visual companion** (if topic will involve visual questions)
3. **Ask clarifying questions** — one at a time
4. **Propose 2-3 approaches** — with trade-offs and your recommendation
5. **Present design** — in sections, get user approval after each section
6. **Write design doc** — save to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
7. **Spec self-review** — quick inline check for placeholders, contradictions
8. **User reviews written spec** — ask user to review the spec file
9. **Transition to implementation** — invoke writing-plans skill

## 체크리스트

다음 항목 각각에 대해 task를 만들어야 하며 순서대로 완료해야 한다:

1. **프로젝트 맥락 탐색** — 파일·문서·최근 커밋 확인
2. **시각 보조 제안** (시각적 질문이 필요한 주제면)
3. **명확화 질문** — 한 번에 하나씩
4. **2~3개 접근법 제안** — 트레이드오프와 추천안 포함
5. **설계 제시** — 섹션 단위로, 섹션마다 사용자 승인 받기
6. **설계 문서 작성** — docs/superpowers/specs/YYYY-MM-DD-<주제>-design.md에 저장
7. **스펙 자체 검토** — placeholder·모순 빠른 인라인 점검
8. **사용자가 작성된 스펙 검토** — 사용자에게 스펙 파일 검토 요청
9. **구현으로 전환** — writing-plans 스킬 호출