skill-from-masters

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill From Masters

大师级Skill创建指南

Create skills that embody the wisdom of domain masters. This skill helps users discover and incorporate proven methodologies from recognized experts before generating a skill.

创建凝聚领域大师智慧的Skill。本Skill可帮助用户在生成Skill之前，发掘并融入权威专家已验证的方法论。

Core Philosophy

核心理念

Most professional domains have outstanding practitioners who have codified their methods through books, talks, interviews, and frameworks. A skill built on these proven methodologies is far more valuable than one created from scratch.

The goal is not just "good enough" — it's reaching the highest level of human expertise in that domain.

大多数专业领域都有杰出的从业者，他们通过书籍、演讲、访谈和框架将自己的方法系统化。基于这些已验证方法论构建的Skill，其价值远高于从零开始创建的Skill。

我们的目标不只是“足够好”——而是要达到该领域人类专业能力的最高水平。

Critical Requirements for Non-Technical Skills

非技术类Skill的关键要求

Technical skills have standard answers. Writing code, debugging, or configuring systems — these have relatively objective quality bars.

Non-technical skills vary dramatically in quality. Skills involving decision-making, communication, persuasion, or judgment can range from mediocre to world-class. The difference comes from incorporating deep expertise.

For non-technical skills (writing, sales, hiring, product decisions, etc.), follow these requirements:

技术类Skill有标准答案。 编写代码、调试或配置系统——这些任务有相对客观的质量标准。

非技术类Skill的质量差异极大。 涉及决策、沟通、说服或判断的Skill，质量可能从平庸到世界级不等。这种差异源于是否融入了深度专业知识。

对于非技术类Skill（写作、销售、招聘、产品决策等），请遵循以下要求：

1. Narrow, Specific Task Definition ⚠️ CRITICAL

1. 精准、具体的任务定义 ⚠️ 至关重要

The task must be extremely specific and well-defined
❌ BAD: "Write a sales email" (too broad)
✅ GOOD: "Write a B2B cold outreach email to enterprise CTOs"
✅ GOOD: "Write a project status report email to executive stakeholders"
Different contexts require completely different skills
If the user's request is too broad, help them narrow it down through questions

任务必须极其具体且定义明确
❌ 错误示例：“写销售邮件”（范围过宽）
✅ 正确示例：“写给企业CTO的B2B陌生开发邮件”
✅ 正确示例：“写给高管利益相关者的项目状态报告邮件”
不同场景需要完全不同的Skill
如果用户的请求过于宽泛，通过提问帮助他们缩小范围

2. Model Selection: Opus Required 🎯 MANDATORY

2. 模型选择：必须使用Opus 🎯 强制要求

Non-technical skills MUST use Claude Opus (claude-opus-4-5)
DO NOT use Sonnet, Haiku, or any other model
Opus has the reasoning depth needed for nuanced, judgment-based tasks
The quality difference is substantial for these domains

非技术类Skill必须使用Claude Opus（claude-opus-4-5）
不得使用Sonnet、Haiku或其他任何模型
Opus具备处理细微差别、基于判断的任务所需的推理深度
在这些领域，模型带来的质量差异非常显著

3. Methodology Research: Clear & Reliable Conclusions 🔍 ESSENTIAL

3. 方法论研究：清晰、可靠的结论 🔍 必备要求

Continue searching and communicating until you reach very clear, reliable conclusions
Don't stop at surface-level research
Sources to exhaust:
- The model's own training knowledge
- Web search for current best practices
- Golden examples from top practitioners
- Counter-examples and common mistakes
Keep iterating until the methodology is crystal clear and well-validated

持续搜索和沟通，直到得出非常清晰、可靠的结论
不要停留在表面研究
需要穷尽的来源：
- 模型自身的训练知识
- 针对当前最佳实践的网络搜索
- 顶尖从业者提供的优质示例
- 反例和常见错误
不断迭代，直到方法论清晰明确且经过充分验证

4. Consider Plan Mode for Complex Tasks 🎯 RECOMMENDED

4. 复杂任务考虑使用计划模式 🎯 推荐

For complex or multi-faceted skills, prefer thinking through the approach first
Better to think more before acting
Use plan mode to structure the methodology research and synthesis

对于复杂或多维度的Skill，建议先梳理方法再行动
行动前多思考更有帮助
使用计划模式来系统化构建方法论研究和整合流程

5. Test Broadly, Then Iterate ✅ REQUIRED

5. 广泛测试，然后迭代优化 ✅ 必备要求

Have the agent think through extensive test scenarios
Test across diverse contexts, edge cases, and failure modes
Review test results and optimize before finalizing
Quality emerges from iteration, not first drafts

让Agent梳理全面的测试场景
在多样的场景、边缘案例和失败模式下进行测试
审查测试结果并在最终确定前优化
质量源于迭代，而非初稿

Workflow

工作流程

Before Starting: Consider Plan Mode 🎯

For complex or high-stakes skill creation (especially non-technical skills), consider using plan mode:

Allows more upfront thinking before taking action
Helps structure the methodology research systematically
Reduces the risk of missing important considerations
Better for skills involving judgment, persuasion, or complex decision-making

To use plan mode, the user can invoke it explicitly, or you can suggest: "This is a complex skill involving [decision-making/communication/etc]. Would you like me to use plan mode to think through the methodology research more carefully?"

开始前：考虑使用计划模式 🎯

对于复杂或高风险的Skill创建（尤其是非技术类Skill），建议使用计划模式：

允许在行动前进行更多前置思考
有助于系统化构建方法论研究
降低遗漏重要考量的风险
更适合涉及判断、说服或复杂决策的Skill

