/methodology-curator

name: methodology-curator
description: 'Surface expert frameworks. Use when creating or evaluating skills, hooks, or agents.'
alwaysApply: false
category: meta-skills
tags:
- methodology
- frameworks
- expertise
- curation
- design
- evaluation
dependencies: []
estimated_tokens: 800

Methodology Curator

Overview

Identifying the best way to approach a domain is often more difficult than the technical scaffolding itself. This skill surfaces frameworks from domain masters to prevent reinventing established processes and identify methodology gaps in existing work. It should be used as a brief initial check before brainstorming or evaluation begins.

Workflow Integration

When starting new work, score every domain below by how many of its terms the task uses and load the top two modules, not the first that fits. Mapping free text onto a category runs about three candidates per correct one (TRIZ-GPT, arXiv 2408.05897, measured on contradiction parameters), so a single pick is wrong often enough that the second module is worth its tokens. Say which two were loaded and why the others were not. Select principles that fit your context and document them in a methodology brief before proceeding to creation.

For existing work, determine what the skill or hook is trying to teach and compare it against established frameworks. This gap analysis identifies opportunities to add missing principles or align terminology with recognized standards. Surgically add methodology rather than rewriting from scratch to maintain authority and effectiveness.

Domain Modules

Each module in the `modules/` directory provides a curated list of masters, key works, and actionable frameworks. These resources include selection guides and anti-patterns to avoid for each domain.

• **Instruction Design**: `modules/instruction-design.md` - Teaching techniques and behavioral objectives.
• **Code Review**: `modules/code-review.md` - Review methodologies and feedback patterns.
• **Debugging**: `modules/debugging.md` - Systematic troubleshooting frameworks.
• **Testing**: `modules/testing.md` - TDD masters and test design patterns.
• **Knowledge Management**: `modules/knowledge-management.md` - Note-taking and knowledge systems.
• **Decision Making**: `modules/decision-making.md` - Mental models and decision frameworks.

When to Skip

Skip for Creation when:

• You're implementing a well-defined spec
• The domain is highly specific to your codebase
• You've already researched methodologies externally
• Creating a simple utility with no pedagogical component

Skip for Evaluation when:

• Fixing syntax/structural issues (use `/validate-plugin` instead)
• The work is purely mechanical (no methodology to ground)
• Already performed a recent methodology audit
• Quick bug fixes that don't change the approach

When NOT To Use

• Scoring a finished skill (use `abstract:skills-eval`)
• The mechanics of writing one (use `abstract:skill-authoring`)

Domain Modules

Each module contains:

• **Masters**: Recognized experts in the domain
• **Key Works**: Essential books/papers/talks
• **Frameworks**: Actionable methodologies
• **Selection Guide**: When to use each approach
• **Anti-patterns**: What to avoid

Adding New Domains

To expand the masters database, create a new module following this template:

# [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]

Integration with Skill Authoring

After curating methodologies, the skill authoring workflow benefits from:

1. **Grounded TDD scenarios**: Test against the methodology's expected behaviors 2. **Principled anti-rationalization**: Counter excuses using the methodology's logic 3. **Authoritative references**: Cite masters in skill documentation 4. **Consistent terminology**: Use the methodology's vocabulary

Related

For Creation

• `/create-skill` - Skill creation workflow (use after this)
• `/create-hook` - Hook creation workflow
• `superpowers:brainstorming` - Refine approach after methodology selection
• `skill-authoring` - Detailed skill writing guidance

For Evaluation

• `/skills-eval` - Evaluate skill quality (complements methodology audit)
• `/analyze-skill` - Analyze skill complexity
• `pensive:code-reviewer` - Code review (uses code-review domain)

Exit Criteria

• [ ] The domain is identified by name (e.g., "Instruction Design", "Debugging") and at least one

module from `modules/` is loaded and consulted.

• [ ] A methodology brief is produced naming at least one expert, their key framework, and a

"Use When / Avoid When" statement applicable to the current work.

• [ ] If the task falls under a "Skip" condition (well-defined spec, purely mechanical fix), the

skip is stated explicitly rather than silently omitted.

• [ ] Any framework selected references one of the documented modules

(`instruction-design.md`, `code-review.md`, `debugging.md`, `testing.md`, `knowledge-management.md`, or `decision-making.md`) rather than an invented source.