Methodology Curator

Table of Contents

• Overview
• Workflow Integration
• Domain Modules
• When to Skip
• Masters Overview
• Selection Matrix

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, identify the domain (e.g., Instruction Design, Code Review, or Knowledge Management) and consult the corresponding module in modules/ to discover experts and their frameworks. 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.