用户可以显式调用计划模式，您也可以建议：“这是一个涉及[决策/沟通等]的复杂Skill。是否需要我使用计划模式来更细致地梳理方法论研究？”

Step 1: Understand and Narrow the Skill Intent

步骤1：理解并缩小Skill的目标范围

CRITICAL FOR NON-TECHNICAL SKILLS: Ensure the task is narrow and specific enough.

Most users will start with a broad request. Your job is to help them narrow it down systematically until the task is specific enough that methodology and quality criteria are unambiguous.

**非技术类Skill的关键要求：**确保任务足够精准和具体。

大多数用户的初始请求都比较宽泛。您的工作是系统地帮助他们缩小范围，直到任务足够具体，方法论和质量标准明确无误。

The 5-Layer Narrowing Framework

五层范围缩小框架

Use this systematic approach to guide users from broad to specific:

使用这套系统方法引导用户从宽泛需求转向具体需求：

Layer 1: Domain Identification

第一层：领域识别

Identify the core domain(s) of the broad task.

Template questions:

"[Broad task] can mean different things depending on the domain. Which of these is closest to what you need?
- [Domain A - description]
- [Domain B - description]
- [Domain C - description]
- Something else?"

Example:

User: "I want a skill for making decisions"
You: "Decision-making varies greatly by domain. Which is closest?
- Product decisions (features, roadmap, prioritization)?
- Hiring decisions (candidate evaluation, role definition)?
- Investment decisions (startups, projects, resource allocation)?
- Strategic business decisions (market entry, partnerships)?
- Something else?"

确定宽泛任务的核心领域。

模板问题：

“[宽泛任务]根据领域的不同含义也不同。您的需求最接近以下哪一种？
- [领域A - 描述]
- [领域B - 描述]
- [领域C - 描述]
- 其他？”

示例：

用户：“我想创建一个用于做决策的Skill”
您：“决策因领域差异很大。您的需求最接近哪一种？
- 产品决策（功能、路线图、优先级）？
- 招聘决策（候选人评估、岗位定义）？
- 投资决策（初创公司、项目、资源分配）？
- 战略业务决策（市场进入、合作）？
- 其他？”

Layer 2: Context Constraints (5W1H)

第二层：场景约束（5W1H）

Once you know the domain, use structured questions to narrow the context:

Template questions:

- **WHO**: Who will use this skill? (Role, seniority, expertise level)
- **WHAT**: What specific output or decision does it produce?
- **WHERE**: What organizational context? (Startup, enterprise, remote, industry)
- **WHEN**: At what stage/timing is it used? (Launch, crisis, quarterly, daily)
- **WHY**: What's the primary goal/outcome? (Alignment, approval, action, learning)
- **HOW**: What constraints exist? (Time limits, process requirements, stakeholders)

Example:

User: "Product decisions"
You: "Let me understand the context better:
- WHO: Are you a PM, founder, or executive making these decisions?
- WHAT: Is this about choosing features, prioritization, or go/no-go launches?
- WHERE: Startup (limited resources) or enterprise (many stakeholders)?
- WHEN: Daily sprint planning or quarterly roadmap decisions?
- WHY: Main goal - team alignment, exec approval, or customer validation?"

确定领域后，通过结构化问题缩小场景范围：

模板问题：

- **谁（WHO）**：谁会使用这个Skill？（角色、职级、专业水平）
- **做什么（WHAT）**：它会产生什么具体的输出或决策？
- **在哪里（WHERE）**：什么组织场景？（初创公司、企业、远程办公、行业）
- **何时（WHEN）**：在什么阶段/时间点使用？（启动、危机、季度、日常）
- **为什么（WHY）**：主要目标/成果是什么？（对齐、批准、行动、学习）
- **如何做（HOW）**：存在哪些约束？（时间限制、流程要求、利益相关者）

示例：

用户：“产品决策”
您：“让我进一步了解场景：
- 谁（WHO）：您是产品经理、创始人还是高管来做这些决策？
- 做什么（WHAT）：是关于选择功能、确定优先级，还是上线与否的决策？
- 在哪里（WHERE）：初创公司（资源有限）还是企业（众多利益相关者）？
- 何时（WHEN）：日常冲刺规划还是季度路线图决策？
- 为什么（WHY）：主要目标——团队对齐、高管批准还是客户验证？”

Layer 3: Comparative Narrowing

第三层：对比式缩小范围

Present 2-3 similar but distinct scenarios. Force a choice or clarification.

Template:

"Within [narrowed domain], I want to make sure we're targeting the right scenario. Which is closest?

A. [Specific scenario A - with context]
B. [Specific scenario B - with context]
C. [Specific scenario C - with context]
D. None of these / Combination

Which matches best?"

Example:

User: "Feature prioritization for a PM at a B2B SaaS startup"
You: "Got it. Let me narrow further:

A. Weekly sprint planning: Prioritizing stories within a committed roadmap B. Quarterly roadmap planning: Deciding which themes/initiatives for next quarter C. Reactive prioritization: Customer escalation or urgent bug vs planned work D. Resource allocation: Multiple products/teams competing for engineering time

Which scenario is most common for you, or do you need to handle multiple?"

呈现2-3个相似但不同的场景，迫使用户做出选择或进一步明确。

模板：

“在[已缩小的领域]中，我需要确保我们针对的是正确场景。您的需求最接近哪一种？

A. [具体场景A - 带场景说明]
B. [具体场景B - 带场景说明]
C. [具体场景C - 带场景说明]
D. 以上都不是 / 组合场景

哪一个最匹配？”

示例：

用户：“B2B SaaS初创公司产品经理的功能优先级排序”
您：“明白。让我进一步缩小范围：

