@bhoon716/skill-forge 1.0.0

package/skills/ultra-grill-me/references/research-question-grill.ko.md

@@ -0,0 +1,87 @@
+# 연구 질문 검증
+
+## 이 reference를 사용할 때
+
+- 연구 질문이 검증 가능하고 좁혀져 있는지 확인해달라는 요청
+- 실험 설계를 질문으로 검증해달라는 요청
+- 조사 방향이 너무 넓은지 grill 해달라는 요청
+- 분석 계획을 검토해달라는 요청
+- 검증 설계가 적절한지 확인해달라는 요청
+
+## 이 reference를 사용하지 않을 때
+
+- 연구 방법론을 설명해달라는 요청
+- 논문을 요약해달라는 요청
+- 데이터 분석을 바로 해달라는 요청
+- 제품 아이디어를 검증하는 경우 → `product-idea-grill.md` 사용
+
+## 질문 우선순위
+
+1. 연구 질문 — 답하려는 질문이 정확히 뭔가?
+2. 검증 가능성 — 이 질문에 데이터로 답할 수 있는가?
+3. 변수와 범위 — 독립변수, 종속변수, 통제변수가 정의되어 있는가?
+4. 데이터 필요 조건 — 어떤 데이터가 필요한가? 확보 가능한가?
+5. 측정 방법 — 어떻게 측정하는가?
+6. 편향 가능성 — selection bias, confirmation bias 등은 없는가?
+7. 비교 기준 — 무엇과 비교하는가? baseline이 있는가?
+8. 성공 / 실패 기준 — 어떤 결과가 나오면 성공이고 실패인가?
+9. 윤리적 리스크 — 윤리적 문제가 있는가?
+10. 가장 작은 검증 설계 — 최소 비용으로 이 가설을 검증할 수 있는 방법은?
+
+## 강한 질문 패턴
+
+- "이 연구 질문에 '예/아니오'로 답할 수 있나요? 아니면 더 좁혀야 하나요?"
+- "이 질문에 답하려면 어떤 데이터가 필요하고, 그 데이터를 확보할 수 있나요?"
+- "이 실험에서 가장 큰 bias 가능성은 뭔가요?"
+- "이 결과가 나오면 '가설이 틀렸다'고 판단할 수 있나요?"
+- "이 실험을 1주일 안에, 예산 없이 할 수 있는 축소 버전으로 만들면 어떻게 되나요?"
+
+## 약한 질문 패턴
+
+- "이 연구가 의미 있나요?"
+- "데이터가 충분한가요?"
+- "결과가 좋을까요?"
+
+## 추천 옵션 구성 규칙
+
+- **연구 질문 범위가 너무 넓을 때**: `(추천) 인과관계/상관관계를 증명하기 위해 가장 좁게 슬라이싱된 구체적인 단일 하위 가설` 옵션을 추천하고, 전반적인 경향 분석 대안들로 선택지 구성
+- **비교 기준(Baseline)이 모호할 때**: `(추천) 변경사항이 전혀 투입되지 않은 통제된 현재 상태(No Intervention/Control Group)` 대안을 대조군(Baseline) 옵션으로 추천하고, 과거 기록 비교/외부 벤치마크 대안들로 선택지 구성
+- **성공/실패 판정 기준이 없을 때**: `(추천) 통계적으로 유의미한 수치 변동 폭(예: p-value < 0.05 또는 효과 크기 X% 이상 향상)` 지표 옵션을 추천하고, 정성적 호평/자연스러운 유입 증가 대안들로 선택지 구성
+
+## 모호한 답변 처리
+
+- "전반적으로 알고 싶어" → "가장 먼저 답해야 하는 하위 질문 하나만 고르면 뭔가요?"로 좁히기
+- "데이터는 있을 거야" → "구체적으로 어떤 데이터를 어디서 가져올 건가요? 확보 비용이나 시간은?"으로 구체화
+- "결과가 좋으면 성공이지" → "'좋다'를 숫자로 정의하면 어떤 지표가 어떤 값 이상이면 성공인가요?"로 구체화
+
+## 케이스별 종료 조건
+
+공통 종료 조건에 더해 다음이 충족되어야 한다.
+
+- 연구 질문이 검증 가능한 형태로 좁혀졌다
+- 필요한 데이터와 확보 방법이 파악되었다
+- 측정 방법이 정해졌다
+- 주요 bias가 최소 하나 검토되었다
+- 성공/실패 기준이 정의되었다
+- 가장 작은 검증 설계가 나왔다
+
+## 최종 정리 필수 항목
+
+공통 최종 정리 형식에 다음을 추가한다.
+
+- 좁혀진 연구 질문
+- 검증 가능한 가설
+- 필요한 데이터와 확보 방법
+- 주요 bias / confounder
+- 측정 기준
+- 성공 / 실패 기준
+- 다음 실험 또는 조사 단계
+
+## 실패 모드
+
+- 연구 질문을 좁히지 않고 너무 넓게 두는 경우
+- 검증 가능성을 확인하지 않는 경우
+- 데이터 확보 가능성을 무시하는 경우
+- bias를 한 번도 검토하지 않는 경우
+- 성공/실패 기준 없이 "결과를 보고 판단하겠다"로 넘어가는 경우
+- 윤리적 리스크를 무시하는 경우

