[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FVY23XXDDPMEC4QJ3TQYT":3,"skill-same:01M70FVY23XXDDPMEC4QJ3TQYT":57},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":42,"install":43,"resources":56},"01M70FVY23XXDDPMEC4QJ3TQYT","brainstorming",null,"rein-native brainstorming. 기존 코드베이스\u002F아키텍처 제약 하에서 아이디어를 spec 초안으로 구체화한다. brownfield (기존 시스템 변경) 에서는 feasibility·compatibility 를 먼저 검증한 뒤 선택지를 수렴하고, greenfield 에서는 얇은 질문 세트로 의도를 빠르게 수렴한다. 산출물은 docs\u002Fbrainstorms\u002F 에 기록되고 spec 이 brainstorm ref: 로 가리킨다. superpowers:brainstorming 과 달리 호환성·구현 가능성을 일급 시민으로 다룬다.","JayJihyunKim\u002Frein","JayJihyunKim","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9338574?v=4","01M70FV3CW5XEZGG6GS341V6J6","flyingcat4","01M70FV3DSX4YES0CN14AFJT2T",1,"MIT","https:\u002F\u002Fgithub.com\u002FJayJihyunKim\u002Frein\u002Fblob\u002Fmain\u002Fplugins\u002Frein-core\u002Fskills\u002Fbrainstorming\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26],"spec","docs","feasibility","brainstorm","superpowers","compatibility","brownfield","native","2026-11-10 10:12:30",false,"---\nname: brainstorming\ndescription: \"rein-native brainstorming. 기존 코드베이스\u002F아키텍처 제약 하에서 아이디어를 spec 초안으로 구체화한다. brownfield (기존 시스템 변경) 에서는 feasibility·compatibility 를 먼저 검증한 뒤 선택지를 수렴하고, greenfield 에서는 얇은 질문 세트로 의도를 빠르게 수렴한다. 산출물은 docs\u002Fbrainstorms\u002F 에 기록되고 spec 이 brainstorm ref: 로 가리킨다. superpowers:brainstorming 과 달리 호환성·구현 가능성을 일급 시민으로 다룬다.\"\ntriggers:\n  - \"신규 기능\u002F변경 아이디어가 들어왔을 때 (구현 착수 전)\"\n  - \"기존 시스템에 기능을 추가할 때 (brownfield)\"\n  - \"설계 결정이 여러 선택지 사이에서 고민될 때\"\n---\n\n# brainstorming\n\n## 왜 이 스킬이 필요한가\n\nsuperpowers:brainstorming 은 사용자 의도를 질문으로 구체화하는 데 탁월하다. 하지만:\n\n- **기존 시스템 제약을 고려하지 않는다** — 사용자가 선택한 방향이 기존 훅\u002F규칙과 충돌해도 인지하지 못함\n- **구현 가능성을 검증하지 않는다** — 선택이 \"실제로 돌아가는가\" 를 묻지 않음\n- **결론이 설계 문서로 옮겨질 때 일부 항목이 조용히 누락된다**\n\nrein 은 이미 design→plan→DoD 구간에 coverage 강제 장치를 갖지만, **brainstorm→spec 구간은 비어 있었다**. 이 스킬이 그 공백을 메운다.\n\n## 언제 쓰는가\n\n| 상황 | 적용 |\n|------|------|\n| 기존 시스템에 기능 추가\u002F변경 (brownfield) | **MUST** — Step 0~6 전부 실행 (Step 0 = pre-question sanity gate) |\n| 완전 신규 시스템 설계 (greenfield) | SHOULD — Step 1, 3, 5, 6 중심으로 얇게 (Step 0 불필요) |\n| 단순 버그 수정 | SKIP — `\u002Fcodex-review` 체인으로 충분 |\n| docs-only 변경 | SKIP |\n\n애매하면 brownfield 로 간주하고 전체 실행.\n\n## 실행 순서\n\n### Brownfield 전용 — Step 0: Pre-question sanity check\n\nbrownfield 에서는 **사용자에게 질문을 던지기 전에** 질문 자체가 현재 코드베이스 구조에서 유효한지 codex-ask 로 검증한다. 이 단계를 생략하면 잘못된 전제를 담은 질문이 사용자의 답변으로 굳어 spec\u002Fplan\u002FDoD 전 구간을 오염시킨다.\n\n- **0.1 최소 탐색** — `Grep` \u002F `Glob` 로 변경이 닿을 표면 1차 스캔. 이 시점에는 전수 조사 불필요. \"어느 훅·규칙·파일이 관련되어 있는가\" 만 식별 (상세는 Step 2 에서).\n- **0.2 질문 초안 작성** — 사용자에게 던질 질문 3~5 개를 미리 작성한다. 각 질문 옆에 **암묵적 전제 (assumption)** 를 한 줄로 명시한다. 예: `Q1: 훅을 분리할까? (전제: 현재는 단일 훅)`\n- **0.3 `\u002Fcodex-ask` 호출** — fresh session 으로 아래 prompt 를 던진다:\n  - \"다음 질문 초안이 현재 코드베이스 구조에서 유효한가? 각 질문의 전제 (assumption) 를 읽고 구조적으로 불가능하거나, 이미 결정된 사안이거나, 잘못된 이분법이면 지적해 줘.\"\n  - 입력: Step 0.1 의 표면 스캔 결과 + Step 0.2 의 질문\u002F전제 쌍\n  - codex-ask 는 리뷰 게이트가 아니므로 stamp 생성 안 됨. 결과는 Claude 주 세션에 돌아와 반영.\n- **0.4 질문 재작성 \u002F 통과** — codex 가 invalid assumption 을 지적하면 해당 질문 제거 또는 재작성 후 **Step 0.3 재호출**. 통과하면 Step 1 로 진행.\n\nStep 0 에서 검증된 질문 세트가 Step 1 의 \"사용자 의도 탐색\" 에 입력된다. Step 0 없이 Step 1 로 바로 들어가는 것은 brownfield 에서 금지.\n\n### 전체 공통\n\n**Step 1 — 사용자 의도 탐색**\n- 문제 진술을 한 문장으로 정리 (\"왜 이것을 하려는가\")\n- 성공 기준을 구체적으로 (\"끝났다고 할 수 있는 상태는 무엇인가\")\n- 2~3 개 질문으로 의도의 모서리를 깎아낸다 (brownfield 에서는 **Step 0 에서 검증된 질문 세트**를 사용)\n- **사용자 질문 강제 (필수)**: brownfield 에서 Step 0.4 통과 후 교정된 질문 세트, greenfield 에서 위에서 도출한 2~3 개 질문은 **반드시 `AskUserQuestion` 으로 사용자에게 제시** 한다. 이 단계를 건너뛰고 Step 2~6 을 Claude 단독으로 합성하는 것은 **금지**. 사용자 답변 없이 만들어진 brainstorm 은 사용자 의도가 아니라 Claude 의 추측을 담게 되어 후속 spec\u002Fplan\u002FDoD 전 구간을 오염시킨다 (회귀 사례: `need-to-confirm.md` 그룹 8 item 1).\n\n### Brownfield (필수 4단계 추가)\n\n**Step 2 — 관련 기존 시스템 탐색**\n- `Grep` \u002F `Glob` 으로 영향 범위 식별\n- 관련 훅, 규칙(rules\u002F), 스킬, 에이전트, 테스트, 문서 목록화\n- \"이 변경이 닿는 surface\" 를 문서에 구체적으로 기록\n\n**Step 3 — Constraint 확인**\n- 기존 훅 중 이 변경을 차단할 수 있는 것 (pre-edit-dod-gate, pre-bash-safety-guard, pre-bash-test-commit-gate 등)\n- 기존 규칙\u002F커버리지 매트릭스에서 강제되는 불변식\n- main\u002Fdev 브랜치 전략상 제약 (rein 프로젝트의 경우 `branch-strategy.md`)\n- 정책\u002F라이선스\u002F보안 레벨 제약\n\n**Step 4 — Feasibility 평가 (각 Option 별)**\n- 각 선택지를 기존 시스템 위에 얹을 때의 **구현 비용** (파일 수, 리팩토링 범위)\n- **운영 비용** (추가 훅, 추가 CI 시간, 문서 동기화 부담)\n- **리스크** (기존 동작 깨질 가능성, migration 필요성)\n\n**Step 5 — Compatibility 검증**\n- Breaking 여부 — 기존 사용자의 워크플로우\u002F파일\u002F인터페이스가 깨지는가?\n- Migration 필요성 — 있다면 1회용인가 반복인가?\n- 하위 호환 유지 전략 (default 값, deprecation 경로, feature flag 등)\n\n### 모든 경우 공통\n\n**Step 6 — 선택지 수렴 + Open Questions**\n- 선택한 방향(Chosen Direction) 과 **근거** 를 명시\n- 기각한 옵션(Rejected Options) 과 **기각 이유** 를 기록 (나중에 재검토 가능하도록)\n- Open Questions 는 spec 단계에서 풀어야 할 질문으로 이관\n\n## 산출물 포맷\n\n저장 위치: `docs\u002Fbrainstorms\u002FYYYY-MM-DD-\u003Cslug>.md`\n\n**작성 시점 (필수)**: `docs\u002Fbrainstorms\u002F\u003Cslug>.md` 파일은 **Step 6 converge 이후에만** 작성한다. Step 1~5 진행 중 사용자 답변이 모이기 전에 미리 작성하는 것은 **금지** — 그 시점의 문서는 사용자 의도가 아니라 Claude 의 추측을 동결한 결과물이 되어 후속 단계를 오염시킨다. Step 6 의 Chosen Direction + Rejected Options + Open Questions 가 모두 결정된 시점에 한 번만 작성한다.\n\n- 날짜 = 작업 시작일\n- slug = 영문 kebab-case, spec slug 와 일치시킨다 (추적 용이)\n- 파일 구조:\n\n~~~markdown\n# [Feature\u002FChange Name] — brainstorm\n\n- 날짜: YYYY-MM-DD\n- 유형: greenfield | brownfield\n- 다음 산출물: docs\u002Fspecs\u002F\u003Cslug>.md (예정)\n\n## Problem Statement\n\n[1~3 문장. 왜 이것을 하려는가. 성공 기준이 무엇인가.]\n\n## Question Sanity Check (codex-ask)\n\n[brownfield 에서 **필수**. greenfield 는 생략 가능. Step 0 의 산출물.]\n\n- 초기 질문 초안 (전제 포함):\n  - Q1: [질문] — 전제: [assumption 한 줄]\n  - Q2: [질문] — 전제: [assumption]\n  - ...\n- codex-ask 세션: [실행 일시 + 모델 + effort]\n- codex 판정 요약: [invalid 지적 \u002F 통과 \u002F 재작성 round 수]\n- 최종 질문 세트 (Step 1 에 입력):\n  - Q1': [재작성된 질문 또는 유지]\n  - ...\n\n## Constraints\n\n[brownfield 에서 필수. 기존 훅\u002F규칙\u002F브랜치 전략\u002F정책 제약.]\n\n- 기존 훅: [이름과 역할]\n- 기존 규칙: [파일 경로와 해당 절]\n- 브랜치 전략: [main 포함\u002F제외, 하위 호환 요구]\n- 기타 정책: [보안 레벨, 라이선스 등]\n\n## Options Considered\n\n### Option A: [이름]\n\n- 구현 스케치: [2~3 줄]\n- 구현 비용: [파일 수, 복잡도]\n- 운영 비용: [추가 훅\u002FCI\u002F문서 부담]\n- 리스크: [깨질 수 있는 지점]\n- Breaking: yes\u002Fno. [yes 면 마이그레이션 요지]\n\n### Option B: [이름]\n\n[동일 포맷]\n\n### Option C: [이름]\n\n[필요 시]\n\n## Chosen Direction\n\n**Option [X]** 를 선택한다.\n\n- 근거: [왜 이 옵션이 다른 옵션보다 나은가]\n- Trade-off 인정: [포기한 것이 무엇인가]\n\n## Rejected Options\n\n- **Option [Y]**: 기각 이유 — [구체적 근거. 재검토 가능하도록]\n- **Option [Z]**: 기각 이유 — [...]\n\n## Open Questions\n\nspec 단계에서 해결할 질문들:\n\n- [ ] [질문 1]\n- [ ] [질문 2]\n\n→ Next: `docs\u002Fspecs\u002F\u003Cslug>.md`\n~~~\n\n## Handoff\n\n완료 후 다음 형식으로 보고한다:\n\n~~~\n## Brainstorm 완료\n\n- 파일: docs\u002Fbrainstorms\u002FYYYY-MM-DD-\u003Cslug>.md\n- 유형: brownfield | greenfield\n- Chosen Direction: [요약 1줄]\n- Open Questions: [개수]\n\n다음 단계: spec 초안 작성 (`docs\u002Fspecs\u002F\u003Cslug>.md`)\nspec 에 다음 줄을 포함하세요:\n  brainstorm ref: docs\u002Fbrainstorms\u002F\u003Cslug>.md\n~~~\n\n## Second opinion 체인 (선택)\n\nStep 6 의 Chosen Direction 확정 **후에도** 결론이 의심스러우면 `\u002Fcodex-ask` 를 한 번 더 호출해 독립 관점으로 반박받을 수 있다. Step 0 의 mandatory pre-question sanity check 와는 역할이 다르다:\n\n| 단계 | 위치 | 대상 | 강제 여부 |\n|------|------|------|----------|\n| Step 0 (brownfield 필수) | Step 1 이전 | 사용자에게 던질 **질문 초안의 전제** | **mandatory** (brownfield) |\n| Second opinion 체인 (선택) | Step 6 이후 | 확정된 **Chosen Direction** | advisory |\n\n두 호출은 목적이 다르므로 각각 fresh codex-ask 세션으로 수행한다 (resume 금지 — codex-ask 원칙).\n\n## 호출 예시\n\n### Good prompt\n\n~~~\n사용자: \"AGENTS.md 규칙이 너무 길어지는데, 섹션별로 분리하고 싶어\"\n→ brownfield. Step 0~6 실행:\n  - Step 0.1: Grep 으로 AGENTS.md 참조처 1차 스캔 (CLAUDE.md, 훅 스크립트, 스킬)\n  - Step 0.2: 질문 초안 +전제\n    - Q1: 전체 분리 vs 일부 분리? (전제: 분리가 기술적으로 가능)\n    - Q2: 파일명 규칙은? (전제: 여러 파일로 쪼갤 때 naming 충돌 없음)\n  - Step 0.3: \u002Fcodex-ask 로 \"이 질문 전제가 현재 @import 체인에서 유효한가?\" 검증\n    → 예시 invalid 지적: \"CLAUDE.md 는 단일 AGENTS.md path 를 하드코딩한 훅이 있음. Q1 의 '분리 가능' 전제가 훅 수정 없이는 불가\"\n  - Step 0.4: 질문 재작성 후 통과\n  - Step 1: 검증된 질문 세트로 사용자 의도 탐색\n  - Step 2: 상세 surface 목록화\n  - Step 3: 기존 @import 체인 제약 구체화\n  - Step 4: 옵션 A (전체 분리 + 훅 수정), B (일부만 분리), C (toc 페이지)\n  - Step 5: Breaking 여부 — 기존 사용자의 AGENTS.md path 가 깨지는가?\n  - Step 6: 근거 + 기각 이유 기록\n~~~\n\n### Bad prompt\n\n~~~\n사용자: \"새 에이전트 만들자\"\n→ greenfield 처럼 보이지만 rein 저장소의 에이전트 layout 이 고정돼 있어 사실상 brownfield.\n   Step 2 를 건너뛰면 기존 에이전트 naming\u002Frole 과 충돌 가능.\n~~~\n\n## superpowers:brainstorming 과의 차이\n\n| 항목 | superpowers:brainstorming | rein brainstorming |\n|------|--------------------------|-------------------|\n| Pre-question sanity check | 없음 | **brownfield 필수 (Step 0, codex-ask fresh session)** |\n| 기존 시스템 탐색 | 선택사항 | brownfield 에서 필수 |\n| Feasibility 검증 | 암묵적 | 명시 Step 4 |\n| Compatibility 확인 | 거의 없음 | 명시 Step 5 |\n| 산출물 포맷 강제 | 느슨 | 7개 섹션 (brownfield) \u002F 6개 (greenfield, Question Sanity Check 생략) |\n| handoff 체인 | 자유 | spec ref 권고 |\n\n두 스킬은 배타적이지 않다. greenfield 에서는 superpowers 를 호출해도 무방하지만, 산출물은 이 스킬 포맷으로 정리해 `docs\u002Fbrainstorms\u002F` 에 저장한다.\n\n## 사용자 안내\n\n이 SKILL 의 결과를 사용자에게 보고할 때 다음 짧은 형식을 **먼저** 출력한다 (운영자\u002F디테일 메타데이터인 `## Brainstorm 완료` 블록은 그 다음에 그대로 이어 붙인다). 형식은 한 문장 또는 두 문장 — 결과 1줄 + 다음 액션 1줄.\n\n**성공 (Step 6 converge 후 산출물 작성)**:\n> brainstorm 마쳤습니다. [Chosen Direction 한 줄] 을 선택했어요. 이제 [다음 산출물 — 보통 spec 또는 DoD] 를 만들면 됩니다.\n\n**Step 0 codex-ask 가 invalid 지적 (재작성 필요)**:\n> codex 가 질문 초안에서 [지적 핵심 1-2건] 을 짚어줬어요. 질문을 재작성한 뒤 Step 0 을 다시 호출하세요.\n\n**Step 1 사용자 결정 대기**:\n> brainstorm 진행 중 — Step 1 의 사용자 결정 N건이 필요해요. AskUserQuestion 답변을 받으면 Step 2 로 진행합니다.\n","# brainstorming\n\n## 왜 이 스킬이 필요한가\n\nsuperpowers:brainstorming 은 사용자 의도를 질문으로 구체화하는 데 탁월하다. 하지만:\n\n- **기존 시스템 제약을 고려하지 않는다** — 사용자가 선택한 방향이 기존 훅\u002F규칙과 충돌해도 인지하지 못함\n- **구현 가능성을 검증하지 않는다** — 선택이 \"실제로 돌아가는가\" 를 묻지 않음\n- **결론이 설계 문서로 옮겨질 때 일부 항목이 조용히 누락된다**\n\nrein 은 이미 design→plan→DoD 구간에 coverage 강제 장치를 갖지만, **brainstorm→spec 구간은 비어 있었다**. 이 스킬이 그 공백을 메운다.\n\n## 언제 쓰는가\n\n| 상황 | 적용 |\n|------|------|\n| 기존 시스템에 기능 추가\u002F변경 (brownfield) | **MUST** — Step 0~6 전부 실행 (Step 0 = pre-question sanity gate) |\n| 완전 신규 시스템 설계 (greenfield) | SHOULD — Step 1, 3, 5, 6 중심으로 얇게 (Step 0 불필요) |\n| 단순 버그 수정 | SKIP — `\u002Fcodex-review` 체인으로 충분 |\n| docs-only 변경 | SKIP |\n\n애매하면 brownfield 로 간주하고 전체 실행.\n\n## 실행 순서\n\n### Brownfield 전용 — Step 0: Pre-question sanity check\n\nbrownfield 에서는 **사용자에게 질문을 던지기 전에** 질문 자체가 현재 코드베이스 구조에서 유효한지 codex-ask 로 검증한다. 이 단계를 생략하면 잘못된 전제를 담은 질문이 사용자의 답변으로 굳어 spec\u002Fplan\u002FDoD 전 구간을 오염시킨다.\n\n- **0.1 최소 탐색** — `Grep` \u002F `Glob` 로 변경이 닿을 표면 1차 스캔. 이 시점에는 전수 조사 불필요. \"어느 훅·규칙·파일이 관련되어 있는가\" 만 식별 (상세는 Step 2 에서).\n- **0.2 질문 초안 작성** — 사용자에게 던질 질문 3~5 개를 미리 작성한다. 각 질문 옆에 **암묵적 전제 (assumption)** 를 한 줄로 명시한다. 예: `Q1: 훅을 분리할까? (전제: 현재는 단일 훅)`\n- **0.3 `\u002Fcodex-ask` 호출** — fresh session 으로 아래 prompt 를 던진다:\n  - \"다음 질문 초안이 현재 코드베이스 구조에서 유효한가? 각 질문의 전제 (assumption) 를 읽고 구조적으로 불가능하거나, 이미 결정된 사안이거나, 잘못된 이분법이면 지적해 줘.\"\n  - 입력: Step 0.1 의 표면 스캔 결과 + Step 0.2 의 질문\u002F전제 쌍\n  - codex-ask 는 리뷰 게이트가 아니므로 stamp 생성 안 됨. 결과는 Claude 주 세션에 돌아와 반영.\n- **0.4 질문 재작성 \u002F 통과** — codex 가 invalid assumption 을 지적하면 해당 질문 제거 또는 재작성 후 **Step 0.3 재호출**. 통과하면 Step 1 로 진행.\n\nStep 0 에서 검증된 질문 세트가 Step 1 의 \"사용자 의도 탐색\" 에 입력된다. Step 0 없이 Step 1 로 바로 들어가는 것은 brownfield 에서 금지.\n\n### 전체 공통\n\n**Step 1 — 사용자 의도 탐색**\n- 문제 진술을 한 문장으로 정리 (\"왜 이것을 하려는가\")\n- 성공 기준을 구체적으로 (\"끝났다고 할 수 있는 상태는 무엇인가\")\n- 2~3 개 질문으로 의도의 모서리를 깎아낸다 (brownfield 에서는 **Step 0 에서 검증된 질문 세트**를 사용)\n- **사용자 질문 강제 (필수)**: brownfield 에서 Step 0.4 통과 후 교정된 질문 세트, greenfield 에서 위에서 도출한 2~3 개 질문은 **반드시 `AskUserQuestion` 으로 사용자에게 제시** 한다. 이 단계를 건너뛰고 Step 2~6 을 Claude 단독으로 합성하는 것은 **금지**. 사용자 답변 없이 만들어진 brainstorm 은 사용자 의도가 아니라 Claude 의 추측을 담게 되어 후속 spec\u002Fplan\u002FDoD 전 구간을 오염시킨다 (회귀 사례: `need-to-confirm.md` 그룹 8 item 1).\n\n### Brownfield (필수 4단계 추가)\n\n**Step 2 — 관련 기존 시스템 탐색**\n- `Grep` \u002F `Glob` 으로 영향 범위 식별\n- 관련 훅, 규칙(rules\u002F), 스킬, 에이전트, 테스트, 문서 목록화\n- \"이 변경이 닿는 surface\" 를 문서에 구체적으로 기록\n\n**Step 3 — Constraint 확인**\n- 기존 훅 중 이 변경을 차단할 수 있는 것 (pre-edit-dod-gate, pre-bash-safety-guard, pre-bash-test-commit-gate 등)\n- 기존 규칙\u002F커버리지 매트릭스에서 강제되는 불변식\n- main\u002Fdev 브랜치 전략상 제약 (rein 프로젝트의 경우 `branch-strategy.md`)\n- 정책\u002F라이선스\u002F보안 레벨 제약\n\n**Step 4 — Feasibility 평가 (각 Option 별)**\n- 각 선택지를 기존 시스템 위에 얹을 때의 **구현 비용** (파일 수, 리팩토링 범위)\n- **운영 비용** (추가 훅, 추가 CI 시간, 문서 동기화 부담)\n- **리스크** (기존 동작 깨질 가능성, migration 필요성)\n\n**Step 5 — Compatibility 검증**\n- Breaking 여부 — 기존 사용자의 워크플로우\u002F파일\u002F인터페이스가 깨지는가?\n- Migration 필요성 — 있다면 1회용인가 반복인가?\n- 하위 호환 유지 전략 (default 값, deprecation 경로, feature flag 등)\n\n### 모든 경우 공통\n\n**Step 6 — 선택지 수렴 + Open Questions**\n- 선택한 방향(Chosen Direction) 과 **근거** 를 명시\n- 기각한 옵션(Rejected Options) 과 **기각 이유** 를 기록 (나중에 재검토 가능하도록)\n- Open Questions 는 spec 단계에서 풀어야 할 질문으로 이관\n\n## 산출물 포맷\n\n저장 위치: `docs\u002Fbrainstorms\u002FYYYY-MM-DD-\u003Cslug>.md`\n\n**작성 시점 (필수)**: `docs\u002Fbrainstorms\u002F\u003Cslug>.md` 파일은 **Step 6 converge 이후에만** 작성한다. Step 1~5 진행 중 사용자 답변이 모이기 전에 미리 작성하는 것은 **금지** — 그 시점의 문서는 사용자 의도가 아니라 Claude 의 추측을 동결한 결과물이 되어 후속 단계를 오염시킨다. Step 6 의 Chosen Direction + Rejected Options + Open Questions 가 모두 결정된 시점에 한 번만 작성한다.\n\n- 날짜 = 작업 시작일\n- slug = 영문 kebab-case, spec slug 와 일치시킨다 (추적 용이)\n- 파일 구조:\n\n~~~markdown\n# [Feature\u002FChange Name] — brainstorm\n\n- 날짜: YYYY-MM-DD\n- 유형: greenfield | brownfield\n- 다음 산출물: docs\u002Fspecs\u002F\u003Cslug>.md (예정)\n\n## Problem Statement\n\n[1~3 문장. 왜 이것을 하려는가. 성공 기준이 무엇인가.]\n\n## Question Sanity Check (codex-ask)\n\n[brownfield 에서 **필수**. greenfield 는 생략 가능. Step 0 의 산출물.]\n\n- 초기 질문 초안 (전제 포함):\n  - Q1: [질문] — 전제: [assumption 한 줄]\n  - Q2: [질문] — 전제: [assumption]\n  - ...\n- codex-ask 세션: [실행 일시 + 모델 + effort]\n- codex 판정 요약: [invalid 지적 \u002F 통과 \u002F 재작성 round 수]\n- 최종 질문 세트 (Step 1 에 입력):\n  - Q1': [재작성된 질문 또는 유지]\n  - ...\n\n## Constraints\n\n[brownfield 에서 필수. 기존 훅\u002F규칙\u002F브랜치 전략\u002F정책 제약.]\n\n- 기존 훅: [이름과 역할]\n- 기존 규칙: [파일 경로와 해당 절]\n- 브랜치 전략: [main 포함\u002F제외, 하위 호환 요구]\n- 기타 정책: [보안 레벨, 라이선스 등]\n\n## Options Considered\n\n### Option A: [이름]\n\n- 구현 스케치: [2~3 줄]\n- 구현 비용: [파일 수, 복잡도]\n- 운영 비용: [추가 훅\u002FCI\u002F문서 부담]\n- 리스크: [깨질 수 있는 지점]\n- Breaking: yes\u002Fno. [yes 면 마이그레이션 요지]\n\n### Option B: [이름]\n\n[동일 포맷]\n\n### Option C: [이름]\n\n[필요 시]\n\n## Chosen Direction\n\n**Option [X]** 를 선택한다.\n\n- 근거: [왜 이 옵션이 다른 옵션보다 나은가]\n- Trade-off 인정: [포기한 것이 무엇인가]\n\n## Rejected Options\n\n- **Option [Y]**: 기각 이유 — [구체적 근거. 재검토 가능하도록]\n- **Option [Z]**: 기각 이유 — [...]\n\n## Open Questions\n\nspec 단계에서 해결할 질문들:\n\n- [ ] [질문 1]\n- [ ] [질문 2]\n\n→ Next: `docs\u002Fspecs\u002F\u003Cslug>.md`\n~~~\n\n## Handoff\n\n완료 후 다음 형식으로 보고한다:\n\n~~~\n## Brainstorm 완료\n\n- 파일: docs\u002Fbrainstorms\u002FYYYY-MM-DD-\u003Cslug>.md\n- 유형: brownfield | greenfield\n- Chosen Direction: [요약 1줄]\n- Open Questions: [개수]\n\n다음 단계: spec 초안 작성 (`docs\u002Fspecs\u002F\u003Cslug>.md`)\nspec 에 다음 줄을 포함하세요:\n  brainstorm ref: docs\u002Fbrainstorms\u002F\u003Cslug>.md\n~~~\n\n## Second opinion 체인 (선택)\n\nStep 6 의 Chosen Direction 확정 **후에도** 결론이 의심스러우면 `\u002Fcodex-ask` 를 한 번 더 호출해 독립 관점으로 반박받을 수 있다. Step 0 의 mandatory pre-question sanity check 와는 역할이 다르다:\n\n| 단계 | 위치 | 대상 | 강제 여부 |\n|------|------|------|----------|\n| Step 0 (brownfield 필수) | Step 1 이전 | 사용자에게 던질 **질문 초안의 전제** | **mandatory** (brownfield) |\n| Second opinion 체인 (선택) | Step 6 이후 | 확정된 **Chosen Direction** | advisory |\n\n두 호출은 목적이 다르므로 각각 fresh codex-ask 세션으로 수행한다 (resume 금지 — codex-ask 원칙).\n\n## 호출 예시\n\n### Good prompt\n\n~~~\n사용자: \"AGENTS.md 규칙이 너무 길어지는데, 섹션별로 분리하고 싶어\"\n→ brownfield. Step 0~6 실행:\n  - Step 0.1: Grep 으로 AGENTS.md 참조처 1차 스캔 (CLAUDE.md, 훅 스크립트, 스킬)\n  - Step 0.2: 질문 초안 +전제\n    - Q1: 전체 분리 vs 일부 분리? (전제: 분리가 기술적으로 가능)\n    - Q2: 파일명 규칙은? (전제: 여러 파일로 쪼갤 때 naming 충돌 없음)\n  - Step 0.3: \u002Fcodex-ask 로 \"이 질문 전제가 현재 @import 체인에서 유효한가?\" 검증\n    → 예시 invalid 지적: \"CLAUDE.md 는 단일 AGENTS.md path 를 하드코딩한 훅이 있음. Q1 의 '분리 가능' 전제가 훅 수정 없이는 불가\"\n  - Step 0.4: 질문 재작성 후 통과\n  - Step 1: 검증된 질문 세트로 사용자 의도 탐색\n  - Step 2: 상세 surface 목록화\n  - Step 3: 기존 @import 체인 제약 구체화\n  - Step 4: 옵션 A (전체 분리 + 훅 수정), B (일부만 분리), C (toc 페이지)\n  - Step 5: Breaking 여부 — 기존 사용자의 AGENTS.md path 가 깨지는가?\n  - Step 6: 근거 + 기각 이유 기록\n~~~\n\n### Bad prompt\n\n~~~\n사용자: \"새 에이전트 만들자\"\n→ greenfield 처럼 보이지만 rein 저장소의 에이전트 layout 이 고정돼 있어 사실상 brownfield.\n   Step 2 를 건너뛰면 기존 에이전트 naming\u002Frole 과 충돌 가능.\n~~~\n\n## superpowers:brainstorming 과의 차이\n\n| 항목 | superpowers:brainstorming | rein brainstorming |\n|------|--------------------------|-------------------|\n| Pre-question sanity check | 없음 | **brownfield 필수 (Step 0, codex-ask fresh session)** |\n| 기존 시스템 탐색 | 선택사항 | brownfield 에서 필수 |\n| Feasibility 검증 | 암묵적 | 명시 Step 4 |\n| Compatibility 확인 | 거의 없음 | 명시 Step 5 |\n| 산출물 포맷 강제 | 느슨 | 7개 섹션 (brownfield) \u002F 6개 (greenfield, Question Sanity Check 생략) |\n| handoff 체인 | 자유 | spec ref 권고 |\n\n두 스킬은 배타적이지 않다. greenfield 에서는 superpowers 를 호출해도 무방하지만, 산출물은 이 스킬 포맷으로 정리해 `docs\u002Fbrainstorms\u002F` 에 저장한다.\n\n## 사용자 안내\n\n이 SKILL 의 결과를 사용자에게 보고할 때 다음 짧은 형식을 **먼저** 출력한다 (운영자\u002F디테일 메타데이터인 `## Brainstorm 완료` 블록은 그 다음에 그대로 이어 붙인다). 형식은 한 문장 또는 두 문장 — 결과 1줄 + 다음 액션 1줄.\n\n**성공 (Step 6 converge 후 산출물 작성)**:\n> brainstorm 마쳤습니다. [Chosen Direction 한 줄] 을 선택했어요. 이제 [다음 산출물 — 보통 spec 또는 DoD] 를 만들면 됩니다.\n\n**Step 0 codex-ask 가 invalid 지적 (재작성 필요)**:\n> codex 가 질문 초안에서 [지적 핵심 1-2건] 을 짚어줬어요. 질문을 재작성한 뒤 Step 0 을 다시 호출하세요.\n\n**Step 1 사용자 결정 대기**:\n> brainstorm 진행 중 — Step 1 의 사용자 결정 N건이 필요해요. AskUserQuestion 답변을 받으면 Step 2 로 진행합니다.\n",{"name":5,"triggers":32,"description":7},[33,34,35],"신규 기능\u002F변경 아이디어가 들어왔을 때 (구현 착수 전)","기존 시스템에 기능을 추가할 때 (brownfield)","설계 결정이 여러 선택지 사이에서 고민될 때","main","8e6e9ee16c5c7343c6f0db55f6c8b37d5ef6f1d0","plugins\u002Frein-core\u002Fskills\u002Fbrainstorming",0,"https:\u002F\u002Fgithub.com\u002FJayJihyunKim\u002Frein","https:\u002F\u002Fgithub.com\u002FJayJihyunKim","2026-10-15 08:31:34",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add JayJihyunKim\u002Frein --skill brainstorming",{"tool":49,"command":50},"bunx","bunx skills add JayJihyunKim\u002Frein --skill brainstorming",{"tool":52,"command":53},"pnpm","pnpm dlx skills add JayJihyunKim\u002Frein --skill brainstorming","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJayJihyunKim\u002Frein\u002Fblob\u002Fmain\u002Fplugins\u002Frein-core\u002Fskills\u002Fbrainstorming\u002FSKILL.md",true,[],[58,71,82,93,105,112],{"skillNo":59,"name":60,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":68,"publishedAt":27},"01M70FX2WFS12FG002RNTCSXC7","sample-skill","https:\u002F\u002Fgithub.com\u002FJayJihyunKim\u002Frein\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Frein-template-min\u002F.claude\u002Fskills\u002Fsample-skill\u002FSKILL.md",[63],{"categoryNo":64,"categoryName":65,"taxonomyType":66,"taxonomyTypeDesc":67},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[69,70],"sample","sample skill",{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":27},"01M70FX0BT6WSNZKFF60KTZ5H9","repo-audit","저장소 전체 상태 점검. 오래된 규칙, 누락 테스트, 비활성 에이전트, trail 일관성 확인.","https:\u002F\u002Fgithub.com\u002FJayJihyunKim\u002Frein\u002Fblob\u002Fmain\u002Fplugins\u002Frein-core\u002Fskills\u002Frepo-audit\u002FSKILL.md",[],[78,79,80,81],"repo","repo audit","audit","trail",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":89,"publishedAt":27},"01M70FWXCWRZEJSDQGTNDEKF2G","promote-agent","에이전트 후보를 정식 에이전트로 승격. 사람 승인 이후에만 실행.","https:\u002F\u002Fgithub.com\u002FJayJihyunKim\u002Frein\u002Fblob\u002Fmain\u002Fplugins\u002Frein-core\u002Fskills\u002Fpromote-agent\u002FSKILL.md",[88],{"categoryNo":64,"categoryName":65,"taxonomyType":66,"taxonomyTypeDesc":67},[90,91,92],"promote agent","promote","incidents",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":27},"01M70FWTP0QPQN09VJR8DNKWZS","pr-review-fixer","PR 리뷰 코멘트를 읽고 수정 사항을 자동으로 적용한다","https:\u002F\u002Fgithub.com\u002FJayJihyunKim\u002Frein\u002Fblob\u002Fmain\u002Fplugins\u002Frein-core\u002Fskills\u002Fpr-review-fixer\u002FSKILL.md",[],[100,101,102,103,104],"pr","review","pr review","pr review fixer","fixer",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":27},"01M70FWR0TC5NDF12D9E5ETBAW","persona","페르소나 프리셋 선택·해제 + 질문-답변 커스텀 프리셋 생성. \"페르소나 골라줘\u002F만들어줘\u002F바꿔줘\u002F꺼줘\" 류 요청에서 호출.","https:\u002F\u002Fgithub.com\u002FJayJihyunKim\u002Frein\u002Fblob\u002Fmain\u002Fplugins\u002Frein-core\u002Fskills\u002Fpersona\u002FSKILL.md",[],[107],{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":27},"01M70FWKFPNVC4M5ECZE1F0WS6","parallel-execute","활성 plan 의 `## 실행 전략`(depends_on\u002Fmode\u002Fscope v2) 을 읽어 의존 위상정렬로 웨이브를 유도하고, 각 웨이브의 독립 edit_only 태스크를 같은 작업 트리에서 서브에이전트로 병렬 실행, mutating·의존 태스크는 순차 실행한다. 부모(메인 세션)가 웨이브 단위로 검증·테스트·커밋. 호스트가 병렬 dispatch 불가 시 순차 fallback 으로 degrade.","https:\u002F\u002Fgithub.com\u002FJayJihyunKim\u002Frein\u002Fblob\u002Fmain\u002Fplugins\u002Frein-core\u002Fskills\u002Fparallel-execute\u002FSKILL.md",[],[119,120,121,122,123,124,125,126,127,128],"parallel","execute","parallel execute","edit","fallback","mode","dispatch","scope","plan","only"]