A. 每周冲刺规划：在已确定的路线图内确定需求优先级 B. 季度路线图规划：决定下一季度的主题/举措 C. 响应式优先级调整：客户紧急需求或严重Bug vs 计划内工作 D. 资源分配：多个产品/团队争夺工程资源

哪种场景对您来说最常见，还是您需要处理多种场景？”

Layer 4: Boundary Validation (Via Negativa)

第四层：边界验证（排除法）

Confirm what the skill does NOT include. This clarifies the edges.

Template:

"To make sure we're aligned, let me confirm the boundaries. This skill:
- ✅ INCLUDES: [Specific scenario X]
- ✅ INCLUDES: [Specific scenario Y]
- ❌ EXCLUDES: [Related but different scenario A]
- ❌ EXCLUDES: [Related but different scenario B]
- ❌ EXCLUDES: [Related but different scenario C]

Does this match your needs?"

Example:

User confirms: "Quarterly roadmap planning for a B2B SaaS PM"
You: "Perfect. To confirm scope, this skill:
- ✅ INCLUDES: Quarterly planning with engineering constraints
- ✅ INCLUDES: Balancing customer requests, tech debt, and strategic bets
- ❌ EXCLUDES: Daily sprint story prioritization
- ❌ EXCLUDES: Crisis/reactive priority decisions
- ❌ EXCLUDES: Multi-product portfolio prioritization (VP-level)
Is this right?"

确认Skill不包含的内容，以此明确边界。

模板：

“为确保我们达成共识，让我确认一下边界。本Skill：
- ✅ 包含：[具体场景X]
- ✅ 包含：[具体场景Y]
- ❌ 不包含：[相关但不同的场景A]
- ❌ 不包含：[相关但不同的场景B]
- ❌ 不包含：[相关但不同的场景C]

这是否符合您的需求？”

示例：

用户确认：“B2B SaaS产品经理的季度路线图规划”
您：“完美。为确认范围，本Skill：
- ✅ 包含：考虑工程约束的季度规划
- ✅ 包含：平衡客户需求、技术债务和战略投入
- ❌ 不包含：日常冲刺需求优先级排序
- ❌ 不包含：危机/响应式优先级决策
- ❌ 不包含：跨产品组合优先级排序（副总裁级别）
对吗？”

Layer 5: Concrete Case Anchoring

第五层：具体案例锚定

Ask for a real, specific example from their experience. This locks in the scope.

Template:

"Can you describe a specific recent situation where you needed this skill? Include:
- What was the situation/context?
- What inputs did you have?
- What decision/output did you need to produce?
- What made it difficult or time-consuming?
- What would an ideal outcome have looked like?"

Example:

User: "Yes, the scope is right"
You: "Great! One last thing to anchor our methodology research. Can you describe a recent quarterly planning session? For example:
- How many features/initiatives were you choosing between?
- What stakeholders were involved?
- What made it hard? (Conflicting data? Stakeholder disagreement? Technical uncertainty?)
- How long did the process take?
- What would have made it easier or better?"

请用户描述他们经历过的真实、具体的场景。这会锁定范围。

模板：

“您能描述一个最近需要使用该Skill的具体场景吗？包括：
- 场景/背景是什么？
- 您有哪些输入信息？
- 您需要做出什么决策/输出？
- 是什么让它变得困难或耗时？
- 理想的结果是什么样的？”

示例：

用户：“是的，范围是对的”
您：“太好了！最后一个问题来锚定我们的方法论研究。您能描述一次最近的季度规划会议吗？例如：
- 您需要在多少个功能/举措中做选择？
- 涉及哪些利益相关者？
- 难点是什么？（数据冲突？利益相关者意见不合？技术不确定性？）
- 这个过程花了多长时间？
- 什么会让这个过程更轻松或更好？”

Stop Condition: Is It Narrow Enough?

停止缩小的条件：是否足够具体？

Stop narrowing when you can answer YES to all:

✅ Unique methodology: Would experts in this specific scenario have unique advice (not generic)?
✅ Clear quality bar: Could someone judge if the output is "excellent" vs "mediocre"?
✅ Specific constraints: Are there context-specific rules, tradeoffs, or failure modes?
✅ Concrete example: Has the user described a real scenario where they'd use this?
✅ Excludes alternatives: Is it clear what related tasks this does NOT cover?

If ANY answer is NO, keep narrowing.

当以下所有问题的答案都是YES时，停止缩小范围：

✅ 独特方法论：该具体场景下的专家是否有独特的建议（而非通用建议）？
✅ 清晰的质量标准：有人能判断输出是“优秀”还是“平庸”吗？
✅ 具体约束：是否存在场景特定的规则、权衡或失败模式？
✅ 具体示例：用户是否描述了一个会使用该Skill的真实场景？
✅ 排除替代任务：是否明确了该Skill不涵盖哪些相关任务？

如果任何一个问题的答案是NO，继续缩小范围。

Common Mistakes: Still Too Broad

常见错误：范围仍然过宽

Even after narrowing, watch for these signs the scope is still too broad:

❌ Too broad:

"Write better emails" → Includes too many email types
"Make product decisions" → Covers too many decision types
"Create marketing content" → Content types vary wildly
"Improve team communication" → Communication contexts differ greatly

✅ Narrow enough:

"Write B2B cold outreach emails to enterprise CTOs"
"Quarterly roadmap prioritization for B2B SaaS PMs with 3-5 eng team"
"Create LinkedIn thought leadership posts for technical founders"
"Run effective incident postmortems for distributed systems teams"

Rule of thumb: If you can describe the skill in one sentence with specific role, context, and output type, you're probably narrow enough.

