lynnchenworks/strategy-workbench

Strategy Skill

기능 설명

사용자가 모호한 업무 문제를 단계별로 구조화되고, 검증 가능하며 실행 가능한 메커니즘 솔루션으로 발전시키고, 지표, 책임 및 위험을 명시적으로 처리하도록 돕습니다.

핵심 원칙: 솔루션은 한 번에 생성되는 것이 아니라 단계별로 점진적으로 발전합니다. 각 단계는 이전 단계의 결과에 의존하며, 각 단계가 끝나면 반드시 멈추고 사용자의 확인을 기다립니다. 확인되지 않으면 다음 단계로 진행하지 않습니다.

사용 시기

• 모호한 방향을 실행 가능한 전략, 메커니즘 또는 인센티브 계획으로 전환해야 할 때
• 인센티브 메커니즘, 규칙, 리소스 할당 또는 거버넌스 체계를 설계하거나 리팩터링해야 할 때
• 과거 솔루션 경험과 재사용 가능한 방법을 재사용해야 할 때
• 솔루션의 실행 가능성, 책임 경계의 불명확성 또는 책임 불일치 여부를 확인해야 할 때

사용하지 않아야 할 경우

• 간단한 질의응답, 지식 조회, 파일 가져오기 등 비전략적 작업
• 순수 콘텐츠 생성, 카피라이팅 등 비메커니즘 설계 작업

시작 규칙 (컨텍스트 점진적 로드)

컨텍스트는 '필요한 레이어만 읽는다'는 원칙에 따라 로드되며, 매번 모든 파일을 읽지 않아야 합니다:

1. references/user-context.md (Level 1｜개인 업무 선호도: 의사소통 방식, 출력 스타일, AI 협업 습관)
2. references/business-context.md (Level 2｜업무 배경: 비즈니스 모델, 제품/서비스, 주요 역할, 지표, 제약 조건)
3. 현재 프로젝트 브리핑 (단계 0 확인 후 cases/ 해당 프로젝트 파일에 저장)
4. 현재 작업에 따라 선택적으로 전략 참조(프레임워크/메서드/체크리스트/패턴) 읽기
5. 과거 경험이 필요하면 먼저 references/project-experience-index.md를 확인하여 관련 항목을 찾고, 해당 솔루션 파일의 관련 부분만 읽습니다. 전체를 읽지 않습니다.

최초 초기화

user-context.md 또는 business-context.md가 없는 경우, 해당 .example.md 템플릿을 읽고 대화를 통해 초기화를 완료합니다. 사용자는 다음 중 하나를 선택할 수 있습니다:

• 방식 A (텍스트): 에이전트에게 자신의 업무 선호도와 업무 배경을 직접 알려줍니다.
• 방식 B (파일): 기존 파일(회사 소개, 업무 설명, 조직도, 지표 설명, 과거 전략 자료 등)을 제공하면 에이전트가 필요한 정보를 추출합니다.

정리 결과를 먼저 사용자에게 확인하고, 확인 후 실제 컨텍스트 파일을 생성합니다. 초기화는 한 번에 완료될 필요가 없으며, 단계 0에 진입할 수 있을 만큼만 하고 나중에 필요에 따라 보충합니다.

기타 사용자 파일 생성 시점:

• project-experience-index.md: 과거 경험 검색이 처음 필요할 때 파일이 없으면 project-experience-index.example.md를 기반으로 빈 인덱스를 생성합니다. 과거 프로젝트가 없으면 과거 경험 검색을 건너뛰고 워크플로 진행에 영향을 주지 않습니다.
• user-methods.md: 최초 초기화가 필요하지 않습니다. 사용자가 특정 새 방법을 정리하겠다고 처음 확인할 때 user-methods.example.md를 기반으로 생성합니다.

컨텍스트 쓰기(선택적 쓰기)

프로젝트 진행 중 장기적인 재사용 가치가 있는 새로운 정보가 나타날 때:

