Skill From Masters

Skill From Masters

创建像实战专家一样的skill，而不是像书呆子一样的skill。

核心理念

Skill是干活的。干活的知识来自实践，不是来自理论。

实践专家 vs 理论专家

我们要找的是实践专家——做得最好的人。理论专家只是辅助解释。

写书的人擅长总结和教学，但不一定是做得最好的。真正的高手往往不写书，但他们的案例、做法、踩过的坑，才是最有价值的。

所以：

❌ 错误：找写书的人 → 提取他们的理论 → 生成skill
✅ 正确：找做得最好的人 → 学习他们怎么做的 → 用理论辅助解释

工作流程

Step 1: 理解和收窄任务

确保任务足够具体。太宽泛的任务无法找到有效案例。

收窄方法： 1. 问领域：这个任务属于什么领域？ 2. 问场景：具体在什么情况下使用？ 3. 问约束：有什么限制条件？ 4. 问案例：能描述一个你实际遇到的情况吗？

收窄标准：

• 能找到这个具体场景的真实案例吗？
• 能判断什么是"做得好"什么是"做得差"吗？

如果答案是否，继续收窄。

---

Step 2: 找案例（最重要的步骤）⚠️

这是整个流程的核心。先找案例，不要先找理论。

2.1 找黄金案例（做得最好的人怎么做的）

关键：找实践中做得最好的人，不是写书的人。

搜索策略：

"[具体任务] top performer"
"[具体任务] how the best do it"
"[具体任务] real example from [top company]"
"[角色] who is the best at [任务]"
"[具体任务] interview with [practitioner]"
"[具体任务] behind the scenes"

目标：找到3-5个实践中公认做得好的真实案例。

识别实践专家的信号：

• 有具体的成果/数据（"成交率提升X%"、"客户满意度最高"）
• 被同行认可（"团队里大家都学他"）
• 有真实的案例细节，不是泛泛的原则

对于每个黄金案例，记录：

• 这个人具体是怎么做的？
• 和普通人做法有什么不同？
• 有什么具体的细节让他做得更好？

2.2 找失败案例（什么是做得差的）⚠️ 同样重要

搜索策略：

"[具体任务] common mistakes"
"[具体任务] what not to do"
"[具体任务] fails"
"[具体任务] I learned the hard way"
"[具体任务] before after comparison"
"why [具体任务] doesn't work"

目标：找到常见的失败模式和踩过的坑。

对于每个失败案例，记录：

• 具体做错了什么？
• 为什么这样做是无效的？
• 应该怎么做才对？

2.3 找对比（有效 vs 无效）

搜索策略：

"[具体任务] good vs bad example"
"[具体任务] before after"
"[具体任务] do this not that"
"[具体任务] comparison"

对比是最有价值的素材，因为它直接展示了差异。

案例收集标准：

• [ ] 找到至少3个黄金案例了吗？
• [ ] 找到至少5个常见失败模式了吗？
• [ ] 找到有效/无效的直接对比了吗？
• [ ] 案例足够具体，能看到实际细节吗？

如果任何一项答案是否，继续搜索。

---

Step 3: 归纳有效/无效模式

从案例中提炼规律，而不是从理论中推导。

归纳方法：

1. 列出所有黄金案例的共同点

• 它们都做了什么？
• 它们有什么共同的特征？
• 为什么这些做法是有效的？

2. 列出所有失败案例的共同点

• 它们都犯了什么错？
• 这些错误的根源是什么？
• 如何避免这些错误？

3. 形成对比表格

| 有效做法 | 无效做法 | 为什么 |
|----------|----------|--------|
| [具体做法A] | [对应的错误做法] | [原因] |
| [具体做法B] | [对应的错误做法] | [原因] |
| ... | ... | ... |

归纳标准：

• [ ] 每个有效做法都有对应的无效做法对比吗？
• [ ] 能用一句话说清楚"做这个，不要做那个"吗？
• [ ] 这些规律来自案例，而不是来自理论假设吗？

---

Step 4: 用理论辅助解释（可选）

理论专家（写书的人）在这一步才登场，作为辅助。

理论的作用是解释为什么实践专家的做法有效，而不是指导怎么做。

搜索策略：

"why [有效做法] works"
"[领域] psychology behind"
"[理论专家名] explains [现象]"

理论的价值：

• 给实践规律提供"为什么"的解释
• 帮助用户理解背后的逻辑
• 增加可信度

注意：

• 理论是辅助，不是主体
• 如果找不到理论解释，也没关系——实践专家的案例本身就是最好的证据
• 不要让理论盖过实践。Skill的核心应该是"做得最好的人怎么做"，而不是"书上怎么说"

---

Step 5: 生成Skill

将案例中归纳的规律转化为skill指令。