即使经过缩小范围，也要注意这些范围仍然过宽的迹象：

❌ 范围过宽：

“写更好的邮件” → 包含太多类型的邮件
“做产品决策” → 涵盖太多类型的决策
“创建营销内容” → 内容类型差异极大
“改善团队沟通” → 沟通场景差异很大

✅ 足够具体：

“写给企业CTO的B2B陌生开发邮件”
“拥有3-5人工程团队的B2B SaaS产品经理的季度路线图优先级排序”
“为技术创始人创建领英思想领导力帖子”
“为分布式系统团队开展有效的事后复盘”

**经验法则：**如果您能用一句话描述该Skill，包含具体角色、场景和输出类型，那么范围可能足够具体。

Quick Reference: Narrowing Question Flow

快速参考：缩小范围的提问流程

Broad Request
    ↓
Layer 1: "Which domain?" → [Pick one]
    ↓
Layer 2: "5W1H context?" → [Answer constraints]
    ↓
Layer 3: "Which specific scenario?" → [Choose from 2-3 options]
    ↓
Layer 4: "What's excluded?" → [Confirm boundaries]
    ↓
Layer 5: "Give me a real example" → [Describe concrete case]
    ↓
Check Stop Condition → [All 5 YES?]
    ↓
✅ Narrow enough → Proceed to Step 2
❌ Still broad → Continue narrowing

宽泛请求
    ↓
第一层：“属于哪个领域？” → [选择一个]
    ↓
第二层：“5W1H场景？” → [明确约束]
    ↓
第三层：“具体是哪个场景？” → [从2-3个选项中选择]
    ↓
第四层：“不包含哪些内容？” → [确认边界]
    ↓
第五层：“给我一个真实示例” → [描述具体案例]
    ↓
检查停止条件 → [全部5个YES？]
    ↓
✅ 足够具体 → 进入步骤2
❌ 仍然过宽 → 继续缩小范围

Step 2: Identify Skill Type

步骤2：确定Skill类型

CRITICAL: Different skill types require fundamentally different methodologies and quality criteria.

Consult

references/skill-taxonomy.md

for the full taxonomy. The core types are:

Type	Core Operation	Key Question
Summary	Compress	Need comprehensive coverage?
Insight	Extract	Need to find what really matters?
Generation	Create	Need new content created?
Decision	Choose	Need to make a choice?
Evaluation	Judge	Need quality judgment?
Diagnosis	Trace	Need to find root cause?
Persuasion	Bridge	Need to change someone's mind?
Planning	Decompose	Need a roadmap?
Research	Discover	Need knowledge gathered?
Facilitation	Elicit	Need to extract info from others?
Transformation	Map	Need format conversion?

How to Identify:

Ask the user: "Based on what you described, this sounds like a [Type] skill—the goal is to [core operation]. Is that right?"

Common Confusions to Clarify:

Summary vs Insight: "Do you need comprehensive coverage, or just the key signals that matter?"
Decision vs Evaluation: "Do you need to make a choice, or judge the quality of something?"
Research vs Insight: "Do you need to gather information, or interpret what it means?"

Why This Matters:

Each type has different:

Methodology sources to draw from
Quality criteria to evaluate output
Output format conventions

Document the identified type before proceeding.

**关键：**不同类型的Skill需要完全不同的方法论和质量标准。

查阅

references/skill-taxonomy.md

获取完整分类。核心类型如下：

类型	核心操作	关键问题
总结	压缩	需要全面覆盖吗？
洞察	提取	需要找到真正重要的内容吗？
生成	创建	需要创建新内容吗？
决策	选择	需要做出选择吗？
评估	判断	需要质量判断吗？
诊断	追溯	需要找到根本原因吗？
说服	搭建桥梁	需要改变他人想法吗？
规划	分解	需要路线图吗？
研究	发现	需要收集知识吗？
引导	引出	需要从他人那里提取信息吗？
转换	映射	需要格式转换吗？

如何确定类型：

询问用户：“根据您的描述，这听起来像是一个**[类型]**Skill——目标是[核心操作]。对吗？”

需要澄清的常见混淆：

总结 vs 洞察：“您需要全面覆盖，还是只需要找到真正重要的关键信号？”
决策 vs 评估：“您需要做出选择，还是判断某事物的质量？”
研究 vs 洞察：“您需要收集信息，还是解读信息的含义？”

为什么这很重要：

每种类型有不同的：

可借鉴的方法论来源
用于评估输出的质量标准
输出格式惯例

在继续之前记录确定的类型。

Step 3: Identify Relevant Domains

步骤3：确定相关领域

Map the skill to one or more methodology domains. A single skill may span multiple domains.

Example mappings:

"Sales email skill" → Sales, Writing, Persuasion
"User interview skill" → User Research, Interviewing, Product Discovery
"Presentation skill" → Storytelling, Visual Design, Persuasion
"Code review skill" → Software Engineering, Feedback, Communication

将Skill映射到一个或多个方法论领域。单个Skill可能跨越多个领域。

示例映射：

“销售邮件Skill” → 销售、写作、说服
“用户访谈Skill” → 用户研究、访谈、产品发现
“演示Skill” → 故事讲述、视觉设计、说服
“代码审查Skill” → 软件工程、反馈、沟通

Step 4: Surface Expert Methodologies (Until Crystal Clear)

步骤4：挖掘专家方法论（直到清晰明确）

GOAL: Don't stop until you have very clear, reliable conclusions about the best methodology.

Layer 1: Local Database Consult

references/methodology-database.md

for known frameworks.

Layer 2: Web Search for Experts Search the web to discover additional experts and methodologies:

Search: "[domain] best practices expert"
Search: "[domain] framework methodology"
Search: "[domain] master practitioner"