package/skills/ultra-grill-me/references/research-question-grill.md

@@ -0,0 +1,68 @@
+# Research Question Verification
+
+## When to use this reference
+
+- Evaluating academic, industry, or data analysis research hypotheses
+- Verifying metric structures, target baselines, or control variables
+- Checking experimental design, analysis logic, or data validation plans
+- Reviewing survey questions, study targets, or user research designs
+
+## When not to use this reference
+
+- Reviewing marketing copy or positioning outlines → Use `writing-direction-grill.md`
+- Verifying code models or database schemas → Use `technical-design-grill.md`
+- Generating bulk reference citations or editing text style directly
+
+## Question Priority
+
+1. **Core Hypothesis** — What is the specific question or relation we are testing?
+2. **Dependent / Independent Variables** — What are we measuring, and what are we changing?
+3. **Control Variables** — What factors must remain constant to isolate the relation?
+4. **Baseline (Control Group)** — What is the benchmark state we compare against?
+5. **Success / Failure Metric** — What specific value changes prove or disprove the hypothesis?
+6. **Data Source & Reliability** — Where does the data come from? How clean is it?
+7. **Alternative Explanations** — What other factors could cause the observed changes?
+8. **Actionable Next Action** — What is the smallest data sample we can test first?
+
+## Strong Question Patterns
+
+- "What is your main hypothesis? (e.g., 'If we change X, then metric Y will increase by Z%')"
+- "What is the baseline? How are you currently measuring this before any changes?"
+- "What other variables could influence Y during this test? How will you keep them constant?"
+- "What result would prove your hypothesis wrong? We need a clear failure threshold."
+
+## Weak Question Patterns
+
+- "Is this research interesting?"
+- "Do you think the data is clean?"
+- "Will we get good results?"
+
+## Recommended Option Rules
+
+- **Hypothesis Ambiguity**: Recommend `(Recommended) A narrow, testable correlation/causality statement focusing on a single change` and include general trends to build the option set.
+- **Baseline Ambiguity**: Recommend `(Recommended) A controlled status quo state with no modifications (Control Group)` and include historical benchmarks to build the option set.
+- **Metric Threshold Ambiguity**: Recommend `(Recommended) Statistically significant change (e.g., p-value < 0.05 or effect size > X% change)` and include general user feedback alternatives to build the option set.
+
+## Handling Vague Answers
+
+- "We want to research everything" → Narrow down: "What is the single most critical sub-hypothesis that must be proven first?"
+- "We'll check the trend" → Quantify: "Let's set a concrete target, such as 'p-value < 0.05'. Shall we use this as our threshold?"
+- "We don't need a control group" → Force baseline: "Without a control group, how will you prove that changes in Y weren't caused by seasonal trends?"
+
+## Stopping Conditions
+
+In addition to common stopping conditions, ensure:
+- The core research hypothesis is testable.
+- Independent and dependent variables are identified.
+- A baseline (control group) benchmark is established.
+- Numerical success/failure thresholds are defined.
+- Primary alternative explanations have been mapped.
+
+## Final Synthesis Required Items
+
+Add the following to the common final synthesis format:
+- Core Hypothesis & Variables
+- Baseline (Control Group) Definition
+- Experimental Verification Milestones
+- Primary Target KPI & Thresholds
+- High-level Risks & Confounding Factors

