# Superpowers vs 아누 시스템 비교 분석 + 적용 방안 (2026-03-23 재확인)

**이전 분석**: task-328.1 (2026-03-06) — v4.3.1 기준
**현재 분석**: task-830.1 (2026-03-23) — v5.0.5 기준
**업데이트 목적**: v4.3.1→v5.0.5 변경사항 반영, 우리 시스템 반영 현황 업데이트
**작성자**: 에인 (UX/UI, 개발3팀)

---

## 1. 아키텍처 비교 (업데이트)

### 1.1 Superpowers v5.0.5 아키텍처

| 항목 | 내용 |
|------|------|
| 구조 | 단일 Claude Code 인스턴스 + SessionStart 훅 자동 스킬 주입 |
| 스킬 수 | 14개 (brainstorming, writing-plans, subagent-driven-development, executing-plans, test-driven-development, systematic-debugging, dispatching-parallel-agents, using-git-worktrees, finishing-a-development-branch, requesting-code-review, receiving-code-review, verification-before-completion, writing-skills, using-superpowers) |
| 서브에이전트 | Implementer / Spec-Reviewer / Code-Quality-Reviewer 3종 |
| 지원 플랫폼 | Claude Code, Cursor, Codex, OpenCode, Gemini CLI (5개, v5.0.x에서 확장) |
| 설치 | `plugin.json` 기반 마켓플레이스 1줄 설치 |
| 컨텍스트 전달 | `async: false` SessionStart 훅 → `<EXTREMELY_IMPORTANT>` 태그 강제 주입 |

v5.0.x 핵심 아키텍처 변화:
- **v5.0.2**: 서브에이전트 컨텍스트 격리 원칙 명시 강화 (세션 히스토리 전달 금지)
- **v5.0.3**: `--resume` 시 훅 재주입 버그 수정 → 세션 재개 후에도 스킬 컨텍스트 보장
- **v5.0.5**: SDD 실행 방식 "강제"에서 "권장(Subagent) vs 선택(Inline)"으로 복원

### 1.2 아누 시스템 현재 상태

| 항목 | 내용 |
|------|------|
| 구조 | 멀티봇(4개 독립 Telegram 봇) + 팀 내 서브에이전트 2-레이어 |
| 스킬 수 | 47개 (`/home/jay/workspace/skills/` 기준 — Superpowers 대비 3.4배) |
| 에이전트 | 20명 (Opus×3 / Sonnet×10 / Haiku×3 / GLM×3 / Gemini×1) |
| 지원 플랫폼 | Claude Code 전용 (단일 플랫폼) |
| 훅 | 4종 (UserPromptSubmit, PostToolUse, stop-qc-reminder, pre-tool-use) |
| 상태 관리 | 파일 기반 (.done 프로토콜, task-timers.json, pipeline-status.json) |

task-328.1 이후 도입 완료된 스킬 (2026-03-06~현재):
- `tdd-enforcement` v1.1 (2026-03-07, 프레이야 작성)
- `git-worktree-isolation` (worktree_manager.py 연동)
- `subagent-driven-development` (Superpowers 원본 기반 커스터마이징)
- `adversarial-review`, `cross-verified-research`, `deep-dive-analyzer`

### 1.3 장단점 비교표