Layer 3: Deep Dive on Selected Experts For promising experts, search for their original content:

Search: "[expert name] methodology interview"
Search: "[expert name] [domain] transcript"
Search: "[expert name] framework explained"

Fetch and read primary sources when available (articles, talk transcripts, blog posts).

Layer 4: Keep Iterating Until Clear ⚠️ NEW

Don't stop at the first search results
If methodologies seem unclear or conflicting, dig deeper
Look for:
- Model's own knowledge (you have extensive training data)
- Current web best practices
- Golden examples from practitioners
- Anti-patterns and common mistakes
Continue the research loop until you can confidently say: "This is the proven way to do this"

For each relevant domain, present:

Key experts and their core contributions
Specific frameworks, principles, or processes
Source materials (books, talks, interviews)
Confidence level in the methodology (keep searching if low)

目标：不要停止，直到您对最佳方法论有非常清晰、可靠的结论。

第一层：本地数据库 查阅

references/methodology-database.md

获取已知框架。

第二层：网络搜索专家 通过网络搜索发现更多专家和方法论：

搜索：“[领域] best practices expert”
搜索：“[领域] framework methodology”
搜索：“[领域] master practitioner”

第三层：深入研究选定的专家 对于有前景的专家，搜索他们的原始内容：

搜索：“[专家姓名] methodology interview”
搜索：“[专家姓名] [领域] transcript”
搜索：“[专家姓名] framework explained”

在可用时获取并阅读原始来源（文章、演讲文稿、博客文章）。

第四层：持续迭代直到清晰明确 ⚠️ 新增

不要停留在第一批搜索结果
如果方法论看起来不清晰或存在冲突，深入挖掘
寻找：
- 模型自身的知识（您有大量训练数据）
- 当前网络上的最佳实践
- 从业者提供的优质示例
- 反模式和常见错误
继续研究循环，直到您可以自信地说：“这是经过验证的正确方法”

对于每个相关领域，呈现：

关键专家及其核心贡献
具体框架、原则或流程
来源材料（书籍、演讲、访谈）
方法论的置信度（如果置信度低则继续搜索）

Step 5: Find Golden Examples

步骤5：寻找优质示例

Before finalizing methodology selection, search for exemplary outputs:

Search: "best [output type] examples"
Search: "[output type] template [top company]"
Search: "award winning [output type]"

Understanding what excellence looks like helps define the quality bar.

在最终确定方法论选择之前，搜索优秀的输出示例：

搜索：“best [输出类型] examples”
搜索：“[输出类型] template [top company]”
搜索：“award winning [输出类型]”

了解优秀的标准有助于定义质量基准。

Step 6: Collaborative Selection

步骤6：协作选择

Present the methodologies to the user and discuss:

Which frameworks resonate with their goals?
Are there conflicts between methodologies to resolve?
Should they combine multiple approaches?
Any specific principles they want to emphasize or exclude?

Guide the user to select 1-3 primary methodologies that will form the skill's foundation.

向用户呈现方法论并讨论：

哪些框架与他们的目标产生共鸣？
方法论之间是否存在需要解决的冲突？
他们是否应该结合多种方法？
他们想要强调或排除哪些具体原则？

引导用户选择1-3种主要方法论，作为Skill的基础。

Step 7: Extract Actionable Principles

步骤7：提取可操作的原则

For each selected methodology, search for and distill:

The Why (Core Principles)

Search: "[methodology] core principles"
Search: "why [methodology] works"

The How (Concrete Process)

Search: "[methodology] step by step"
Search: "[methodology] implementation guide"

The What (Quality Criteria)

Search: "[methodology] checklist"
Search: "[methodology] evaluation criteria"

The Pitfalls (Common Mistakes)

Search: "[domain] common mistakes"
Search: "[methodology] pitfalls avoid"

Fetch primary sources to get exact wording and nuance, not just summaries.

对于每个选定的方法论，搜索并提炼：

为什么（核心原则）

搜索：“[方法论] core principles”
搜索：“why [方法论] works”

如何做（具体流程）

搜索：“[方法论] step by step”
搜索：“[方法论] implementation guide”

是什么（质量标准）

搜索：“[方法论] checklist”
搜索：“[方法论] evaluation criteria”

陷阱（常见错误）

搜索：“[领域] common mistakes”
搜索：“[方法论] pitfalls avoid”

获取原始来源以获取准确的措辞和细微差别，而不仅仅是摘要。

Step 8: Cross-Validate

步骤8：交叉验证

Compare insights across multiple sources:

What principles appear consistently? (high confidence)
Where do experts disagree? (flag for user)
What's unique to each approach? (differentiation)

Synthesize a coherent framework that takes the best from each source.

比较多个来源的见解：

哪些原则始终出现？（高置信度）
专家在哪些方面存在分歧？（向用户标记）
每种方法的独特之处是什么？（差异化）

整合一个连贯的框架，吸收每个来源的精华。

Step 9: Design Test Scenarios (Before Generation)

步骤9：设计测试场景（生成之前）

CRITICAL: Before generating the skill, design comprehensive test scenarios.

Work with the user to identify:

Diverse Test Cases:

Typical scenarios (the common case)
Edge cases (unusual but valid situations)
Boundary conditions (where the methodology might break down)
Failure modes (what could go wrong)

Context Variations:

Different user expertise levels
Different organizational contexts (startup vs enterprise)
Different constraints (time, resources, stakeholder complexity)
Cultural or industry differences

Quality Validation:

What does "excellent" output look like?
What are the most common mistakes to avoid?
How will we know if the skill is working?

Document these test scenarios — they'll be used after generation to validate and iterate.

