=== adaptive-quality.md ===
---
name: adaptive-quality
description: Per-task execution profile selection based on complexity in Balanced quality mode
triggers:
  - adaptive quality
  - 적응형 품질
  - complexity
  - 복잡도
category: agentic
level1_metadata: "adaptive quality, complexity assessment, execution profiles, cost optimization, Balanced mode"
---

# Adaptive Quality Skill

## Overview

Adaptive Quality is a sub-extension of Quality Mode. In **Balanced mode only**, task complexity determines the execution profile used for each `Agent()` call. High-complexity tasks still receive the strongest reasoning path, while routine tasks stay on the standard path. In this workspace, Claude no longer falls back to haiku; Codex stays on GPT-5.5 and varies reasoning effort; OpenCode keeps its configured default model.

## Relationship to Quality Mode

| Mode | Behavior |
|------|----------|
| **Ultra** | ALL tasks use the premium execution path. Complexity is IGNORED. |
| **Balanced** | Complexity determines the execution profile. Adaptive Quality applies. |
| **Solo** | No Agent() calls. Not applicable. |

Adaptive Quality is **not** a replacement for Quality Mode — it is a refinement that operates exclusively within Balanced mode.

## Complexity Assessment Criteria


=== agent-pipeline.md ===
---
name: agent-pipeline
description: Multi-agent pipeline orchestration skill
triggers:
  - pipeline
  - multi-agent
  - 파이프라인
  - 멀티에이전트
category: agentic
level1_metadata: "5-Phase pipeline, automatic agent delegation, quality gates"
---

# Agent Pipeline Skill

A 5-Phase multi-agent pipeline orchestration skill. This is the **default** execution mode for `/auto go`.

## Activation

This skill is the default for `/auto go SPEC-ID`.

| 플래그 | 모드 | 설명 |
|--------|------|------|
| (없음) | **서브에이전트 파이프라인** | Agent tool로 서브에이전트 스폰 (이 스킬). 메인 세션이 파이프라인 흐름 제어 |
| `--team` | **Agent Teams** | Claude Code Agent Teams 사용. 팀원 간 직접 통신, 공유 태스크 리스트, 자기 조율 |
| `--solo` | **단일 세션** | 메인 세션이 직접 TDD 구현. 서브에이전트 없음 |
| `--multi` | **멀티프로바이더** | Review Phase에서 orchestra engine 사용. 다른 모드와 조합 가능 |

For Agent Teams mode (`--team`), see `.claude/skills/autopus/agent-teams.md` for role-based team composition (Lead/Builder/Guardian).

@.claude/skills/autopus/worktree-isolation.md

=== agent-presets.md ===
---
name: agent-presets
description: Domain-specific agent configurations for different project types
triggers:
  - preset
  - presets
  - 프리셋
  - agent preset
category: agentic
level1_metadata: "agent presets, backend-go, fullstack, cli-tool, pipeline configuration, agent activation"
---

# Agent Presets Skill

## Overview

Agent presets define which agents are active for a given project type. Presets allow teams to activate only the agents relevant to their domain, skipping phases that reference inactive agents and reducing unnecessary overhead.

## Preset Definitions

### `backend-go`

Optimized for Go backend services.

**Active agents**: executor, tester, planner, reviewer, validator, security-auditor, annotator, perf-engineer

### `fullstack`

Includes all backend-go agents plus frontend support.


=== agent-teams.md ===
---
name: agent-teams
description: Role-based team composition skill for Claude Code Agent Teams mode
triggers:
  - agent teams
  - teams
  - 에이전트 팀
  - 팀 구성
category: agentic
level1_metadata: "Agent Teams, role-based, Lead-Builder-Guardian, SendMessage, worktree isolation"
---

# Agent Teams Skill

## Overview

Agent Teams mode (`--team`) enables role-based team collaboration via Claude Code Agent Teams. Instead of spawning ephemeral subagents per task, this mode creates persistent teammates that communicate directly, share a task list, and self-coordinate through the pipeline.

**Activation flag**: `/auto go SPEC-ID --team`

## Activation

### Prerequisites

| Requirement | Value | How to verify |
|-------------|-------|---------------|
| Claude Code version | v2.1.32 or later | `claude --version` |
| Environment variable | `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` | `echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` |
| Feature status | **Experimental** — disabled by default | Official: https://code.claude.com/docs/en/agent-teams |


=== api-design.md ===
---
name: api-design
description: REST/gRPC/GraphQL API 설계 패턴 및 모범 사례
triggers:
  - api
  - rest
  - grpc
  - graphql
  - endpoint
  - API 설계
category: development
level1_metadata: "RESTful 설계, gRPC 프로토, GraphQL 스키마, 버전 관리"
---

# API Design Skill

확장 가능하고 일관된 API를 설계하는 스킬입니다.

## RESTful API 설계 원칙

### URL 설계
```
GET    /api/v1/users          # 목록 조회
GET    /api/v1/users/:id      # 단건 조회
POST   /api/v1/users          # 생성
PUT    /api/v1/users/:id      # 전체 수정
PATCH  /api/v1/users/:id      # 부분 수정
DELETE /api/v1/users/:id      # 삭제
```


=== ast-refactoring.md ===
---
name: ast-refactoring
description: AST 기반 안전한 코드 리팩토링 스킬
triggers:
  - refactor
  - ast
  - refactoring
  - 리팩토링
  - ast 리팩토링