| 항목 | Superpowers v5.0.5 | 아누 시스템 (현재) | 우위 |
|------|-------------------|------------------|------|
| 설치 복잡도 | 1줄 (`plugin.json`) | 수십 개 파일 + 봇 4개 | SP |
| 스킬 수 | 14개 | 47개 | 아누 |
| 멀티모델 | Claude 단일 | 5종 모델 (Opus/Sonnet/Haiku/GLM/Gemini) | 아누 |
| 플랫폼 지원 | 5개 (Claude/Cursor/Codex/OpenCode/Gemini CLI) | 1개 (Claude Code) | SP |
| 컨텍스트 격리 | 서브에이전트 세션 히스토리 금지 (v5.0.2 강화) | 봇 독립 세션 + 격리 원칙 (스킬에 명시) | 동등 |
| TDD 강제 | Iron Law (코드 삭제 메커니즘) | tdd-enforcement 스킬 v1.1 (규칙 기반) | SP (엄격도) |
| 리뷰 최적화 | 청크별→전체 1회 (v5.0.4), 최대 3회 | qc_verify.py 8개 verifier | 아누 (폭) |
| 조직 규모 | 개인 개발자 수준 | 20명 매트릭스 조직 | 아누 |
| 운영 인프라 | 전무 (개발 도구만) | 대시보드 + Audit Trail + 일일 업무일지 | 아누 |
| Visual 도구 | Visual Companion (v5.0.1+) | 없음 | SP |
| 브레인스토밍 서버 | Zero-dep Brainstorm Server (v5.0.2, Node.js 내장 모듈만) | dashboard/server.py (별도 서버 운영) | SP (경량성) |

---

## 2. 워크플로우 단계별 비교

Superpowers 7단계 vs 아누 워크플로우 매핑:

| SP 단계 | SP 스킬 | 아누 대응 | 유사점 | 차이점 (업데이트) |
|---------|---------|----------|--------|-----------------|
| **1. Brainstorming** | brainstorming | 에이전트 미팅 + DA | 코딩 전 설계 강제 (HARD-GATE) | 아누: 다수 페르소나 + DA 필수 / SP: Visual Companion 추가 (v5.0.1) |
| **2. Git Worktrees** | using-git-worktrees | git-worktree-isolation 스킬 | 격리 환경 | 아누: worktree_manager.py + 멀티봇 충돌 방지 규칙 포함. SP는 `.worktrees/` 단순 디렉토리 |
| **3. Writing Plans** | writing-plans | 3문서 시스템 + 작업 레벨 판정 | 계획 선행 | 아누: Lv.1~4 차등 계획 깊이 / SP: 2~5분 마이크로태스크 + 계획 리뷰어 3회 루프 |
| **4. SDD** | subagent-driven-development | dispatch.py + Task tool 코워크 | 서브에이전트 위임 | 아누: subagent-driven-development 스킬 도입됨. 2-레이어(봇간+팀내) / SP: 단일 레이어 |
| **5. TDD** | test-driven-development | tdd-enforcement 스킬 v1.1 | 품질 강제 | 아누: audit-trail 타임스탬프 순서 검증 추가. SP: "Delete means delete" 더 극단적 |
| **6. Code Review** | requesting/receiving-code-review | 3단계 QC (normal/critical/security) | 자동화 리뷰 | 아누: v5.0.4 토큰 최적화 유사 기능 있지만 구조 다름. SP: git SHA 기반 정밀 범위 지정 |
| **7. Branch Completion** | finishing-a-development-branch | .done 프로토콜 + task-timer end | 완료 처리 | 아누: 파일 이벤트 기반 / SP: 4가지 옵션 (로컬병합/PR/유지/폐기) 명시적 UX |

---

## 3. 이미 도입한 항목 (completed)

기존 분석 task-328.1 TOP-5 중 도입 현황:

### TOP-1: TDD 강제 스킬 — 완료 (2026-03-07)

- **파일**: `/home/jay/workspace/skills/tdd-enforcement/SKILL.md` (v1.1)
- **핵심 규칙**: RED → GREEN → REFACTOR 사이클, Lv.2+ 자동 적용
- **아누 특화 추가**: `tdd_check` verifier — audit-trail 기반 파일 타임스탬프 순서 검증 (테스트 파일이 구현 파일보다 먼저 생성되어야 함)
- **Superpowers 대비 차이**: SP의 "Delete means delete" 물리적 삭제 메커니즘은 미도입. 아누는 경고 + 팀장 보고 방식

### TOP-2: Git Worktree 격리 — 완료