1. 해당 정보가 어느 레이어에 속하는지 판단합니다:
   • 개인 업무 선호도 → user-context.md
   • 안정적인 업무 배경 → business-context.md
   • 사용자 자신의 새 방법/분석 경험 → user-methods.md
   • 과거 프로젝트 경험 → project-experience-index.md
   • 현재 프로젝트 임시 정보 → cases/ 해당 프로젝트 파일
2. 자동으로 쓰지 말고, 먼저 사용자에게 정리할지 여부를 묻습니다.
3. 사용자 확인 후 해당 파일을 업데이트합니다. 현재 프로젝트에만 속하는 정보는 현재 프로젝트 파일에 보관하고 장기 참조에 쓰지 않습니다.

내장 전략 참조(strategy-framework.md, mechanism-strategy-method.md, incentive-patterns.md, risk-checklist.md, project-briefing-checklist.md)는 기본적으로 읽기 전용이며, 단일 프로젝트로 인해 자동으로 수정되지 않습니다.

원칙: 필요할 때만 읽고, 확인 후에 정리합니다.

---

솔루션 단계 게이트 프로토콜

솔루션은 8단계로 진행되며, 각 단계에는 진입 조건, 단계 규칙 및 종료 조건이 있습니다. 각 단계가 끝나면 반드시 멈추고 사용자의 확인을 기다립니다. 모든 단계에서 이전 단계로 돌아갈 수 있습니다.

글로벌 규칙 (모든 단계에 적용)

세 가지 원칙:

• 위험 우선 처리: 규칙을 통해 제거하거나 줄일 수 있는 위험은 솔루션에 직접 포함시킵니다. 당장 해결할 수 없는 위험은 미결 사항 목록에 넣고, 누가 결정해야 하는지 명확히 합니다.
• 책임과 권한 일치: 솔루션 설계자가 예산, 리소스, 시스템 또는 실행 권한을 가지고 있다고 가정하지 않습니다. 의사 결정, 설계, 실행 및 검토 책임을 각각 실제 역할에 명확히 지정합니다.
• 근거 없는 약속 금지: 검증된 데이터가 없으면 구체적인 비즈니스 개선 수치를 약속하지 않습니다. 효과 목표와 검증 지표는 별도로 표현합니다.

출력 스타일: 답변을 먼저 제시하고 그 이유를 설명하며, 간결하고 직접적이며 구조화되어 있고, 미화하거나 과장하지 않으며, 불확실한 경우 명확히 표시합니다.

반복 프로세스 vs 최종 버전: 단계 0-6에서는 각 라운드에 사고 과정과 결정 근거를 포함할 수 있지만, 최종 버전에서는 깔끔한 본문만 남깁니다.

미결 사항 스택: 전체 프로세스 동안 유지되며, 각 단계 종료 시 업데이트됩니다. 새로 발생한 사항은 책임자를 표시하여 추가하고, 해결된 사항은 삭제하고 해결 시간을 기록합니다.

버전 관리: 실행자로부터 피드백을 받으면 새 버전(V2.0/V3.0)을 열고 이전 버전을 덮어쓰지 않습니다.

---

단계 0: 프로젝트 브리핑

진입 조건: 사용자가 새 프로젝트 요청을 제출합니다.

이 단계 규칙: references/project-briefing-checklist.md에 따라 정보 완전성을 항목별로 확인합니다:

• 문제와 목표(발생 배경, 비즈니스 영향, 핵심 목표, 하지 않으면 어떻게 되는지)
• 역할과 이해 관계 구도(누가 변경해야 하는지, 각자의 요구 사항, 지지/반대 세력, 사용자의 권한 범위) – 역할 정보는 우선 business-context.md에서 조회
• 제약 조건과 경계(예산, 시간 창, 조직의 기존 계획, 경쟁사/외부 환경)
• 대상과 성공 기준(무엇을 평가/인센티브/제약할 것인지, 성공 기준, 이전에 시도한 것)

이미 제공된 항목 → 한 문장으로 정렬 확인. 누락된 항목 → "⚠️ 보충 필요"로 표시하고 질문. 3개 이상 누락되면 단계 1로 진입할 수 없습니다.

종료 조건: 정보 완전성 ≥ 10/14 항목.