category: quality
level1_metadata: "AST 파싱, 구조적 코드 변환, 안전한 리팩토링"
---

# AST Refactoring Skill

Abstract Syntax Tree(AST)를 활용하여 코드를 안전하게 리팩토링하는 스킬입니다.

## AST 기반 리팩토링 원칙

### 왜 AST인가?
- 텍스트 기반 치환: `sed`, 정규식 → 오탐, 부분 매칭 위험
- AST 기반 변환: 문법을 이해하고 변환 → 안전

### Go AST 도구

```bash
# gorename: 심볼 안전 이름 변경
gorename -from "github.com/org/pkg.OldName" -to NewName

# gofmt -r: 패턴 기반 변환

=== ax-annotation.md ===
---
name: ax-annotation
description: "@AX code annotation workflow skill for agent-driven tag application"
triggers:
  - ax
  - annotation
  - 어노테이션
  - 태그
category: quality
level1_metadata: "@AX tags, NOTE/WARN/ANCHOR/TODO, per-file limits, [AUTO] prefix"
---

# @AX Annotation Skill

Reference: `pkg/content/ax.go:GenerateAXInstruction()` is the canonical source for all @AX rules.
This skill provides actionable guidance for WHEN and HOW agents apply @AX tags.

## Canonical Source

All tag type definitions, trigger conditions, lifecycle rules, and per-file limits are defined in
`pkg/content/ax.go:GenerateAXInstruction()`. Do NOT redefine rules here — consult that function
as the authoritative source before applying any tag.

## When to Apply @AX Tags

### NOTE Triggers

Apply `@AX:NOTE` when you encounter:
- A magic constant with no explanation
- An exported function over 100 lines that has no godoc comment

=== brainstorming.md ===
---
name: brainstorming
description: 아이디어 발산 및 창의적 문제 해결 스킬
triggers:
  - brainstorm
  - brainstorming
  - 아이디어
  - 발산
  - 창의
category: workflow
level1_metadata: "발산적 사고, 아이디어 생성, 창의적 문제 해결"
---

# Brainstorming Skill

창의적인 아이디어를 발산하고 최적의 해결책을 탐색하는 스킬입니다.

## 브레인스토밍 기법

### 발산 단계 (Diverge)

아이디어의 수와 다양성을 극대화합니다:

1. **SCAMPER 기법**
   - **S**ubstitute: 대체할 수 있는 것은?
   - **C**ombine: 결합할 수 있는 것은?
   - **A**dapt: 적용/수정할 수 있는 것은?
   - **M**odify/Magnify: 변형하거나 확대할 수 있는 것은?
   - **P**ut to other uses: 다른 용도로 활용할 수 있는 것은?
   - **E**liminate: 제거할 수 있는 것은?

=== browser-automation.md ===
---
name: browser-automation
description: 터미널 환경 자동 감지 브라우저 자동화 스킬 — AI 에이전트가 직접 웹 페이지를 조작하고 검증
triggers:
  - browser
  - browse
  - 브라우저
  - 웹 테스트
  - 운영 확인
  - UI 확인
  - 페이지 확인
category: testing
level1_metadata: "cmux browser, agent-browser, 터미널 자동 감지, 접근성 트리 snapshot, 운영환경 UI 검증"
---

# Browser Automation Skill

터미널 환경을 자동 감지하여 cmux browser 또는 agent-browser CLI를 활용해 AI 에이전트가 직접 웹 페이지를 조작하고 검증하는 스킬입니다.

## 도구 선택

| 도구 | 용도 | 선택 기준 |
|------|------|-----------|
| **cmux browser** | cmux 환경 네이티브 조작 | cmux 터미널에서 자동 선택 (최우선) |
| **agent-browser** | 에이전트 직접 조작 | tmux/plain 환경 폴백 |
| **Playwright** | E2E 테스트 스위트 | 반복 실행, CI/CD, 회귀 테스트 |

백엔드는 `auto terminal detect` 결과에 따라 자동 선택됩니다. 수동 지정하지 마세요.

## 백엔드 자동 감지

=== ci-cd.md ===
---
name: ci-cd
description: GitHub Actions CI/CD 파이프라인 설계 및 자동화
triggers:
  - ci
  - cd
  - github actions
  - pipeline
  - 파이프라인
  - 배포 자동화
category: devops
level1_metadata: "GitHub Actions, 빌드/테스트/배포 자동화, 릴리스 워크플로우"
---

# CI/CD Skill

GitHub Actions 기반 CI/CD 파이프라인을 설계하는 스킬입니다.

## CI 파이프라인 (Pull Request)

```yaml
name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:

=== competitive-analysis.md ===
---
name: competitive-analysis
description: SWOT, competitive landscape analysis, and battlecard generation
triggers:
  - competitive
  - competitor
  - 경쟁 분석
  - swot
  - battlecard
  - 배틀카드
category: strategy
level1_metadata: "SWOT analysis, Porter's Five Forces, competitive battlecard, market positioning"
---

# Competitive Analysis Skill

경쟁 환경을 구조적으로 분석하고 포지셔닝 전략을 도출하는 스킬입니다.

## 분석 프레임워크

### 1. SWOT

| 축 | 질문 |
|---|---|
| Strengths | 우리가 경쟁사보다 명확히 잘하는 것은 무엇인가? |
| Weaknesses | 현재 약점과 제약은 무엇인가? |
| Opportunities | 시장 변화가 여는 기회는 무엇인가? |
| Threats | 경쟁, 대체재, 규제가 만드는 위협은 무엇인가? |