package/skills/ultra-grill-me/references/skill-design-grill.ko.md

@@ -0,0 +1,88 @@
+# Skill 설계 검증
+
+## 이 reference를 사용할 때
+
+- Agent Skill 설계를 검증해달라는 요청
+- SKILL.md 구조를 만들기 전에 질문으로 검증해달라는 요청
+- trigger 규칙이 맞는지 확인해달라는 요청
+- reference 구조가 적절한지 grill 해달라는 요청
+- eval 설계를 검토해달라는 요청
+- Skill의 scope가 적절한지 확인해달라는 요청
+
+## 이 reference를 사용하지 않을 때
+
+- Skill이 뭔지 설명해달라는 요청
+- SKILL.md를 바로 작성해달라는 요청
+- 프롬프트를 교정해달라는 요청
+- 일반적인 프롬프트 엔지니어링 조언을 구하는 요청
+
+## 질문 우선순위
+
+1. Skill로 만들 만한 반복 작업인지
+2. trigger 조건 — 어떤 요청에서 켜져야 하는지
+3. non-trigger 조건 — 어떤 요청에서 켜지면 안 되는지
+4. workflow 관찰 가능성 — 각 단계가 테스트 가능한지
+5. output format — 결과물의 구조가 정해져 있는지
+6. reference selection — 어떤 reference를 언제 읽을지 명시되어 있는지
+7. stopping conditions — 언제 멈출지 기준이 있는지
+8. gotchas — 자주 실패하는 지점이 정리되어 있는지
+9. eval case — 테스트 케이스를 만들 수 있는지
+10. release gate — 배포 기준이 있는지
+
+## 강한 질문 패턴
+
+- "이 Skill이 반복적으로 처리하는 작업이 정확히 뭔가요? 한 문장으로 말해주세요."
+- "이 Skill이 켜지면 안 되는 요청을 3개만 들어주세요."
+- "workflow의 각 단계를 외부에서 관찰할 수 있나요? 예를 들어 '질문을 하나만 했는지' 같은 건 확인 가능한가요?"
+- "이 Skill의 output format 없이도 결과물이 일관될까요?"
+- "description이 너무 넓어서 다른 Skill과 trigger가 겹치지 않나요?"
+
+## 약한 질문 패턴
+
+- "이 Skill 괜찮아 보이나요?"
+- "뭔가 빠진 거 없나요?"
+- "더 좋게 만들 수 있나요?"
+
+## 추천 옵션 구성 규칙
+
+- **Skill scope가 불분명할 때**: `(추천) 하나의 좁고 반복 가능한 핵심 워크플로에 집중` 옵션을 추천하고, 넓은 기능 범위를 가진 대안들을 포함하여 선택지 구성
+- **trigger 조건이 모호할 때**: `(추천) Use when [명확한 진입상황]. Do not use for [제외상황].` 템플릿 옵션을 추천하고, 광범위한 자연어 trigger 설정 대안들로 선택지 구성
+- **output format이 없을 때**: `(추천) 최소 3개 필수 섹션 (요약, 핵심 발견, 다음 행동)` 구조 옵션을 추천하고, 자유 형식 출력 대안들로 선택지 구성
+
+
+## 모호한 답변 처리
+
+- "아직 정확히 모르겠어" → "그럼 이 Skill이 처리하는 작업을 '사용자의 X를 Y 방식으로 검증하는 것'으로 임시 정의할까요?"로 기본값 제안
+- "여러 가지를 다 하고 싶어" → "하나의 Skill이 여러 job을 하면 trigger가 겹치고 테스트가 어려워집니다. 가장 자주 반복되는 하나만 먼저 고르면 어떤 건가요?"로 범위 좁히기
+- "나중에 정할게" → assumption으로 기록하고 다음 질문으로 넘어간다
+
+## 케이스별 종료 조건
+
+공통 종료 조건에 더해 다음이 충족되어야 한다.
+
+- Skill의 반복 작업이 한 문장으로 정리되었다
+- trigger와 non-trigger가 각각 최소 3개 예시로 구분 가능하다
+- workflow 단계가 관찰 가능하다
+- output format이 있다
+- 최소 1개의 eval case를 만들 수 있다
+- 가장 먼저 작성할 파일이 정해졌다
+
+## 최종 정리 필수 항목
+
+공통 최종 정리 형식에 다음을 추가한다.
+
+- 확정된 Skill 범위
+- trigger / non-trigger 경계
+- workflow
+- reference 구조
+- eval 설계
+- 가장 먼저 작성할 파일
+
+## 실패 모드
+
+- Skill scope를 너무 넓게 잡아서 만능 프롬프트가 되는 경우
+- trigger와 non-trigger 경계를 정하지 않은 채 SKILL.md를 작성하기 시작하는 경우
+- workflow 단계가 테스트 불가능한 경우
+- description이 다른 Skill과 겹치는 경우
+- reference를 분리했지만 언제 읽을지 명시하지 않은 경우
+- eval 없이 완성이라고 판단하는 경우