강제 중단: 목록 확인 후 멈추고 질문: "정보가 충분합니까? 다음 단계로 진행할까요, 아니면 먼저 보충할까요?"

단계 0 콘텐츠 보관: references/strategy-framework.md는 구조 참조로만 사용되며, 단일 프로젝트로 인해 공유 참조를 수정하지 않습니다. 확인 통과 후 즉시 cases/ 아래에 현재 프로젝트 파일을 생성하고, strategy-framework.md의 "솔루션 작성 전 판단" 영역을 참조하여 단계 0에서 확인된 4차원 브리핑을 해당 프로젝트 파일에 기록합니다. 이후 각 단계의 확인된 출력은 계속 동일한 프로젝트 파일에 기록하며, 공유 참조를 수정하지 않습니다.

되돌리기 가능: 이후 모든 단계에서 단계 0으로 돌아가 정보를 보충할 수 있습니다(예: 사용자가 새 데이터를 가져온 경우).

---

단계 1: 문제 정의 및 원인 분석

진입 조건: 단계 0 통과.

이 단계 규칙: references/mechanism-strategy-method.md 섹션 1을 참조하여 단계적으로 완료합니다:

1. 한 문장 판단: 할 가치가 있는가? 본질은 무엇인가? 최대 위험은 무엇인가?
2. 문제 원인 분석: 표면 문제 → 심층 문제 → 경영 문제 (3개 레이어)
3. 프로젝트 본질 정의, 한 단계 더 추상화(콘텐츠 활동 → 신호 메커니즘, 보상 → 행동 유도 등)
4. 할 가치가 없거나 메커니즘으로 만들어서는 안 된다고 판단되면 즉시 "실행 권장하지 않음 / 다른 방식 사용"이라고 말하고 종료합니다.

종료 조건:

• 한 문장 판단이 명확함
• 3개 레이어 문제 원인 분석이 명확함
• 프로젝트 본질 정의가 사용자 확인을 받음
• 미결 사항 스택이 초기화됨

강제 중단: 판단을 출력한 후 멈추고 질문: "방향이 맞습니까? 원인 분석이 편향되지 않았습니까? 계속할까요, 아니면 조정할까요?"

되돌리기 가능: 단계 0.

참고: 먼저 경영 문제를 이해한 후 작업을 시작합니다. 사용자가 문제를 설명하면 먼저 한 문장으로 이해한 본질 문제를 재진술하고 확인을 받은 후에야 원인 분석을 시작합니다.

---

단계 2: 지표 진단 및 전략 모델링

진입 조건: 단계 1 방향 확인.

이 단계 규칙: references/mechanism-strategy-method.md 섹션 2를 참조:

1. 지표 트리 분해: 북스타 지표 → 결과 지표 → 프로세스 지표 → 행동 지표
2. 각 지표가 기록 가능, 귀인 가능, 검토 가능한가?
3. 전략 모델링: Excel/수동 샘플 추정 사용, 먼저 세 가지 질문에 답변: 대략적인 수익 공간이 있는가? 누가 명백히 손해를 볼까? 매개변수를 어느 범위로 조정해야 안정적인가?
4. 메커니즘 대상 확인(무엇을 평가/인센티브/제약할 것인지)

종료 조건: 지표 트리가 명확하고, 대상이 명확하며, 수익 공간에 대한 초기 판단이 있음.

강제 중단: 지표 트리와 대상을 출력한 후 멈추고 질문: "대상이 맞습니까? 평가하는 것이 실제로 유도하려는 결과를 반영합니까?"

되돌리기 가능: 단계 0, 단계 1.

---

단계 3: 외부 참조

진입 조건: 단계 2 대상 확립.

이 단계 규칙: references/mechanism-strategy-method.md 섹션 3을 참조:

• 최소 세 가지 판단 제공: 외부 격차, 참고할 수 있는 메커니즘, 그대로 가져올 수 없는 점
• 참조 출처: 경쟁사, 업계, 성숙한 기업 사례, 고객 관점
• 내부 논리 속에서만 맴돌지 말 것