- **파일**: `/home/jay/workspace/skills/git-worktree-isolation/SKILL.md`
- **스크립트**: `/home/jay/workspace/scripts/worktree_manager.py`
- **아누 특화 추가**: 멀티봇 충돌 방지 규칙 4개 (팀별 격리 원칙, 메인 브랜치 직접 수정 금지, 충돌 보고 프로세스, 1프로젝트 1팀 원칙)
- **조건**: Lv.2 이상 + Git repo + 2팀 이상 동시 투입 시 자동 활성화

### TOP-3: 마이크로태스크 분해 — 부분 완료

- `subagent-driven-development` 스킬 도입으로 태스크별 fresh 서브에이전트 + 2단계 리뷰 구조 확보
- 단, Superpowers의 "정확한 파일 경로 + 완성된 코드 + 검증 명령어 + 커밋 명령어" 4요소 마이크로태스크 포맷은 아직 DIRECT-WORKFLOW에 명시적으로 통합 미흡

### TOP-4: 스킬 품질 관리 — 부분 완료

- `skill-creator` 스킬 도입으로 새 스킬 작성 방법론 확보
- SP의 합리화 표(Rationalization Table) + CSO(Claude Search Optimization) 원칙은 일부 스킬에만 적용됨

### TOP-5: 서브에이전트 리뷰 2단계 — 완료

- `subagent-driven-development` 스킬: spec-reviewer → code-quality-reviewer 2단계 리뷰 구조 반영
- SP 원본 기반 커스터마이징으로 Superpowers와 동등한 리뷰 구조 확보

---

## 4. v5.0.x 신규 기능 — 우리 시스템 적용 검토

### 4.1 Visual Companion

**Superpowers 내용**: v5.0.1 도입. 브라우저 기반 시각 도구. UI 관련 작업에서 목업, 다이어그램 생성. Brainstorming Phase 9단계 중 별도 메시지로만 제안 (메인 흐름 방해 금지).

**우리 시스템 현황**: 없음. 현재 canvas-design 스킬이 UI 설계 관련 기능을 담당하지만 브라우저 기반 시각화 도구는 아님.

**적용 검토**:
- 비너스(Gemini, 디자인팀)가 시각적 브레인스토밍 도구를 사용할 수 있다면 설계 품질 향상 가능
- 단, 우리 시스템은 Telegram 봇 기반이라 브라우저 UI 연동에 추가 인프라 필요
- 단기 대안: `canvas-design` 스킬에 "시각 자료 필요 시 별도 메시지로만 제안" 규칙 추가

### 4.2 서브에이전트 컨텍스트 격리 명시화

**Superpowers v5.0.2 변경**: 서브에이전트에 세션 히스토리 전달 금지를 명시적 원칙으로 강화. 대신 필요한 컨텍스트만 정밀 구성 (태스크 전문 텍스트 + 장면 설정 + 코드 조직 원칙).

**우리 시스템 현황**: `git-worktree-isolation` 스킬에 "팀별 격리 원칙"이 있고, dispatch.py도 팀별 독립 cokacdir 세션을 사용. 그러나 워크플로우 문서에 "서브에이전트에 세션 히스토리 전달 금지"를 명시적으로 규정하지 않음.

**적용 검토**: 즉시 도입 가능. `subagent-driven-development` 스킬에 아래 원칙 추가:
```
서브에이전트 컨텍스트 구성 원칙:
1. 세션 히스토리 전달 금지
2. 태스크 전문 텍스트만 전달
3. 필요한 파일 내용은 직접 첨부
```

### 4.3 리뷰 루프 토큰 최적화

**Superpowers v5.0.4 변경**: 코드 리뷰를 청크별 반복에서 전체 코드 1회 리뷰로 변경. 리뷰 최대 횟수 3회로 제한. 리뷰어 판단 기준 강화.

**우리 시스템 현황**: `qc_verify.py` 8개 verifier가 파이프라인 방식으로 실행됨. 각 verifier가 독립적으로 실행되어 중복 컨텍스트 소비 가능성 있음. 마아트(critical/security)가 "개발자 보고를 신뢰하지 않고 직접 재실행"하는 구조는 오히려 더 철저하나, 토큰 효율 측면에서 개선 여지 있음.