SWOT은 항목 나열로 끝내지 않고 아래 전략으로 연결합니다.

=== context-search.md ===
---
name: context-search
description: 이전 세션 컨텍스트 검색 및 연속성 유지 스킬
triggers:
  - context search
  - previous session
  - 이전 세션
  - 컨텍스트 검색
  - 작업 재개
category: workflow
level1_metadata: "세션 인덱스 검색, 컨텍스트 주입, 작업 재개"
---

# Context Search Skill

이전 Claude Code 세션의 컨텍스트를 검색하여 작업을 연속적으로 진행하는 스킬입니다.

## 검색 시점

다음 상황에서 컨텍스트를 검색합니다:
- 사용자가 이전 작업을 언급할 때
- SPEC-ID가 현재 세션에 없을 때
- "지난번에", "이어서", "계속" 등의 표현 감지

## 검색 절차

### 1단계: 현재 세션 확인
먼저 현재 세션에 관련 컨텍스트가 있는지 확인합니다.
있으면 검색 불필요 → 스킵.


=== database.md ===
---
name: database
description: 데이터베이스 스키마 설계, 마이그레이션, 쿼리 최적화
triggers:
  - database
  - db
  - migration
  - schema
  - 데이터베이스
  - 마이그레이션
  - sql
category: development
level1_metadata: "스키마 설계, 마이그레이션 관리, 쿼리 최적화, 인덱스 전략"
---

# Database Skill

데이터베이스 스키마를 설계하고 안전하게 마이그레이션하는 스킬입니다.

## 스키마 설계 원칙

### 정규화 기본
| 정규형 | 규칙 | 예시 |
|--------|------|------|
| 1NF | 원자값, 반복 그룹 없음 | 전화번호 배열 → 별도 테이블 |
| 2NF | 부분 함수 종속 제거 | 복합 키의 일부에만 의존하는 컬럼 분리 |
| 3NF | 이행 종속 제거 | A→B→C이면 C를 별도 테이블로 |

### 명명 규칙
```sql

=== ddd.md ===
---
name: ddd
description: Disciplined Design Development — 기존 코드 보존 우선 개발 방법론
triggers:
  - ddd
  - disciplined
  - 기존 코드
  - 보존
  - legacy
category: methodology
level1_metadata: "ANALYZE-PRESERVE-IMPROVE 사이클, 기존 동작 보존"
---

# DDD (Disciplined Design Development) Skill

기존 코드의 동작을 분석하고 보존하면서 점진적으로 개선하는 방법론입니다.

## ANALYZE-PRESERVE-IMPROVE 사이클

### ANALYZE 단계: 기존 동작 분석

변경 전에 반드시 현재 동작을 완전히 이해합니다:

```
1. 코드 목적 파악 — 무엇을 하는 코드인가?
2. 호출자 파악 — 누가 이 코드를 사용하는가? (fan_in)
3. 사이드 이펙트 식별 — 어떤 부수 효과가 있는가?
4. 테스트 현황 파악 — 어떤 테스트가 존재하는가?
5. 경계 조건 파악 — 어떤 엣지 케이스가 있는가?
```

=== debugging.md ===
---
name: debugging
description: 체계적 디버깅 및 버그 수정 스킬
triggers:
  - debug
  - debugging
  - bug
  - error
  - 버그
  - 에러
  - 디버그
category: quality
level1_metadata: "재현 테스트 우선, 근본 원인 분석, 최소 수정"
---

# Debugging Skill

버그를 체계적으로 재현하고 근본 원인을 분석하여 수정하는 스킬입니다.

## 핵심 원칙

**재현 테스트를 먼저 작성한다.** 수정 전에 버그를 재현하는 테스트를 작성하고, 수정 후 테스트가 통과하는지 확인합니다.

## 디버깅 프로세스

### 1단계: 버그 재현

```
1. 버그 재현 조건 파악
   - 어떤 입력/상태에서 발생하는가?

=== docker.md ===
---
name: docker
description: Dockerfile 작성, 멀티스테이지 빌드, Docker Compose 설정
triggers:
  - docker
  - dockerfile
  - container
  - 컨테이너
  - compose
  - 도커
category: devops
level1_metadata: "멀티스테이지 빌드, Compose, 이미지 최적화, 보안 설정"
---

# Docker Skill

효율적이고 안전한 컨테이너 이미지를 빌드하는 스킬입니다.

## Go 멀티스테이지 Dockerfile

```dockerfile
# Stage 1: 빌드
FROM golang:1.23-alpine AS builder
RUN apk add --no-cache git ca-certificates
WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY . .

=== double-diamond.md ===
---
name: double-diamond
description: Double Diamond 디자인 방법론 — 문제 탐색과 해결책 개발
triggers:
  - double-diamond
  - double diamond
  - 더블 다이아몬드
  - design thinking
  - 디자인 씽킹
category: methodology
level1_metadata: "Discover-Define-Develop-Deliver 4단계 프로세스"
---

# Double Diamond Skill

문제를 발산적으로 탐색하고 수렴하는 4단계 디자인 방법론입니다.

## 다이아몬드 1: 올바른 문제 찾기

### Discover 단계 (발산)
문제 공간을 넓게 탐색합니다:

- **현장 조사**: 실제 사용자 관찰
- **인터뷰**: 이해관계자 심층 인터뷰
- **데이터 분석**: 기존 로그와 메트릭 분석
- **경쟁 분석**: 유사 솔루션 조사

```
목표: 가능한 한 많은 인사이트 수집
방법: 가정하지 말고 관찰하라