生成原则：

1. 用案例说话

• 每个规则都要有具体的"这样做"和"不要这样做"的例子
• 例子来自真实案例，不是编造的

2. 先说怎么做，再说为什么

• 用户首先需要知道该怎么做
• 理论解释放在后面

3. 失败案例和黄金案例同等重要

• 知道"不要做什么"往往比知道"要做什么"更实用
• 专门设置"常见错误"或"避免这样做"的章节

4. 保持具体

• 避免抽象的原则（如"要有同理心"）
• 用具体的做法替代（如"当用户说X时，回应Y而不是Z"）

调用skill-creator生成：

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

确保：

• 添加 model: opus（如果是需要判断力的skill）
• 包含黄金案例和失败案例的对比
• 用命令式语气写作

---

Step 6: 用案例测试

用真实案例测试生成的skill。

1. 拿一个黄金案例，看skill是否能产出类似质量的结果 2. 故意触发一个失败模式，看skill是否能避免 3. 让用户用自己的真实场景测试

如果测试失败，回到Step 2找更多案例。

---

搜索策略对比

❌ 旧的（偏理论）

"[domain] best practices expert"
"[domain] framework methodology"
"[expert name] methodology"
"[domain] principles"

这些搜索会返回书籍摘要、学术框架、抽象原则——都是"书本知识"。

✅ 新的（偏实践）

"[task] real example"
"[task] case study"
"[task] common mistakes"
"[task] what not to do"
"[task] before after"
"[task] I learned the hard way"
"how [company] does [task]"

这些搜索会返回真实案例、失败教训、对比——都是"实战知识"。

---

质量检查清单

在完成skill之前，确认：

案例质量：

• [ ] 找到了足够多的黄金案例（至少3个）？
• [ ] 找到了足够多的失败案例（至少5个常见错误）？
• [ ] 案例来自真实实践，不是理论假设？
• [ ] 案例足够具体，能看到实际细节？

归纳质量：

• [ ] 有效/无效做法形成了清晰的对比？
• [ ] 每个规则都有"做这个"和"不要做那个"的配对？
• [ ] 规律是从案例中归纳的，不是从理论中推导的？

Skill质量：

• [ ] Skill中包含了具体的例子，而不只是抽象原则？
• [ ] 失败案例和黄金案例都被体现了？
• [ ] 用真实案例测试过了？

最终检验：

• [ ] 这个skill像一个"做过无数次的老手"，还是像一个"读过很多书的人"？

---

示例：员工关怀Skill的正确做法

❌ 错误做法（旧流程）

1. 搜索"active listening methodology" 2. 找到卡尔·罗杰斯的三原则 3. 找到厚生劳动省的傾聴指南 4. 提取原则，生成skill 5. 结果：skill很学术，用户反馈"没有被关怀的感觉"

✅ 正确做法（新流程）

1. 搜索"employee care conversation example" 2. 搜索"what makes people feel heard" 3. 搜索"bad listening examples" 4. 搜索"therapist response good vs bad" 5. 找到大量真实对话对比：

• ❌ "您感到疲惫了呢" → 冷漠，像回音壁
• ✅ "怎么了？最近发生什么事了？" → 温暖，有兴趣

6. 归纳规律：

• 不要オウム返し（回音壁式重复）
• 要表现出真正的好奇心和关心
• 具体追问，而不是泛泛共情

7. 生成skill，包含大量"这样说 vs 不要这样说"的对比 8. 结果：skill有温度，用户感觉被关心

---

核心记住

1. 找做得最好的人，不是写书的人 — 实践专家 > 理论专家 2. 先案例，后理论 — 理论只是辅助解释 3. 黄金案例 + 失败案例 — 知道什么不能做，比知道什么能做更实用 4. 对比是最有价值的 — "这样做 vs 那样做"的对比最直观 5. Skill是干活的 — 生成的应该是"实战高手"，不是"读过很多书的人"

Methodology Database

A curated collection of proven methodologies from domain experts. Organized by domain for quick reference.

---

Writing & Communication

Business Writing

Persuasion & Copywriting

Storytelling

---

Product & Design

Product Management

User Research

Design

---

Sales & Marketing

Sales

Marketing

Pricing

---

Leadership & Management

Hiring

Feedback & Performance

Decision Making

Meetings

---

Engineering & Technology

Software Development

System Design

Engineering Culture

---

Startup & Entrepreneurship

Lean Startup

Scaling

---

Personal Effectiveness

Productivity

Thinking

---

Negotiation

---

Finance & Investing

---

Oral Tradition (No Books, But Documented)

These experts primarily share through talks, interviews, and social media:

---

How to Use This Database