**적용 검토**: `diff-aware-qa.py`가 이미 변경된 파일만 선별 검증하는 방향으로 설계됨 (dispatch-improvement-reference.md 참조). SP의 git SHA 기반 정밀 범위 지정을 qc_verify.py에 적용하면 불필요한 전체 파일 재검증 줄일 수 있음.

### 4.4 멀티플랫폼 지원

**Superpowers 현황**: Claude Code → Gemini CLI (v5.0.1) → Cursor (v5.0.3) → OpenCode (v5.0.4) 순으로 2주 안에 4개 플랫폼 추가. 플랫폼별 훅 설정 파일 분리 (hooks.json / hooks-cursor.json).

**우리 시스템 현황**: Claude Code 전용. cokacdir 프레임워크와 Telegram 봇이 Claude Code에 의존. 타 플랫폼 지원은 아키텍처 수준 변경 필요.

**적용 검토**: 단기 내 멀티플랫폼 지원은 현실적으로 어려움. 장기적으로 특정 팀(예: GLM 기반 3팀)을 Gemini CLI 연동으로 확장하는 방향은 검토 가능.

---

## 5. 도입 가능한 패턴 전체 목록

### 5.1 즉시 도입 가능 (low effort, high impact)

| 패턴 | 출처 | 적용 방법 | 예상 효과 |
|------|------|----------|----------|
| 서브에이전트 컨텍스트 격리 원칙 명시 | SP v5.0.2 | `subagent-driven-development/SKILL.md` 3원칙 추가 | 서브에이전트 혼란 감소, 토큰 절약 |
| git SHA 기반 리뷰 범위 지정 | SP v5.0.4 | `qc_verify.py` scope_check verifier에 SHA 활용 | 리뷰 노이즈 감소, 정밀도 향상 |
| 스킬 description CSO 최적화 | SP 설계 원칙 | 기존 47개 스킬 description 재검토 (트리거 조건만 기술) | 스킬 자동 매칭 정확도 향상 |
| 150단어 이하 자주 로드 스킬 최적화 | SP 토큰 경제 | 고빈도 스킬 (tdd-enforcement, 3docs-create 등) 압축 | 컨텍스트 윈도우 절약 |
| Branch Completion 4옵션 UX | SP Phase 7 | DIRECT-WORKFLOW.md에 merge/PR/keep/discard 명시 | 완료 처리 일관성 향상 |

### 5.2 중기 도입 (설계 변경 필요)

| 패턴 | 출처 | 설계 변경 내용 | 예상 효과 |
|------|------|--------------|----------|
| 마이크로태스크 4요소 포맷 | SP writing-plans | DIRECT-WORKFLOW.md에 "파일경로+완성코드+검증명령+커밋명령" 4요소 필수화 | 팀원 할당 정밀도 향상 |
| Plan Review Loop 3회 제한 | SP v5.0.4 | chain_manager.py에 리뷰 루프 최대 3회 제한 로직 추가 | 무한 리뷰 루프 방지 |
| verification-before-completion 게이트 | SP 스킬 | .done 프로토콜 전 검증 체크리스트 강제 | 미완성 보고 방지 |
| diff-aware-qa 연동 qc_verify | SP 토큰 최적화 | qc_verify.py에 변경 파일만 선별 검증 로직 | 검증 속도 향상, 토큰 절약 |
| TDD "Delete means delete" 물리적 강제 | SP Iron Law | tdd-enforcement 스킬에 구현 파일 삭제 + 재작성 절차 추가 | TDD 강제력 강화 |

### 5.3 장기 검토 (아키텍처 변경 필요)