=== entropy-scan.md ===
---
name: entropy-scan
description: 코드베이스 엔트로피 측정 및 기술 부채 탐지 스킬
triggers:
  - entropy
  - entropy-scan
  - technical debt
  - 기술 부채
  - 코드 품질 분석
category: quality
level1_metadata: "복잡도 측정, 순환 의존성 탐지, 핫스팟 분석"
---

# Entropy Scan Skill

코드베이스의 엔트로피(무질서도)를 측정하고 개선이 필요한 영역을 탐지합니다.

## 엔트로피 지표

### 순환 복잡도 (Cyclomatic Complexity)
```
임계값:
- 1-5: 단순, 유지보수 용이
- 6-10: 보통, 주의 필요
- 11-15: 복잡, @AX:WARN 태그 추가
- 16+: 매우 복잡, 즉시 리팩토링 권장
```

### 결합도 (Coupling)
```bash

=== experiment.md ===
---
name: experiment
description: Experiment loop for iterative metric-driven code optimization using XLOOP
triggers:
  - experiment
  - xloop
  - 실험
  - 반복 개선
  - metric optimization
  - iterative improvement
category: agentic
level1_metadata: "XLOOP experiment loop, metric-driven optimization, circuit breaker, simplicity gate"
---

# Experiment Loop Skill (XLOOP)

Skill for running automated iterative improvement loops that optimize a measurable metric
while keeping changes simple and reversible.

## Overview

The experiment loop (`auto experiment`) runs an agent-driven cycle:

1. Measure baseline metric
2. Ask an executor agent to make one focused change
3. Measure the new metric
4. Decide: keep (commit) or discard (reset)
5. Check circuit breaker and simplicity gate
6. Repeat until MaxIterations or circuit break


=== frontend-skill.md ===
---
name: frontend-skill
description: Use when the task asks for a visually strong landing page, website, app, prototype, demo, or game UI. This skill enforces restrained composition, image-led hierarchy, cohesive content structure, and tasteful motion while avoiding generic cards, weak branding, and UI clutter.
triggers:
  - frontend
  - frontend design
  - design
  - landing page
  - website
  - UI design
  - app design
  - prototype
  - demo
  - 프론트엔드
  - 디자인
  - 랜딩페이지
  - 웹디자인
category: methodology
level1_metadata: "visual thesis, constraint-based design, full-bleed hero, cardless layouts, brand-first hierarchy, intentional motion, Linear-style app UI"
---

# Frontend skill

Use this skill when the quality of the work depends on art direction, hierarchy, restraint, imagery, and motion rather than component count.

Goal: ship interfaces that feel deliberate, premium, and current. Default toward award-level composition: one big idea, strong imagery, sparse copy, rigorous spacing, and a small number of memorable motions.

## Working Model

Before building, write three things:

=== frontend-verify.md ===
---
name: frontend-verify
description: 프론트엔드 UX 검증 및 비주얼 테스트 스킬
triggers:
  - verify
  - frontend-verify
  - ux-verify
  - 프론트엔드 검증
  - 비주얼 검증
  - UX 검증
category: quality
level1_metadata: "5-Phase pipeline, VLM visual check, Playwright E2E, self-healing selectors"
---

# Frontend Verify Skill

Claude Vision을 활용하여 프론트엔드 UX를 5단계 파이프라인으로 자동 검증하는 스킬입니다.

## 5단계 파이프라인

### Phase 0: 변경 범위 분석

`git diff`를 기반으로 영향 범위를 파악합니다.

- UI 관련 범위: React `.tsx` / `.jsx`, CSS-family 파일, theme/token/design-system 경로
- 변경된 컴포넌트 목록 및 연관 페이지 추출
- 검증 범위를 변경된 페이지로 한정하여 토큰 비용 최소화

```bash
git diff --name-only HEAD~1 | grep -E '(\.(tsx|jsx|css|scss|sass|less)$|(^|/)(theme|tokens?|design-system))'

=== git-worktrees.md ===
---
name: git-worktrees
description: Git Worktree를 활용한 병렬 브랜치 작업 스킬
triggers:
  - worktree
  - git worktree
  - 워크트리
  - 병렬 브랜치
category: workflow
level1_metadata: "Git worktree 생성/관리, 병렬 작업 격리"
---

# Git Worktrees Skill

Git Worktree를 사용하여 여러 브랜치를 동시에 작업하는 스킬입니다.

## Git Worktree 기본

```bash
# 새 worktree 생성 (브랜치 자동 생성)
git worktree add ../project-feature feature/new-feature

# 기존 브랜치로 worktree 생성
git worktree add ../project-hotfix hotfix/critical-fix

# worktree 목록 확인
git worktree list

# worktree 제거
git worktree remove ../project-feature

=== hash-anchored-edit.md ===
---
name: hash-anchored-edit
description: 해시 앵커 기반 안전한 파일 수정 스킬
triggers:
  - hash anchor
  - anchored edit
  - 해시 앵커
  - safe edit
  - 안전한 수정
category: workflow
level1_metadata: "SHA256 해시 기반 파일 무결성 검증, 충돌 방지 수정"
---

# Hash-Anchored Edit Skill

파일 수정 전 SHA256 해시로 무결성을 검증하여 충돌 없이 안전하게 수정하는 스킬입니다.

## 핵심 개념

### 왜 해시 앵커가 필요한가?
병렬 에이전트 환경에서 동일 파일에 여러 에이전트가 접근할 경우:
- 에이전트 A가 읽은 후 에이전트 B가 수정
- 에이전트 A가 구버전 기반으로 수정 → 충돌 또는 유실

해시 앵커는 파일 상태를 고정하여 이를 방지합니다.

## 해시 앵커 적용 절차

### 1단계: 현재 상태 기록
```bash

