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

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
• /bulletproof-skill - Harden against rationalization
• pensive:code-reviewer - Code review (uses code-review domain)

Code Review Masters

Expert frameworks for conducting effective code reviews, providing constructive feedback, and improving code quality through review processes.

Masters Overview

Detailed Frameworks

Google's Code Review Standards

Source: Google Engineering Practices Documentation (public)

Core Idea: Reviews should improve code health while enabling progress.

Key Principles:

• Speed matters: Review within 24 hours, ideally same day
• Small changes: Prefer small, focused CLs (changelists)
• Approve if better: Don't block for perfection
• Distinguish severity: Nit vs. suggestion vs. blocker

The Standard:

"Reviewers should approve a CL once it definitely improves overall code health, even if it isn't perfect."

Comment Prefixes:

Nit:      Minor style preference, optional
Suggest:  Improvement idea, author decides
Consider: Worth thinking about, not blocking
BLOCKING: Must fix before approval

Use When: Establishing team review standards, training reviewers.

Avoid When: Security-critical code (needs stricter process).

---

Fowler's Refactoring Patterns

Source: Martin Fowler - "Refactoring" (1999, 2nd ed. 2018)

Core Idea: Catalog of named transformations for improving code structure.

Review Application: Use pattern names as shared vocabulary in reviews.

High-Value Patterns for Reviews:

Use When: Providing actionable refactoring suggestions.

---

Feathers' Legacy Code Strategies

Source: Michael Feathers - "Working Effectively with Legacy Code" (2004)

Core Idea: "Legacy code is code without tests." Review for testability.

Key Review Questions: 1. Seams: Are there places to substitute behavior for testing? 2. Dependencies: Can this be tested in isolation? 3. Characterization: Would a test capture current behavior?

The Legacy Change Algorithm: 1. Identify change points 2. Find test points 3. Break dependencies 4. Write tests 5. Make changes

Review Comments for Legacy:

"Before modifying this, consider adding a characterization test"
"This method has too many dependencies. Can we inject the database?"
"Consider introducing a seam here for testability"

Use When: Reviewing changes to untested code.

---

Wiegers' Peer Review Types

Source: Karl Wiegers - "Peer Reviews in Software" (2002)

Core Idea: Match review intensity to risk level.

Review Spectrum:

Defect Detection Rates:

• Inspection: 60-90% of defects found
• Walkthrough: 20-40%
• Testing alone: 25-35%

Use When: Deciding review depth for different code types.

---

Gee's Practical Code Review

Source: Trisha Gee - Various talks and articles (JetBrains)

Core Idea: Reviews should be humane and focused on learning.

Key Principles:

• Automate the boring stuff: Linting, formatting, style → CI
• Focus human attention: Logic, design, readability
• Be kind: Criticize code, not people
• Ask questions: "What was the thinking here?" vs "This is wrong"

Comment Formulas:

Instead of: "This is wrong"
Try:        "I'm curious: what led to this approach?"

Instead of: "Use X pattern"
Try:        "Have you considered X? It might help with Y"

Instead of: "This will break"
Try:        "What happens if input is null here?"

Feedback Categories: 1. Bugs: Logic errors, edge cases 2. Design: Coupling, cohesion, patterns 3. Readability: Naming, structure, comments 4. Learning: Knowledge sharing opportunities

Use When: Writing constructive review feedback, training reviewers.

Selection Matrix

Review Checklist Template

Based on blended frameworks:

## Quick Checks (Automate These)
- [ ] Passes linting
- [ ] Passes tests
- [ ] No merge conflicts

## Human Review Focus
### Correctness
- [ ] Logic handles edge cases
- [ ] Error handling appropriate

### Design (Fowler)
- [ ] No obvious code smells
- [ ] Single responsibility followed
- [ ] Dependencies reasonable

### Testability (Feathers)
- [ ] New code has tests
- [ ] Changes don't break test isolation
- [ ] Can test in isolation

### Readability (Gee)
- [ ] Names reveal intent
- [ ] Comments explain "why" not "what"
- [ ] Complexity appropriate