| 패턴 | 출처 | 아키텍처 변경 내용 | 리스크 |
|------|------|-----------------|--------|
| Visual Companion 연동 | SP v5.0.1 | 브라우저 기반 시각화 서버 + Telegram 봇 연동 | 인프라 복잡도 대폭 증가 |
| Zero-dep Brainstorm Server | SP v5.0.2 | dashboard/server.py와 통합 또는 대체 | 현재 8개 API 엔드포인트 마이그레이션 필요 |
| 멀티플랫폼 훅 지원 | SP v5.0.x | 플랫폼별 훅 설정 파일 분리, cokacdir 추상화 | 전체 봇 아키텍처 리팩토링 필요 |
| 스킬 마켓플레이스 연동 | SP plugin.json | agentskills.io 또는 자체 마켓플레이스 구축 | 47개 스킬 포맷 통일 + 공개 결정 필요 |

---

## 6. 우리 시스템 개선 제안

### 6.1 dispatch.py 개선점

현재 `dispatch.py`는 단일 팀에게 순차적으로 작업을 위임하는 구조다 (기존 분석 참조). Superpowers의 3가지 패턴을 참조한 개선 방향:

**Fork-Join 패턴 (설계 참조 완료, dispatch-improvement-reference.md)**:
- 현재: 아누가 직접 여러 번 dispatch 호출
- 개선: `dispatch.py --fork [팀A, 팀B, 팀C] --join-condition all_done` 파라미터 추가
- 효과: 병렬 팀 작업 후 모든 완료 시 자동 체이닝

**Iterative 패턴 (chain_manager.py 연동)**:
- 현재: Phase 완료 후 수동 체이닝
- 개선: `chain_manager.py`에 `max_iterations: 3` 파라미터로 QC 루프 자동 제한
- SP v5.0.4의 "최대 3회 리뷰" 원칙과 동일한 보호 장치

**Quality Gate 패턴**:
- 현재: qc_verify.py 결과를 팀장이 직접 해석
- 개선: `dispatch.py`에 `--quality-gate qc_verify` 옵션 추가. verifier 통과 실패 시 자동 재위임 (최대 2회)

### 6.2 스킬 시스템 강화

**현황**: 47개 스킬, Superpowers 대비 3.4배. 그러나 스킬 품질이 불균일함.

**개선 방향**:

1. **CSO(Claude Search Optimization) 점검**: 현재 스킬 중 description에 워크플로우 요약이 들어간 스킬 확인 후 "언제 이 스킬을 쓸지"만 남기도록 수정. 대상: `agent-meeting`, `3docs-create`, `project-kickoff` 등 복잡한 description을 가진 스킬들.

2. **토큰 최적화**: 고빈도 로드 스킬(예: `tdd-enforcement`, `systematic-debugging`)의 본문을 150단어 이하로 압축. 상세 내용은 별도 `SKILL-EXAMPLES.md`로 분리 (tdd-enforcement는 이미 이 구조를 채택함).

3. **합리화 표 추가**: 주요 스킬(특히 `tdd-enforcement`, `adversarial-review`)에 Superpowers 방식의 합리화 표 추가. "이 규칙을 우회하려는 핑계 → 현실 반박" 구조로 에이전트 규칙 우회 방지.

### 6.3 서브에이전트 프롬프트 품질 개선 (Superpowers 방식 참고)

Superpowers `implementer-prompt.md`의 구조화된 서브에이전트 프롬프트에서 배울 점:

**현재 아누의 `dispatch.py`**: `build_prompt()` 함수로 팀/작업/컨텍스트를 조합. 세션 히스토리 전달 여부가 명시적으로 통제되지 않음.

**개선 제안**: `prompts/team_prompts.py`에 서브에이전트 프롬프트 구성 시 아래 체크리스트 강제:
```
□ 세션 히스토리 미포함 (격리 원칙)
□ 태스크 전문 텍스트 포함
□ 장면 설정: 프로젝트 현재 상태 + 관련 파일 내용
□ 코드 조직 원칙 포함
□ 완료 상태 코드 명시 (DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED)
```