=== idea.md ===
---
name: idea
description: 멀티 프로바이더 아이디어 토론 및 발산 스킬
triggers:
  - idea
  - 아이디어 토론
  - brainstorm idea
  - 아이디어 발산
category: workflow
level1_metadata: "멀티 프로바이더 아이디어 토론, SCAMPER/HMW/ICE, BS 파일 생성"
---

# Idea Skill

멀티 프로바이더 오케스트라를 활용해 아이디어를 구조화하고 발산 후 BS 파일로 저장합니다.

## 사용법

```
/auto idea "설명" [--strategy debate|consensus|pipeline|fastest] [--providers list] [--auto] [--deep-clarify]
```

**플래그:**
- `--strategy` — 오케스트레이션 전략 지정 (기본값: `debate`)
- `--providers` — 사용할 프로바이더 목록 (기본값: orchestra 설정 전체)
- `--auto` — clarification 질문 0개, inferred rows는 `assumed`/`deferred`로 기록, 완료 후 `/auto plan --from-idea BS-{ID}` 자동 체이닝
- `--deep-clarify` — 기본 1문항 대신 최대 3문항까지 clarification 허용

## 저장 위치 규칙


=== korean-writing-refiner.md ===
---
name: korean-writing-refiner
description: |
  한국어 문장을 자연스럽고 명확하게 다듬어 가독성을 높이는 스킬. 번역투 표현, 명사형 표현 남발, 조사 오남용, 어색한 외래어, 주어와 술어 관계의 모호함, 문장 구조의 정합성을 함께 개선한다.
  문장 교정 요청뿐 아니라 GitHub 이슈, PR, 댓글, 커밋, README, UI 문구처럼 외부 표면에 노출될 한국어 최종 문안을 어시스턴트가 직접 작성하거나 수정할 때 사용한다.
  분석, 리뷰, 전략 정리, 코드 구현처럼 문안 작성이 본체가 아닌 작업에는 자동으로 사용하지 않는다.
triggers:
  - 한국어 문장 다듬기
  - 한국어 문장 교정
  - 한국어 문안
  - PR 본문
  - GitHub 댓글
  - 커밋 메시지
  - README 문구
  - UI 문구
  - 에러 메시지
category: documentation
level1_metadata: "외부 노출 한국어 최종 문안 교정, 번역투/명사형/조사/외래어/문장 구조 개선"
bundles:
  - research
---

# Korean Writing Refiner

한국어 문장을 자연스럽고 명확하게 다듬어, 독자가 바로 이해할 수 있는 최종 문안으로 만든다.

## 트리거 기준

핵심 기준은 요청 문구가 아니라 산출물이다. 어시스턴트가 외부 표면에 노출될 한국어 최종 문안을 직접 생성하거나 수정하면 이 스킬을 적용한다.


=== lore-commit.md ===
---
name: lore-commit
description: Lore 커밋 메시지 작성 및 의사결정 기록 스킬
triggers:
  - lore
  - commit message
  - 커밋 메시지
  - 의사결정
  - decision record
category: workflow
level1_metadata: "Lore 커밋 형식, 의사결정 기록, 트레일러 태그"
---

# Lore Commit Skill

Lore 형식으로 의사결정을 커밋 메시지에 기록하는 스킬입니다.

## Lore 커밋 형식

### 기본 구조
```
<type>(<scope>): <subject>

<body>

<lore-trailers>
🐙 Autopus <noreply@autopus.co>
```

### 타입 분류

=== metrics.md ===
---
name: metrics
description: North Star Metric, input metrics, and success dashboard design
triggers:
  - metrics
  - 지표
  - north star
  - 노스스타
  - KPI
  - success metrics
  - 성공 지표
category: strategy
level1_metadata: "North Star Metric, input metrics, success criteria dashboard, metric-driven development"
---

# Metrics Skill

North Star Metric을 정의하고 입력 지표와 guard rail을 설계하는 스킬입니다.

## Metrics Hierarchy

```text
North Star Metric
  ├─ Input Metric 1
  ├─ Input Metric 2
  ├─ Input Metric 3
  └─ Health Metrics
```

## 3단계 설계 프로세스

=== migration.md ===
---
name: migration
description: 언어/프레임워크 버전 업그레이드 및 코드 마이그레이션 전략
triggers:
  - migration
  - upgrade
  - 업그레이드
  - version upgrade
  - 마이그레이션
  - deprecation
category: methodology
level1_metadata: "버전 업그레이드, 브레이킹 체인지 대응, 점진적 마이그레이션"
---

# Migration Skill

언어, 프레임워크, 라이브러리 버전 업그레이드를 안전하게 수행하는 스킬입니다.

## 마이그레이션 프로세스

### 1단계: 영향 분석
```bash
# Go 모듈 의존성 확인
go list -m -u all          # 업데이트 가능한 모듈 목록
go mod graph               # 의존성 그래프

# 브레이킹 체인지 확인
# 릴리스 노트, CHANGELOG, migration guide 확인
```