package/skills/ultra-grill-me/references/skill-design-grill.md

@@ -0,0 +1,70 @@
+# Agent Skill Design Verification
+
+## When to use this reference
+
+- Stress-testing custom Agent Skill designs before draft generation
+- Verifying trigger/non-trigger conditions and workflow steps in `SKILL.md`
+- Critiquing skill folder structures, templates, or testing designs
+- Evaluating skill scope boundaries or gotchas configurations
+
+## When not to use this reference
+
+- Reviewing standard application logic or code architecture → Use `technical-design-grill.md`
+- Verifying business viability or pricing models → Use `business-strategy-grill.md`
+- Generating raw markdown templates directly
+
+## Question Priority
+
+1. **Core Repeatable Job** — Is this a specific, repeatable task suitable for a skill?
+2. **Trigger Condition** — Exactly what query forms should turn this skill on?
+3. **Non-trigger Condition** — Exactly what queries must NOT activate this skill?
+4. **Observable Workflow** — Are the internal execution steps testable from the outside?
+5. **Output Format** — Is the structure of the final output consistent and defined?
+6. **Reference Strategy** — Are reference files mapped to be loaded only when needed?
+7. **Stopping Conditions** — Is it clear when the skill execution loop terminates?
+8. **Gotchas** — Are common AI failure modes for this task explicitly documented?
+9. **Test Cases (Evals)** — Can we design concrete pass/fail checks for this skill?
+10. **Release Gate** — What are the performance and precision limits for deployment?
+
+## Strong Question Patterns
+
+- "What is the single, repeatable job this skill performs? Please define it in one sentence."
+- "What are three examples of user queries that look similar but must NOT trigger this skill?"
+- "Are the workflow steps observable? How do we verify that the agent actually executed Step 2?"
+- "Is your description narrow enough to prevent conflicts with other system skills?"
+
+## Weak Question Patterns
+
+- "Does this skill look okay?"
+- "Is there anything missing?"
+- "How do we make it better?"
+
+## Recommended Option Rules
+
+- **Scope Ambiguity**: Recommend `(Recommended) Target exactly one narrow, repeatable, high-value workflow` and include multi-tasking options to build the option set.
+- **Trigger Ambiguity**: Recommend `(Recommended) Use when [clear trigger situation]. Do not use for [similar exclusion situation].` and include loose natural language matching to build the option set.
+- **Output Format Ambiguity**: Recommend `(Recommended) Require at least 3 fixed sections (Summary, Key Findings, Next Steps)` and include free-form output alternatives to build the option set.
+
+## Handling Vague Answers
+
+- "I want the skill to handle everything" → Push for focus: "If a single skill does multiple jobs, it leads to routing conflicts. Which single job is repeated most frequently?"
+- "The trigger is just when they talk about planning" → Force exclusion: "If the user asks 'What is planning?', should this skill turn on? Let's add that to non-triggers."
+- "We don't need a strict output format" → Enforce consistency: "Shall we set a temporary output constraint of 'having a final Actionable Next Step section' for quality checks?"
+
+## Stopping Conditions
+
+In addition to common stopping conditions, ensure:
+- The core repeatable workflow is clearly defined.
+- Trigger/Non-trigger examples are explicitly mapped.
+- Workflow steps are distinct and observable.
+- A fixed output structure is defined.
+- Primary gotchas (failure modes) are documented.
+
+## Final Synthesis Required Items
+
+Add the following to the common final synthesis format:
+- Core Repeatable Job Definition
+- Trigger & Non-Trigger Scenarios
+- Step-by-Step Observable Workflow
+- Fixed Output Schema Specs
+- Task-Specific Gotchas List

