methodology-curator

方法论策展

概述

找到处理某个领域的最佳方法，往往比技术层面的搭建本身更困难。这项技能从领域大师的成果中提炼框架，以避免重新发明已有流程，并找出现有工作中的方法论缺口。在开始头脑风暴或评估之前，应将其用作简短的初步检查。

工作流集成

开始新工作时，根据任务使用了多少相关术语，为下方每个领域评分，并加载得分最高的两个模块，而不是只加载第一个看起来合适的模块。将自由文本映射到某个类别时，每找到一个正确候选项，通常会有三个候选项（TRIZ-GPT、arXiv 2408.05897，在矛盾参数上测得），因此只选一个往往容易出错，值得多花一些 token 加载第二个模块。说明加载了哪两个模块，以及为何没有加载其他模块。选择适合当前情境的原则，并在开始创作之前将其记录在方法论简报中。

对于已有工作，判断这项技能或钩子试图传授什么，并将其与既有框架进行比较。这种差距分析可以发现补充缺失原则或使术语与公认标准保持一致的机会。应有针对性地补充方法论，而不是从头重写，以保持权威性和有效性。

领域模块

modules/ 目录中的每个模块都提供经过筛选的大师、重要作品和可操作框架清单。这些资源还包括各领域的选择指南和应避免的反模式。

• 指令设计：modules/instruction-design.md - 教学技巧和行为目标。
• 代码审查：modules/code-review.md - 审查方法和反馈模式。
• 调试：modules/debugging.md - 系统化故障排查框架。
• 测试：modules/testing.md - TDD 大师和测试设计模式。
• 知识管理：modules/knowledge-management.md - 笔记记录和知识体系。
• 决策：modules/decision-making.md - 心智模型和决策框架。

何时跳过

创建时跳过：

• 正在实现定义明确的规范
• 该领域高度特定于你的代码库
• 你已在外部研究过相关方法论
• 正在创建不含教学成分的简单工具

评估时跳过：

• 修复语法或结构问题（改用 /validate-plugin）
• 工作纯属机械操作（没有需要依据的方法论）
• 最近已进行过方法论审查
• 不改变处理方法的快速 Bug 修复

何时不要使用

• 为已完成的技能评分（使用 abstract:skills-eval）
• 编写技能的具体机制（使用 abstract:skill-authoring）

领域模块

每个模块都包含：

• 大师：该领域公认的专家
• 重要作品：必读书籍、论文或演讲
• 框架：可操作的方法论
• 选择指南：何时使用每种方法
• 反模式：应避免的做法

添加新领域

要扩展大师数据库，请按此模板创建新模块：

# [Domain Name] Masters

## Masters Overview
| Expert | Key Contribution | Best For |
|--------|-----------------|----------|
| Name   | Framework/Book  | Context  |

## Detailed Frameworks

### [Framework 1]
**Source**: [Expert] - [Work]
**Core Idea**: [One sentence]
**Key Principles**:
- Principle 1
- Principle 2
**Use When**: [Context]
**Avoid When**: [Anti-context]

## Selection Matrix
[Decision guide for choosing between frameworks]

与技能编写的集成

整理好方法论后，技能编写工作流可以从以下方面受益：

1. 有依据的 TDD 场景：针对方法论预期的行为进行测试
2. 有原则的反合理化：运用方法论的逻辑反驳借口
3. 权威参考资料：在技能文档中引用大师
4. 术语一致性：使用该方法论的词汇

相关内容

创建

• /create-skill - 技能创建工作流（在此步骤之后使用）
• /create-hook - 钩子创建工作流
• superpowers:brainstorming - 方法论选择后优化处理思路
• skill-authoring - 详细的技能编写指南

评估

• /skills-eval - 评估技能质量（补充方法论审查）
• /analyze-skill - 分析技能复杂度
• pensive:code-reviewer - 代码审查（使用代码审查领域模块）

退出标准

• 按名称识别领域（例如“指令设计”“调试”），并加载和参考 modules/ 中至少一个模块。
• 编写方法论简报，其中列出至少一位专家、其核心框架，以及适用于当前工作的“适用时机／避免时机”说明。
• 如果任务符合“跳过”条件（规范定义明确、纯机械性修复），则明确说明跳过，而不是默默省略。
• 所选框架必须引用已记录的模块之一（instruction-design.md、code-review.md、debugging.md、testing.md、knowledge-management.md 或 decision-making.md），不得引用虚构来源。