특히 `BLOCKED` 상태 코드 도입을 권장. 현재 아누 시스템은 서브에이전트가 막혔을 때 에스컬레이션 절차가 암묵적으로만 존재함.

### 6.4 Verification-Before-Completion 도입

Superpowers의 `verification-before-completion` 스킬은 .done 보고 전 최종 게이트다. 현재 아누의 `.done 프로토콜`은 완료 신호를 보내지만 "완료 전 검증"이 명시적으로 강제되지 않음.

**도입 제안**: `/home/jay/workspace/skills/` 아래 `verification-before-completion/SKILL.md` 작성. 내용:
- 기능이 실제로 동작하는가? (런타임 검증)
- 모든 테스트가 통과하는가? (qc_verify.py 실행 확인)
- 팀장에게 보고한 내용이 정확한가? (Self-Deception 방지)
- 범위를 벗어난 부수 변경은 없는가? (scope_check 연동)

이 스킬을 `.done` 파일 생성 전 `post-tool-use.sh` 훅에서 자동 상기시키는 방식으로 연동 가능.

---

## 7. 핵심 인사이트 10개+

1. **스킬 수 ≠ 스킬 품질**: 아누의 47개 스킬은 Superpowers 14개의 3.4배지만, CSO 최적화·합리화 표·토큰 경제가 적용된 스킬은 소수임. 규모보다 품질 관리 체계가 더 중요.

2. **v5.0.5의 SDD 강제 해제**: Superpowers가 "Subagent-Driven 강제"를 철회한 것은 아누 시스템의 방향을 지지함. 작업 복잡도에 따라 실행 방식을 선택하는 아누의 Lv.1~4 시스템이 더 성숙한 접근법.

3. **컨텍스트 격리의 두 방향**: SP는 서브에이전트 세션 히스토리 금지(micro), 아누는 봇 독립 세션(macro) 방식으로 격리. 두 방식이 상호 보완적이며, 아누에 SP의 micro 격리 원칙을 추가하면 이중 방어선 완성.

4. **토큰 경제의 비대칭성**: SP는 스킬 150단어 제한, 청크별→전체 1회 리뷰로 적극적 토큰 관리. 아누는 47개 스킬을 유지하며 토큰 비용이 누적됨. 고빈도 스킬 압축은 즉시 효과를 낼 수 있는 저비용 개선.

5. **합리화 표는 방어 코딩의 AI 버전**: SP의 합리화 표(11가지 핑계 → 현실 반박)는 에이전트의 규칙 우회 패턴을 예측하고 선제 차단한다. 이는 일반 프롬프트 엔지니어링을 넘어선 수준. 아누의 핵심 스킬에 도입 필요.

6. **Git SHA 기반 리뷰는 범위 명확성의 핵심**: SP가 code-review 서브에이전트에게 git SHA를 명시하는 이유는 "어디서 어디까지 리뷰하는가"가 명확해야 노이즈가 줄기 때문. 아누의 qc_verify.py에도 `scope_check verifier`가 있으나, SHA 기반 정밀 범위 지정은 미구현.

7. **HARD-GATE vs 핵미사일 발사코드**: 둘 다 "설계 승인 전 코딩 금지"라는 같은 철학이지만, SP의 HARD-GATE는 단순 강제, 아누의 핵미사일은 Context Purge + 세션 재시작 + 제이회장님 승인을 포함. 아누가 더 정교하지만 그만큼 마찰도 큼.

8. **Zero-dep Brainstorm Server의 교훈**: SP가 Node.js 내장 모듈만으로 브레인스토밍 서버를 구현한 것은 "의존성 없음이 최고의 이식성"이라는 신호. 아누의 dashboard/server.py는 반대 방향(다수 의존성). 신규 도구 설계 시 Zero-dep 원칙 참조 가치 있음.

9. **Cursor/OpenCode/Gemini CLI 지원 속도**: SP가 2주 만에 4개 플랫폼을 추가한 것은 hooks 파일 분리 아키텍처 덕분. 아누가 미래에 멀티플랫폼을 지원하려면 지금부터 훅 설정을 플랫폼별로 분리하는 구조로 설계해야 함.