1. Identify domains: Map your skill to 1-3 relevant domains above 2. Select experts: Choose 1-3 experts whose philosophy matches your goals 3. Go to sources: Use the source column to find primary material 4. Extract principles: Distill actionable rules from their frameworks 5. Resolve conflicts: If methodologies conflict, choose based on context or create synthesis

Expanding the Database

If a domain isn't covered: 1. Web search for "[domain] best practices expert" 2. Look for: books with 1000+ reviews, popular conference talks, influential practitioners 3. Identify their core framework or methodology 4. Add to the appropriate section

Skill Taxonomy: Non-Technical Skill Categories

This document defines a taxonomy for non-technical skills based on their core cognitive operation. Different skill types require different methodologies, quality criteria, and generation approaches.

Why Taxonomy Matters

Non-technical skills are NOT all the same. A "writing skill" and an "analysis skill" require fundamentally different:

• Methodologies to draw from
• Quality criteria to evaluate output
• Prompting strategies to generate effectively

Misclassifying a skill leads to mediocre results. For example:

• Treating an Insight task as Summary → Gets comprehensive but shallow output
• Treating a Decision task as Research → Gets information but no commitment

---

The Core Taxonomy

Overview Table

---

Detailed Definitions

1. 总结类 (Summary)

Core Operation: Compress

Essence: Reduce information volume while preserving coverage. The goal is completeness in fewer words.

Transformation: Many → Fewer (equal weight compression)

Example Output:

"The candidate has experience in: backend development (5 years),
microservices (3 projects), cloud platforms (AWS, GCP), and
some AI/ML exposure. Education includes CS degree from..."

Quality Criteria:

• Completeness: Did it cover all important aspects?
• Accuracy: Is the compression faithful to the original?
• Structure: Is it well-organized and scannable?

Methodology Sources:

• Barbara Minto (Pyramid Principle)
• MECE frameworks
• Information architecture

When to Use: When the user needs a comprehensive overview, not a judgment.

---

2. 洞察类 (Insight)

Core Operation: Extract the exceptional

Essence: Find the few signals that actually matter. Filter out noise to reveal meaning.

Transformation: Many → Few (finding what's decisive)

Analogy:

• Summary = Panoramic photo (everything visible, no focus)
• Insight = Finding the focal point (background fades)

Example Output:

"The KEY issue with this candidate: microservices experience
is real but language mismatch is significant. The AI claim
is likely superficial—no quantified results, vague language."

Quality Criteria:

• Depth: Does it answer WHY, not just WHAT?
• Prioritization: Are insights ranked by importance?
• Actionability: Can you act on this insight?

Methodology Sources:

• NN/g Data → Findings → Insights framework
• Signal detection theory
• Topgrading (A-player identification)

When to Use: When the user needs to understand what really matters, not everything.

---

3. 生成类 (Generation)

Core Operation: Create under constraints

Essence: Produce new content that didn't exist, while meeting requirements.

Transformation: Constraints/Requirements → New artifact

Example Tasks:

• Write a cold outreach email
• Draft a PRD
• Create a presentation

Quality Criteria:

• Fit: Does it meet all constraints?
• Effectiveness: Will it achieve its goal?
• Style: Is tone/voice appropriate for audience?

Methodology Sources:

• Domain-specific writing frameworks
• Copywriting principles (if persuasive)
• Genre conventions

When to Use: When the user needs content created, not analyzed.

---

4. 决策类 (Decision)

Core Operation: Choose and commit

Essence: Weigh trade-offs between incommensurable factors and make a choice.

Transformation: Options + Criteria → Selection + Rationale

Key Challenge: Factors often can't be directly compared (speed vs quality, cost vs risk).

Example Output:

"Recommendation: Go with Option B.

Rationale: While Option A is cheaper, Option B's
time-to-market advantage outweighs the 20% cost increase
given current competitive pressure."

Quality Criteria:

• Clarity: Is the recommendation unambiguous?
• Rationale: Is the reasoning explicit and logical?
• Trade-off acknowledgment: Are downsides stated?

Methodology Sources:

• MCDA (Multi-Criteria Decision Analysis)
• Decision matrices
• Bezos "one-way vs two-way door" framework

When to Use: When the user needs a choice, not more options.

---

5. 评估类 (Evaluation)

Core Operation: Judge against standards

Essence: Compare an artifact to ideal standards and identify gaps.

Transformation: Artifact → Quality judgment + Gap analysis

Example Tasks:

• Code review
• Proposal evaluation
• Performance assessment

Quality Criteria:

• Objectivity: Based on clear standards, not preference
• Specificity: Exact issues identified, not vague complaints
• Constructiveness: Actionable improvements suggested

Methodology Sources:

• Domain-specific quality frameworks
• Rubrics and evaluation criteria
• Best practice checklists

When to Use: When the user needs quality judgment, not creation.

---

6. 诊断类 (Diagnosis)

Core Operation: Trace back to root cause

Essence: Reason backward from symptoms to underlying causes.

Transformation: Symptoms/Problems → Root cause + Fix

Key Challenge: Not stopping at surface-level causes.

Example Output:

"The build is failing not because of the syntax error (that's
the symptom), but because the dependency update changed the
API signature. Fix: Pin dependency to v2.3.x or update all
call sites."

