---
name: structure-design
description: "구조/지침 설계 및 개선 스킬. 지침·규칙·프롬프트·워크플로우·시스템·프로세스를 새로 설계하거나, 기존 것을 진단·개선할 때 사용한다. 트리거: '지침 만들어줘', '규칙 설계', '워크플로우 잡아줘', '프롬프트 구조', '시스템 설계', '프로세스 만들어줘', '이 지침 진단해줘', '규칙 개선하자', '구조 최적화'. 기존 지침을 검토·수정·재설계하는 요청, 새로운 운영 규칙이나 자동화 워크플로우를 설계하는 요청에도 반드시 이 스킬을 사용한다. 단순한 텍스트 교정이나 가독성 다듬기는 이 스킬이 아닌 readability 스킬을 사용할 것."
---

# 구조/지침 설계 및 개선

## 이 스킬의 목적
지침·규칙·워크플로우·프로세스를 설계하거나 기존 것을 진단·개선하는 작업에서, 일관된 품질 기준과 절차를 적용한다.

## 작업 진입 절차

### 1단계: 새 설계인지 기존 개선인지 판별
- 사용자가 "만들어줘/설계해줘" → 새 설계 모드
- 사용자가 "진단해줘/개선하자/고쳐줘" → 기존 개선 모드
- 불분명하면 "새로 만드는 건가요, 기존 것을 개선하는 건가요?" 1문장으로 확인

### 2단계: 목적 정의 확인
작업 시작 전에 아래 3가지를 1줄씩 확인하고 사용자 동의를 받는다:
- 목적: 이 작업이 달성하려는 것
- 현재 단계: 해당 시스템의 생애주기 기준 (설계/검증 vs 확정·운영 중)
- 최우선 과제: 지금 가장 먼저 해결할 것

## 새 설계 모드

### 절차
1. 목적 정의 — "이 지침/워크플로우가 해결하려는 문제는 무엇인가?"부터 시작
2. 적용 범위 — 누가, 언제, 어떤 상황에서 사용하는지 확정
3. 구조 설계 — 목적과 범위에 맞는 구조 초안 작성
4. 검증 기준 설정 — "이 설계가 성공했다고 판단할 기준"을 명시
5. 사용자 검토 — 초안 제시 후 피드백 반영

### 설계 원칙
- 추상적 원칙보다 구체적 if-then 절차를 우선한다
- "~해야 한다"보다 "~하면 → ~한다"로 작성한다
- 규칙의 트리거 조건(언제 발동하는가)을 명시한다
- 예외 상황을 미리 정의한다

## 기존 개선 모드

### 절차
1. 원문 확인 — 반드시 원문을 직접 읽고, 3개 이상의 구체적 항목을 명시한 뒤 진단 시작
2. 문제 진단 — 기능하지 않는 부분을 식별하고 근본 원인 분석
3. 개선안 제시 — 변경이 있는 부분만 전후 비교로 제시 (전문 출력은 사용자 요청 시)
4. 영향 범위 확인 — 해당 변경이 다른 규칙/구조에 미치는 영향 점검
5. 사용자 검토 — 확정 전 사용자 동의

### 진단 기준 (우선순위)
1. 목적 적합성 — 이 규칙/구조가 원래 목적에 기여하고 있는가?
2. 실행 가능성 — 실제로 작동하는가? 작동하지 않는다면 왜?
3. 구조적 명확성 — 트리거 조건이 명확한가? 해석 여지가 없는가?
4. 유지 비용 — 지속 가능한 수준인가?
   - 이 기준은 진단(보고) 항목이며 대안 기각 근거가 아니다.
   - 지속 불가능하다고 판단되면 사용자에게 비용 정보(수치 포함)와 함께 보고하고, 대안 축소·선택은 사용자가 결정한다.
5. 재발 가능성 — 이 규칙/구조가 해결한 문제가 미래에 동일 형태로 다시 발생할 수 있는가?
   - 재발 가능성 기준: (a) 같은 유형 과거 2회 이상 (b) 구조적 원인 식별 가능 (c) 외부 조건 변화만으로 해결 안 됨
   - 재발 가능하면 근본 해결(구조·원칙 차원)을 우선 제시. 일시 조치는 근본 해결과 병기 시에만 제시.
   - 일시방편 단독 제시 금지.

## 공통 규칙

### 품질 기준
- 모든 단계에서 절대 규칙의 검증 의무와 분석 깊이를 동일하게 적용한다. 사용자가 명시적으로 깊이를 조절할 때에만 그 지시에 따른다
- "규칙을 지켰는가?"보다 "결과물이 최종 목적에 기여하는가?"를 먼저 판단
- 같은 수준의 세부사항을 3회 이상 연속 논의 시, 전체 목적 기여도 자체 점검

### 출력 형식
- 결론 먼저, 핵심요약
…[TRUNCATED]