package/skills/ultra-grill-me/references/technical-design-grill.ko.md

@@ -0,0 +1,88 @@
+# 기술 설계 검증
+
+## 이 reference를 사용할 때
+
+- 구현 방식이 맞는지 검증해달라는 요청
+- API 설계를 질문으로 검토해달라는 요청
+- 데이터 모델이 괜찮은지 grill 해달라는 요청
+- 시스템 설계의 빈틈을 찾아달라는 요청
+- 기술 tradeoff를 검증해달라는 요청
+
+## 이 reference를 사용하지 않을 때
+
+- 아키텍처 수준의 큰 결정 → `architecture-decision-grill.md` 사용
+- 구현 순서와 일정 리스크 → `implementation-plan-grill.md` 사용
+- 기술 개념을 설명해달라는 요청
+- 코드를 바로 작성해달라는 요청
+
+## 질문 우선순위
+
+1. 기능 요구사항 — 이 설계가 충족해야 하는 기능은 정확히 뭔가?
+2. 비기능 요구사항 — 성능, 가용성, 확장성, 보안 기준이 있는가?
+3. 현재 시스템 제약 — 기존 시스템과의 호환성, 기술 스택 제약이 있는가?
+4. 데이터 흐름 — 데이터가 어디서 생성되고, 어디를 거쳐, 어디에 저장되는가?
+5. API 경계 — 내부/외부 인터페이스가 명확한가?
+6. 성능 병목 — 예상 부하에서 어디가 먼저 터지는가?
+7. 장애 모드 — 이 설계가 실패하면 어떤 일이 벌어지는가?
+8. 보안 / 권한 — 인증, 인가, 데이터 보호가 충분한가?
+9. 마이그레이션 — 기존 데이터나 시스템에서 어떻게 전환하는가?
+10. 테스트 전략 — 이 설계를 어떻게 테스트하는가?
+
+## 강한 질문 패턴
+
+- "이 API가 초당 1000건 요청을 받으면 어디가 먼저 병목이 되나요?"
+- "이 데이터 모델에서 스키마를 변경해야 할 때 마이그레이션 비용이 얼마나 되나요?"
+- "이 서비스가 죽으면 사용자에게 어떤 일이 벌어지나요?"
+- "이 설계에서 보안 관련으로 가장 걱정되는 부분은 뭔가요?"
+- "이 설계를 자동화된 테스트로 검증할 수 있나요?"
+
+## 약한 질문 패턴
+
+- "이 설계 괜찮나요?"
+- "뭔가 빠진 거 없나요?"
+- "더 나은 방법이 있나요?"
+
+## 추천 옵션 구성 규칙
+
+- **비기능 요구사항이 없을 때**: `(추천) p99 latency < 500ms, 가용성 99.9%, 무상태(Stateless) 아키텍처로 수평 확장 가능` 옵션을 추천하고, 비실시간/느슨한 가용성 대안들로 선택지 구성
+- **테스트 전략이 없을 때**: `(추천) 핵심 유스케이스 단위 테스트 + 모의(Mock) 통합 테스트 + 핵심 경로 E2E 테스트` 옵션을 추천하고, 수동 QA 전담 대안들로 선택지 구성
+- **장장애 모드(Failure Mode) 검토가 안 됐을 때**: `(추천) 가장 의존성이 높은 외부 핵심 API/서비스가 15분간 마비되는 상황` 상황 대안을 추천하고, 대안 장애 시나리오들로 선택지 구성
+
+## 모호한 답변 처리
+
+- "성능은 나중에 볼게" → "그럼 임시 기준으로 'p99 latency < 500ms, 동시 사용자 100명'을 두고 진행할까요?"로 기본값 제안
+- "보안은 일반적인 수준이면 돼" → "인증은 OAuth 2.0, 데이터 암호화는 AES-256 at rest + TLS in transit 정도면 될까요?"로 구체화
+- "잘 모르겠어" → 가장 보수적인 옵션을 기본값으로 제안
+
+## 케이스별 종료 조건
+
+공통 종료 조건에 더해 다음이 충족되어야 한다.
+
+- 기능 요구사항이 목록화되었다
+- 비기능 요구사항이 최소 하나 정의되었다
+- 주요 장애 모드가 최소 하나 검토되었다
+- 보안/권한 관련 리스크가 확인되었다
+- 테스트 전략이 최소한 방향이 잡혔다
+- 가장 위험한 기술 결정이 식별되었다
+
+## 최종 정리 필수 항목
+
+공통 최종 정리 형식에 다음을 추가한다.
+
+- 확정된 기술 방향
+- 남은 기술 리스크
+- 기능 요구사항 / 비기능 요구사항
+- 주요 tradeoff
+- 장애 모드
+- 검증해야 할 위험 지점
+- 테스트 전략
+- 구현 전 체크리스트
+
+## 실패 모드
+
+- 비기능 요구사항 없이 기능만 논의하는 경우
+- 장애 모드를 한 번도 검토하지 않는 경우
+- 보안을 "나중에"로 미루는 경우
+- 마이그레이션 비용을 무시하는 경우
+- 테스트 불가능한 설계를 그대로 두는 경우
+- 기존 시스템 제약을 확인하지 않는 경우