**关键：**在生成Skill之前，设计全面的测试场景。

与用户合作确定：

多样的测试用例：

典型场景（常见情况）
边缘案例（不常见但有效的情况）
边界条件（方法论可能失效的情况）
失败模式（可能出错的情况）

场景变化：

不同的用户专业水平
不同的组织场景（初创公司 vs 企业）
不同的约束（时间、资源、利益相关者复杂度）
文化或行业差异

质量验证：

“优秀”的输出是什么样的？
最常见的错误有哪些需要避免？
我们如何知道Skill是否有效？

记录这些测试场景——它们将在生成后用于验证和迭代。

Step 10: Generate the Skill

步骤10：生成Skill

With methodologies confirmed and test scenarios designed, invoke the
skill-creator
skill to generate the final skill with proper format.

HOW TO INVOKE:

Use the Skill tool with: skill: "skill-creator:skill-creator"

This ensures:

Proper YAML frontmatter (name, description)
Correct directory structure
Validation before packaging
Imperative writing style (not second person)

For non-technical skills, CRITICAL:

Add
```
model: opus
```
in the YAML frontmatter
This ensures the skill uses Claude Opus, not a weaker model

The generated skill should:

Credit the methodology sources in a comment (documenting provenance)
Translate expert wisdom into actionable instructions
Include concrete examples derived from golden examples found
Capture quality criteria as explicit checkpoints
Include "don't do this" anti-patterns from pitfall research
Match the quality bar of the best human practitioners
Include the test scenarios as part of the skill's self-validation

在方法论确认且测试场景设计完成后，调用
skill-creator
Skill以正确格式生成最终Skill。

调用方式：

使用Skill工具，参数：skill: "skill-creator:skill-creator"

这确保：

正确的YAML前置内容（名称、描述）
正确的目录结构
打包前的验证
命令式写作风格（而非第二人称）

对于非技术类Skill，关键要求：

在YAML前置内容中添加
```
model: opus
```
这确保Skill使用Claude Opus，而非更弱的模型

生成的Skill应：

在注释中注明方法论来源（记录出处）
将专家智慧转化为可操作的指令
包含从找到的优质示例中衍生的具体示例
将质量标准捕获为明确的检查点
包含从陷阱研究中得出的“不要这样做”的反模式
匹配顶尖人类从业者的质量标准
包含测试场景作为Skill自我验证的一部分

Step 11: Test, Review, and Iterate

步骤11：测试、审查和迭代

Don't stop at first generation. Quality emerges through iteration.

Run Test Scenarios: Apply the skill to each test case designed in Step 9
Evaluate Results: Compare outputs against quality criteria
Identify Gaps: Where did the skill fall short?
Refine Methodology: Do we need additional expert guidance?
Regenerate: Update the skill based on learnings
Repeat: Until the skill consistently produces excellent results

Involve the user in this evaluation — they know their domain and can spot nuances.

**不要停留在第一次生成。**质量源于迭代。

运行测试场景：将Skill应用于步骤9中设计的每个测试用例
评估结果：将输出与质量标准进行比较
识别差距：Skill在哪些方面存在不足？
优化方法论：我们是否需要额外的专家指导？
重新生成：根据经验更新Skill
重复：直到Skill持续产生优秀结果

让用户参与此评估——他们了解自己的领域，能够发现细微差别。

Quality Checklist

质量检查表

Example Interaction: Full Narrowing Process

示例交互：完整的缩小范围流程

This example shows the complete 5-layer narrowing in action.

User: I want to create a skill for writing product requirement documents.

Assistant: Great! PRDs are an important skill. Let me help narrow this down using a systematic approach.

[Layer 1: Domain Identification]

PRDs can serve different purposes depending on the audience and goal. Which is closest to what you need?

Engineering-focused specs: Detailed feature requirements for implementation
Stakeholder alignment docs: High-level documents to get buy-in from executives/leadership
Design briefs: Product requirements focused on user experience and design direction
External vendor specs: Technical requirements for third-party development

Which type of PRD do you most often need to write?

User: Engineering-focused specs.

Assistant: Perfect. Now let me understand the context better.

[Layer 2: Context Constraints (5W1H)]

WHO: What's your role? (PM, Senior PM, Product Lead, or Founder?)
WHERE: What type of company? (Startup, mid-size, or enterprise? B2B or B2C?)
WHEN: How often do you write these? (Every sprint? Per quarter? Per major initiative?)
WHY: Primary goal - is it to get eng buy-in, ensure nothing is missed, or facilitate estimation?
HOW: Any constraints - do you follow a specific template? Any required sections?

User: I'm a Senior PM at a B2B SaaS company (100 people, growing fast). I write PRDs for major features (usually 3-5 per quarter). Main goal is to ensure engineers have everything they need to start building without constant back-and-forth. No required template, but we try to keep docs under 2 pages.

Assistant: Excellent context. Let me narrow further.

[Layer 3: Comparative Narrowing]

Within "engineering PRDs for major features," which scenario is most common?

A. Net-new features: Building something completely new (new product area, new capability) B. Major enhancements: Significant upgrades to existing features (new workflow, architecture change) C. Cross-system features: Features requiring coordination across multiple teams/services D. Customer-driven builds: Custom features for enterprise customers with tight timelines

Which is most frequent, or do you need to handle multiple types?

User: Mostly A and B. Sometimes C, but rarely D.

Assistant: Got it. Let me confirm the boundaries.

[Layer 4: Boundary Validation]

So this skill should:

✅ INCLUDE: Net-new features and major enhancements for engineering teams
✅ INCLUDE: B2B SaaS context with 3-10 engineer scope typically
✅ INCLUDE: Cross-team coordination when needed
❌ EXCLUDE: Small story-level specs (those go directly in Jira/tickets)
❌ EXCLUDE: Customer-specific custom builds with tight deadlines
❌ EXCLUDE: Executive-facing strategy documents or roadmap presentations

Does this match what you need?

User: Yes, exactly!

Assistant: Perfect. One final question to anchor the methodology research.

[Layer 5: Concrete Case Anchoring]

Can you describe a recent PRD you wrote that was either particularly challenging or time-consuming? For example:

What feature were you speccing?
What made it hard to write the PRD?
How long did it take you?
Did engineers come back with lots of questions, or did it work well?

User: Last month I wrote a PRD for an API rate limiting feature. Took me about 6 hours spread over 3 days. The hard part was explaining the business logic (what counts toward limits, how to handle bursts) clearly enough that engineers understood the intent but could still design the technical solution. We did 2 rounds of clarification before they felt ready to estimate. Would love to get that down to 3 hours and one round of Q&A.

Assistant: Perfect! Now I have a crystal-clear picture.

📌 Final Skill Definition:

"Create engineering-focused PRDs for B2B SaaS senior PMs writing specs for net-new features and major enhancements. PRDs should be 1-2 pages, clearly communicate business logic and user needs without over-specifying technical implementation, and enable engineering teams to estimate and start building with minimal back-and-forth."

This passes all 5 stop conditions:

✅ Unique methodology - Yes (balancing business logic vs technical freedom)
✅ Clear quality bar - Yes (minimize eng questions, enable estimation)
✅ Specific constraints - Yes (B2B SaaS, 1-2 pages, major features)
✅ Concrete example - Yes (API rate limiting feature, 6→3 hours)
✅ Excludes alternatives - Yes (not small stories, not exec docs)

Ready to move to Step 2: Methodology Research. Since this is a non-technical skill involving communication and judgment, I'd recommend using plan mode to think through the methodology research carefully. Should I proceed in plan mode?

User: Yes, go ahead.

Assistant: Perfect, that's specific enough. Since this is a non-technical skill involving communication and judgment, I'd recommend using plan mode to think through the methodology research carefully. Should I proceed in plan mode?

User: Yes, go ahead.

Assistant: [Enters plan mode and structures the research approach]

Let me search systematically for the best methodologies on engineering-focused PRD writing.

[Searches: "PRD best practices expert", "product requirements document methodology for engineers", "best PRD examples B2B SaaS"]

I found several strong frameworks:

Product Management:

Marty Cagan (SVPG): Emphasizes problem-first PRDs, separating problem space from solution space
Teresa Torres: Continuous discovery, outcome-focused requirements

Business Writing:

Barbara Minto: Pyramid Principle - lead with conclusion, MECE structure
Amazon: Working backwards from press release, 6-pager narrative format

Golden Examples Found:

Intercom's public PRD template
Linear's product spec format

Common Mistakes (from my search):

Jumping to solutions before defining the problem
Writing for engineers instead of for alignment
Missing success metrics

Let me dig deeper into primary sources to get very clear conclusions...

[Continues searching until methodology is crystal clear]

Which of these approaches resonates? Or should I search deeper into any of them?

User: I like Amazon's approach combined with Cagan's problem-first thinking. Can you find more details on Amazon's method?

Assistant: [Searches: "Amazon 6-pager template", "Amazon working backwards methodology", "Amazon PR FAQ process"]

[Fetches relevant articles and synthesizes key principles]

Here's what I found from primary sources...

[After thorough methodology research]

Assistant: Before I generate the skill, let me design test scenarios. Let's think through diverse cases:

Test Scenarios:

Simple feature: Adding a filter to existing dashboard
Complex feature: New AI-powered recommendation engine
Edge case: Feature requiring significant backend architecture changes
Failure mode: Vague problem statement that needs refinement

Does this cover the range of PRDs you typically write? Any other scenarios we should test?

User: Also add: Feature that needs cross-team coordination.

Assistant: Great addition. Now I'll invoke skill-creator to generate the skill with proper format.

[Invokes: Skill tool with skill: "skill-creator:skill-creator"]

The skill-creator will guide me through:

Creating proper YAML frontmatter (name, description, model: opus)
Writing in imperative form
Structuring the skill directory
Validating the output

[After skill-creator completes]

I've generated the skill. Let me test it against our scenarios...

[Reviews results, identifies gaps, iterates]

[Continues to Step 10: refinement based on test results]

此示例展示了完整的五层缩小范围流程的实际应用。

用户：我想创建一个用于编写产品需求文档的Skill。

助手：太好了！PRD是一项重要的Skill。让我用系统方法帮您缩小范围。

[第一层：领域识别]

根据受众和目标的不同，PRD有不同的用途。您的需求最接近哪一种？

面向工程师的规格说明：用于实现的详细功能需求
利益相关者对齐文档：用于获得高管/领导层认可的高层文档
设计简报：专注于用户体验和设计方向的产品需求
外部供应商规格：用于第三方开发的技术需求

您最常需要编写哪种类型的PRD？

用户：面向工程师的规格说明。

助手：完美。让我进一步了解场景。

[第二层：场景约束（5W1H）]

谁（WHO）：您的角色是什么？（产品经理、创始人还是高管？）
做什么（WHAT）：这是关于选择功能、确定优先级，还是上线与否的决策？
在哪里（WHERE）：什么类型的公司？（初创公司、中型公司还是企业？B2B还是B2C？）
何时（WHEN）：您多久写一次？（每个冲刺？每个季度？每个重大举措？）
为什么（WHY）：主要目标是——获得工程师认可、确保没有遗漏，还是便于估算？
如何做（HOW）：有任何约束吗？（时间限制、流程要求、利益相关者）