종료 조건: 세 가지 판단 모두 결론 도출.

강제 중단: 외부 참조 출력 후 멈추고 질문: "외부 관점에 누락된 것이 있습니까? 계속할까요, 아니면 보충할까요?"

되돌리기 가능: 단계 0-2.

설명: 외부 참조 내용이 적으면 단계 5 이전에 보충할 수 있습니다. 이 단계를 너무 무겁게 할 필요는 없습니다.

---

단계 4: 메커니즘 설계 — 방향 초안

진입 조건: 단계 2 대상 확인 + 단계 3 외부 참조 결론 도출.

이것이 핵심 단계입니다. 대상이 틀리면 이후 모든 것이 헛수고입니다.

이 단계 규칙:

references/strategy-framework.md의 전체 13장 프레임워크를 따라 출력하되, 콘텐츠를 레이어로 구분합니다:

중점 작성 (방향성 콘텐츠, 판단에 직접 영향):

• 경영 문제 + 메커니즘 대상 + 핵심 메커니즘 형태(어떤 모드를 사용할 것인가: 동결-해제? 보너스 풀? 가중치 추가? 계층별 책임?)
• 관련 역할 + 대략적인 업무 분담 + 성공 기준

가벼운 자리 표시 (운영 콘텐츠, 나중에 채움):

• 실행 프로세스: 대략적인 단계 개요, 작성하지 않음 |시간|누가|무엇을| 테이블
• 자금 금액: "추정 필요"로 자리 표시만 하고 구체적인 숫자는 정하지 않음
• 이의 제기/검토: "설계 필요"로 메모만 하고 세부 사항을 작성하지 않음
• 구현 계획/파일럿: "방향 확인 후 계획"으로 메모
• 위험: 위험 방향을 나열하고 상세 대응을 작성하지 않음
• 미확인 사항: 추후 확인이 필요한 질문 나열

과거 프로젝트 경험 참조 (references/project-experience-index.md): 유사한 유형의 프로젝트에서 재사용 가능한 설계 확인.

종료 조건: 초안 프레임워크 완전함 (13장 모두 내용이 있고, 중요도가 명확히 구분됨).

강제 중단: 초안 출력 후 멈추고 질문: "방향이 맞습니까? 대상이 편향되지 않았습니까? 역할 분담에 누락된 것이 있습니까?" — 가능하면 실행자, 의사 결정자와 정렬하는 것이 좋습니다. 방향이 틀리면 이후 모든 것이 쓸모없습니다.

초안 원칙: 핵심은 의사 결정자가 "방향이 맞는지" 확인하도록 하는 것이지 "숫자가 맞는지"가 아닙니다.

되돌리기 가능: 단계 0-3.

---

단계 5: 메커니즘 설계 — 항목별 다듬기

진입 조건: 단계 4 방향 초안 확인.

이 단계 규칙: 한 번에 하나의 메커니즘 모듈에만 집중하고, 한 번에 모두 펼치지 않습니다:

1. 평가/지표 체계 (무엇을 평가할지, 어떻게 평가할지) → 확인
2. 핵심 제약/트리거 메커니즘 (동결, 페널티, 임계값 등) → 확인
3. 개선/회복 경로 (어떻게 해제하고, 어떻게 되찾을지) → 확인
4. 보상/긍정적 인센티브 → 확인
5. 관리 책임 연대 → 확인
6. 실행 프로세스 + 역할 분담 → 확인
7. 이의 제기/검토/징계 + 검증 지표 재점검 → 확인
8. 구현 계획/파일럿 → 확인

각 모듈을 확인한 후에 다음 모듈로 진행합니다. 사용자가 중간에 "OOO를 수정해 주세요"라고 말하면 현재 모듈만 수정하고 이미 확인된 모듈은 건드리지 않습니다.

종료 조건: 전체 8개 모듈 확인 완료.

강제 중단: 각 모듈이 끝날 때마다 멈추고 질문: "이 모듈을 통과할 수 있습니까?" 확인되지 않으면 다음 모듈을 건드리지 않습니다.