package/skills/ultra-grill-me/references/technical-design-grill.md

@@ -0,0 +1,66 @@
+# Technical Design Verification
+
+## When to use this reference
+
+- Verifying API design, data models, or system workflows
+- Evaluating concrete code implementation plans
+- Highlighting system bottlenecks, data consistency, or latency tradeoffs
+- Checking developer-level integration plans before code generation
+
+## When not to use this reference
+
+- High-level platform architecture decisions (e.g., monolith vs. MSA) → Use `architecture-decision-grill.md`
+- Product roadmap or business logic critique → Use `product-idea-grill.md`
+- Generating raw boilerplates directly
+
+## Question Priority
+
+1. **Non-functional Requirements** — What are the performance, scale, and latency targets?
+2. **Data Model & Schema** — Are table relations, indexing, and data life cycles defined?
+3. **API Contracts** — Are input/output schemas, error codes, and validation rules explicit?
+4. **Consistency & Concurrency** — How do we handle race conditions, transaction rollbacks, or sync offsets?
+5. **Security & Auth** — Are encryption, RBAC, and input sanitization handled?
+6. **Error Handling & Fault Tolerance** — What happens when internal/external dependencies fail?
+7. **Test Strategy** — How do we verify this code behaves correctly at scale?
+8. **Observability** — How do we trace, log, and alert on errors?
+
+## Strong Question Patterns
+
+- "What is your target scale? (e.g., 500 TPS write, sub-100ms read latency) How does this schema support it?"
+- "What happens if the database connection drops halfway through this multi-step transaction? How do you ensure rollback?"
+- "If two users request the same resource at the same millisecond, how does your implementation prevent duplicate writes?"
+- "How do you verify this integration in tests without relying on live production APIs?"
+
+## Weak Question Patterns
+
+- "Is this database choice fast enough?"
+- "Are we going to write unit tests?"
+- "Is the code clean?"
+
+## Recommended Option Rules
+
+- **NFR Ambiguity**: Recommend `(Recommended) Target p99 latency < 500ms, SLA 99.9% availability, stateless scaling` and include loose hobby-scale alternatives to build the option set.
+- **Test Strategy Ambiguity**: Recommend `(Recommended) 80% coverage unit tests for core logic + Mock integration tests` and include manual-only alternatives to build the option set.
+- **Fault Tolerance Ambiguity**: Recommend `(Recommended) Circuit breaker with local fallback cache when dependency fails` and include crash-on-error alternatives to build the option set.
+
+## Handling Vague Answers
+
+- "Performance doesn't matter yet" → Propose safety defaults: "Let's set a baseline target of p99 latency < 500ms at 100 concurrent connections. Shall we use this as our constraint?"
+- "We'll test it later" → Emphasize unit tests: "Shall we define that any new API route requires at least 3 automated unit tests covering validation failures before merging?"
+- "It won't fail" → Force failure check: "If the authentication service fails, should the API return a cached token fallback, or drop the request immediately with a 503 error?"
+
+## Stopping Conditions
+
+In addition to common stopping conditions, ensure:
+- Performance targets (latency, throughput) are established.
+- Core database schema and relations are defined.
+- Error codes and validation limits are listed.
+- Fail-safe strategies for external dependency drops are outlined.
+
+## Final Synthesis Required Items
+
+Add the following to the common final synthesis format:
+- Key Data Model Schemas / Fields
+- API Spec Draft (Endpoint, Payload, Success/Error codes)
+- Error Handling & Fallback Protocols
+- Automated Test Requirements