=== monitor-patterns.md ===
---
name: monitor-patterns
description: Monitor tool usage patterns and grep --line-buffered compatibility guide
triggers:
  - monitor
  - monitor-patterns
  - line-buffered
category: agentic
level1_metadata: "Monitor tool usage, grep line-buffered, idle prompt regex, orchestra Round 2 wait"
---

# Monitor Patterns Skill

Claude Code 2.1.x `Monitor` tool을 활용한 pane 이벤트 스트리밍 패턴.
주 사용처는 orchestra Round 2 응답 대기(`idea.md` Step 3.6).

## 1. Monitor Tool 개요

`Monitor`는 실행 중인 command의 stdout을 실시간 tail하여 각 라인을 notification으로
전달한다. `until-loop`/`polling sleep` 보다 저렴하다 — 대기 중 토큰 소비 없음.

기본 호출:

```python
Monitor(
  command = "...",
  timeout_ms = 180000
)
```


=== performance.md ===
---
name: performance
description: 프로파일링, 벤치마크, 성능 최적화 기법
triggers:
  - performance
  - 성능
  - profiling
  - benchmark
  - 최적화
  - bottleneck
category: quality
level1_metadata: "pprof 프로파일링, 벤치마크, 메모리 최적화, 캐싱 전략"
---

# Performance Skill

Go 애플리케이션의 성능을 측정하고 최적화하는 스킬입니다.

## 벤치마크 작성

```go
func BenchmarkFunction(b *testing.B) {
    // 셋업 (타이머에 포함되지 않음)
    data := prepareTestData()
    b.ResetTimer()

    for i := 0; i < b.N; i++ {
        Function(data)
    }
}

=== planning.md ===
---
name: planning
description: 기능 기획 및 요구사항 분석 스킬
triggers:
  - plan
  - planning
  - 기획
  - 요구사항
  - feature
category: workflow
level1_metadata: "기능 기획, 요구사항 분석, EARS 형식 수락 기준 정의"
level3_resources:
  - "https://en.wikipedia.org/wiki/EARS_(requirements)"
---

# Planning Skill

새로운 기능을 기획하고 요구사항을 분석하는 스킬입니다.

## 기획 프로세스

### 1단계: 목표 명확화

사용자의 요청을 분석하여 핵심 목표를 도출합니다:
- **What**: 무엇을 만들 것인가?
- **Why**: 왜 필요한가?
- **Who**: 누구를 위한 것인가?
- **When**: 언제 필요한가?

### 1.5단계: 시각 설명 구성

=== playwright-cli.md ===
---
name: playwright-cli
description: playwright-cli를 사용한 브라우저 자동화 — 폼 입력, 스크린샷, 테스트 생성, 세션 관리
triggers:
  - playwright
  - playwright-cli
  - 폼 입력
  - 스크린샷
  - 웹 자동화
category: testing
level1_metadata: "playwright-cli, snapshot refs, form filling, screenshot, session management"
allowed-tools: Bash(playwright-cli:*)
---

# Browser Automation with playwright-cli

## Quick Start

```bash
playwright-cli open                         # open new browser
playwright-cli goto https://playwright.dev  # navigate
playwright-cli snapshot                     # get element refs
playwright-cli click e15                    # interact with ref
playwright-cli type "search query"          # type text
playwright-cli screenshot                   # capture screenshot
playwright-cli close                        # close browser
```

## Commands


=== prd.md ===
---
name: prd
description: PRD(Product Requirements Document) 작성 스킬
triggers:
  - prd
  - PRD
  - product requirements
  - 기획서
category: workflow
level1_metadata: "PRD generation, Standard/Minimal modes, quality validation"
---

# PRD Skill

Skill for creating Product Requirements Documents (PRD) that provide top-level context for the Planning → SPEC pipeline.

## PRD Writing Process

### Step 1: Request Analysis

Identify the four core dimensions from the user's request:

- **What**: What product or feature are we building?
- **Why**: What problem does it solve? What is the business motivation?
- **Who**: Who are the primary users or stakeholders?
- **When**: What is the target release or deadline?

Clarify any missing dimensions before proceeding.

### Step 1.5: Discovery Q&A

=== product-discovery.md ===
---
name: product-discovery
description: Product discovery workflow with OST, assumption testing, and interview scripts
triggers:
  - discover
  - discovery
  - 디스커버리
  - 제품 발견
  - assumption test
  - 가정 검증
category: workflow
level1_metadata: "Opportunity-Solution Tree, assumption testing, interview script, user research"
---

# Product Discovery Skill

Opportunity-Solution Tree를 중심으로 사용자 문제를 탐색하고 솔루션 가설을 검증하는 디스커버리 워크플로우입니다.

## 핵심 흐름

### 1. Outcome 정의

- Business Outcome: 어떤 비즈니스 지표를 움직이려는가?
- Product Outcome: 사용자 행동이 어떻게 바뀌어야 하는가?
- Constraint: 시간, 기술, 리소스 제약은 무엇인가?

Outcome은 반드시 측정 가능하고 기간이 명시되어야 합니다.

### 2. Opportunity 탐색


=== refactoring.md ===
---
name: refactoring
description: 안전한 코드 리팩토링 패턴 및 레거시 현대화 전략
triggers:
  - refactor
  - refactoring
  - 리팩토링
  - clean code
  - 코드 정리
  - legacy
category: methodology
level1_metadata: "Extract, Inline, Rename, Strangler Fig, 데드코드 제거"
---

# Refactoring Skill

기존 동작을 보존하면서 코드 구조를 개선하는 스킬입니다.

## 핵심 원칙

1. **테스트 먼저**: 리팩토링 전 기존 동작을 테스트로 보호
2. **작은 단계**: 한 번에 하나의 변환만 적용
3. **행동 보존**: 외부 동작 변경 금지
4. **기능 변경 분리**: 리팩토링 커밋과 기능 변경 커밋 분리

## 안전한 리팩토링 패턴

### Extract Function
```go
// Before: 긴 함수