Anti-Patterns to Avoid

• Nitpick storms: Dozens of style comments (use linters)
• Rubber stamping: Approving without reading
• Gatekeeping: Using reviews to block or control
• Scope creep: Requesting unrelated changes
• Delayed reviews: Blocking progress for days

Debugging Masters

Expert frameworks for systematic troubleshooting, root cause analysis, and efficient bug resolution.

Masters Overview

Detailed Frameworks

Zeller's Scientific Debugging

Source: Andreas Zeller - "Why Programs Fail" (2009)

Core Idea: Apply scientific method to debugging: hypothesis, experiment, conclusion.

The Scientific Debugging Process:

1. OBSERVE failure
2. HYPOTHESIZE cause (be specific!)
3. PREDICT behavior if hypothesis true
4. EXPERIMENT to test prediction
5. CONCLUDE: confirmed or refuted
6. REPEAT with new hypothesis

Key Principle: Never change code to "see if it fixes it." That's guessing, not debugging.

Hypothesis Quality:

BAD:  "Something's wrong with the database"
GOOD: "The query times out because it scans all rows without index"

Delta Debugging (Zeller's technique):

• Minimize failing input
• Find smallest change that triggers bug
• Isolate exactly what causes failure

Use When: Complex bugs, intermittent failures, need systematic approach.

---

Agans' Nine Rules

Source: David Agans - "Debugging: The 9 Indispensable Rules" (2002)

Core Idea: Universal rules that apply to any debugging scenario.

The Nine Rules:

Most Violated Rules:

• #3: Jumping to hypotheses without reading the actual error
• #5: Changing multiple things hoping something works
• #9: Seeing issue disappear and assuming it's fixed

Use When: Any debugging situation; these are universal.

---

Spinellis' Debugging Strategies

Source: Diomidis Spinellis - "Effective Debugging" (2016)

Core Idea: Thorough toolkit organized by debugging phase.

Strategy Categories:

High-Level Strategies:

Technical Strategies:

Process Strategies:

Use When: Need specific technique for specific problem type.

---

Miller's Debugging Questions

Source: Rob Miller (MIT) - Debugging lectures

Core Idea: Systematic questioning reveals root cause.

The Question Ladder:

1. What did you expect to happen? 2. What actually happened? 3. What's the difference? 4. When did it last work? 5. What changed since then? 6. Where exactly does behavior diverge from expectation?

Localization Questions:

• At what point does the state become incorrect?
• What is the last known good state?
• What is the first known bad state?

Use When: Starting any debugging session, structuring investigation.

---

Regehr's Low-Level Debugging

Source: John Regehr - Embedded Systems & Compiler Expert

Core Idea: Systems-level bugs need systems-level thinking.

Principles:

• Trust nothing: Verify compiler output, hardware state
• Reduce: Minimize to smallest reproducer
• Isolation: Test components independently
• Invariants: Assert what must be true

Common Systems Bug Categories:

Use When: Low-level, systems, or intermittent bugs.

Selection Matrix

Debugging Workflow Template

Blended from all frameworks:

## Bug: [Brief description]

### 1. Understand & Reproduce (Agans #1, #2)
- System understanding: [What should happen]
- Reproduction steps:
  1. [Step]
  2. [Step]
- Reproduction rate: [Always/Sometimes/Rare]

### 2. Observe (Agans #3, Miller)
- Expected: [What should happen]
- Actual: [What happens]
- Difference: [Gap]
- Last working: [When/version]

### 3. Hypothesize (Zeller)
| # | Hypothesis | Prediction | Test | Result |
|---|------------|------------|------|--------|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |

### 4. Isolate (Agans #4, #5)
- Binary search log:
  - [✓] Works at commit abc123
  - [✗] Fails at commit def456
  - Narrowed to: [specific change]

### 5. Fix & Verify (Agans #9)
- Root cause: [Actual cause]
- Fix: [What changed]
- Verification: [How confirmed]
- Regression test added: [Yes/No]

Anti-Patterns to Avoid

• Shotgun debugging: Changing random things hoping to fix it
• Assumption debugging: Not verifying basic assumptions (Agans #7)
• Tunnel vision: Fixating on one hypothesis without testing others
• History blindness: Not checking what recently changed
• Solo heroics: Not asking for help when stuck (Agans #8)
• Premature celebration: Assuming it's fixed without proof (Agans #9)

Decision Making Masters

Expert frameworks for making better decisions, avoiding cognitive biases, and developing reliable judgment.

Masters Overview

Detailed Frameworks

Munger's Mental Models

Source: Charlie Munger - "Poor Charlie's Almanack", Berkshire letters

Core Idea: Build a latticework of mental models from multiple disciplines; use them in combination.

Key Mental Models:

Inversion Technique:

Instead of: "How do I succeed?"
Ask:        "How would I guarantee failure?"
Then:       Avoid those things

Instead of: "How do I make a great skill?"
Ask:        "What makes skills terrible?"
Then:       Eliminate those patterns

Use When: Complex decisions, need diverse perspectives, avoiding blind spots.

---

Kahneman's System 1/System 2

Source: Daniel Kahneman - "Thinking, Fast and Slow" (2011)

Core Idea: Two thinking systems with different strengths and failure modes.

The Two Systems:

Key Biases to Counter:

Pre-Mortem Technique:

Imagine the project has failed spectacularly.
Write the story of why it failed.
Now prevent those things.

Use When: Need to check intuitions, high-stakes decisions, avoiding biases.

---

Klein's Recognition-Primed Decision (RPD)

Source: Gary Klein - "Sources of Power" (1998)

Core Idea: Experts don't compare options; they recognize patterns and simulate actions.

How Experts Decide:

1. Recognize situation type (pattern match)
2. Identify typical action for situation
3. Mental simulation: "If I do this, what happens?"
4. If simulation works → act
5. If problems → modify or consider next option

Key Insight: Experts rarely compare options analytically. They satisfice, not optimize.

When to Trust Intuition:

Use When: Time pressure, experienced domain, need fast action.

---

Duke's Thinking in Bets

Source: Annie Duke - "Thinking in Bets" (2018)

Core Idea: Decisions are bets about the future; separate decision quality from outcome quality.

Key Principles:

• Resulting: Judging decision by outcome is wrong
• Uncertainty: All decisions are probabilistic
• Expected value: Probability × payoff

Decision Quality vs. Outcome Quality:

                    OUTCOME
                Good        Bad
         Good   Deserved    Bad luck
DECISION        win         (learn nothing)
         Bad    Good luck   Deserved
                (dangerous) loss

The 10-10-10 Rule:

How will I feel about this decision:
- 10 minutes from now?
- 10 months from now?
- 10 years from now?

Decision Groups:

• Find truth-seeking group
• Agree to criticize ideas, not people
• Reward process, not outcome
• Update beliefs openly

Use When: Uncertain outcomes, need to separate luck from skill.

---

Dalio's Principles

Source: Ray Dalio - "Principles" (2017)

Core Idea: Make decisions through explicit principles; radical transparency.

The Idea Meritocracy:

Best ideas win, regardless of source
Believability-weighted voting
Radical transparency in reasoning

Decision-Making Process: 1. Perceive problems accurately 2. Diagnose root causes 3. Design solutions (principles) 4. Do (execute) 5. Document as principle for future

Believability Weighting:

Not all opinions equal. Weight by:
- Track record in relevant area
- Demonstrated reasoning ability
- Appropriate confidence level

Radical Transparency Questions:

• What don't I know?
• Who can help me see blind spots?
• What would change my mind?

Use When: Team decisions, building organizational processes, documenting decisions.

Selection Matrix

Decision Framework Template

Blended approach for important decisions:

## Decision: [Brief statement]

### 1. Frame (Munger + Kahneman)
- What's the actual decision?
- Inversion: How would I guarantee failure?
- What am I not seeing? (availability bias check)

### 2. Generate Options
- Option A: [description]
- Option B: [description]
- Option C: Do nothing / wait

### 3. Evaluate (Duke + Klein)
| Option | Probability of Success | Upside | Downside | Expected Value |
|--------|----------------------|--------|----------|----------------|
| A | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |
| B | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |
| C | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |

### 4. Pre-Mortem (Kahneman)
If this fails, it will be because:
1. [Risk 1]
2. [Risk 2]
Mitigations: [How to prevent]

### 5. Decide & Document (Dalio)
**Decision**: [Choice]
**Reasoning**: [Why this option]
**Confidence**: [High/Medium/Low]
**Review date**: [When to evaluate]

### 6. Post-Decision (Duke)
**Outcome**: [What happened]
**Was decision quality good?**: [Separate from outcome]
**What to learn**: [Principle for future]

For Scope-Guard / Imbue Plugin

Specific applications:

Anti-Patterns to Avoid

• Analysis paralysis: Perfect information doesn't exist
• Resulting: Judging decisions by outcomes alone
• Consensus seeking: Agreement ≠ correctness
• Confidence = competence: Loudest isn't rightest
• Single model thinking: One mental model isn't enough
• Ignoring base rates: Your situation probably isn't special

Instruction Design Masters

Expert frameworks for teaching techniques, writing effective instructions, and creating behavioral change through documentation.

Masters Overview

Detailed Frameworks

Mager's Behavioral Objectives

Source: Robert Mager - "Preparing Instructional Objectives" (1962)

Core Idea: Objectives must specify observable behavior, conditions, and criteria.

Key Principles:

• Performance: What the learner will DO (observable verb)
• Conditions: Under what circumstances (tools, constraints)
• Criterion: How well (accuracy, speed, quality threshold)

Formula: "Given [conditions], the learner will [performance] to [criterion]."

Example for Skills:

BAD:  "Understand TDD methodology"
GOOD: "Given a failing test, implement minimal code to pass within 3 iterations"

Use When: Creating technique skills, defining success criteria, writing "Use when" clauses.

Avoid When: Teaching abstract concepts, pattern recognition, creative tasks.

---

Bloom's Taxonomy (Revised)

Source: Benjamin Bloom et al., revised by Anderson & Krathwohl (2001)

Core Idea: Learning has hierarchical levels; target the right cognitive level.

Levels (lowest to highest): 1. Remember: Recall facts → Reference skills, checklists 2. Understand: Explain concepts → Pattern skills, mental models 3. Apply: Use in new situations → Technique skills, workflows 4. Analyze: Break down, find patterns → Debugging skills, code review 5. Evaluate: Judge, critique → Assessment frameworks, quality gates 6. Create: Produce new work → Design skills, architecture guidance

Use When: Determining skill type, structuring progressive disclosure, setting appropriate depth.

Skill Mapping:

---

Gagné's Nine Events of Instruction

Source: Robert Gagné - "The Conditions of Learning" (1965)

Core Idea: Effective instruction follows nine sequential events.

The Nine Events: 1. Gain attention: Hook with problem or scenario 2. Inform objectives: State what they'll learn (Use when clause) 3. Stimulate recall: Connect to prior knowledge 4. Present content: The actual instruction 5. Provide guidance: Examples, worked problems 6. Elicit performance: Practice opportunity 7. Provide feedback: Correct/reinforce 8. Assess performance: Verify learning 9. Enhance retention: Transfer to real contexts

Skill Structure Mapping:

SKILL.md Structure           Gagné Event
─────────────────────────────────────────
Overview/Problem statement → 1. Gain attention
"Use when" clause          → 2. Inform objectives
Related skills/prereqs     → 3. Stimulate recall
Core content               → 4. Present content
Examples                   → 5. Provide guidance
Workflows/checklists       → 6. Elicit performance
Anti-patterns/red flags    → 7. Provide feedback
Validation commands        → 8. Assess performance
Real-world scenarios       → 9. Enhance retention

Use When: Designing complete skill structure, ensuring nothing essential is missing.

---

Cognitive Load Theory

Source: John Sweller - "Cognitive Load Theory" (1988)

Core Idea: Working memory is limited; reduce unnecessary load.

Three Types of Load:

• Intrinsic: Complexity inherent to the material (can't reduce)
• Extraneous: Poor presentation adding confusion (ELIMINATE)
• Germane: Effort building mental models (MAXIMIZE)

Techniques for Skills:

Use When: Optimizing token efficiency, structuring modules, deciding what to cut.

---

Clark's Evidence-Based Training

Source: Ruth Clark - "Evidence-Based Training Methods" (2019)

Core Idea: Use research-proven methods, not intuition.

Key Findings:

• Examples beat descriptions: Show, don't tell
• Practice with feedback: Interactive > passive reading
• Spaced learning: Break into digestible chunks
• Relevant context: Real scenarios > abstract theory

Anti-patterns (feel effective but aren't):

• Long prose explanations
• Thorough coverage without practice
• Learning styles myths (visual/auditory)
• Information dumps

Use When: Reviewing skills for effectiveness, cutting unnecessary content.

Selection Matrix

Blending Example

Creating a debugging skill: 1. Bloom: Target "Analyze" level (break down, identify patterns) 2. Mager: "Given error output, identify root cause within 3 hypotheses" 3. Cognitive Load: Use worked examples, progressive modules 4. Gagné: Structure with attention hook → examples → practice workflow

Anti-Patterns to Avoid

• Covering everything: Cognitive overload, low retention
• Vague objectives: "Understand debugging" (not measurable)
• Missing practice: All theory, no application
• Wrong level: Teaching "remember" when "apply" is needed

Knowledge Management Masters

Expert frameworks for capturing, organizing, connecting, and retrieving knowledge effectively.

Masters Overview

Detailed Frameworks

Luhmann's Zettelkasten

Source: Niklas Luhmann - Sociologist, 70+ books, 90,000+ notes

Core Idea: Atomic notes with explicit links create a "conversation partner" that surfaces unexpected connections.

Key Principles:

• Atomicity: One idea per note
• Linking: Notes connect to other notes, not just categories
• Own words: Rewrite in your understanding, never copy
• Unique identifiers: Every note has permanent address
• Emergence: Structure emerges from links, not imposed hierarchy

Note Types:

The Process:

1. Capture fleeting notes throughout day
2. Process into permanent notes (rewrite, atomize)
3. Link to existing notes (where does this connect?)
4. Add to structure notes (entry points)
5. Review and discover connections

Use When: Building long-term knowledge base, research, writing projects.

---

Ahrens' Smart Notes

Source: Sönke Ahrens - "How to Take Smart Notes" (2017)

Core Idea: Writing is thinking; note-taking should support writing output.

Key Principles:

• Writing as thinking: You don't write up ideas, you think through writing
• Bottom-up structure: Let topics emerge from notes
• Slip-box as partner: External thinking system
• Focus on output: Notes serve future writing

The Workflow:

Reading → Fleeting Notes → Literature Notes → Permanent Notes → Writing

Quality Criteria for Permanent Notes:

• Could someone else understand it without context?
• Is it written in complete sentences?
• Does it stand on its own?
• Does it connect to existing notes?

Writing Process: 1. Collect relevant permanent notes 2. Arrange in sequence 3. Turn sequence into draft 4. Edit and refine

Use When: Academic writing, knowledge synthesis, developing arguments.

---

Bush's Memex & Associative Trails

Source: Vannevar Bush - "As We May Think" (1945)

Core Idea: Human mind works by association; tools should support trails of thought.

Key Concepts:

• Associative indexing: Link by meaning, not alphabet
• Trails: Paths through information, shareable
• Personal library: All knowledge accessible, connected
• Selection vs. creation: Value in curating paths

Modern Applications:

Use When: Designing knowledge systems, understanding hypertext principles.

---

Allen's GTD (Getting Things Done)

Source: David Allen - "Getting Things Done" (2001)

Core Idea: Capture everything; mind is for having ideas, not holding them.

The Five Steps:

1. CAPTURE    - Get everything out of your head
2. CLARIFY    - What is it? Is it actionable?
3. ORGANIZE   - Put it where it belongs
4. REFLECT    - Review regularly
5. ENGAGE     - Do with confidence

The Two-Minute Rule: If it takes less than 2 minutes, do it now.

Clarify Decision Tree:

Is it actionable?
├── NO → Reference, Someday/Maybe, or Trash
└── YES → What's the next action?
    ├── Multi-step? → It's a Project
    └── Single step?
        ├── <2 min? → Do it now
        ├── Delegate? → Waiting For
        └── Defer? → Next Actions (by context)

Use When: Action-oriented knowledge, task management, reducing cognitive load.

---

Forte's PARA & Second Brain

Source: Tiago Forte - "Building a Second Brain" (2022)

Core Idea: Organize by actionability, not topic. Progressive summarization for retrieval.

PARA System:

Progressive Summarization:

Layer 0: Original source
Layer 1: Bolded passages (10-20%)
Layer 2: Highlighted from bold (10-20% of bold)
Layer 3: Executive summary (your words)
Layer 4: Remix (original synthesis)

CODE Method:

• Capture: Save resonant information
• Organize: Put in PARA folder
• Distill: Progressive summarization
• Express: Create output

Use When: Digital knowledge management, balancing capture and retrieval.

Selection Matrix

Knowledge System Template

Blended approach for a knowledge base:

## Knowledge System Design

### Capture Layer (GTD + PARA)
- Inbox: Quick capture without friction
- Two-minute rule for processing
- Daily processing to zero

### Organization (PARA + Zettelkasten)
- Projects: Active work with deadlines
- Areas: Ongoing responsibilities
- Notes: Atomic, linked permanent notes
- Archive: Completed/inactive

### Connection (Zettelkasten)
- Every note links to 2+ existing notes
- Structure notes (MOCs) for entry points
- Tags for cross-cutting themes
- Regular gardening/review

### Output (Ahrens + Progressive Summary)
- Progressive summarization of sources
- Assemble notes for projects
- Write from accumulated notes

For Memory-Palace Plugin

Specific applications:

Anti-Patterns to Avoid

• Collector's fallacy: Saving without processing
• Tagging obsession: Tags without links
• Hierarchy prison: Rigid folders killing discovery
• Perfect system seeking: Setup > usage
• Copy-paste notes: No rewriting = no understanding
• Orphan notes: Notes without connections die

Testing & TDD Masters

Expert frameworks for test-driven development, test design, and building confidence in code through systematic verification.

Masters Overview

Detailed Frameworks

Beck's Test-Driven Development

Source: Kent Beck - "Test-Driven Development: By Example" (2002)

Core Idea: Write failing test first, then minimal code to pass, then refactor.

The TDD Cycle:

RED    → Write failing test (design the interface)
GREEN  → Write minimal code to pass (make it work)
REFACTOR → Improve code (make it right)
REPEAT

Key Principles:

• Test first, not test after: Tests drive design
• Small steps: One assertion, one tiny change
• Minimal code: Only enough to pass the test
• Continuous refactoring: Clean as you go

Beck's Three Laws of TDD: 1. Don't write production code until you have a failing test 2. Don't write more test than sufficient to fail 3. Don't write more production code than sufficient to pass

Use When: Greenfield development, clear requirements, need design guidance.

Avoid When: Exploratory prototyping, highly uncertain domains.

---

Freeman & Pryce's Outside-In TDD (GOOS)

Source: "Growing Object-Oriented Software, Guided by Tests" (2009)

Core Idea: Start from acceptance tests, work inward, discover design.

The Double Loop:

flowchart LR
    subgraph outer["Outer Loop (Acceptance)"]
        a1["1. Write failing<br/>acceptance test"]
        a2["2. When acceptance<br/>passes, next feature"]
    end
    subgraph inner["Inner Loop (Unit)"]
        u1["1. Write failing unit test"]
        u2["2. Make it pass"]
        u3["3. Refactor"]
        u4["4. Next unit..."]
    end

    a1 --> u1
    u1 --> u2 --> u3 --> u4
    u4 -.-> u1
    u4 --> a2
    a2 -.-> a1

    style outer fill:#e3f2fd,stroke:#1976d2
    style inner fill:#fff8e1,stroke:#ffa000

Key Principles:

• Outside-in: Start at edges (UI/API), work toward core
• Mock at boundaries: Use mocks to discover collaborators
• Listen to tests: Painful tests reveal design problems
• Walking skeleton: First test is end-to-end (thin vertical slice)

Design Discovery:

"When we write a test, we're designing the API we want to use."
"Mocks tell us what collaborators we need."

Use When: Complex systems, need design guidance, object-oriented code.

---

Meszaros' xUnit Test Patterns

Source: Gerard Meszaros - "xUnit Test Patterns" (2007)

Core Idea: Catalog of patterns for well-designed, maintainable tests.

Test Structure (Four-Phase):

1. SETUP    - Establish preconditions
2. EXERCISE - Execute behavior under test
3. VERIFY   - Check expected outcomes
4. TEARDOWN - Clean up (often implicit)

Key Patterns:

Test Smells:

Use When: Test suite is growing complex, tests becoming maintenance burden.

---

Feathers' Legacy Code Techniques

Source: Michael Feathers - "Working Effectively with Legacy Code" (2004)

Core Idea: "Legacy code is code without tests." Strategies to add them.

Definition: Legacy code = code without tests (regardless of age)

The Legacy Code Change Algorithm: 1. Identify change points 2. Find test points 3. Break dependencies 4. Write characterization tests (capture current behavior) 5. Make changes and refactor

Key Techniques:

Seam Types (places to inject test behavior):

• Object seams: Override in subclass
• Compile seams: Swap at build time
• Link seams: Swap libraries

Use When: Adding tests to existing codebase, modifying untested code.

---

Bach & Bolton's Exploratory Testing

Source: James Bach & Michael Bolton - Rapid Software Testing

Core Idea: Skilled, intentional exploration guided by heuristics, not scripts.

Key Concepts:

• Testing vs. Checking: Testing = exploration, Checking = verification
• Heuristics: Guidelines, not rules
• Session-based: Timeboxed, focused exploration
• Charter: Goal for exploration session

SFDPOT Heuristic (what to test):

Use When: Need human judgment, can't specify all cases, exploring new features.

Selection Matrix

TDD Workflow Template

Blended from Beck and Freeman:

## Feature: [Name]

### Acceptance Criteria (Outer Loop)
- [ ] Given [context], when [action], then [outcome]

### Implementation Plan

#### Cycle 1
**RED**:
- Test: `test_[what]_[scenario]`
- Assertion: [expected behavior]
- Status: FAILING

**GREEN**:
- Minimal implementation: [approach]
- Status: PASSING

**REFACTOR**:
- Improvement: [what cleaned up]
- Tests still passing: YES

#### Cycle 2
[Continue...]

Test Quality Checklist

Based on Meszaros patterns:

## Test Review Checklist

### Structure
- [ ] Clear arrange/act/assert phases
- [ ] One logical assertion per test
- [ ] Descriptive test name (what_when_then)

### Independence
- [ ] No test depends on another's side effects
- [ ] Can run in any order
- [ ] Clean setup/teardown

### Readability
- [ ] Test tells a story
- [ ] No mystery guests (unexplained values)
- [ ] Relevant data visible in test

### Maintainability
- [ ] No fragile assertions (over-specification)
- [ ] Uses appropriate test doubles
- [ ] DRY via helpers, not copy-paste

Anti-Patterns to Avoid

• Test after: Writing tests after code removes design benefits
• Testing implementation: Coupling tests to internal structure
• Slow tests: Not isolating from slow dependencies
• Test-per-method: Testing methods instead of behaviors
• 100% coverage worship: Coverage doesn't equal quality
• Commented tests: Delete or fix, never comment out