package/skills/ultra-grill-me/references/writing-direction-grill.ko.md

@@ -0,0 +1,88 @@
+# 글쓰기 방향 검증
+
+## 이 reference를 사용할 때
+
+- 글 방향이 맞는지 질문으로 검증해달라는 요청
+- 발표 메시지의 빈틈을 찾아달라는 요청
+- 포지셔닝을 grill 해달라는 요청
+- 콘텐츠 전략을 검증해달라는 요청
+- 내러티브가 설득력 있는지 확인해달라는 요청
+
+## 이 reference를 사용하지 않을 때
+
+- 글을 바로 작성해달라는 요청
+- 문장을 교정해달라는 요청
+- 글쓰기 팁을 설명해달라는 요청
+- 사업 전략을 검증하는 경우 → `business-strategy-grill.md` 사용
+
+## 질문 우선순위
+
+1. 독자 — 이 글의 1차 독자는 누구인가?
+2. 독자가 이미 믿는 것 — 독자가 현재 가지고 있는 생각은?
+3. 바꾸고 싶은 생각 — 이 글을 읽은 뒤 독자의 생각이 어떻게 바뀌어야 하는가?
+4. 핵심 주장 — 한 문장으로 말하면 뭔가?
+5. 근거 — 왜 그 주장이 맞는가? 증거는?
+6. 반론 — 가장 강력한 반론은 뭔가?
+7. 톤 — 어떤 톤으로 쓰는가?
+8. 구조 — 어떤 순서로 전개하는가?
+9. 기억에 남을 한 문장 — 독자가 딱 하나만 기억한다면?
+10. 읽은 뒤 행동 — 독자가 읽은 뒤 뭘 해야 하는가?
+
+## 강한 질문 패턴
+
+- "이 글을 읽는 사람이 지금 어떤 생각을 가지고 있고, 읽은 뒤에 어떤 생각으로 바뀌어야 하나요?"
+- "이 글의 핵심 주장을 한 문장으로 말하면 뭔가요?"
+- "이 주장에 대한 가장 강한 반론은 뭔가요? 그 반론에 어떻게 답할 건가요?"
+- "독자가 이 글에서 딱 하나만 기억한다면 그게 뭐였으면 하나요?"
+- "이 글을 읽은 사람이 다음에 뭘 해야 하나요?"
+
+## 약한 질문 패턴
+
+- "이 글 괜찮나요?"
+- "더 설득력 있게 할 수 있나요?"
+- "구조가 맞나요?"
+
+## 추천 옵션 구성 규칙
+
+- **1차 독자가 불분명할 때**: `(추천) 이 분야/주제에 깊은 관심은 있으나 실무 전문 지식(배경 맥락)은 부족한 비전문가층` 옵션을 추천하고, 극도의 주니어/극도의 시니어 타겟 대안들로 선택지 구성
+- **어조와 톤(Tone)이 미정일 때**: `(추천) 객관적 지표와 팩트를 중심으로 설득하되 지나친 전문용어는 배제한 친절한 전문가 톤` 옵션을 추천하고, 격식 없는 일상 톤/과하게 권위적인 톤 대안들로 선택지 구성
+- **글의 논리 전개 구조가 미정일 때**: `(추천) 문제 제기 → 핵심 솔루션 제안(주장) → 객관적 증거/근거 제공 → 예상되는 반론 및 답변 → 독자 실행 행동(CTA) 촉구` 5단계 구조 옵션을 추천하고, 연대기적 설명/일방적 정보 나열 대안들로 선택지 구성
+
+## 모호한 답변 처리
+
+- "다양한 사람들이 읽을 거야" → "가장 중요한 독자 한 그룹만 고르면 누구인가요?"로 좁히기
+- "설득하고 싶어" → "독자가 지금 어떤 생각을 하고 있고, 읽은 뒤에 어떤 생각으로 바뀌어야 하나요?"로 구체화
+- "적당한 톤이면 돼" → "'전문적이지만 접근 가능한 톤'을 기본값으로 둘까요?"로 기본값 제안
+
+## 케이스별 종료 조건
+
+공통 종료 조건에 더해 다음이 충족되어야 한다.
+
+- 1차 독자가 정의되었다
+- 핵심 주장이 한 문장으로 정리되었다
+- 바꾸고 싶은 독자의 생각이 명확하다
+- 주요 근거가 최소 하나 있다
+- 가장 강한 반론이 검토되었다
+- 다음 작성 액션이 정해졌다
+
+## 최종 정리 필수 항목
+
+공통 최종 정리 형식에 다음을 추가한다.
+
+- 독자 정의
+- 핵심 메시지
+- 바꿔야 할 독자의 생각
+- 주요 근거
+- 예상 반론과 대응
+- 추천 구조
+- 기억에 남을 한 문장
+- 다음 작성 액션
+
+## 실패 모드
+
+- 독자를 정의하지 않고 글 방향을 논의하는 경우
+- 핵심 주장 없이 구조만 논의하는 경우
+- 반론을 검토하지 않는 경우
+- "설득력 있게"라는 모호한 목표만 두는 경우
+- 읽은 뒤 행동을 정하지 않는 경우
+- 독자가 이미 아는 것과 모르는 것을 구분하지 않는 경우