Quality Criteria:

• Depth: Did it find the TRUE root cause?
• Completeness: Are all contributing factors identified?
• Actionability: Is the fix clear and executable?

Methodology Sources:

• 5 Whys
• Fishbone diagrams
• Systems thinking

When to Use: When something is broken and needs fixing.

---

7. 说服类 (Persuasion)

Core Operation: Bridge worldviews

Essence: Connect your goal to their action by understanding their mental model.

Transformation: My goal + Their worldview → Message that moves them

Key Challenge: Understanding what they already believe, fear, and want.

Example Tasks:

• Sales pitch
• Stakeholder buy-in
• Negotiation

Quality Criteria:

• Audience fit: Does it speak to THEIR concerns?
• Credibility: Is it believable?
• Call to action: Is next step clear?

Methodology Sources:

• Cialdini (Influence)
• SPIN Selling
• Aristotle's Rhetoric (Ethos, Pathos, Logos)

When to Use: When the user needs to change someone's mind or behavior.

---

8. 规划类 (Planning)

Core Operation: Decompose into steps

Essence: Break a goal into a sequence of achievable milestones.

Transformation: Goal → Path with milestones + Dependencies

Key Challenge: Right level of detail, handling uncertainty.

Example Output:

"Phase 1 (Week 1-2): Research & Design
  - Define API contract
  - Design database schema
Phase 2 (Week 3-4): Implementation
  - Core CRUD operations
  - Authentication integration
..."

Quality Criteria:

• Completeness: Are all necessary steps included?
• Sequencing: Are dependencies correct?
• Granularity: Right level of detail for the audience?

Methodology Sources:

• Work breakdown structures
• Agile planning
• Critical path analysis

When to Use: When the user needs a roadmap, not just a goal.

---

9. 调研类 (Research)

Core Operation: Discover and structure

Essence: Explore unknown territory and return with organized knowledge.

Transformation: Questions → Structured answers with sources

Key Challenge: Knowing when you have "enough", avoiding confirmation bias.

Example Tasks:

• Market research
• Competitive analysis
• Technology evaluation

Quality Criteria:

• Coverage: Were enough sources consulted?
• Objectivity: Is it balanced, not cherry-picked?
• Structure: Is knowledge organized usefully?

Methodology Sources:

• Research methodology
• Source evaluation frameworks
• Synthesis techniques

When to Use: When the user needs knowledge gathered, not generated.

---

10. 引导类 (Facilitation)

Core Operation: Elicit through questions

Essence: Help others surface their own knowledge through skilled questioning.

Transformation: Hidden/tacit knowledge → Explicit, articulated knowledge

Key Challenge: Not leading too much (bias) or too little (missing key info).

Example Tasks:

• User interviews
• Requirements elicitation
• Coaching conversations

Quality Criteria:

• Depth: Did it surface non-obvious information?
• Neutrality: Avoided leading questions?
• Completeness: Covered all important areas?

Methodology Sources:

• Mom Test (Rob Fitzpatrick)
• Motivational Interviewing
• SPIN Selling (for discovery)

When to Use: When the user needs to extract information from others.

---

11. 转化类 (Transformation)

Core Operation: Map between representations

Essence: Convert from one format/perspective to another while preserving meaning.

Transformation: Format A → Format B (isomorphic mapping)

Key Challenge: Knowing what to preserve vs. adapt.

Example Tasks:

• Technical → Business translation
• Meeting → Action items
• Long-form → Executive summary

Quality Criteria:

• Fidelity: Is essential meaning preserved?
• Fit: Is output appropriate for target format?
• Clarity: Is it clear in the new format?

Methodology Sources:

• Translation theory
• Information design
• Audience adaptation

When to Use: When content exists but needs reformatting or re-framing.

---

How to Use This Taxonomy

Step 1: Identify the Skill Type

When a user requests a skill, first determine its type:

Step 2: Validate with User

Confirm the type with the user:

"It sounds like you need an INSIGHT-type skill (finding what really
matters) rather than a SUMMARY-type skill (comprehensive overview).
Is that right?"

Step 3: Apply Type-Specific Generation

Use appropriate:

• Methodology sources for that type
• Quality criteria for that type
• Output format conventions for that type

---

Common Confusions

---

Version History

• v1.0 (2026-01-21): Initial taxonomy with 11 types