Guide for creating optimized Claude Code agents. Use to design a new specialized agent, a swarm sub-agent, or a multi-agent workflow. Follows the Skill → Agent (preloaded skills) → Skill orchestration pattern.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Business discovery before technical specs. Use to explore a problem, define personas, clarify the value proposition. Produces Lean Canvas, Personas, and Problem Statements in /docs/business/.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
Read .claude/roles/specifier.md — adopt this profile and follow all its rules.
Discovery comes BEFORE specs. We explore:
"Fall in love with the problem, not the solution." — Uri Levine
This skill activates when the user wants to explore:
| Artifact | File | When to use |
|---|---|---|
| Problem Statement | docs/business/problems/<name>.md | Define the problem precisely |
| Persona | docs/business/personas/<name>.md | Understand who has the problem |
| Lean Canvas | docs/business/canvas/<name>.md | Overview of an opportunity |
DISCOVERY - Start
You want to explore: [subject]
Where do we begin?
1. Problem Statement — What problem exactly?
2. Persona — Who has this problem?
3. Lean Canvas — Overview of the opportunity?
Choose your entry point, or tell me what you already know.
PROBLEM STATEMENT - Exploration
I see: [vague description of the problem]
Let's dig deeper:
1. Who exactly has this problem?
2. When/where does it manifest?
3. What do they do today to work around it?
4. What is the consequence if we don't solve it?
Answer what resonates, we'll iterate.
File: docs/business/problems/<name>.md
# Problem Statement: [Explicit title]
## The problem
[Persona] encounters [problem] when [context/trigger].
Today, [persona] [current behavior / workaround].
This causes [negative consequence] and [measurable impact].
## Frequency and severity
| Dimension | Assessment |
|-----------|------------|
| Frequency | [daily/weekly/monthly/occasional] |
| Severity | [blocking/hindering/irritating] |
| Affected population | [estimate] |
## Hypotheses to validate
- [ ] [Hypothesis about the existence of the problem]
- [ ] [Hypothesis about frequency]
- [ ] [Hypothesis about impact]
## What the problem is NOT
- [Red herring 1 — why it's a red herring]
- [Red herring 2]
## Research questions
- [Open question to explore]
PERSONA - Construction
I'm going to ask you questions to define this persona.
1. Who is this person? (role, context, environment)
2. What are they trying to accomplish? (goals)
3. What frustrates them today? (pain points)
4. How do they handle the problem currently? (workarounds)
Start by describing this person as if you were introducing them to me.
File: docs/business/personas/<name>.md
# Persona: [Descriptive name]
## Identity
| Attribute | Description |
|-----------|-------------|
| Role | [role in the usage context] |
| Context | [environment, constraints, resources] |
| Experience | [expertise level on the subject] |
## Goals
What this person wants to accomplish:
1. **[Primary goal]** — [why it matters to them]
2. **[Secondary goal]** — [why it matters]
## Frustrations (Pain Points)
What blocks or irritates them today:
1. **[Frustration 1]** — Impact: [concrete consequence]
2. **[Frustration 2]** — Impact: [concrete consequence]
## Current behaviors
How they handle the problem today:
- [Workaround 1] — [limitations of this solution]
- [Workaround 2] — [limitations]
## Typical quote
> "[A sentence this person would say, capturing their mindset]"
## Success criteria
How do they know their problem is solved?
- [Measurable criterion 1]
- [Measurable criterion 2]
## Anti-persona
This persona is NOT:
- [Profile not to confuse with — why]
LEAN CANVAS - Construction
We're going to build the canvas block by block.
Let's start with the most important:
1. What is the main problem? (not 10, just 1-3)
2. For whom? (priority segment)
Once we have that, we continue with the value proposition.
File: docs/business/canvas/<name>.md
# Lean Canvas: [Product/feature name]
## 1. Problem
The 3 main problems:
1. **[Problem 1]**
2. **[Problem 2]**
3. **[Problem 3]**
### Existing alternatives
How users solve these problems today:
- [Current solution 1] — [limitations]
- [Current solution 2] — [limitations]
---
## 2. User segments
| Segment | Characteristics | Priority |
|---------|-----------------|----------|
| Early Adopters | [who will adopt first and why] | Target |
| Main market | [who represents the volume] | Later |
---
## 3. Unique value proposition
> [One sentence explaining why it's different and why it's worth it]
### High-Level Concept
"It's like [known analogy] for [specific context]"
---
## 4. Solution
The 3 key features:
| Feature | Solves |
|---------|--------|
| [Feature 1] | Problem 1 |
| [Feature 2] | Problem 2 |
| [Feature 3] | Problem 3 |
---
## 5. Channels
How to reach users:
- **Acquisition**: [how they discover]
- **Activation**: [how they start using]
- **Retention**: [how they come back]
---
## 6. Revenue streams
- [Revenue source 1] — [model: subscription, one-shot, freemium...]
- [Revenue source 2]
---
## 7. Cost structure
| Type | Cost | Recurrence |
|------|------|------------|
| [Fixed cost] | [amount] | [monthly/yearly] |
| [Variable cost] | [amount/unit] | [per usage] |
---
## 8. Key metrics
| Metric | Target | Why this metric |
|--------|--------|-----------------|
| [Metric 1] | [target] | [what it measures] |
| [Metric 2] | [target] | [what it measures] |
---
## 9. Competitive advantage
What cannot be easily copied:
- [Advantage 1] — [why it's defensible]
- [Advantage 2]
---
## Hypotheses to validate
| Hypothesis | Risk if wrong | How to validate | Status |
|------------|---------------|-----------------|--------|
| [Hypothesis 1] | [impact] | [method] | Pending |
| [Hypothesis 2] | [impact] | [method] | Pending |
| Anti-pattern | Example | Reaction |
|---|---|---|
| Jumping to solutions | "We'll build a mobile app" | Go back to the problem |
| Generic persona | "Users want..." | Ask who exactly |
| Problem without impact | "It's not optimal" | Ask for the consequence |
| Canvas without hypotheses | "We know that..." | Challenge the certainties |
| Confusing request/need | "They want a button" | Dig into the why |
Request: "We want to add a gamification feature"
DISCOVERY - Challenge
"Gamification" is a solution, not a problem.
Questions:
1. What user behavior do you want to encourage?
2. Why don't users do it naturally?
3. How do you know gamification will work?
Let's go back to the problem before discussing solutions.
Request: "Our users want an Excel export"
DISCOVERY - Challenge
Warning: what users ask for is not always what they need.
Questions:
1. What do they do with that Excel once exported?
2. If we gave them the end result directly, would that work?
3. Who is asking for this exactly? (persona)
Maybe the real need is a dashboard, not an export.
After discovery:
/pm to turn insights into actionable specs/ddd if a new bounded context emerges아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Guide for creating optimized Claude Code agents. Use to design a new specialized agent, a swarm sub-agent, or a multi-agent workflow. Follows the Skill → Agent (preloaded skills) → Skill orchestration pattern.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Anti-overengineering guide based on YAGNI. Use before adding an architectural pattern, during code review, or to challenge an overly complex implementation.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Clean Architecture (Uncle Bob) guide for this project. Use when creating modules, entities, use cases, presenters, controllers, gateways, guards, services. Contains tactical patterns and structure conventions.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Audit documentation for duplication, staleness, language issues, and verbosity. Read-only — produces an actionable report.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Local auto-review of modified code (no GitLab/GitHub). Runs 5 sequential audits and generates a local report. Ideal for validating code before creating a MR/PR.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Clean Code (Robert C. Martin) guide to produce and challenge code that is readable, durable, simple, and consistent. Covers naming, functions, comments, smells, and refactor heuristics. Complements `/solid` (SOLID principles) and `/anti-overengineering` (YAGNI/KISS). Activate during the REFACTOR phase of the TDD cycle and during implementation self-review.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.