package/skills/ultra-grill-me/references/writing-direction-grill.md

@@ -0,0 +1,68 @@
+# Writing Direction Verification
+
+## When to use this reference
+
+- Reviewing document outlines, presentation flow, or content positioning
+- Verifying targeted readers, narrative structures, and content tone
+- Checking email copy, blog structures, or key presentation slide outlines
+- Refining marketing copy or corporate positioning statements
+
+## When not to use this reference
+
+- Reviewing user personas or product feature ideas → Use `product-idea-grill.md`
+- Verifying code models or API specifications → Use `technical-design-grill.md`
+- Generating bulk blog paragraphs or editing spelling directly
+
+## Question Priority
+
+1. **Target Reader** — Who is the primary audience? What is their background?
+2. **Core Message** — What is the single most important takeaway?
+3. **Reader Value** — Why does the reader care about this? What is their payoff?
+4. **Tone & Voice** — What is the emotional or professional tone of this piece?
+5. **Narrative Structure** — How does the logical flow progress?
+6. **Objections & Obvious Questions** — What objections will the reader raise?
+7. **Call to Action (CTA)** — What should the reader do after reading?
+8. **Smallest Next Action** — What outline section needs to be drafted first?
+
+## Strong Question Patterns
+
+- "Who is the primary reader? What background context or vocabulary do they already have?"
+- "If the reader only remembers one sentence from this document, what should it be?"
+- "What is the reader's immediate objection at page 2? How do we address it early?"
+- "What do you want the reader to do next? (e.g., sign up, reply, schedule a call)"
+
+## Weak Question Patterns
+
+- "Is this writing good?"
+- "Does this sound professional?"
+- "Should we write more pages?"
+
+## Recommended Option Rules
+
+- **Reader Ambiguity**: Recommend `(Recommended) Readers who are interested in the topic but lack specific background technical knowledge` and include junior/senior options to build the option set.
+- **Tone Ambiguity**: Recommend `(Recommended) A clear, objective tone using facts and data without jargon` and include informal/formal options to build the option set.
+- **Structure Ambiguity**: Recommend `(Recommended) Problem → Core Solution → Supporting Evidence → Counter-objections → CTA` structure to build the option set.
+
+## Handling Vague Answers
+
+- "Everyone should read this" → Narrow down: "If only one person's opinion matters for this document's success, who is that person?"
+- "I want it to sound smart and casual" → Force choice: "Let's stick to an 'objective expert tone using concrete data'. Shall we use this as our voice guideline?"
+- "They just need to understand it" → Force Action: "After reading, what is the single next step they should take? Let's add a clear CTA."
+
+## Stopping Conditions
+
+In addition to common stopping conditions, ensure:
+- The target reader's context/knowledge level is defined.
+- The single core message is clear.
+- Tone and voice guidelines are established.
+- Logical outline structure is mapped.
+- The Call to Action (CTA) is explicit.
+
+## Final Synthesis Required Items
+
+Add the following to the common final synthesis format:
+- Refined Reader Profile
+- Core Message Statement
+- Outline Structure Map
+- Tone & Voice Guidelines
+- Core CTA Definition