=== review.md ===
---
name: review
description: 코드 리뷰 및 품질 검토 스킬
triggers:
  - review
  - code review
  - 리뷰
  - 코드 검토
  - PR 검토
category: quality
level1_metadata: "TRUST 5 기준 검토, 자동화 품질 게이트"
---

# Code Review Skill

TRUST 5 기준으로 코드를 체계적으로 검토하는 스킬입니다.

## TRUST 5 리뷰 기준

### T — Tested (테스트됨)
- [ ] 85% 이상 테스트 커버리지
- [ ] 모든 엣지 케이스 테스트
- [ ] 레이스/동시성 테스트 (Go: `go test -race`, Python: `pytest-asyncio`, etc.)
- [ ] 특성 테스트 존재 (기존 코드 변경 시)
- [ ] 경계 통합 검증: 패키지/모듈 간 호출이 실제로 연결됨 (스텁 아님)
- [ ] CLI/API entry point가 실제 실행 가능 (smoke test)

### R — Readable (가독성)
- [ ] 함수/변수 명명이 명확한가?
- [ ] 함수가 단일 책임을 가지는가?

=== security-audit.md ===
---
name: security-audit
description: 보안 감사 및 취약점 탐지 스킬
triggers:
  - security
  - audit
  - vulnerability
  - 보안
  - 취약점
  - owasp
category: security
level1_metadata: "OWASP Top 10, 보안 감사, 취약점 분석"
---

# Security Audit Skill

OWASP Top 10 기준으로 보안 취약점을 탐지하고 수정하는 스킬입니다.

## OWASP Top 10 체크리스트

### A01: 접근 제어 실패
```go
// ❌ 위험: 권한 확인 없음
func GetUserData(userID string) (*User, error) {
    return db.FindUser(userID)
}

// ✅ 안전: 권한 확인 포함
func GetUserData(ctx context.Context, requestorID, targetUserID string) (*User, error) {
    if !hasPermission(ctx, requestorID, "read:user", targetUserID) {

=== spec-review.md ===
---
name: spec-review
description: Multi-provider SPEC review gate skill
triggers:
  - spec review
  - review gate
  - spec 리뷰
  - 리뷰 게이트
category: quality
level1_metadata: "Multi-provider review, orchestra engine, PASS/REVISE/REJECT verdict"
---

# SPEC Review Gate Skill

A review gate that validates SPEC document quality using multiple providers.
Before Step 1, treat `content/rules/spec-quality.md` as the pre-review self-check that spec-writer should already have applied to `spec.md`, `plan.md`, `acceptance.md`, and `research.md`.

## Review Process

### Step 0: spec-writer self-verify

Confirm that the draft went through a first-pass self-check using `content/rules/spec-quality.md`.
Look for observable traces such as `research.md`'s `## Self-Verify Summary` or `spec.md`'s `## Open Issues`.
Also prefer the draft's `## Outcome Lock`, `## Completion Debt`, `## Evolution Ideas`, `## Reviewer Brief`, `## Traceability Matrix`, and `## Reference Discipline` as scope-control evidence: review listed blockers and invariants first, treat Completion Debt as blocking, and treat Evolution Ideas or unrelated deeper-layer suggestions as advisory unless they expose critical/security/data integrity risk.
Do not create or request follow-up/sibling SPECs from Evolution Ideas. A sibling SPEC request is valid only when the draft includes a `## Sibling SPEC Decision` with an allowed reason and bounded ownership.
If the checklist was skipped or obviously not reflected in the draft, call that out as a completeness or style finding before continuing.

### Step 1: Load SPEC

Load `.autopus/specs/SPEC-{ID}/spec.md` and extract requirements.

=== subagent-dev.md ===
---
name: subagent-dev
description: 서브에이전트 개발 및 오케스트레이션 스킬
triggers:
  - subagent
  - 서브에이전트
  - agent development
  - 에이전트 개발
  - orchestration
category: agentic
level1_metadata: "서브에이전트 설계, 오케스트레이션 패턴, 병렬 실행"
---

# Subagent Development Skill

효과적인 서브에이전트를 설계하고 오케스트레이션하는 스킬입니다.

## 에이전트 정의 형식 (Claude Code 2.0+)

에이전트는 `.claude/agents/<name>.md` 에 YAML 프론트매터로 정의합니다.

### 프론트매터 필드

| 필드 | 필수 | 기본값 | 설명 |
|------|------|--------|------|
| `name` | Yes | - | 고유 식별자, 소문자+하이픈 |
| `description` | Yes | - | 에이전트 역할 설명 (언제 위임할지 기준) |
| `tools` | No | 전체 상속 | 허용 도구 목록 (allowlist) |
| `disallowedTools` | No | 없음 | 차단 도구 목록 (denylist, tools와 상호배타) |
| `model` | No | 상속 | opus, sonnet, haiku |