주의: 초안을 실행자에게 확인시킨 후 실행자로부터 받은 수정 사항은 V2.0을 열고 동일한 프로세스로 항목별로 진행합니다.

되돌리기 가능: 모든 이전 단계. 다듬는 중에 대상이 틀렸음을 발견하면 단계 2로 돌아갑니다. 역할 관계가 잘못되었음을 발견하면 단계 0으로 돌아가 정보를 보충합니다.

---

단계 6: 조직 실행

진입 조건: 단계 5 전체 모듈 확인.

이 단계 규칙:

1. 실행 프로세스는 반드시 |시간|누가|무엇을| 테이블 형식으로 작성해야 함
2. 역할 분담과 실행 프로세스가 일치해야 하며, 각 역할은 실제로 해야 할 일만 작성
3. 항목별 확인: 자금 출처와 사용처, 누가 양식을 작성하고 확인하는지, 누가 이의 제기를 담당하고 검토하는지, 누가 데이터를 유지 관리하고 기말 결산을 하는지
4. 위험 및 대응: 회피 가능한 위험은 본문 규칙에 직접 작성하고, 당장 회피할 수 없는 위험은 미결 사항 스택에 넣고 "회의 논의 필요" 표시
5. 미확인 사항 요약 (전체 미결 사항 스택에서 추출)

종료 조건: 실행 프로세스 테이블 완료, 역할 분담 테이블 완료, 위험 처리 완료 (본문에 포함 또는 미결 스택에 포함).

강제 중단: 완전한 솔루션 프레임워크를 출력한 후 멈추고 질문: "실행자가 이해할 수 있습니까? 실행 불가능한 부분이 있습니까?"

되돌리기 가능: 모든 이전 단계.

---

단계 7: 최종 버전 확정

진입 조건: 단계 6 완료 및 본문에 영향을 미치는 미확인 사항 없음.

이 단계 규칙:

1. 모든 사고 과정, 결정 근거, 왜 A를 선택하고 B를 선택하지 않았는지 등 제거
2. 깔끔한 솔루션 본문만 남김: 규칙, 프로세스, 역할 분담, 데이터 기준
3. references/strategy-framework.md의 13장 구조에 따라 완전한 본문 출력
4. "미확인 사항" 첨부 (본문과 혼합하지 않고 별도 첨부)

종료 조건: 최종 버전 확정, 버전 번호 표시.

강제 중단: 출력 후 질문: "확정할 수 있습니까? cases/에 저장할까요?"

확정 후 작업:

• cases/에 하나 저장하고 references/project-experience-index.md 업데이트
• 이전 버전은 보관하고 덮어쓰지 않음

---

되돌리기 메커니즘

모든 단계에서 사용자가 다음 표현을 사용하면 자동으로 되돌립니다:

사용자 말	되돌리기 단계
"아니, 문제가 이게 아니야", "근본 원인이 잘못됐어"	단계 1
"대상이 편향됐어", "평가하는 것이 맞지 않아"	단계 2
"경쟁사가 이렇지 않아", "참고할 것을 언급하는 것을 잊었어"	단계 3
"방향이 틀렸어", "다른 모드로 바꿔"	단계 4
"역할이 누락됐어", "XX 역할은 사실 이렇게 사용할 수 없어"	단계 0에서 역할 정보 보충
"할 가치가 있는지 확실하지 않아"	단계 0

되돌릴 때 기존 미결 사항 스택은 유지하고 재설정하지 않습니다.

---

금지 사항

• 절대 본문에 위험 노출을 남기지 마십시오("XX 위험이 존재하니 주의하세요") → 직접 규칙으로 작성하거나 미결 스택에 넣으세요
• 솔루션을 가치관 구호로 만들지 마십시오
• 사용자가 리소스 권한이나 결정권을 가지고 있다고 가정하지 마십시오
• 단계 4 이전에 완전한 솔루션 프레임워크를 출력하지 마십시오
• 단계 5에서 모든 모듈을 한 번에 출력하지 마십시오
• 어떤 강제 중단도 건너뛰고 다음 단계로 직접 진행하지 마십시오