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/.
中文简介正在准备中。当前显示原文说明。
安装前可以查看交给 AI 代理的指令内容。
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.
中文简介正在准备中。当前显示原文说明。