10. **TDD for Skills (메타 방법론)**: SP의 `writing-skills` 스킬이 스킬 작성에 TDD를 적용하는 것은 "시스템 자체의 신뢰성 보장"이라는 메타 수준의 접근. 아누의 `skill-creator` 스킬에 이 접근법 통합 필요. 새 스킬 작성 시 "스킬 없이 에이전트가 잘못 동작하는 케이스 먼저 기록 → 스킬 작성 → 동작 교정 확인" 순서 강제.

11. **BLOCKED 상태 코드 부재**: SP의 서브에이전트는 DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED 4가지 상태를 명시적으로 보고. 아누는 이 구조가 없어 서브에이전트가 막혔을 때 에스컬레이션이 암묵적. dispatch.py와 .done 프로토콜에 이 4-state 모델 도입을 검토해야 함.

12. **"예외 없음" 명시의 심리학적 효과**: SP의 Rigid 스킬(TDD, 디버깅)이 "예외 없음"을 반복 강조하는 것은 에이전트가 "이번만은 괜찮겠지"라는 합리화를 시도하기 때문. 아누의 핵심 규칙도 예외 조항을 최소화하고 "절대 규칙" 섹션을 명시적으로 분리하는 것이 효과적.

---

## 8. 실행 가능한 액션 아이템 (우선순위별)

### 즉시 실행 (이번 주, Lv.1~2 작업)

**A-1. `subagent-driven-development/SKILL.md` 컨텍스트 격리 원칙 추가**
- 파일: `/home/jay/workspace/skills/subagent-driven-development/SKILL.md`
- 수정 내용: "컨텍스트 구성 원칙" 섹션 추가 (세션 히스토리 금지 + 4-state 완료 코드)
- 기대 효과: SP v5.0.2 수준의 격리 원칙 달성

**A-2. 고빈도 스킬 토큰 최적화 (tdd-enforcement, systematic-debugging)**
- 파일: `/home/jay/workspace/skills/systematic-debugging/SKILL.md`
- 수정 내용: 150단어 이하로 핵심 원칙만 남기고 상세 내용 `SKILL-EXAMPLES.md`로 분리
- tdd-enforcement는 이미 분리 구조 채택 → systematic-debugging에 동일 패턴 적용
- 기대 효과: 컨텍스트 윈도우 절약

**A-3. 스킬 description CSO 점검 (3개 우선 대상)**
- 대상: `agent-meeting`, `3docs-create`, `project-kickoff`
- 수정 방향: description에서 워크플로우 요약 제거, "언제 이 스킬을 쓸지"만 남기기
- 기대 효과: 스킬 자동 매칭 정확도 향상

### 단기 실행 (2주 내, Lv.2 작업)

**B-1. `verification-before-completion/SKILL.md` 신규 작성**
- 경로: `/home/jay/workspace/skills/verification-before-completion/SKILL.md`
- 내용: 런타임 검증 + 테스트 통과 확인 + 범위 초과 변경 확인 + Self-Deception 방지 체크리스트
- 연동: `post-tool-use.sh`에서 `.done` 파일 생성 전 이 스킬 트리거

**B-2. `tdd-enforcement/SKILL.md` 합리화 표 추가**
- 파일: `/home/jay/workspace/skills/tdd-enforcement/SKILL.md`
- 추가 내용: SP 방식의 합리화 표 ("이건 너무 단순해서 테스트 불필요 → 단순한 코드가 가장 많이 변경됨" 등 5가지)
- 기대 효과: TDD 우회 시도 감소

**B-3. `dispatch.py` 4-state 완료 코드 도입 설계**
- 파일: `/home/jay/workspace/memory/specs/dispatch-improvement-reference.md`에 4-state 설계 추가
- 내용: DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED 상태 코드 + .done 파일 포맷 변경
- 주의: `.done 프로토콜` 변경은 기존 done-watcher.py, task-timer.py 연동 확인 필요