用户：我是一家B2B SaaS公司（100人，快速增长）的高级产品经理。我为重大功能编写PRD（通常每季度3-5个）。主要目标是确保工程师拥有开始构建所需的一切信息，无需反复沟通。没有强制模板，但我们尽量将文档控制在2页以内。

助手：非常好的场景信息。让我进一步缩小范围。

[第三层：对比式缩小范围]

在“面向工程师的重大功能PRD”中，哪种场景最常见？

A. 全新功能：构建完全新的东西（新产品领域、新功能） B. 重大增强：对现有功能的重大升级（新工作流程、架构变更） C. 跨系统功能：需要跨多个团队/服务协调的功能 D. 客户驱动的构建：为企业客户定制的功能，时间紧迫

哪种最常见，还是您需要处理多种类型？

用户：主要是A和B。有时是C，但很少是D。

助手：明白了。让我确认边界。

[第四层：边界验证]

因此，本Skill应：

✅ 包含：面向工程团队的全新功能和重大增强PRD
✅ 包含：B2B SaaS场景，通常涉及3-10名工程师
✅ 包含：需要时的跨团队协调
❌ 不包含：小型需求级规格说明（这些直接写在Jira/工单中）
❌ 不包含：时间紧迫的客户定制构建
❌ 不包含：面向高管的战略文档或路线图演示

这符合您的需求吗？

用户：是的，完全符合！

助手：完美。最后一个问题来锚定我们的方法论研究。

[第五层：具体案例锚定]

您能描述一个最近编写的、特别有挑战性或耗时的PRD吗？例如：

您在为哪个功能编写规格？
编写PRD的难点是什么？
花了多长时间？
工程师是否提出了很多问题，还是效果很好？

用户：上个月我为一个API速率限制功能写了PRD。花了大约6个小时，分3天完成。难点是清晰地解释业务逻辑（什么计入限制、如何处理突发流量），让工程师理解意图但仍能设计技术解决方案。我们进行了2轮澄清，他们才觉得可以开始估算。我希望能把时间缩短到3小时，只需要一轮问答。

助手：完美！现在我有了非常清晰的画面。

📌 最终Skill定义：

“为B2B SaaS高级产品经理创建面向工程师的PRD，用于编写全新功能和重大增强的规格说明。PRD应控制在1-2页，清晰传达业务逻辑和用户需求，不过度指定技术实现，使工程团队能够估算并开始构建，尽量减少反复沟通。”

这满足所有5个停止条件：

✅ 独特方法论 - 是（平衡业务逻辑与技术自由度）
✅ 清晰的质量标准 - 是（减少工程师的问题，便于估算）
✅ 具体约束 - 是（B2B SaaS，1-2页，重大功能）
✅ 具体示例 - 是（API速率限制功能，6→3小时）
✅ 排除替代任务 - 是（不是小型需求，不是高管文档）

准备进入步骤2：方法论研究。由于这是一个涉及沟通和判断的非技术类Skill，我建议使用计划模式来更细致地梳理方法论研究。我应该以计划模式继续吗？

用户：是的，继续。

助手：完美，范围足够具体了。由于这是一个涉及沟通和判断的非技术类Skill，我建议使用计划模式来更细致地梳理方法论研究。我应该以计划模式继续吗？

用户：是的，继续。

助手：[进入计划模式并构建研究方法]

让我系统地搜索面向工程师的PRD写作的最佳方法论。

[搜索：“PRD best practices expert”, “product requirements document methodology for engineers”, “best PRD examples B2B SaaS”]

我找到了几个强大的框架：

产品管理领域：

Marty Cagan（SVPG）：强调以问题为导向的PRD，区分问题空间和解决方案空间
Teresa Torres：持续发现，以结果为导向的需求

商务写作领域：

Barbara Minto：金字塔原理 - 结论先行，MECE结构
亚马逊：从新闻稿倒推，6页纸叙事格式

找到的优质示例：

Intercom的公开PRD模板
Linear的产品规格格式

常见错误（来自我的搜索）：

在定义问题之前就跳到解决方案
为工程师写作而非为对齐写作
缺少成功指标

让我深入研究原始来源以得出非常清晰的结论...

[继续搜索，直到方法论清晰明确]

这些方法中哪一个引起了您的共鸣？或者我需要更深入地搜索其中任何一个吗？

用户：我喜欢亚马逊的方法结合Cagan的以问题为导向的思路。你能找到更多关于亚马逊方法的细节吗？

助手：[搜索：“Amazon 6-pager template”, “Amazon working backwards methodology”, “Amazon PR FAQ process”]

[获取相关文章并提炼关键原则]

这是我从原始来源中找到的...

[经过全面的方法论研究后]

助手：在生成Skill之前，让我设计测试场景。让我们梳理多样的案例：

测试场景：

简单功能：为现有仪表板添加筛选器
复杂功能：新的AI驱动推荐引擎
边缘案例：需要重大后端架构变更的功能
失败模式：需要细化的模糊问题陈述

这涵盖了您通常编写的PRD范围吗？我们还应该测试其他场景吗？

用户：还要添加：需要跨团队协调的功能。

助手：很好的补充。现在我将调用skill-creator以正确格式生成Skill。

[调用：Skill工具，参数：skill: "skill-creator:skill-creator"]

skill-creator将引导我完成：

创建正确的YAML前置内容（名称、描述、model: opus）
以命令式写作
构建Skill目录
验证输出

[skill-creator完成后]

我已经生成了Skill。让我根据我们的场景进行测试...

[审查结果，识别差距，迭代优化]

[继续到步骤10：根据测试结果细化]