=== tdd.md ===
---
name: tdd
description: Test-Driven Development 방법론 스킬
triggers:
  - tdd
  - test-driven
  - 테스트 주도
  - red green refactor
category: methodology
level1_metadata: "RED-GREEN-REFACTOR 사이클, 테스트 우선 작성"
---

# TDD (Test-Driven Development) Skill

테스트를 먼저 작성하고 구현하는 RED-GREEN-REFACTOR 사이클을 적용하는 스킬입니다.

## 핵심 원칙

**테스트 없이 코드를 작성하지 않는다.** 이 규칙을 위반하면 작업을 거부합니다.

## RED-GREEN-REFACTOR 사이클

### RED 단계: 실패하는 테스트 작성

```
1. 구현하려는 동작을 테스트로 먼저 작성
2. 테스트가 실패하는지 확인 (컴파일 에러 포함)
3. 올바른 실패 이유인지 확인
```


=== testing-strategy.md ===
---
name: testing-strategy
description: 통합/E2E/계약 테스트 전략 및 테스트 피라미드
triggers:
  - testing strategy
  - integration test
  - e2e test
  - 통합 테스트
  - 테스트 전략
  - contract test
category: quality
level1_metadata: "테스트 피라미드, 통합 테스트, E2E, 계약 테스트, 커버리지 전략"
---

# Testing Strategy Skill

단위 테스트를 넘어 통합/E2E/계약 테스트를 설계하는 스킬입니다.

## 테스트 피라미드

```
        /  E2E  \        ← 적게, 핵심 플로우만
       /  통합   \       ← 중간, 컴포넌트 간 연동
      /   단위    \      ← 많이, 빠르고 격리
```

| 계층 | 비중 | 속도 | 범위 |
|------|------|------|------|
| 단위 | 70% | 빠름 (ms) | 함수/메서드 |
| 통합 | 20% | 중간 (s) | 컴포넌트 간 |

=== using-autopus.md ===
---
name: using-autopus
description: Autopus-ADK 설치 및 활용 가이드 스킬
triggers:
  - autopus
  - harness
  - auto install
  - 하네스 설치
category: workflow
level1_metadata: "autopus-adk CLI 사용법, 하네스 설치/업데이트"
---

# Using Autopus-ADK Skill

Autopus-ADK를 사용하여 코딩 CLI에 하네스를 설치하는 방법입니다.

## 설치 모드

### Full Mode
모든 기능을 포함하는 완전한 하네스:
- 방법론 (TDD/DDD/Double Diamond)
- 모델 라우터
- 인텐트 게이트
- 세션 연속성
- 훅 시스템

### Lite Mode
핵심 기능만 포함하는 경량 하네스:
- 아키텍처 문서
- Lore 커밋 시스템

=== verification.md ===
---
name: verification
description: 구현 결과 검증 및 품질 게이트 통과 스킬
triggers:
  - verify
  - verification
  - 검증
  - quality gate
  - 품질 게이트
category: quality
level1_metadata: "구현 검증, 품질 게이트, 수락 기준 확인"
---

# Verification Skill

구현 완료 후 품질 게이트를 통과하고 수락 기준을 검증하는 스킬입니다.

## 검증 단계

### 1단계: 기능 검증
요구사항과 구현 결과를 대조합니다:
```
각 요구사항 항목에 대해:
- [ ] 구현됨
- [ ] 테스트로 검증됨
- [ ] 엣지 케이스 처리됨
```

### 2단계: 자동화 품질 게이트


=== worktree-isolation.md ===
---
name: worktree-isolation
description: Worktree isolation for parallel agent execution in the pipeline
triggers:
  - worktree
  - isolation
  - 워크트리
  - 격리
  - parallel agent
category: agentic
level1_metadata: "worktree isolation, file ownership, merge strategy, parallel executor"
---

# Worktree Isolation Skill

Integrated skill for worktree isolation in the multi-agent subagent pipeline. Ensures parallel executor agents work in independent git worktrees and safely merge results back into the working branch.

## Overview

When the default subagent pipeline runs Phase 2 with parallel tasks, each executor agent receives `isolation: "worktree"` so Claude Code places it in a separate git worktree. After all parallel agents complete, their branches are merged sequentially (Phase 2.1) before Gate 2 validation.

**Ref**: SPEC-WORKTREE-001

## Activation Conditions

Applied when:
- Default subagent pipeline mode (no `--team` or `--solo` flag)
- Phase 2 has tasks with `Mode = "parallel"`

NOT applied when:

=== writing-skills.md ===
---
name: writing-skills
description: 기술 문서 및 Claude Code 스킬/에이전트 작성 가이드
triggers:
  - write docs
  - documentation
  - 문서 작성
  - readme
  - 기술 문서
  - skill authoring
  - 스킬 작성
category: documentation
level1_metadata: "API 문서, README, 기술 설계 문서, 스킬/에이전트 정의 작성"
---

# Writing Skills

명확하고 유용한 기술 문서와 Claude Code 구성 요소를 작성하는 스킬입니다.

## Claude Code 스킬 작성 (2.0+)

### 스킬 파일 구조

스킬은 `.claude/skills/<skill-name>/SKILL.md` 에 정의합니다.

### 프론트매터 필드

**표준 필드:**

| 필드 | 필수 | 설명 |