### 중기 실행 (4주 내, Lv.2~3 작업)

**C-1. `chain_manager.py` 리뷰 루프 최대 3회 제한 추가**
- 파일: `/home/jay/workspace/chain_manager.py`
- 내용: `max_review_iterations: 3` 파라미터 + 초과 시 팀장 에스컬레이션
- 근거: SP v5.0.4 "최대 3회 리뷰" 원칙, 무한 리뷰 루프 방지

**C-2. `qc_verify.py` diff-aware + SHA 기반 범위 지정**
- 파일: `/home/jay/workspace/teams/dev1/qc/qc_verify.py`
- 내용: `scope_check verifier`에 git SHA 파라미터 추가, 변경 파일만 선별 검증
- 기대 효과: qc_verify 실행 시간 단축, 토큰 절약

---

## 9. 참고 파일 경로 맵

| 파일 경로 | 역할 | 참고할 점 (SP 연결) |
|----------|------|-------------------|
| `/home/jay/workspace/skills/tdd-enforcement/SKILL.md` | TDD 강제 스킬 v1.1 | SP Iron Law 대응. 합리화 표 추가 필요. audit-trail 타임스탬프 검증이 SP에 없는 아누 고유 기능 |
| `/home/jay/workspace/skills/git-worktree-isolation/SKILL.md` | Git Worktree 격리 스킬 | SP `using-git-worktrees`와 동일 기능. 멀티봇 충돌 방지 규칙 4개가 아누 특화 추가분 |
| `/home/jay/workspace/skills/subagent-driven-development/SKILL.md` | 서브에이전트 개발 스킬 | SP 원본 기반. 컨텍스트 격리 원칙 (v5.0.2) + 4-state 완료 코드 추가 필요 |
| `/home/jay/workspace/dispatch.py` | 작업 위임 디스패처 | SP의 dispatching-parallel-agents + Quality Gate 패턴 도입 설계 대상. Fork-Join 파라미터 추가 검토 |
| `/home/jay/workspace/chain_manager.py` | Phase 자동 체이닝 | SP v5.0.4 "최대 3회 리뷰" 원칙 적용 대상. max_iterations 파라미터 추가 |
| `/home/jay/workspace/teams/dev1/qc/qc_verify.py` | 자동 QC 검증 (8개 verifier) | SP 리뷰 루프 토큰 최적화(v5.0.4) 참조. git SHA 기반 범위 지정 + diff-aware 선별 검증 |
| `/home/jay/workspace/scripts/worktree_manager.py` | Worktree 관리 스크립트 | SP `using-git-worktrees`의 `.worktrees/` 디렉토리 전략 + 아누의 멀티봇 충돌 방지 통합 |
| `/home/jay/workspace/memory/specs/dispatch-improvement-reference.md` | dispatch.py 개선 설계 | Fork-Join/Iterative/Quality Gate 패턴 매핑. B-3 4-state 설계 추가 대상 |
| `/home/jay/workspace/memory/research/superpowers-deep-analysis.md` | SP v5.0.5 심층 분석 | 이 문서의 1차 소스. 버전별 변경사항 상세 기록 |
| `/home/jay/workspace/memory/research/superpowers-vs-anu-comparison.md` | task-328.1 이전 비교 분석 (v4.3.1) | 이 문서로 대체됨. 구조적 비교 원본 |
| `/home/jay/workspace/skills/systematic-debugging/SKILL.md` | 체계적 디버깅 스킬 | SP Rigid 스킬 동일 대응. A-2 토큰 최적화 1순위 대상 |
| `/home/jay/workspace/memory/specs/anu-guide.md` | 아누 가이드 v1.1 | 아누 시스템 근본 원칙. SP 설계 철학과 비교 시 참조 |

---

*이 문서는 task-830.1 산출물. 다음 재확인 시점: Superpowers v5.1.x 릴리스 또는 아누 시스템 아키텍처 변경 시.*