{"id":"8c79e52a-ed8f-430c-b239-61114934fc88","entityType":"agent","slug":"clawhub-athola-nm-abstract-methodology-curator","name":"methodology-curator","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-abstract-methodology-curator","canonicalPath":"/agent/clawhub-athola-nm-abstract-methodology-curator","generatedAt":"2026-10-10T10:02:18.365Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T00:17:52.100Z","emptyReason":null},"description":"Surface expert frameworks Skill: methodology-curator Owner: athola Summary: Surface expert frameworks Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:03:31.291Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:27:54.111Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:27:47.102Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:44:41.928Z | user Release v1.9.16 v1.9.15 | 2026-07-04T21:19:18.229Z | user Release v1.9.15 v1.9.14 | 2026-06","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.8K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-abstract-methodology-curator","sourceUrl":"https://clawhub.ai/athola/nm-abstract-methodology-curator","homepage":"https://clawhub.ai/athola/skills/nm-abstract-methodology-curator","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-abstract-methodology-curator","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-abstract-methodology-curator","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":42,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Surface expert frameworks Skill: methodology-curator Owner: athola Summary: Surface expert frameworks Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T00:17:52.100Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T00:17:52.100Z","emptyReason":null},"stars":null,"forks":null,"downloads":1844,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.8K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T00:17:52.099Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T00:17:52.100Z","lastCrawledAt":"2026-10-10T00:17:52.099Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T00:17:52.099Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:03:31.291Z","changelog":"Release v1.9.19","fileCount":9,"zipByteSize":23626},{"version":"1.9.18","createdAt":"2026-08-15T21:27:54.111Z","changelog":"Release v1.9.18","fileCount":9,"zipByteSize":23708},{"version":"1.9.17","createdAt":"2026-07-30T05:27:47.102Z","changelog":"Release v1.9.17","fileCount":9,"zipByteSize":23665},{"version":"1.9.16","createdAt":"2026-07-14T19:44:41.928Z","changelog":"Release v1.9.16","fileCount":9,"zipByteSize":23820},{"version":"1.9.15","createdAt":"2026-07-04T21:19:18.229Z","changelog":"Release v1.9.15","fileCount":9,"zipByteSize":23661},{"version":"1.9.14","createdAt":"2026-06-30T17:49:52.480Z","changelog":"Release v1.9.14","fileCount":9,"zipByteSize":23894},{"version":"1.9.13","createdAt":"2026-06-27T16:14:30.195Z","changelog":"Release v1.9.13","fileCount":9,"zipByteSize":23836},{"version":"1.9.12","createdAt":"2026-06-19T03:07:37.559Z","changelog":"Release v1.9.12","fileCount":9,"zipByteSize":23674}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-abstract-methodology-curator","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-abstract-methodology-curator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-abstract-methodology-curator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-abstract-methodology-curator/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-abstract-methodology-curator/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-abstract-methodology-curator/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-abstract-methodology-curator/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T10:02:18.357Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-abstract-methodology-curator/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-abstract-methodology-curator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-abstract-methodology-curator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-abstract-methodology-curator/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T00:17:52.100Z","emptyReason":null},"readme":"Skill: methodology-curator\n\nOwner: athola\n\nSummary: Surface expert frameworks\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:03:31.291Z | user\n\nRelease v1.9.19\n\nv1.9.18 | 2026-08-15T21:27:54.111Z | user\n\nRelease v1.9.18\n\nv1.9.17 | 2026-07-30T05:27:47.102Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:44:41.928Z | user\n\nRelease v1.9.16\n\nv1.9.15 | 2026-07-04T21:19:18.229Z | user\n\nRelease v1.9.15\n\nv1.9.14 | 2026-06-30T17:49:52.480Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:14:30.195Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:07:37.559Z | user\n\nRelease v1.9.12\n\nv1.8.6 | 2026-06-07T21:21:46.675Z | user\n\nRelease v1.9.11\n\nv1.8.5 | 2026-05-09T02:14:52.755Z | user\n\nRelease v1.9.5\n\nv1.8.4 | 2026-05-06T14:14:23.487Z | user\n\nRelease v1.9.4\n\nv1.8.3 | 2026-04-10T05:44:52.461Z | user\n\nRelease v1.8.3\n\nv1.8.2 | 2026-04-06T14:17:25.208Z | user\n\nRelease v1.8.2\n\nv1.0.0 | 2026-04-06T05:55:22.311Z | auto\n\n- Initial release of the Methodology Curator skill.\n- Surfaces expert frameworks and methodologies across multiple domains (instruction design, code review, debugging, testing, knowledge management, decision making).\n- Provides curated modules highlighting domain masters, key works, actionable frameworks, selection guides, and anti-patterns.\n- Offers guidance for when to apply or skip methodology checks during skill creation and evaluation.\n- Includes template instructions for adding new domain modules.\n\nArchive index:\n\nArchive v1.9.19: 9 files, 23626 bytes\n\nFiles: modules/code-review.md (6241b), modules/debugging.md (7053b), modules/decision-making.md (8095b), modules/instruction-design.md (6372b), modules/knowledge-management.md (7318b), modules/testing.md (7955b), skill-card.md (1873b), SKILL.md (5000b), _meta.json (151b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: methodology-curator\ndescription: Surface expert frameworks\nversion: 1.9.8\ntriggers:\n  - methodology\n  - frameworks\n  - expertise\n  - curation\n  - design\n  - evaluation\n  - creating or evaluating skills\n  - hooks\n  - or agents\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/abstract\", \"emoji\": \"\\ud83e\\udde0\"}}\nsource: claude-night-market\nsource_plugin: abstract\n---\n\n> **Night Market Skill** — ported from [claude-night-market/abstract](https://github.com/athola/claude-night-market/tree/master/plugins/abstract). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Overview](#overview)\n- [Workflow Integration](#workflow-integration)\n- [Domain Modules](#domain-modules)\n- [When to Skip](#when-to-skip)\n- [Masters Overview](#masters-overview)\n- [Selection Matrix](#selection-matrix)\n\n# Methodology Curator\n\n## Overview\n\nIdentifying 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.\n\n## Workflow Integration\n\nWhen 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.\n\nFor 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.\n\n## Domain Modules\n\nEach 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.\n\n- **Instruction Design**: `modules/instruction-design.md` - Teaching techniques and behavioral objectives.\n- **Code Review**: `modules/code-review.md` - Review methodologies and feedback patterns.\n- **Debugging**: `modules/debugging.md` - Systematic troubleshooting frameworks.\n- **Testing**: `modules/testing.md` - TDD masters and test design patterns.\n- **Knowledge Management**: `modules/knowledge-management.md` - Note-taking and knowledge systems.\n- **Decision Making**: `modules/decision-making.md` - Mental models and decision frameworks.\n\n## When to Skip\n\n### Skip for Creation when:\n- You're implementing a well-defined spec\n- The domain is highly specific to your codebase\n- You've already researched methodologies externally\n- Creating a simple utility with no pedagogical component\n\n### Skip for Evaluation when:\n- Fixing syntax/structural issues (use `/validate-plugin` instead)\n- The work is purely mechanical (no methodology to ground)\n- Already performed a recent methodology audit\n- Quick bug fixes that don't change the approach\n\n## Domain Modules\n\nEach module contains:\n- **Masters**: Recognized experts in the domain\n- **Key Works**: Essential books/papers/talks\n- **Frameworks**: Actionable methodologies\n- **Selection Guide**: When to use each approach\n- **Anti-patterns**: What to avoid\n\n### Adding New Domains\n\nTo expand the masters database, create a new module following this template:\n\n```markdown\n# [Domain Name] Masters\n\n## Masters Overview\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Name   | Framework/Book  | Context  |\n\n## Detailed Frameworks\n\n### [Framework 1]\n**Source**: [Expert] - [Work]\n**Core Idea**: [One sentence]\n**Key Principles**:\n- Principle 1\n- Principle 2\n**Use When**: [Context]\n**Avoid When**: [Anti-context]\n\n## Selection Matrix\n[Decision guide for choosing between frameworks]\n```\n\n## Integration with Skill Authoring\n\nAfter curating methodologies, the skill authoring workflow benefits from:\n\n1. **Grounded TDD scenarios**: Test against the methodology's expected behaviors\n2. **Principled anti-rationalization**: Counter excuses using the methodology's logic\n3. **Authoritative references**: Cite masters in skill documentation\n4. **Consistent terminology**: Use the methodology's vocabulary\n\n## Related\n\n### For Creation\n- `/create-skill` - Skill creation workflow (use after this)\n- `/create-hook` - Hook creation workflow\n- `superpowers:brainstorming` - Refine approach after methodology selection\n- `skill-authoring` - Detailed skill writing guidance\n\n### For Evaluation\n- `/skills-eval` - Evaluate skill quality (complements methodology audit)\n- `/analyze-skill` - Analyze skill complexity\n- `/bulletproof-skill` - Harden against rationalization\n- `pensive:code-reviewer` - Code review (uses code-review domain)\n\nFile v1.9.19:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-abstract-methodology-curator\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749411291\n}\n\nFile v1.9.19:modules/code-review.md\n\n# Code Review Masters\n\nExpert frameworks for conducting effective code reviews, providing constructive feedback, and improving code quality through review processes.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Google Engineering | Google's Code Review Guidelines | Scalable team practices |\n| Martin Fowler | Refactoring Catalog | Identifying improvement patterns |\n| Michael Feathers | Working with Legacy Code | Safe modification strategies |\n| Karl Wiegers | Peer Reviews in Software | Process optimization |\n| Trisha Gee | Code Review Best Practices | Practical JetBrains wisdom |\n\n## Detailed Frameworks\n\n### Google's Code Review Standards\n\n**Source**: Google Engineering Practices Documentation (public)\n\n**Core Idea**: Reviews should improve code health while enabling progress.\n\n**Key Principles**:\n- **Speed matters**: Review within 24 hours, ideally same day\n- **Small changes**: Prefer small, focused CLs (changelists)\n- **Approve if better**: Don't block for perfection\n- **Distinguish severity**: Nit vs. suggestion vs. blocker\n\n**The Standard**:\n> \"Reviewers should approve a CL once it definitely improves overall code health, even if it isn't perfect.\"\n\n**Comment Prefixes**:\n```\nNit:      Minor style preference, optional\nSuggest:  Improvement idea, author decides\nConsider: Worth thinking about, not blocking\nBLOCKING: Must fix before approval\n```\n\n**Use When**: Establishing team review standards, training reviewers.\n\n**Avoid When**: Security-critical code (needs stricter process).\n\n---\n\n### Fowler's Refactoring Patterns\n\n**Source**: Martin Fowler - \"Refactoring\" (1999, 2nd ed. 2018)\n\n**Core Idea**: Catalog of named transformations for improving code structure.\n\n**Review Application**: Use pattern names as shared vocabulary in reviews.\n\n**High-Value Patterns for Reviews**:\n| Smell | Refactoring | Review Comment |\n|-------|-------------|----------------|\n| Long function | Extract Method | \"This could be extracted into `calculateTotal()`\" |\n| Repeated code | Extract Method/Class | \"Duplicated in lines 45, 89—extract?\" |\n| Long parameter list | Introduce Parameter Object | \"Consider grouping these into a config object\" |\n| Feature Envy | Move Method | \"This method uses more of Order than Cart\" |\n| Primitive Obsession | Replace with Value Object | \"A Money type would prevent currency bugs\" |\n\n**Use When**: Providing actionable refactoring suggestions.\n\n---\n\n### Feathers' Legacy Code Strategies\n\n**Source**: Michael Feathers - \"Working Effectively with Legacy Code\" (2004)\n\n**Core Idea**: \"Legacy code is code without tests.\" Review for testability.\n\n**Key Review Questions**:\n1. **Seams**: Are there places to substitute behavior for testing?\n2. **Dependencies**: Can this be tested in isolation?\n3. **Characterization**: Would a test capture current behavior?\n\n**The Legacy Change Algorithm**:\n1. Identify change points\n2. Find test points\n3. Break dependencies\n4. Write tests\n5. Make changes\n\n**Review Comments for Legacy**:\n```\n\"Before modifying this, consider adding a characterization test\"\n\"This method has too many dependencies—can we inject the database?\"\n\"Consider introducing a seam here for testability\"\n```\n\n**Use When**: Reviewing changes to untested code.\n\n---\n\n### Wiegers' Peer Review Types\n\n**Source**: Karl Wiegers - \"Peer Reviews in Software\" (2002)\n\n**Core Idea**: Match review intensity to risk level.\n\n**Review Spectrum**:\n| Type | Effort | When to Use |\n|------|--------|-------------|\n| **Ad-hoc** | Lowest | Quick questions, pair checks |\n| **Passaround** | Low | Routine changes, docs |\n| **Walkthrough** | Medium | Knowledge sharing, onboarding |\n| **Team Review** | Medium-High | Design decisions, complex logic |\n| **Inspection** | Highest | Safety-critical, core algorithms |\n\n**Defect Detection Rates**:\n- Inspection: 60-90% of defects found\n- Walkthrough: 20-40%\n- Testing alone: 25-35%\n\n**Use When**: Deciding review depth for different code types.\n\n---\n\n### Gee's Practical Code Review\n\n**Source**: Trisha Gee - Various talks and articles (JetBrains)\n\n**Core Idea**: Reviews should be humane and focused on learning.\n\n**Key Principles**:\n- **Automate the boring stuff**: Linting, formatting, style → CI\n- **Focus human attention**: Logic, design, readability\n- **Be kind**: Criticize code, not people\n- **Ask questions**: \"What was the thinking here?\" vs \"This is wrong\"\n\n**Comment Formulas**:\n```\nInstead of: \"This is wrong\"\nTry:        \"I'm curious—what led to this approach?\"\n\nInstead of: \"Use X pattern\"\nTry:        \"Have you considered X? It might help with Y\"\n\nInstead of: \"This will break\"\nTry:        \"What happens if input is null here?\"\n```\n\n**Feedback Categories**:\n1. **Bugs**: Logic errors, edge cases\n2. **Design**: Coupling, cohesion, patterns\n3. **Readability**: Naming, structure, comments\n4. **Learning**: Knowledge sharing opportunities\n\n**Use When**: Writing constructive review feedback, training reviewers.\n\n## Selection Matrix\n\n| Your Context | Primary Framework | Supporting |\n|--------------|------------------|------------|\n| High-velocity team | Google Standards | Gee |\n| Improving existing code | Fowler | Feathers |\n| Safety-critical systems | Wiegers | Feathers |\n| Team culture improvement | Gee | Google |\n| Legacy codebase | Feathers | Fowler |\n\n## Review Checklist Template\n\nBased on blended frameworks:\n\n```markdown\n## Quick Checks (Automate These)\n- [ ] Passes linting\n- [ ] Passes tests\n- [ ] No merge conflicts\n\n## Human Review Focus\n### Correctness\n- [ ] Logic handles edge cases\n- [ ] Error handling appropriate\n\n### Design (Fowler)\n- [ ] No obvious code smells\n- [ ] Single responsibility followed\n- [ ] Dependencies reasonable\n\n### Testability (Feathers)\n- [ ] New code has tests\n- [ ] Changes don't break test isolation\n- [ ] Can test in isolation\n\n### Readability (Gee)\n- [ ] Names reveal intent\n- [ ] Comments explain \"why\" not \"what\"\n- [ ] Complexity appropriate\n```\n\n## Anti-Patterns to Avoid\n\n- **Nitpick storms**: Dozens of style comments (use linters)\n- **Rubber stamping**: Approving without reading\n- **Gatekeeping**: Using reviews to block or control\n- **Scope creep**: Requesting unrelated changes\n- **Delayed reviews**: Blocking progress for days\n\nFile v1.9.19:modules/debugging.md\n\n# Debugging Masters\n\nExpert frameworks for systematic troubleshooting, root cause analysis, and efficient bug resolution.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Andreas Zeller | Scientific Debugging | Systematic hypothesis testing |\n| David Agans | Nine Rules of Debugging | Universal debugging principles |\n| Diomidis Spinellis | Effective Debugging | Comprehensive toolkit |\n| Rob Miller | Debugging by Asking | Root cause questioning |\n| John Regehr | Compiler/Systems Debugging | Low-level issues |\n\n## Detailed Frameworks\n\n### Zeller's Scientific Debugging\n\n**Source**: Andreas Zeller - \"Why Programs Fail\" (2009)\n\n**Core Idea**: Apply scientific method to debugging—hypothesis, experiment, conclusion.\n\n**The Scientific Debugging Process**:\n```\n1. OBSERVE failure\n2. HYPOTHESIZE cause (be specific!)\n3. PREDICT behavior if hypothesis true\n4. EXPERIMENT to test prediction\n5. CONCLUDE: confirmed or refuted\n6. REPEAT with new hypothesis\n```\n\n**Key Principle**: Never change code to \"see if it fixes it.\" That's guessing, not debugging.\n\n**Hypothesis Quality**:\n```\nBAD:  \"Something's wrong with the database\"\nGOOD: \"The query times out because it scans all rows without index\"\n```\n\n**Delta Debugging** (Zeller's technique):\n- Minimize failing input\n- Find smallest change that triggers bug\n- Isolate exactly what causes failure\n\n**Use When**: Complex bugs, intermittent failures, need systematic approach.\n\n---\n\n### Agans' Nine Rules\n\n**Source**: David Agans - \"Debugging: The 9 Indispensable Rules\" (2002)\n\n**Core Idea**: Universal rules that apply to any debugging scenario.\n\n**The Nine Rules**:\n\n| # | Rule | Application |\n|---|------|-------------|\n| 1 | **Understand the System** | Read docs, trace data flow before assuming |\n| 2 | **Make It Fail** | Reproduce reliably before investigating |\n| 3 | **Quit Thinking and Look** | Actually read error messages, logs, state |\n| 4 | **Divide and Conquer** | Binary search to isolate |\n| 5 | **Change One Thing at a Time** | Controlled experiments only |\n| 6 | **Keep an Audit Trail** | Log what you tried and results |\n| 7 | **Check the Plug** | Verify assumptions, environment, obvious things |\n| 8 | **Get a Fresh View** | Rubber duck, ask colleague, sleep on it |\n| 9 | **If You Didn't Fix It, It Ain't Fixed** | Verify root cause, not just symptoms |\n\n**Most Violated Rules**:\n- #3: Jumping to hypotheses without reading the actual error\n- #5: Changing multiple things hoping something works\n- #9: Seeing issue disappear and assuming it's fixed\n\n**Use When**: Any debugging situation—these are universal.\n\n---\n\n### Spinellis' Debugging Strategies\n\n**Source**: Diomidis Spinellis - \"Effective Debugging\" (2016)\n\n**Core Idea**: Comprehensive toolkit organized by debugging phase.\n\n**Strategy Categories**:\n\n**High-Level Strategies**:\n| Strategy | When to Use |\n|----------|-------------|\n| Reproduce consistently | First step, always |\n| Simplify input | Large inputs, complex state |\n| Minimize code | Isolate to smallest failing example |\n| Add instrumentation | Need visibility into behavior |\n| Review recent changes | \"It was working yesterday\" |\n\n**Technical Strategies**:\n| Strategy | Application |\n|----------|-------------|\n| Printf debugging | Quick visibility, any environment |\n| Debugger stepping | Complex control flow |\n| Core dump analysis | Crashes, post-mortem |\n| Profiling | Performance issues |\n| Tracing | System call, network issues |\n\n**Process Strategies**:\n| Strategy | When to Use |\n|----------|-------------|\n| Pair debugging | Stuck for >30 minutes |\n| Take a break | Tunnel vision, frustration |\n| Explain to rubber duck | Can't articulate problem |\n| Search error message | May be known issue |\n\n**Use When**: Need specific technique for specific problem type.\n\n---\n\n### Miller's Debugging Questions\n\n**Source**: Rob Miller (MIT) - Debugging lectures\n\n**Core Idea**: Systematic questioning reveals root cause.\n\n**The Question Ladder**:\n\n1. **What did you expect to happen?**\n2. **What actually happened?**\n3. **What's the difference?**\n4. **When did it last work?**\n5. **What changed since then?**\n6. **Where exactly does behavior diverge from expectation?**\n\n**Localization Questions**:\n- At what point does the state become incorrect?\n- What is the last known good state?\n- What is the first known bad state?\n\n**Use When**: Starting any debugging session, structuring investigation.\n\n---\n\n### Regehr's Low-Level Debugging\n\n**Source**: John Regehr - Embedded Systems & Compiler Expert\n\n**Core Idea**: Systems-level bugs need systems-level thinking.\n\n**Principles**:\n- **Trust nothing**: Verify compiler output, hardware state\n- **Reduce**: Minimize to smallest reproducer\n- **Isolation**: Test components independently\n- **Invariants**: Assert what must be true\n\n**Common Systems Bug Categories**:\n| Category | Symptoms | Approach |\n|----------|----------|----------|\n| Memory corruption | Crashes, weird values | Valgrind, ASan |\n| Race conditions | Intermittent, timing-dependent | Thread sanitizer, logging |\n| Resource leaks | Slow degradation | Monitor, profiling |\n| Undefined behavior | \"Works on my machine\" | UBSan, static analysis |\n\n**Use When**: Low-level, systems, or intermittent bugs.\n\n## Selection Matrix\n\n| Bug Type | Primary Framework | Supporting |\n|----------|------------------|------------|\n| Any bug (start here) | Agans' 9 Rules | Miller Questions |\n| Complex/subtle bugs | Zeller Scientific | Agans #5, #6 |\n| \"It was working\" | Spinellis Review Changes | Agans #1 |\n| Intermittent failures | Zeller Delta Debug | Regehr |\n| Performance issues | Spinellis Profiling | Agans #4 |\n| Unknown territory | Agans #1, #7 | Miller Questions |\n\n## Debugging Workflow Template\n\nBlended from all frameworks:\n\n```markdown\n## Bug: [Brief description]\n\n### 1. Understand & Reproduce (Agans #1, #2)\n- System understanding: [What should happen]\n- Reproduction steps:\n  1. [Step]\n  2. [Step]\n- Reproduction rate: [Always/Sometimes/Rare]\n\n### 2. Observe (Agans #3, Miller)\n- Expected: [What should happen]\n- Actual: [What happens]\n- Difference: [Gap]\n- Last working: [When/version]\n\n### 3. Hypothesize (Zeller)\n| # | Hypothesis | Prediction | Test | Result |\n|---|------------|------------|------|--------|\n| 1 | | | | |\n| 2 | | | | |\n| 3 | | | | |\n\n### 4. Isolate (Agans #4, #5)\n- Binary search log:\n  - [✓] Works at commit abc123\n  - [✗] Fails at commit def456\n  - Narrowed to: [specific change]\n\n### 5. Fix & Verify (Agans #9)\n- Root cause: [Actual cause]\n- Fix: [What changed]\n- Verification: [How confirmed]\n- Regression test added: [Yes/No]\n```\n\n## Anti-Patterns to Avoid\n\n- **Shotgun debugging**: Changing random things hoping to fix it\n- **Assumption debugging**: Not verifying basic assumptions (Agans #7)\n- **Tunnel vision**: Fixating on one hypothesis without testing others\n- **History blindness**: Not checking what recently changed\n- **Solo heroics**: Not asking for help when stuck (Agans #8)\n- **Premature celebration**: Assuming it's fixed without proof (Agans #9)\n\nFile v1.9.19:modules/decision-making.md\n\n# Decision Making Masters\n\nExpert frameworks for making better decisions, avoiding cognitive biases, and developing reliable judgment.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Charlie Munger | Mental Models, Inversion | Investment/business decisions |\n| Daniel Kahneman | System 1/2, Biases | Understanding cognitive limitations |\n| Gary Klein | Recognition-Primed Decision | Expert intuition, time pressure |\n| Annie Duke | Thinking in Bets | Decisions under uncertainty |\n| Ray Dalio | Principles, Radical Transparency | Organizational decisions |\n\n## Detailed Frameworks\n\n### Munger's Mental Models\n\n**Source**: Charlie Munger - \"Poor Charlie's Almanack\", Berkshire letters\n\n**Core Idea**: Build a latticework of mental models from multiple disciplines; use them in combination.\n\n**Key Mental Models**:\n\n| Model | Discipline | Application |\n|-------|------------|-------------|\n| **Inversion** | Mathematics | \"What would make this fail?\" |\n| **Second-Order Effects** | Physics | \"What happens next? Then what?\" |\n| **Circle of Competence** | Self-knowledge | \"What do I actually understand?\" |\n| **Margin of Safety** | Engineering | \"What's the buffer for error?\" |\n| **Opportunity Cost** | Economics | \"What am I giving up?\" |\n| **Incentives** | Psychology | \"What are people rewarded for?\" |\n\n**Inversion Technique**:\n```\nInstead of: \"How do I succeed?\"\nAsk:        \"How would I guarantee failure?\"\nThen:       Avoid those things\n\nInstead of: \"How do I make a great skill?\"\nAsk:        \"What makes skills terrible?\"\nThen:       Eliminate those patterns\n```\n\n**Use When**: Complex decisions, need diverse perspectives, avoiding blind spots.\n\n---\n\n### Kahneman's System 1/System 2\n\n**Source**: Daniel Kahneman - \"Thinking, Fast and Slow\" (2011)\n\n**Core Idea**: Two thinking systems with different strengths and failure modes.\n\n**The Two Systems**:\n| System 1 (Fast) | System 2 (Slow) |\n|-----------------|-----------------|\n| Automatic | Effortful |\n| Intuitive | Analytical |\n| Parallel | Serial |\n| Emotional | Logical |\n| Error-prone | Accurate but lazy |\n\n**Key Biases to Counter**:\n| Bias | Description | Countermeasure |\n|------|-------------|----------------|\n| **Anchoring** | First number influences | Generate own estimate first |\n| **Availability** | Recent = likely | Ask \"What am I not seeing?\" |\n| **Confirmation** | Seek supporting evidence | Actively seek disconfirming |\n| **Overconfidence** | Certainty exceeds accuracy | Estimate confidence intervals |\n| **Hindsight** | \"I knew it all along\" | Record predictions beforehand |\n| **Sunk cost** | Continue because invested | \"Would I start this now?\" |\n\n**Pre-Mortem Technique**:\n```\nImagine the project has failed spectacularly.\nWrite the story of why it failed.\nNow prevent those things.\n```\n\n**Use When**: Need to check intuitions, high-stakes decisions, avoiding biases.\n\n---\n\n### Klein's Recognition-Primed Decision (RPD)\n\n**Source**: Gary Klein - \"Sources of Power\" (1998)\n\n**Core Idea**: Experts don't compare options; they recognize patterns and simulate actions.\n\n**How Experts Decide**:\n```\n1. Recognize situation type (pattern match)\n2. Identify typical action for situation\n3. Mental simulation: \"If I do this, what happens?\"\n4. If simulation works → act\n5. If problems → modify or consider next option\n```\n\n**Key Insight**: Experts rarely compare options analytically. They satisfice, not optimize.\n\n**When to Trust Intuition**:\n| Trust intuition when: | Don't trust when: |\n|----------------------|-------------------|\n| High experience in domain | Novel domain |\n| Regular, rapid feedback | Delayed/noisy feedback |\n| Stable, predictable environment | Chaotic, random environment |\n\n**Use When**: Time pressure, experienced domain, need fast action.\n\n---\n\n### Duke's Thinking in Bets\n\n**Source**: Annie Duke - \"Thinking in Bets\" (2018)\n\n**Core Idea**: Decisions are bets about the future; separate decision quality from outcome quality.\n\n**Key Principles**:\n- **Resulting**: Judging decision by outcome is wrong\n- **Uncertainty**: All decisions are probabilistic\n- **Expected value**: Probability × payoff\n\n**Decision Quality vs. Outcome Quality**:\n```\n                    OUTCOME\n                Good        Bad\n         Good   Deserved    Bad luck\nDECISION        win         (learn nothing)\n         Bad    Good luck   Deserved\n                (dangerous) loss\n```\n\n**The 10-10-10 Rule**:\n```\nHow will I feel about this decision:\n- 10 minutes from now?\n- 10 months from now?\n- 10 years from now?\n```\n\n**Decision Groups**:\n- Find truth-seeking group\n- Agree to criticize ideas, not people\n- Reward process, not outcome\n- Update beliefs openly\n\n**Use When**: Uncertain outcomes, need to separate luck from skill.\n\n---\n\n### Dalio's Principles\n\n**Source**: Ray Dalio - \"Principles\" (2017)\n\n**Core Idea**: Make decisions through explicit principles; radical transparency.\n\n**The Idea Meritocracy**:\n```\nBest ideas win, regardless of source\nBelievability-weighted voting\nRadical transparency in reasoning\n```\n\n**Decision-Making Process**:\n1. **Perceive** problems accurately\n2. **Diagnose** root causes\n3. **Design** solutions (principles)\n4. **Do** (execute)\n5. **Document** as principle for future\n\n**Believability Weighting**:\n```\nNot all opinions equal. Weight by:\n- Track record in relevant area\n- Demonstrated reasoning ability\n- Appropriate confidence level\n```\n\n**Radical Transparency Questions**:\n- What don't I know?\n- Who can help me see blind spots?\n- What would change my mind?\n\n**Use When**: Team decisions, building organizational processes, documenting decisions.\n\n## Selection Matrix\n\n| Decision Context | Primary Framework | Supporting |\n|------------------|------------------|------------|\n| Strategic/business | Munger | Dalio |\n| Individual bias check | Kahneman | Duke |\n| Time pressure | Klein RPD | Munger (prepared models) |\n| Uncertain outcomes | Duke | Kahneman |\n| Team decisions | Dalio | Duke |\n| Building expertise | Klein | Kahneman |\n\n## Decision Framework Template\n\nBlended approach for important decisions:\n\n```markdown\n## Decision: [Brief statement]\n\n### 1. Frame (Munger + Kahneman)\n- What's the actual decision?\n- Inversion: How would I guarantee failure?\n- What am I not seeing? (availability bias check)\n\n### 2. Generate Options\n- Option A: [description]\n- Option B: [description]\n- Option C: Do nothing / wait\n\n### 3. Evaluate (Duke + Klein)\n| Option | Probability of Success | Upside | Downside | Expected Value |\n|--------|----------------------|--------|----------|----------------|\n| A | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |\n| B | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |\n| C | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |\n\n### 4. Pre-Mortem (Kahneman)\nIf this fails, it will be because:\n1. [Risk 1]\n2. [Risk 2]\nMitigations: [How to prevent]\n\n### 5. Decide & Document (Dalio)\n**Decision**: [Choice]\n**Reasoning**: [Why this option]\n**Confidence**: [High/Medium/Low]\n**Review date**: [When to evaluate]\n\n### 6. Post-Decision (Duke)\n**Outcome**: [What happened]\n**Was decision quality good?**: [Separate from outcome]\n**What to learn**: [Principle for future]\n```\n\n## For Scope-Guard / Imbue Plugin\n\nSpecific applications:\n\n| Decision Need | Methodology Application |\n|--------------|------------------------|\n| Worthiness scoring | Expected value (Duke) |\n| Anti-overengineering | Inversion (Munger) |\n| Scope decisions | Pre-mortem (Kahneman) |\n| Feature prioritization | Opportunity cost (Munger) |\n| Review evidence logging | Principles documentation (Dalio) |\n\n## Anti-Patterns to Avoid\n\n- **Analysis paralysis**: Perfect information doesn't exist\n- **Resulting**: Judging decisions by outcomes alone\n- **Consensus seeking**: Agreement ≠ correctness\n- **Confidence = competence**: Loudest isn't rightest\n- **Single model thinking**: One mental model isn't enough\n- **Ignoring base rates**: Your situation probably isn't special\n\nFile v1.9.19:modules/instruction-design.md\n\n# Instruction Design Masters\n\nExpert frameworks for teaching techniques, writing effective instructions, and creating behavioral change through documentation.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Robert Mager | Behavioral Objectives | Measurable skill outcomes |\n| Benjamin Bloom | Taxonomy of Learning | Cognitive level targeting |\n| Robert Gagné | Nine Events of Instruction | Structured lesson design |\n| John Sweller | Cognitive Load Theory | Reducing mental overhead |\n| Ruth Clark | Evidence-Based Training | Practical instructional design |\n\n## Detailed Frameworks\n\n### Mager's Behavioral Objectives\n\n**Source**: Robert Mager - \"Preparing Instructional Objectives\" (1962)\n\n**Core Idea**: Objectives must specify observable behavior, conditions, and criteria.\n\n**Key Principles**:\n- **Performance**: What the learner will DO (observable verb)\n- **Conditions**: Under what circumstances (tools, constraints)\n- **Criterion**: How well (accuracy, speed, quality threshold)\n\n**Formula**: \"Given [conditions], the learner will [performance] to [criterion].\"\n\n**Example for Skills**:\n```\nBAD:  \"Understand TDD methodology\"\nGOOD: \"Given a failing test, implement minimal code to pass within 3 iterations\"\n```\n\n**Use When**: Creating technique skills, defining success criteria, writing \"Use when\" clauses.\n\n**Avoid When**: Teaching abstract concepts, pattern recognition, creative tasks.\n\n---\n\n### Bloom's Taxonomy (Revised)\n\n**Source**: Benjamin Bloom et al., revised by Anderson & Krathwohl (2001)\n\n**Core Idea**: Learning has hierarchical levels; target the right cognitive level.\n\n**Levels (lowest to highest)**:\n1. **Remember**: Recall facts → Reference skills, checklists\n2. **Understand**: Explain concepts → Pattern skills, mental models\n3. **Apply**: Use in new situations → Technique skills, workflows\n4. **Analyze**: Break down, find patterns → Debugging skills, code review\n5. **Evaluate**: Judge, critique → Assessment frameworks, quality gates\n6. **Create**: Produce new work → Design skills, architecture guidance\n\n**Use When**: Determining skill type, structuring progressive disclosure, setting appropriate depth.\n\n**Skill Mapping**:\n| Skill Type | Target Level | Verbs to Use |\n|-----------|--------------|--------------|\n| Reference | Remember | List, recall, identify |\n| Pattern | Understand | Explain, compare, summarize |\n| Technique | Apply/Analyze | Implement, execute, debug |\n\n---\n\n### Gagné's Nine Events of Instruction\n\n**Source**: Robert Gagné - \"The Conditions of Learning\" (1965)\n\n**Core Idea**: Effective instruction follows nine sequential events.\n\n**The Nine Events**:\n1. **Gain attention**: Hook with problem or scenario\n2. **Inform objectives**: State what they'll learn (Use when clause)\n3. **Stimulate recall**: Connect to prior knowledge\n4. **Present content**: The actual instruction\n5. **Provide guidance**: Examples, worked problems\n6. **Elicit performance**: Practice opportunity\n7. **Provide feedback**: Correct/reinforce\n8. **Assess performance**: Verify learning\n9. **Enhance retention**: Transfer to real contexts\n\n**Skill Structure Mapping**:\n```\nSKILL.md Structure           Gagné Event\n─────────────────────────────────────────\nOverview/Problem statement → 1. Gain attention\n\"Use when\" clause          → 2. Inform objectives\nRelated skills/prereqs     → 3. Stimulate recall\nCore content               → 4. Present content\nExamples                   → 5. Provide guidance\nWorkflows/checklists       → 6. Elicit performance\nAnti-patterns/red flags    → 7. Provide feedback\nValidation commands        → 8. Assess performance\nReal-world scenarios       → 9. Enhance retention\n```\n\n**Use When**: Designing complete skill structure, ensuring nothing essential is missing.\n\n---\n\n### Cognitive Load Theory\n\n**Source**: John Sweller - \"Cognitive Load Theory\" (1988)\n\n**Core Idea**: Working memory is limited; reduce unnecessary load.\n\n**Three Types of Load**:\n- **Intrinsic**: Complexity inherent to the material (can't reduce)\n- **Extraneous**: Poor presentation adding confusion (ELIMINATE)\n- **Germane**: Effort building mental models (MAXIMIZE)\n\n**Techniques for Skills**:\n| Principle | Application |\n|-----------|-------------|\n| Chunking | Progressive disclosure, modular files |\n| Worked examples | Complete code samples, not pseudocode |\n| Split attention | Keep related info together (no \"see also\" mid-flow) |\n| Redundancy | Don't repeat same info in text AND diagram |\n| Expertise reversal | Advanced users need less scaffolding |\n\n**Use When**: Optimizing token efficiency, structuring modules, deciding what to cut.\n\n---\n\n### Clark's Evidence-Based Training\n\n**Source**: Ruth Clark - \"Evidence-Based Training Methods\" (2019)\n\n**Core Idea**: Use research-proven methods, not intuition.\n\n**Key Findings**:\n- **Examples beat descriptions**: Show, don't tell\n- **Practice with feedback**: Interactive > passive reading\n- **Spaced learning**: Break into digestible chunks\n- **Relevant context**: Real scenarios > abstract theory\n\n**Anti-patterns** (feel effective but aren't):\n- Long prose explanations\n- Comprehensive coverage without practice\n- Learning styles myths (visual/auditory)\n- Information dumps\n\n**Use When**: Reviewing skills for effectiveness, cutting unnecessary content.\n\n## Selection Matrix\n\n| Your Goal | Primary Framework | Supporting |\n|-----------|------------------|------------|\n| Define clear outcomes | Mager | Bloom |\n| Structure complete skill | Gagné | Cognitive Load |\n| Reduce skill complexity | Cognitive Load | Clark |\n| Choose skill type | Bloom | Mager |\n| Validate effectiveness | Clark | Gagné |\n\n## Blending Example\n\nCreating a debugging skill:\n1. **Bloom**: Target \"Analyze\" level (break down, identify patterns)\n2. **Mager**: \"Given error output, identify root cause within 3 hypotheses\"\n3. **Cognitive Load**: Use worked examples, progressive modules\n4. **Gagné**: Structure with attention hook → examples → practice workflow\n\n## Anti-Patterns to Avoid\n\n- **Covering everything**: Cognitive overload, low retention\n- **Vague objectives**: \"Understand debugging\" (not measurable)\n- **Missing practice**: All theory, no application\n- **Wrong level**: Teaching \"remember\" when \"apply\" is needed\n\nFile v1.9.19:modules/knowledge-management.md\n\n# Knowledge Management Masters\n\nExpert frameworks for capturing, organizing, connecting, and retrieving knowledge effectively.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Niklas Luhmann | Zettelkasten (Slip-box) | Connected notes, emergent thinking |\n| Sönke Ahrens | Smart Notes Method | Writing-focused knowledge work |\n| Vannevar Bush | Memex Concept | Associative trails, hypertext thinking |\n| David Allen | GTD (Getting Things Done) | Action-oriented knowledge capture |\n| Tiago Forte | PARA and Building a Second Brain | Digital organization, progressive summarization |\n\n## Detailed Frameworks\n\n### Luhmann's Zettelkasten\n\n**Source**: Niklas Luhmann - Sociologist, 70+ books, 90,000+ notes\n\n**Core Idea**: Atomic notes with explicit links create a \"conversation partner\" that surfaces unexpected connections.\n\n**Key Principles**:\n- **Atomicity**: One idea per note\n- **Linking**: Notes connect to other notes, not just categories\n- **Own words**: Rewrite in your understanding, never copy\n- **Unique identifiers**: Every note has permanent address\n- **Emergence**: Structure emerges from links, not imposed hierarchy\n\n**Note Types**:\n| Type | Purpose | Example |\n|------|---------|---------|\n| Fleeting | Quick capture | \"Idea: cognitive load applies to skills\" |\n| Literature | Reference to source | \"Sweller 1988 argues...\" |\n| Permanent | Processed, atomic insight | \"Cognitive load limits skill file size\" |\n| Structure | Index/hub notes | \"MOC: Skill Design Principles\" |\n\n**The Process**:\n```\n1. Capture fleeting notes throughout day\n2. Process into permanent notes (rewrite, atomize)\n3. Link to existing notes (where does this connect?)\n4. Add to structure notes (entry points)\n5. Review and discover connections\n```\n\n**Use When**: Building long-term knowledge base, research, writing projects.\n\n---\n\n### Ahrens' Smart Notes\n\n**Source**: Sönke Ahrens - \"How to Take Smart Notes\" (2017)\n\n**Core Idea**: Writing is thinking; note-taking should support writing output.\n\n**Key Principles**:\n- **Writing as thinking**: You don't write up ideas, you think through writing\n- **Bottom-up structure**: Let topics emerge from notes\n- **Slip-box as partner**: External thinking system\n- **Focus on output**: Notes serve future writing\n\n**The Workflow**:\n```\nReading → Fleeting Notes → Literature Notes → Permanent Notes → Writing\n```\n\n**Quality Criteria for Permanent Notes**:\n- Could someone else understand it without context?\n- Is it written in complete sentences?\n- Does it stand on its own?\n- Does it connect to existing notes?\n\n**Writing Process**:\n1. Collect relevant permanent notes\n2. Arrange in sequence\n3. Turn sequence into draft\n4. Edit and refine\n\n**Use When**: Academic writing, knowledge synthesis, developing arguments.\n\n---\n\n### Bush's Memex & Associative Trails\n\n**Source**: Vannevar Bush - \"As We May Think\" (1945)\n\n**Core Idea**: Human mind works by association; tools should support trails of thought.\n\n**Key Concepts**:\n- **Associative indexing**: Link by meaning, not alphabet\n- **Trails**: Paths through information, shareable\n- **Personal library**: All knowledge accessible, connected\n- **Selection vs. creation**: Value in curating paths\n\n**Modern Applications**:\n| Memex Concept | Modern Implementation |\n|---------------|----------------------|\n| Associative links | Hyperlinks, backlinks |\n| Trails | Curated reading paths, playlists |\n| Personal library | Personal wikis, note apps |\n| Selection devices | Search, tags, filters |\n\n**Use When**: Designing knowledge systems, understanding hypertext principles.\n\n---\n\n### Allen's GTD (Getting Things Done)\n\n**Source**: David Allen - \"Getting Things Done\" (2001)\n\n**Core Idea**: Capture everything; mind is for having ideas, not holding them.\n\n**The Five Steps**:\n```\n1. CAPTURE    - Get everything out of your head\n2. CLARIFY    - What is it? Is it actionable?\n3. ORGANIZE   - Put it where it belongs\n4. REFLECT    - Review regularly\n5. ENGAGE     - Do with confidence\n```\n\n**The Two-Minute Rule**: If it takes less than 2 minutes, do it now.\n\n**Clarify Decision Tree**:\n```\nIs it actionable?\n├── NO → Reference, Someday/Maybe, or Trash\n└── YES → What's the next action?\n    ├── Multi-step? → It's a Project\n    └── Single step?\n        ├── <2 min? → Do it now\n        ├── Delegate? → Waiting For\n        └── Defer? → Next Actions (by context)\n```\n\n**Use When**: Action-oriented knowledge, task management, reducing cognitive load.\n\n---\n\n### Forte's PARA & Second Brain\n\n**Source**: Tiago Forte - \"Building a Second Brain\" (2022)\n\n**Core Idea**: Organize by actionability, not topic. Progressive summarization for retrieval.\n\n**PARA System**:\n| Folder | Contains | Timeframe |\n|--------|----------|-----------|\n| **P**rojects | Active outcomes | Weeks |\n| **A**reas | Ongoing responsibilities | Indefinite |\n| **R**esources | Useful references | As needed |\n| **A**rchive | Inactive items | Done |\n\n**Progressive Summarization**:\n```\nLayer 0: Original source\nLayer 1: Bolded passages (10-20%)\nLayer 2: Highlighted from bold (10-20% of bold)\nLayer 3: Executive summary (your words)\nLayer 4: Remix (original synthesis)\n```\n\n**CODE Method**:\n- **C**apture: Save resonant information\n- **O**rganize: Put in PARA folder\n- **D**istill: Progressive summarization\n- **E**xpress: Create output\n\n**Use When**: Digital knowledge management, balancing capture and retrieval.\n\n## Selection Matrix\n\n| Your Goal | Primary Framework | Supporting |\n|-----------|------------------|------------|\n| Long-term knowledge building | Zettelkasten | Ahrens |\n| Writing/research output | Ahrens | Zettelkasten |\n| Task/action management | GTD | PARA |\n| Digital organization | PARA | GTD |\n| System design | Bush Memex | Zettelkasten |\n| Reducing overwhelm | GTD | PARA |\n\n## Knowledge System Template\n\nBlended approach for a knowledge base:\n\n```markdown\n## Knowledge System Design\n\n### Capture Layer (GTD + PARA)\n- Inbox: Quick capture without friction\n- Two-minute rule for processing\n- Daily processing to zero\n\n### Organization (PARA + Zettelkasten)\n- Projects: Active work with deadlines\n- Areas: Ongoing responsibilities\n- Notes: Atomic, linked permanent notes\n- Archive: Completed/inactive\n\n### Connection (Zettelkasten)\n- Every note links to 2+ existing notes\n- Structure notes (MOCs) for entry points\n- Tags for cross-cutting themes\n- Regular gardening/review\n\n### Output (Ahrens + Progressive Summary)\n- Progressive summarization of sources\n- Assemble notes for projects\n- Write from accumulated notes\n```\n\n## For Memory-Palace Plugin\n\nSpecific applications:\n\n| Memory-Palace Feature | Methodology Source |\n|----------------------|-------------------|\n| Knowledge nodes | Zettelkasten atomicity |\n| Backlinks | Luhmann's linking |\n| Daily notes | GTD capture |\n| MOC/Index notes | Zettelkasten structure notes |\n| Project organization | PARA |\n| Search/retrieval | Progressive summarization |\n\n## Anti-Patterns to Avoid\n\n- **Collector's fallacy**: Saving without processing\n- **Tagging obsession**: Tags without links\n- **Hierarchy prison**: Rigid folders killing discovery\n- **Perfect system seeking**: Setup > usage\n- **Copy-paste notes**: No rewriting = no understanding\n- **Orphan notes**: Notes without connections die\n\nFile v1.9.19:modules/testing.md\n\n# Testing & TDD Masters\n\nExpert frameworks for test-driven development, test design, and building confidence in code through systematic verification.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Kent Beck | TDD, xUnit Patterns | Test-first development |\n| Steve Freeman & Nat Pryce | GOOS (Growing Object-Oriented Software) | Outside-in TDD |\n| Gerard Meszaros | xUnit Test Patterns | Test design & maintenance |\n| Michael Feathers | Legacy Code Testing | Adding tests to existing code |\n| James Bach & Michael Bolton | Exploratory Testing | Manual testing rigor |\n\n## Detailed Frameworks\n\n### Beck's Test-Driven Development\n\n**Source**: Kent Beck - \"Test-Driven Development: By Example\" (2002)\n\n**Core Idea**: Write failing test first, then minimal code to pass, then refactor.\n\n**The TDD Cycle**:\n```\nRED    → Write failing test (design the interface)\nGREEN  → Write minimal code to pass (make it work)\nREFACTOR → Improve code (make it right)\nREPEAT\n```\n\n**Key Principles**:\n- **Test first, not test after**: Tests drive design\n- **Small steps**: One assertion, one tiny change\n- **Minimal code**: Only enough to pass the test\n- **Continuous refactoring**: Clean as you go\n\n**Beck's Three Laws of TDD**:\n1. Don't write production code until you have a failing test\n2. Don't write more test than sufficient to fail\n3. Don't write more production code than sufficient to pass\n\n**Use When**: Greenfield development, clear requirements, need design guidance.\n\n**Avoid When**: Exploratory prototyping, highly uncertain domains.\n\n---\n\n### Freeman & Pryce's Outside-In TDD (GOOS)\n\n**Source**: \"Growing Object-Oriented Software, Guided by Tests\" (2009)\n\n**Core Idea**: Start from acceptance tests, work inward, discover design.\n\n**The Double Loop**:\n```mermaid\nflowchart LR\n    subgraph outer[\"Outer Loop (Acceptance)\"]\n        a1[\"1. Write failing<br/>acceptance test\"]\n        a2[\"2. When acceptance<br/>passes, next feature\"]\n    end\n    subgraph inner[\"Inner Loop (Unit)\"]\n        u1[\"1. Write failing unit test\"]\n        u2[\"2. Make it pass\"]\n        u3[\"3. Refactor\"]\n        u4[\"4. Next unit...\"]\n    end\n\n    a1 --> u1\n    u1 --> u2 --> u3 --> u4\n    u4 -.-> u1\n    u4 --> a2\n    a2 -.-> a1\n\n    style outer fill:#e3f2fd,stroke:#1976d2\n    style inner fill:#fff8e1,stroke:#ffa000\n```\n\n**Key Principles**:\n- **Outside-in**: Start at edges (UI/API), work toward core\n- **Mock at boundaries**: Use mocks to discover collaborators\n- **Listen to tests**: Painful tests reveal design problems\n- **Walking skeleton**: First test is end-to-end (thin vertical slice)\n\n**Design Discovery**:\n```\n\"When we write a test, we're designing the API we want to use.\"\n\"Mocks tell us what collaborators we need.\"\n```\n\n**Use When**: Complex systems, need design guidance, object-oriented code.\n\n---\n\n### Meszaros' xUnit Test Patterns\n\n**Source**: Gerard Meszaros - \"xUnit Test Patterns\" (2007)\n\n**Core Idea**: Catalog of patterns for well-designed, maintainable tests.\n\n**Test Structure (Four-Phase)**:\n```\n1. SETUP    - Establish preconditions\n2. EXERCISE - Execute behavior under test\n3. VERIFY   - Check expected outcomes\n4. TEARDOWN - Clean up (often implicit)\n```\n\n**Key Patterns**:\n| Pattern | Problem | Solution |\n|---------|---------|----------|\n| Test Double | Need to isolate | Use Dummy, Stub, Spy, Mock, Fake |\n| Object Mother | Repetitive setup | Factory for test objects |\n| Test Data Builder | Complex object construction | Fluent builder for tests |\n| Parameterized Test | Similar tests, different data | Data-driven test |\n\n**Test Smells**:\n| Smell | Symptom | Cure |\n|-------|---------|------|\n| Fragile Test | Breaks on unrelated changes | Better isolation, less coupling |\n| Obscure Test | Hard to understand | Clear names, one assertion |\n| Slow Test | Takes too long | Mock external deps, parallelize |\n| Erratic Test | Sometimes passes/fails | Fix non-determinism |\n\n**Use When**: Test suite is growing complex, tests becoming maintenance burden.\n\n---\n\n### Feathers' Legacy Code Techniques\n\n**Source**: Michael Feathers - \"Working Effectively with Legacy Code\" (2004)\n\n**Core Idea**: \"Legacy code is code without tests.\" Strategies to add them.\n\n**Definition**: Legacy code = code without tests (regardless of age)\n\n**The Legacy Code Change Algorithm**:\n1. **Identify change points**\n2. **Find test points**\n3. **Break dependencies**\n4. **Write characterization tests** (capture current behavior)\n5. **Make changes and refactor**\n\n**Key Techniques**:\n| Technique | Purpose |\n|-----------|---------|\n| Characterization Test | Document what code actually does (not what it should do) |\n| Sprout Method | Add new code in testable method, call from legacy |\n| Sprout Class | New functionality in new testable class |\n| Wrap Method | Wrap existing method to add behavior |\n| Extract Interface | Break dependency on concrete class |\n\n**Seam Types** (places to inject test behavior):\n- **Object seams**: Override in subclass\n- **Compile seams**: Swap at build time\n- **Link seams**: Swap libraries\n\n**Use When**: Adding tests to existing codebase, modifying untested code.\n\n---\n\n### Bach & Bolton's Exploratory Testing\n\n**Source**: James Bach & Michael Bolton - Rapid Software Testing\n\n**Core Idea**: Skilled, intentional exploration guided by heuristics, not scripts.\n\n**Key Concepts**:\n- **Testing vs. Checking**: Testing = exploration, Checking = verification\n- **Heuristics**: Guidelines, not rules\n- **Session-based**: Timeboxed, focused exploration\n- **Charter**: Goal for exploration session\n\n**SFDPOT Heuristic** (what to test):\n| Letter | Category | Questions |\n|--------|----------|-----------|\n| S | Structure | What is it made of? |\n| F | Function | What does it do? |\n| D | Data | What data does it process? |\n| P | Platform | What does it depend on? |\n| O | Operations | How is it used? |\n| T | Time | How does it change over time? |\n\n**Use When**: Need human judgment, can't specify all cases, exploring new features.\n\n## Selection Matrix\n\n| Your Context | Primary Framework | Supporting |\n|--------------|------------------|------------|\n| New feature development | Beck TDD | Freeman GOOS |\n| Complex system design | Freeman GOOS | Beck |\n| Test suite maintenance | Meszaros | Feathers |\n| Legacy codebase | Feathers | Meszaros |\n| Manual testing guidance | Bach/Bolton | - |\n| Clear requirements | Beck | Meszaros |\n| Discovering requirements | Freeman GOOS | Bach/Bolton |\n\n## TDD Workflow Template\n\nBlended from Beck and Freeman:\n\n```markdown\n## Feature: [Name]\n\n### Acceptance Criteria (Outer Loop)\n- [ ] Given [context], when [action], then [outcome]\n\n### Implementation Plan\n\n#### Cycle 1\n**RED**:\n- Test: `test_[what]_[scenario]`\n- Assertion: [expected behavior]\n- Status: FAILING\n\n**GREEN**:\n- Minimal implementation: [approach]\n- Status: PASSING\n\n**REFACTOR**:\n- Improvement: [what cleaned up]\n- Tests still passing: YES\n\n#### Cycle 2\n[Continue...]\n```\n\n## Test Quality Checklist\n\nBased on Meszaros patterns:\n\n```markdown\n## Test Review Checklist\n\n### Structure\n- [ ] Clear arrange/act/assert phases\n- [ ] One logical assertion per test\n- [ ] Descriptive test name (what_when_then)\n\n### Independence\n- [ ] No test depends on another's side effects\n- [ ] Can run in any order\n- [ ] Clean setup/teardown\n\n### Readability\n- [ ] Test tells a story\n- [ ] No mystery guests (unexplained values)\n- [ ] Relevant data visible in test\n\n### Maintainability\n- [ ] No fragile assertions (over-specification)\n- [ ] Uses appropriate test doubles\n- [ ] DRY via helpers, not copy-paste\n```\n\n## Anti-Patterns to Avoid\n\n- **Test after**: Writing tests after code removes design benefits\n- **Testing implementation**: Coupling tests to internal structure\n- **Slow tests**: Not isolating from slow dependencies\n- **Test-per-method**: Testing methods instead of behaviors\n- **100% coverage worship**: Coverage doesn't equal quality\n- **Commented tests**: Delete or fix, never comment out\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nSurfaces expert frameworks for selecting methodologies before brainstorming, evaluation, or skill authoring.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, skill authors, and reviewers use this skill to choose established methodology frameworks and identify methodology gaps before creating or evaluating agent skills, hooks, or guidance.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad trigger terms may cause methodology advice to appear in contexts where the user did not intend to invoke this skill.\n\nMitigation: Review activation behavior after installation and narrow the trigger list when quieter activation is preferred.\n\n## Reference(s):\n\n- [claude-night-market abstract plugin homepage](https://github.com/athola/claude-night-market/tree/master/plugins/abstract)\n- [Instruction Design Masters](modules/instruction-design.md)\n- [Code Review Masters](modules/code-review.md)\n- [Debugging Masters](modules/debugging.md)\n- [Testing & TDD Masters](modules/testing.md)\n- [Knowledge Management Masters](modules/knowledge-management.md)\n- [Decision Making Masters](modules/decision-making.md)\n\n## Skill Output:\n\n**Output Type(s):** [guidance, markdown, text]\n\n**Output Format:** [Markdown or concise text guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Markdown-only reference; no code execution or external tool calls.]\n\n## Skill Version(s):\n\n1.9.19 (source: ClawHub release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.18: 9 files, 23708 bytes\n\nFiles: modules/code-review.md (6241b), modules/debugging.md (7053b), modules/decision-making.md (8095b), modules/instruction-design.md (6372b), modules/knowledge-management.md (7318b), modules/testing.md (7955b), skill-card.md (2043b), SKILL.md (5000b), _meta.json (151b)\n\nFile v1.9.18:SKILL.md\n\n---\nname: methodology-curator\ndescription: Surface expert frameworks\nversion: 1.9.8\ntriggers:\n  - methodology\n  - frameworks\n  - expertise\n  - curation\n  - design\n  - evaluation\n  - creating or evaluating skills\n  - hooks\n  - or agents\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/abstract\", \"emoji\": \"\\ud83e\\udde0\"}}\nsource: claude-night-market\nsource_plugin: abstract\n---\n\n> **Night Market Skill** — ported from [claude-night-market/abstract](https://github.com/athola/claude-night-market/tree/master/plugins/abstract). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Overview](#overview)\n- [Workflow Integration](#workflow-integration)\n- [Domain Modules](#domain-modules)\n- [When to Skip](#when-to-skip)\n- [Masters Overview](#masters-overview)\n- [Selection Matrix](#selection-matrix)\n\n# Methodology Curator\n\n## Overview\n\nIdentifying 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.\n\n## Workflow Integration\n\nWhen 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.\n\nFor 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.\n\n## Domain Modules\n\nEach 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.\n\n- **Instruction Design**: `modules/instruction-design.md` - Teaching techniques and behavioral objectives.\n- **Code Review**: `modules/code-review.md` - Review methodologies and feedback patterns.\n- **Debugging**: `modules/debugging.md` - Systematic troubleshooting frameworks.\n- **Testing**: `modules/testing.md` - TDD masters and test design patterns.\n- **Knowledge Management**: `modules/knowledge-management.md` - Note-taking and knowledge systems.\n- **Decision Making**: `modules/decision-making.md` - Mental models and decision frameworks.\n\n## When to Skip\n\n### Skip for Creation when:\n- You're implementing a well-defined spec\n- The domain is highly specific to your codebase\n- You've already researched methodologies externally\n- Creating a simple utility with no pedagogical component\n\n### Skip for Evaluation when:\n- Fixing syntax/structural issues (use `/validate-plugin` instead)\n- The work is purely mechanical (no methodology to ground)\n- Already performed a recent methodology audit\n- Quick bug fixes that don't change the approach\n\n## Domain Modules\n\nEach module contains:\n- **Masters**: Recognized experts in the domain\n- **Key Works**: Essential books/papers/talks\n- **Frameworks**: Actionable methodologies\n- **Selection Guide**: When to use each approach\n- **Anti-patterns**: What to avoid\n\n### Adding New Domains\n\nTo expand the masters database, create a new module following this template:\n\n```markdown\n# [Domain Name] Masters\n\n## Masters Overview\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Name   | Framework/Book  | Context  |\n\n## Detailed Frameworks\n\n### [Framework 1]\n**Source**: [Expert] - [Work]\n**Core Idea**: [One sentence]\n**Key Principles**:\n- Principle 1\n- Principle 2\n**Use When**: [Context]\n**Avoid When**: [Anti-context]\n\n## Selection Matrix\n[Decision guide for choosing between frameworks]\n```\n\n## Integration with Skill Authoring\n\nAfter curating methodologies, the skill authoring workflow benefits from:\n\n1. **Grounded TDD scenarios**: Test against the methodology's expected behaviors\n2. **Principled anti-rationalization**: Counter excuses using the methodology's logic\n3. **Authoritative references**: Cite masters in skill documentation\n4. **Consistent terminology**: Use the methodology's vocabulary\n\n## Related\n\n### For Creation\n- `/create-skill` - Skill creation workflow (use after this)\n- `/create-hook` - Hook creation workflow\n- `superpowers:brainstorming` - Refine approach after methodology selection\n- `skill-authoring` - Detailed skill writing guidance\n\n### For Evaluation\n- `/skills-eval` - Evaluate skill quality (complements methodology audit)\n- `/analyze-skill` - Analyze skill complexity\n- `/bulletproof-skill` - Harden against rationalization\n- `pensive:code-reviewer` - Code review (uses code-review domain)\n\nFile v1.9.18:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-abstract-methodology-curator\",\n  \"version\": \"1.9.18\",\n  \"publishedAt\": 1786829274111\n}\n\nFile v1.9.18:modules/code-review.md\n\n# Code Review Masters\n\nExpert frameworks for conducting effective code reviews, providing constructive feedback, and improving code quality through review processes.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Google Engineering | Google's Code Review Guidelines | Scalable team practices |\n| Martin Fowler | Refactoring Catalog | Identifying improvement patterns |\n| Michael Feathers | Working with Legacy Code | Safe modification strategies |\n| Karl Wiegers | Peer Reviews in Software | Process optimization |\n| Trisha Gee | Code Review Best Practices | Practical JetBrains wisdom |\n\n## Detailed Frameworks\n\n### Google's Code Review Standards\n\n**Source**: Google Engineering Practices Documentation (public)\n\n**Core Idea**: Reviews should improve code health while enabling progress.\n\n**Key Principles**:\n- **Speed matters**: Review within 24 hours, ideally same day\n- **Small changes**: Prefer small, focused CLs (changelists)\n- **Approve if better**: Don't block for perfection\n- **Distinguish severity**: Nit vs. suggestion vs. blocker\n\n**The Standard**:\n> \"Reviewers should approve a CL once it definitely improves overall code health, even if it isn't perfect.\"\n\n**Comment Prefixes**:\n```\nNit:      Minor style preference, optional\nSuggest:  Improvement idea, author decides\nConsider: Worth thinking about, not blocking\nBLOCKING: Must fix before approval\n```\n\n**Use When**: Establishing team review standards, training reviewers.\n\n**Avoid When**: Security-critical code (needs stricter process).\n\n---\n\n### Fowler's Refactoring Patterns\n\n**Source**: Martin Fowler - \"Refactoring\" (1999, 2nd ed. 2018)\n\n**Core Idea**: Catalog of named transformations for improving code structure.\n\n**Review Application**: Use pattern names as shared vocabulary in reviews.\n\n**High-Value Patterns for Reviews**:\n| Smell | Refactoring | Review Comment |\n|-------|-------------|----------------|\n| Long function | Extract Method | \"This could be extracted into `calculateTotal()`\" |\n| Repeated code | Extract Method/Class | \"Duplicated in lines 45, 89—extract?\" |\n| Long parameter list | Introduce Parameter Object | \"Consider grouping these into a config object\" |\n| Feature Envy | Move Method | \"This method uses more of Order than Cart\" |\n| Primitive Obsession | Replace with Value Object | \"A Money type would prevent currency bugs\" |\n\n**Use When**: Providing actionable refactoring suggestions.\n\n---\n\n### Feathers' Legacy Code Strategies\n\n**Source**: Michael Feathers - \"Working Effectively with Legacy Code\" (2004)\n\n**Core Idea**: \"Legacy code is code without tests.\" Review for testability.\n\n**Key Review Questions**:\n1. **Seams**: Are there places to substitute behavior for testing?\n2. **Dependencies**: Can this be tested in isolation?\n3. **Characterization**: Would a test capture current behavior?\n\n**The Legacy Change Algorithm**:\n1. Identify change points\n2. Find test points\n3. Break dependencies\n4. Write tests\n5. Make changes\n\n**Review Comments for Legacy**:\n```\n\"Before modifying this, consider adding a characterization test\"\n\"This method has too many dependencies—can we inject the database?\"\n\"Consider introducing a seam here for testability\"\n```\n\n**Use When**: Reviewing changes to untested code.\n\n---\n\n### Wiegers' Peer Review Types\n\n**Source**: Karl Wiegers - \"Peer Reviews in Software\" (2002)\n\n**Core Idea**: Match review intensity to risk level.\n\n**Review Spectrum**:\n| Type | Effort | When to Use |\n|------|--------|-------------|\n| **Ad-hoc** | Lowest | Quick questions, pair checks |\n| **Passaround** | Low | Routine changes, docs |\n| **Walkthrough** | Medium | Knowledge sharing, onboarding |\n| **Team Review** | Medium-High | Design decisions, complex logic |\n| **Inspection** | Highest | Safety-critical, core algorithms |\n\n**Defect Detection Rates**:\n- Inspection: 60-90% of defects found\n- Walkthrough: 20-40%\n- Testing alone: 25-35%\n\n**Use When**: Deciding review depth for different code types.\n\n---\n\n### Gee's Practical Code Review\n\n**Source**: Trisha Gee - Various talks and articles (JetBrains)\n\n**Core Idea**: Reviews should be humane and focused on learning.\n\n**Key Principles**:\n- **Automate the boring stuff**: Linting, formatting, style → CI\n- **Focus human attention**: Logic, design, readability\n- **Be kind**: Criticize code, not people\n- **Ask questions**: \"What was the thinking here?\" vs \"This is wrong\"\n\n**Comment Formulas**:\n```\nInstead of: \"This is wrong\"\nTry:        \"I'm curious—what led to this approach?\"\n\nInstead of: \"Use X pattern\"\nTry:        \"Have you considered X? It might help with Y\"\n\nInstead of: \"This will break\"\nTry:        \"What happens if input is null here?\"\n```\n\n**Feedback Categories**:\n1. **Bugs**: Logic errors, edge cases\n2. **Design**: Coupling, cohesion, patterns\n3. **Readability**: Naming, structure, comments\n4. **Learning**: Knowledge sharing opportunities\n\n**Use When**: Writing constructive review feedback, training reviewers.\n\n## Selection Matrix\n\n| Your Context | Primary Framework | Supporting |\n|--------------|------------------|------------|\n| High-velocity team | Google Standards | Gee |\n| Improving existing code | Fowler | Feathers |\n| Safety-critical systems | Wiegers | Feathers |\n| Team culture improvement | Gee | Google |\n| Legacy codebase | Feathers | Fowler |\n\n## Review Checklist Template\n\nBased on blended frameworks:\n\n```markdown\n## Quick Checks (Automate These)\n- [ ] Passes linting\n- [ ] Passes tests\n- [ ] No merge conflicts\n\n## Human Review Focus\n### Correctness\n- [ ] Logic handles edge cases\n- [ ] Error handling appropriate\n\n### Design (Fowler)\n- [ ] No obvious code smells\n- [ ] Single responsibility followed\n- [ ] Dependencies reasonable\n\n### Testability (Feathers)\n- [ ] New code has tests\n- [ ] Changes don't break test isolation\n- [ ] Can test in isolation\n\n### Readability (Gee)\n- [ ] Names reveal intent\n- [ ] Comments explain \"why\" not \"what\"\n- [ ] Complexity appropriate\n```\n\n## Anti-Patterns to Avoid\n\n- **Nitpick storms**: Dozens of style comments (use linters)\n- **Rubber stamping**: Approving without reading\n- **Gatekeeping**: Using reviews to block or control\n- **Scope creep**: Requesting unrelated changes\n- **Delayed reviews**: Blocking progress for days\n\nFile v1.9.18:modules/debugging.md\n\n# Debugging Masters\n\nExpert frameworks for systematic troubleshooting, root cause analysis, and efficient bug resolution.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Andreas Zeller | Scientific Debugging | Systematic hypothesis testing |\n| David Agans | Nine Rules of Debugging | Universal debugging principles |\n| Diomidis Spinellis | Effective Debugging | Comprehensive toolkit |\n| Rob Miller | Debugging by Asking | Root cause questioning |\n| John Regehr | Compiler/Systems Debugging | Low-level issues |\n\n## Detailed Frameworks\n\n### Zeller's Scientific Debugging\n\n**Source**: Andreas Zeller - \"Why Programs Fail\" (2009)\n\n**Core Idea**: Apply scientific method to debugging—hypothesis, experiment, conclusion.\n\n**The Scientific Debugging Process**:\n```\n1. OBSERVE failure\n2. HYPOTHESIZE cause (be specific!)\n3. PREDICT behavior if hypothesis true\n4. EXPERIMENT to test prediction\n5. CONCLUDE: confirmed or refuted\n6. REPEAT with new hypothesis\n```\n\n**Key Principle**: Never change code to \"see if it fixes it.\" That's guessing, not debugging.\n\n**Hypothesis Quality**:\n```\nBAD:  \"Something's wrong with the database\"\nGOOD: \"The query times out because it scans all rows without index\"\n```\n\n**Delta Debugging** (Zeller's technique):\n- Minimize failing input\n- Find smallest change that triggers bug\n- Isolate exactly what causes failure\n\n**Use When**: Complex bugs, intermittent failures, need systematic approach.\n\n---\n\n### Agans' Nine Rules\n\n**Source**: David Agans - \"Debugging: The 9 Indispensable Rules\" (2002)\n\n**Core Idea**: Universal rules that apply to any debugging scenario.\n\n**The Nine Rules**:\n\n| # | Rule | Application |\n|---|------|-------------|\n| 1 | **Understand the System** | Read docs, trace data flow before assuming |\n| 2 | **Make It Fail** | Reproduce reliably before investigating |\n| 3 | **Quit Thinking and Look** | Actually read error messages, logs, state |\n| 4 | **Divide and Conquer** | Binary search to isolate |\n| 5 | **Change One Thing at a Time** | Controlled experiments only |\n| 6 | **Keep an Audit Trail** | Log what you tried and results |\n| 7 | **Check the Plug** | Verify assumptions, environment, obvious things |\n| 8 | **Get a Fresh View** | Rubber duck, ask colleague, sleep on it |\n| 9 | **If You Didn't Fix It, It Ain't Fixed** | Verify root cause, not just symptoms |\n\n**Most Violated Rules**:\n- #3: Jumping to hypotheses without reading the actual error\n- #5: Changing multiple things hoping something works\n- #9: Seeing issue disappear and assuming it's fixed\n\n**Use When**: Any debugging situation—these are universal.\n\n---\n\n### Spinellis' Debugging Strategies\n\n**Source**: Diomidis Spinellis - \"Effective Debugging\" (2016)\n\n**Core Idea**: Comprehensive toolkit organized by debugging phase.\n\n**Strategy Categories**:\n\n**High-Level Strategies**:\n| Strategy | When to Use |\n|----------|-------------|\n| Reproduce consistently | First step, always |\n| Simplify input | Large inputs, complex state |\n| Minimize code | Isolate to smallest failing example |\n| Add instrumentation | Need visibility into behavior |\n| Review recent changes | \"It was working yesterday\" |\n\n**Technical Strategies**:\n| Strategy | Application |\n|----------|-------------|\n| Printf debugging | Quick visibility, any environment |\n| Debugger stepping | Complex control flow |\n| Core dump analysis | Crashes, post-mortem |\n| Profiling | Performance issues |\n| Tracing | System call, network issues |\n\n**Process Strategies**:\n| Strategy | When to Use |\n|----------|-------------|\n| Pair debugging | Stuck for >30 minutes |\n| Take a break | Tunnel vision, frustration |\n| Explain to rubber duck | Can't articulate problem |\n| Search error message | May be known issue |\n\n**Use When**: Need specific technique for specific problem type.\n\n---\n\n### Miller's Debugging Questions\n\n**Source**: Rob Miller (MIT) - Debugging lectures\n\n**Core Idea**: Systematic questioning reveals root cause.\n\n**The Question Ladder**:\n\n1. **What did you expect to happen?**\n2. **What actually happened?**\n3. **What's the difference?**\n4. **When did it last work?**\n5. **What changed since then?**\n6. **Where exactly does behavior diverge from expectation?**\n\n**Localization Questions**:\n- At what point does the state become incorrect?\n- What is the last known good state?\n- What is the first known bad state?\n\n**Use When**: Starting any debugging session, structuring investigation.\n\n---\n\n### Regehr's Low-Level Debugging\n\n**Source**: John Regehr - Embedded Systems & Compiler Expert\n\n**Core Idea**: Systems-level bugs need systems-level thinking.\n\n**Principles**:\n- **Trust nothing**: Verify compiler output, hardware state\n- **Reduce**: Minimize to smallest reproducer\n- **Isolation**: Test components independently\n- **Invariants**: Assert what must be true\n\n**Common Systems Bug Categories**:\n| Category | Symptoms | Approach |\n|----------|----------|----------|\n| Memory corruption | Crashes, weird values | Valgrind, ASan |\n| Race conditions | Intermittent, timing-dependent | Thread sanitizer, logging |\n| Resource leaks | Slow degradation | Monitor, profiling |\n| Undefined behavior | \"Works on my machine\" | UBSan, static analysis |\n\n**Use When**: Low-level, systems, or intermittent bugs.\n\n## Selection Matrix\n\n| Bug Type | Primary Framework | Supporting |\n|----------|------------------|------------|\n| Any bug (start here) | Agans' 9 Rules | Miller Questions |\n| Complex/subtle bugs | Zeller Scientific | Agans #5, #6 |\n| \"It was working\" | Spinellis Review Changes | Agans #1 |\n| Intermittent failures | Zeller Delta Debug | Regehr |\n| Performance issues | Spinellis Profiling | Agans #4 |\n| Unknown territory | Agans #1, #7 | Miller Questions |\n\n## Debugging Workflow Template\n\nBlended from all frameworks:\n\n```markdown\n## Bug: [Brief description]\n\n### 1. Understand & Reproduce (Agans #1, #2)\n- System understanding: [What should happen]\n- Reproduction steps:\n  1. [Step]\n  2. [Step]\n- Reproduction rate: [Always/Sometimes/Rare]\n\n### 2. Observe (Agans #3, Miller)\n- Expected: [What should happen]\n- Actual: [What happens]\n- Difference: [Gap]\n- Last working: [When/version]\n\n### 3. Hypothesize (Zeller)\n| # | Hypothesis | Prediction | Test | Result |\n|---|------------|------------|------|--------|\n| 1 | | | | |\n| 2 | | | | |\n| 3 | | | | |\n\n### 4. Isolate (Agans #4, #5)\n- Binary search log:\n  - [✓] Works at commit abc123\n  - [✗] Fails at commit def456\n  - Narrowed to: [specific change]\n\n### 5. Fix & Verify (Agans #9)\n- Root cause: [Actual cause]\n- Fix: [What changed]\n- Verification: [How confirmed]\n- Regression test added: [Yes/No]\n```\n\n## Anti-Patterns to Avoid\n\n- **Shotgun debugging**: Changing random things hoping to fix it\n- **Assumption debugging**: Not verifying basic assumptions (Agans #7)\n- **Tunnel vision**: Fixating on one hypothesis without testing others\n- **History blindness**: Not checking what recently changed\n- **Solo heroics**: Not asking for help when stuck (Agans #8)\n- **Premature celebration**: Assuming it's fixed without proof (Agans #9)\n\nFile v1.9.18:modules/decision-making.md\n\n# Decision Making Masters\n\nExpert frameworks for making better decisions, avoiding cognitive biases, and developing reliable judgment.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Charlie Munger | Mental Models, Inversion | Investment/business decisions |\n| Daniel Kahneman | System 1/2, Biases | Understanding cognitive limitations |\n| Gary Klein | Recognition-Primed Decision | Expert intuition, time pressure |\n| Annie Duke | Thinking in Bets | Decisions under uncertainty |\n| Ray Dalio | Principles, Radical Transparency | Organizational decisions |\n\n## Detailed Frameworks\n\n### Munger's Mental Models\n\n**Source**: Charlie Munger - \"Poor Charlie's Almanack\", Berkshire letters\n\n**Core Idea**: Build a latticework of mental models from multiple disciplines; use them in combination.\n\n**Key Mental Models**:\n\n| Model | Discipline | Application |\n|-------|------------|-------------|\n| **Inversion** | Mathematics | \"What would make this fail?\" |\n| **Second-Order Effects** | Physics | \"What happens next? Then what?\" |\n| **Circle of Competence** | Self-knowledge | \"What do I actually understand?\" |\n| **Margin of Safety** | Engineering | \"What's the buffer for error?\" |\n| **Opportunity Cost** | Economics | \"What am I giving up?\" |\n| **Incentives** | Psychology | \"What are people rewarded for?\" |\n\n**Inversion Technique**:\n```\nInstead of: \"How do I succeed?\"\nAsk:        \"How would I guarantee failure?\"\nThen:       Avoid those things\n\nInstead of: \"How do I make a great skill?\"\nAsk:        \"What makes skills terrible?\"\nThen:       Eliminate those patterns\n```\n\n**Use When**: Complex decisions, need diverse perspectives, avoiding blind spots.\n\n---\n\n### Kahneman's System 1/System 2\n\n**Source**: Daniel Kahneman - \"Thinking, Fast and Slow\" (2011)\n\n**Core Idea**: Two thinking systems with different strengths and failure modes.\n\n**The Two Systems**:\n| System 1 (Fast) | System 2 (Slow) |\n|-----------------|-----------------|\n| Automatic | Effortful |\n| Intuitive | Analytical |\n| Parallel | Serial |\n| Emotional | Logical |\n| Error-prone | Accurate but lazy |\n\n**Key Biases to Counter**:\n| Bias | Description | Countermeasure |\n|------|-------------|----------------|\n| **Anchoring** | First number influences | Generate own estimate first |\n| **Availability** | Recent = likely | Ask \"What am I not seeing?\" |\n| **Confirmation** | Seek supporting evidence | Actively seek disconfirming |\n| **Overconfidence** | Certainty exceeds accuracy | Estimate confidence intervals |\n| **Hindsight** | \"I knew it all along\" | Record predictions beforehand |\n| **Sunk cost** | Continue because invested | \"Would I start this now?\" |\n\n**Pre-Mortem Technique**:\n```\nImagine the project has failed spectacularly.\nWrite the story of why it failed.\nNow prevent those things.\n```\n\n**Use When**: Need to check intuitions, high-stakes decisions, avoiding biases.\n\n---\n\n### Klein's Recognition-Primed Decision (RPD)\n\n**Source**: Gary Klein - \"Sources of Power\" (1998)\n\n**Core Idea**: Experts don't compare options; they recognize patterns and simulate actions.\n\n**How Experts Decide**:\n```\n1. Recognize situation type (pattern match)\n2. Identify typical action for situation\n3. Mental simulation: \"If I do this, what happens?\"\n4. If simulation works → act\n5. If problems → modify or consider next option\n```\n\n**Key Insight**: Experts rarely compare options analytically. They satisfice, not optimize.\n\n**When to Trust Intuition**:\n| Trust intuition when: | Don't trust when: |\n|----------------------|-------------------|\n| High experience in domain | Novel domain |\n| Regular, rapid feedback | Delayed/noisy feedback |\n| Stable, predictable environment | Chaotic, random environment |\n\n**Use When**: Time pressure, experienced domain, need fast action.\n\n---\n\n### Duke's Thinking in Bets\n\n**Source**: Annie Duke - \"Thinking in Bets\" (2018)\n\n**Core Idea**: Decisions are bets about the future; separate decision quality from outcome quality.\n\n**Key Principles**:\n- **Resulting**: Judging decision by outcome is wrong\n- **Uncertainty**: All decisions are probabilistic\n- **Expected value**: Probability × payoff\n\n**Decision Quality vs. Outcome Quality**:\n```\n                    OUTCOME\n                Good        Bad\n         Good   Deserved    Bad luck\nDECISION        win         (learn nothing)\n         Bad    Good luck   Deserved\n                (dangerous) loss\n```\n\n**The 10-10-10 Rule**:\n```\nHow will I feel about this decision:\n- 10 minutes from now?\n- 10 months from now?\n- 10 years from now?\n```\n\n**Decision Groups**:\n- Find truth-seeking group\n- Agree to criticize ideas, not people\n- Reward process, not outcome\n- Update beliefs openly\n\n**Use When**: Uncertain outcomes, need to separate luck from skill.\n\n---\n\n### Dalio's Principles\n\n**Source**: Ray Dalio - \"Principles\" (2017)\n\n**Core Idea**: Make decisions through explicit principles; radical transparency.\n\n**The Idea Meritocracy**:\n```\nBest ideas win, regardless of source\nBelievability-weighted voting\nRadical transparency in reasoning\n```\n\n**Decision-Making Process**:\n1. **Perceive** problems accurately\n2. **Diagnose** root causes\n3. **Design** solutions (principles)\n4. **Do** (execute)\n5. **Document** as principle for future\n\n**Believability Weighting**:\n```\nNot all opinions equal. Weight by:\n- Track record in relevant area\n- Demonstrated reasoning ability\n- Appropriate confidence level\n```\n\n**Radical Transparency Questions**:\n- What don't I know?\n- Who can help me see blind spots?\n- What would change my mind?\n\n**Use When**: Team decisions, building organizational processes, documenting decisions.\n\n## Selection Matrix\n\n| Decision Context | Primary Framework | Supporting |\n|------------------|------------------|------------|\n| Strategic/business | Munger | Dalio |\n| Individual bias check | Kahneman | Duke |\n| Time pressure | Klein RPD | Munger (prepared models) |\n| Uncertain outcomes | Duke | Kahneman |\n| Team decisions | Dalio | Duke |\n| Building expertise | Klein | Kahneman |\n\n## Decision Framework Template\n\nBlended approach for important decisions:\n\n```markdown\n## Decision: [Brief statement]\n\n### 1. Frame (Munger + Kahneman)\n- What's the actual decision?\n- Inversion: How would I guarantee failure?\n- What am I not seeing? (availability bias check)\n\n### 2. Generate Options\n- Option A: [description]\n- Option B: [description]\n- Option C: Do nothing / wait\n\n### 3. Evaluate (Duke + Klein)\n| Option | Probability of Success | Upside | Downside | Expected Value |\n|--------|----------------------|--------|----------|----------------|\n| A | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |\n| B | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |\n| C | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |\n\n### 4. Pre-Mortem (Kahneman)\nIf this fails, it will be because:\n1. [Risk 1]\n2. [Risk 2]\nMitigations: [How to prevent]\n\n### 5. Decide & Document (Dalio)\n**Decision**: [Choice]\n**Reasoning**: [Why this option]\n**Confidence**: [High/Medium/Low]\n**Review date**: [When to evaluate]\n\n### 6. Post-Decision (Duke)\n**Outcome**: [What happened]\n**Was decision quality good?**: [Separate from outcome]\n**What to learn**: [Principle for future]\n```\n\n## For Scope-Guard / Imbue Plugin\n\nSpecific applications:\n\n| Decision Need | Methodology Application |\n|--------------|------------------------|\n| Worthiness scoring | Expected value (Duke) |\n| Anti-overengineering | Inversion (Munger) |\n| Scope decisions | Pre-mortem (Kahneman) |\n| Feature prioritization | Opportunity cost (Munger) |\n| Review evidence logging | Principles documentation (Dalio) |\n\n## Anti-Patterns to Avoid\n\n- **Analysis paralysis**: Perfect information doesn't exist\n- **Resulting**: Judging decisions by outcomes alone\n- **Consensus seeking**: Agreement ≠ correctness\n- **Confidence = competence**: Loudest isn't rightest\n- **Single model thinking**: One mental model isn't enough\n- **Ignoring base rates**: Your situation probably isn't special\n\nFile v1.9.18:modules/instruction-design.md\n\n# Instruction Design Masters\n\nExpert frameworks for teaching techniques, writing effective instructions, and creating behavioral change through documentation.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Robert Mager | Behavioral Objectives | Measurable skill outcomes |\n| Benjamin Bloom | Taxonomy of Learning | Cognitive level targeting |\n| Robert Gagné | Nine Events of Instruction | Structured lesson design |\n| John Sweller | Cognitive Load Theory | Reducing mental overhead |\n| Ruth Clark | Evidence-Based Training | Practical instructional design |\n\n## Detailed Frameworks\n\n### Mager's Behavioral Objectives\n\n**Source**: Robert Mager - \"Preparing Instructional Objectives\" (1962)\n\n**Core Idea**: Objectives must specify observable behavior, conditions, and criteria.\n\n**Key Principles**:\n- **Performance**: What the learner will DO (observable verb)\n- **Conditions**: Under what circumstances (tools, constraints)\n- **Criterion**: How well (accuracy, speed, quality threshold)\n\n**Formula**: \"Given [conditions], the learner will [performance] to [criterion].\"\n\n**Example for Skills**:\n```\nBAD:  \"Understand TDD methodology\"\nGOOD: \"Given a failing test, implement minimal code to pass within 3 iterations\"\n```\n\n**Use When**: Creating technique skills, defining success criteria, writing \"Use when\" clauses.\n\n**Avoid When**: Teaching abstract concepts, pattern recognition, creative tasks.\n\n---\n\n### Bloom's Taxonomy (Revised)\n\n**Source**: Benjamin Bloom et al., revised by Anderson & Krathwohl (2001)\n\n**Core Idea**: Learning has hierarchical levels; target the right cognitive level.\n\n**Levels (lowest to highest)**:\n1. **Remember**: Recall facts → Reference skills, checklists\n2. **Understand**: Explain concepts → Pattern skills, mental models\n3. **Apply**: Use in new situations → Technique skills, workflows\n4. **Analyze**: Break down, find patterns → Debugging skills, code review\n5. **Evaluate**: Judge, critique → Assessment frameworks, quality gates\n6. **Create**: Produce new work → Design skills, architecture guidance\n\n**Use When**: Determining skill type, structuring progressive disclosure, setting appropriate depth.\n\n**Skill Mapping**:\n| Skill Type | Target Level | Verbs to Use |\n|-----------|--------------|--------------|\n| Reference | Remember | List, recall, identify |\n| Pattern | Understand | Explain, compare, summarize |\n| Technique | Apply/Analyze | Implement, execute, debug |\n\n---\n\n### Gagné's Nine Events of Instruction\n\n**Source**: Robert Gagné - \"The Conditions of Learning\" (1965)\n\n**Core Idea**: Effective instruction follows nine sequential events.\n\n**The Nine Events**:\n1. **Gain attention**: Hook with problem or scenario\n2. **Inform objectives**: State what they'll learn (Use when clause)\n3. **Stimulate recall**: Connect to prior knowledge\n4. **Present content**: The actual instruction\n5. **Provide guidance**: Examples, worked problems\n6. **Elicit performance**: Practice opportunity\n7. **Provide feedback**: Correct/reinforce\n8. **Assess performance**: Verify learning\n9. **Enhance retention**: Transfer to real contexts\n\n**Skill Structure Mapping**:\n```\nSKILL.md Structure           Gagné Event\n─────────────────────────────────────────\nOverview/Problem statement → 1. Gain attention\n\"Use when\" clause          → 2. Inform objectives\nRelated skills/prereqs     → 3. Stimulate recall\nCore content               → 4. Present content\nExamples                   → 5. Provide guidance\nWorkflows/checklists       → 6. Elicit performance\nAnti-patterns/red flags    → 7. Provide feedback\nValidation commands        → 8. Assess performance\nReal-world scenarios       → 9. Enhance retention\n```\n\n**Use When**: Designing complete skill structure, ensuring nothing essential is missing.\n\n---\n\n### Cognitive Load Theory\n\n**Source**: John Sweller - \"Cognitive Load Theory\" (1988)\n\n**Core Idea**: Working memory is limited; reduce unnecessary load.\n\n**Three Types of Load**:\n- **Intrinsic**: Complexity inherent to the material (can't reduce)\n- **Extraneous**: Poor presentation adding confusion (ELIMINATE)\n- **Germane**: Effort building mental models (MAXIMIZE)\n\n**Techniques for Skills**:\n| Principle | Application |\n|-----------|-------------|\n| Chunking | Progressive disclosure, modular files |\n| Worked examples | Complete code samples, not pseudocode |\n| Split attention | Keep related info together (no \"see also\" mid-flow) |\n| Redundancy | Don't repeat same info in text AND diagram |\n| Expertise reversal | Advanced users need less scaffolding |\n\n**Use When**: Optimizing token efficiency, structuring modules, deciding what to cut.\n\n---\n\n### Clark's Evidence-Based Training\n\n**Source**: Ruth Clark - \"Evidence-Based Training Methods\" (2019)\n\n**Core Idea**: Use research-proven methods, not intuition.\n\n**Key Findings**:\n- **Examples beat descriptions**: Show, don't tell\n- **Practice with feedback**: Interactive > passive reading\n- **Spaced learning**: Break into digestible chunks\n- **Relevant context**: Real scenarios > abstract theory\n\n**Anti-patterns** (feel effective but aren't):\n- Long prose explanations\n- Comprehensive coverage without practice\n- Learning styles myths (visual/auditory)\n- Information dumps\n\n**Use When**: Reviewing skills for effectiveness, cutting unnecessary content.\n\n## Selection Matrix\n\n| Your Goal | Primary Framework | Supporting |\n|-----------|------------------|------------|\n| Define clear outcomes | Mager | Bloom |\n| Structure complete skill | Gagné | Cognitive Load |\n| Reduce skill complexity | Cognitive Load | Clark |\n| Choose skill type | Bloom | Mager |\n| Validate effectiveness | Clark | Gagné |\n\n## Blending Example\n\nCreating a debugging skill:\n1. **Bloom**: Target \"Analyze\" level (break down, identify patterns)\n2. **Mager**: \"Given error output, identify root cause within 3 hypotheses\"\n3. **Cognitive Load**: Use worked examples, progressive modules\n4. **Gagné**: Structure with attention hook → examples → practice workflow\n\n## Anti-Patterns to Avoid\n\n- **Covering everything**: Cognitive overload, low retention\n- **Vague objectives**: \"Understand debugging\" (not measurable)\n- **Missing practice**: All theory, no application\n- **Wrong level**: Teaching \"remember\" when \"apply\" is needed\n\nFile v1.9.18:modules/knowledge-management.md\n\n# Knowledge Management Masters\n\nExpert frameworks for capturing, organizing, connecting, and retrieving knowledge effectively.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Niklas Luhmann | Zettelkasten (Slip-box) | Connected notes, emergent thinking |\n| Sönke Ahrens | Smart Notes Method | Writing-focused knowledge work |\n| Vannevar Bush | Memex Concept | Associative trails, hypertext thinking |\n| David Allen | GTD (Getting Things Done) | Action-oriented knowledge capture |\n| Tiago Forte | PARA and Building a Second Brain | Digital organization, progressive summarization |\n\n## Detailed Frameworks\n\n### Luhmann's Zettelkasten\n\n**Source**: Niklas Luhmann - Sociologist, 70+ books, 90,000+ notes\n\n**Core Idea**: Atomic notes with explicit links create a \"conversation partner\" that surfaces unexpected connections.\n\n**Key Principles**:\n- **Atomicity**: One idea per note\n- **Linking**: Notes connect to other notes, not just categories\n- **Own words**: Rewrite in your understanding, never copy\n- **Unique identifiers**: Every note has permanent address\n- **Emergence**: Structure emerges from links, not imposed hierarchy\n\n**Note Types**:\n| Type | Purpose | Example |\n|------|---------|---------|\n| Fleeting | Quick capture | \"Idea: cognitive load applies to skills\" |\n| Literature | Reference to source | \"Sweller 1988 argues...\" |\n| Permanent | Processed, atomic insight | \"Cognitive load limits skill file size\" |\n| Structure | Index/hub notes | \"MOC: Skill Design Principles\" |\n\n**The Process**:\n```\n1. Capture fleeting notes throughout day\n2. Process into permanent notes (rewrite, atomize)\n3. Link to existing notes (where does this connect?)\n4. Add to structure notes (entry points)\n5. Review and discover connections\n```\n\n**Use When**: Building long-term knowledge base, research, writing projects.\n\n---\n\n### Ahrens' Smart Notes\n\n**Source**: Sönke Ahrens - \"How to Take Smart Notes\" (2017)\n\n**Core Idea**: Writing is thinking; note-taking should support writing output.\n\n**Key Principles**:\n- **Writing as thinking**: You don't write up ideas, you think through writing\n- **Bottom-up structure**: Let topics emerge from notes\n- **Slip-box as partner**: External thinking system\n- **Focus on output**: Notes serve future writing\n\n**The Workflow**:\n```\nReading → Fleeting Notes → Literature Notes → Permanent Notes → Writing\n```\n\n**Quality Criteria for Permanent Notes**:\n- Could someone else understand it without context?\n- Is it written in complete sentences?\n- Does it stand on its own?\n- Does it connect to existing notes?\n\n**Writing Process**:\n1. Collect relevant permanent notes\n2. Arrange in sequence\n3. Turn sequence into draft\n4. Edit and refine\n\n**Use When**: Academic writing, knowledge synthesis, developing arguments.\n\n---\n\n### Bush's Memex & Associative Trails\n\n**Source**: Vannevar Bush - \"As We May Think\" (1945)\n\n**Core Idea**: Human mind works by association; tools should support trails of thought.\n\n**Key Concepts**:\n- **Associative indexing**: Link by meaning, not alphabet\n- **Trails**: Paths through information, shareable\n- **Personal library**: All knowledge accessible, connected\n- **Selection vs. creation**: Value in curating paths\n\n**Modern Applications**:\n| Memex Concept | Modern Implementation |\n|---------------|----------------------|\n| Associative links | Hyperlinks, backlinks |\n| Trails | Curated reading paths, playlists |\n| Personal library | Personal wikis, note apps |\n| Selection devices | Search, tags, filters |\n\n**Use When**: Designing knowledge systems, understanding hypertext principles.\n\n---\n\n### Allen's GTD (Getting Things Done)\n\n**Source**: David Allen - \"Getting Things Done\" (2001)\n\n**Core Idea**: Capture everything; mind is for having ideas, not holding them.\n\n**The Five Steps**:\n```\n1. CAPTURE    - Get everything out of your head\n2. CLARIFY    - What is it? Is it actionable?\n3. ORGANIZE   - Put it where it belongs\n4. REFLECT    - Review regularly\n5. ENGAGE     - Do with confidence\n```\n\n**The Two-Minute Rule**: If it takes less than 2 minutes, do it now.\n\n**Clarify Decision Tree**:\n```\nIs it actionable?\n├── NO → Reference, Someday/Maybe, or Trash\n└── YES → What's the next action?\n    ├── Multi-step? → It's a Project\n    └── Single step?\n        ├── <2 min? → Do it now\n        ├── Delegate? → Waiting For\n        └── Defer? → Next Actions (by context)\n```\n\n**Use When**: Action-oriented knowledge, task management, reducing cognitive load.\n\n---\n\n### Forte's PARA & Second Brain\n\n**Source**: Tiago Forte - \"Building a Second Brain\" (2022)\n\n**Core Idea**: Organize by actionability, not topic. Progressive summarization for retrieval.\n\n**PARA System**:\n| Folder | Contains | Timeframe |\n|--------|----------|-----------|\n| **P**rojects | Active outcomes | Weeks |\n| **A**reas | Ongoing responsibilities | Indefinite |\n| **R**esources | Useful references | As needed |\n| **A**rchive | Inactive items | Done |\n\n**Progressive Summarization**:\n```\nLayer 0: Original source\nLayer 1: Bolded passages (10-20%)\nLayer 2: Highlighted from bold (10-20% of bold)\nLayer 3: Executive summary (your words)\nLayer 4: Remix (original synthesis)\n```\n\n**CODE Method**:\n- **C**apture: Save resonant information\n- **O**rganize: Put in PARA folder\n- **D**istill: Progressive summarization\n- **E**xpress: Create output\n\n**Use When**: Digital knowledge management, balancing capture and retrieval.\n\n## Selection Matrix\n\n| Your Goal | Primary Framework | Supporting |\n|-----------|------------------|------------|\n| Long-term knowledge building | Zettelkasten | Ahrens |\n| Writing/research output | Ahrens | Zettelkasten |\n| Task/action management | GTD | PARA |\n| Digital organization | PARA | GTD |\n| System design | Bush Memex | Zettelkasten |\n| Reducing overwhelm | GTD | PARA |\n\n## Knowledge System Template\n\nBlended approach for a knowledge base:\n\n```markdown\n## Knowledge System Design\n\n### Capture Layer (GTD + PARA)\n- Inbox: Quick capture without friction\n- Two-minute rule for processing\n- Daily processing to zero\n\n### Organization (PARA + Zettelkasten)\n- Projects: Active work with deadlines\n- Areas: Ongoing responsibilities\n- Notes: Atomic, linked permanent notes\n- Archive: Completed/inactive\n\n### Connection (Zettelkasten)\n- Every note links to 2+ existing notes\n- Structure notes (MOCs) for entry points\n- Tags for cross-cutting themes\n- Regular gardening/review\n\n### Output (Ahrens + Progressive Summary)\n- Progressive summarization of sources\n- Assemble notes for projects\n- Write from accumulated notes\n```\n\n## For Memory-Palace Plugin\n\nSpecific applications:\n\n| Memory-Palace Feature | Methodology Source |\n|----------------------|-------------------|\n| Knowledge nodes | Zettelkasten atomicity |\n| Backlinks | Luhmann's linking |\n| Daily notes | GTD capture |\n| MOC/Index notes | Zettelkasten structure notes |\n| Project organization | PARA |\n| Search/retrieval | Progressive summarization |\n\n## Anti-Patterns to Avoid\n\n- **Collector's fallacy**: Saving without processing\n- **Tagging obsession**: Tags without links\n- **Hierarchy prison**: Rigid folders killing discovery\n- **Perfect system seeking**: Setup > usage\n- **Copy-paste notes**: No rewriting = no understanding\n- **Orphan notes**: Notes without connections die\n\nFile v1.9.18:modules/testing.md\n\n# Testing & TDD Masters\n\nExpert frameworks for test-driven development, test design, and building confidence in code through systematic verification.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Kent Beck | TDD, xUnit Patterns | Test-first development |\n| Steve Freeman & Nat Pryce | GOOS (Growing Object-Oriented Software) | Outside-in TDD |\n| Gerard Meszaros | xUnit Test Patterns | Test design & maintenance |\n| Michael Feathers | Legacy Code Testing | Adding tests to existing code |\n| James Bach & Michael Bolton | Exploratory Testing | Manual testing rigor |\n\n## Detailed Frameworks\n\n### Beck's Test-Driven Development\n\n**Source**: Kent Beck - \"Test-Driven Development: By Example\" (2002)\n\n**Core Idea**: Write failing test first, then minimal code to pass, then refactor.\n\n**The TDD Cycle**:\n```\nRED    → Write failing test (design the interface)\nGREEN  → Write minimal code to pass (make it work)\nREFACTOR → Improve code (make it right)\nREPEAT\n```\n\n**Key Principles**:\n- **Test first, not test after**: Tests drive design\n- **Small steps**: One assertion, one tiny change\n- **Minimal code**: Only enough to pass the test\n- **Continuous refactoring**: Clean as you go\n\n**Beck's Three Laws of TDD**:\n1. Don't write production code until you have a failing test\n2. Don't write more test than sufficient to fail\n3. Don't write more production code than sufficient to pass\n\n**Use When**: Greenfield development, clear requirements, need design guidance.\n\n**Avoid When**: Exploratory prototyping, highly uncertain domains.\n\n---\n\n### Freeman & Pryce's Outside-In TDD (GOOS)\n\n**Source**: \"Growing Object-Oriented Software, Guided by Tests\" (2009)\n\n**Core Idea**: Start from acceptance tests, work inward, discover design.\n\n**The Double Loop**:\n```mermaid\nflowchart LR\n    subgraph outer[\"Outer Loop (Acceptance)\"]\n        a1[\"1. Write failing<br/>acceptance test\"]\n        a2[\"2. When acceptance<br/>passes, next feature\"]\n    end\n    subgraph inner[\"Inner Loop (Unit)\"]\n        u1[\"1. Write failing unit test\"]\n        u2[\"2. Make it pass\"]\n        u3[\"3. Refactor\"]\n        u4[\"4. Next unit...\"]\n    end\n\n    a1 --> u1\n    u1 --> u2 --> u3 --> u4\n    u4 -.-> u1\n    u4 --> a2\n    a2 -.-> a1\n\n    style outer fill:#e3f2fd,stroke:#1976d2\n    style inner fill:#fff8e1,stroke:#ffa000\n```\n\n**Key Principles**:\n- **Outside-in**: Start at edges (UI/API), work toward core\n- **Mock at boundaries**: Use mocks to discover collaborators\n- **Listen to tests**: Painful tests reveal design problems\n- **Walking skeleton**: First test is end-to-end (thin vertical slice)\n\n**Design Discovery**:\n```\n\"When we write a test, we're designing the API we want to use.\"\n\"Mocks tell us what collaborators we need.\"\n```\n\n**Use When**: Complex systems, need design guidance, object-oriented code.\n\n---\n\n### Meszaros' xUnit Test Patterns\n\n**Source**: Gerard Meszaros - \"xUnit Test Patterns\" (2007)\n\n**Core Idea**: Catalog of patterns for well-designed, maintainable tests.\n\n**Test Structure (Four-Phase)**:\n```\n1. SETUP    - Establish preconditions\n2. EXERCISE - Execute behavior under test\n3. VERIFY   - Check expected outcomes\n4. TEARDOWN - Clean up (often implicit)\n```\n\n**Key Patterns**:\n| Pattern | Problem | Solution |\n|---------|---------|----------|\n| Test Double | Need to isolate | Use Dummy, Stub, Spy, Mock, Fake |\n| Object Mother | Repetitive setup | Factory for test objects |\n| Test Data Builder | Complex object construction | Fluent builder for tests |\n| Parameterized Test | Similar tests, different data | Data-driven test |\n\n**Test Smells**:\n| Smell | Symptom | Cure |\n|-------|---------|------|\n| Fragile Test | Breaks on unrelated changes | Better isolation, less coupling |\n| Obscure Test | Hard to understand | Clear names, one assertion |\n| Slow Test | Takes too long | Mock external deps, parallelize |\n| Erratic Test | Sometimes passes/fails | Fix non-determinism |\n\n**Use When**: Test suite is growing complex, tests becoming maintenance burden.\n\n---\n\n### Feathers' Legacy Code Techniques\n\n**Source**: Michael Feathers - \"Working Effectively with Legacy Code\" (2004)\n\n**Core Idea**: \"Legacy code is code without tests.\" Strategies to add them.\n\n**Definition**: Legacy code = code without tests (regardless of age)\n\n**The Legacy Code Change Algorithm**:\n1. **Identify change points**\n2. **Find test points**\n3. **Break dependencies**\n4. **Write characterization tests** (capture current behavior)\n5. **Make changes and refactor**\n\n**Key Techniques**:\n| Technique | Purpose |\n|-----------|---------|\n| Characterization Test | Document what code actually does (not what it should do) |\n| Sprout Method | Add new code in testable method, call from legacy |\n| Sprout Class | New functionality in new testable class |\n| Wrap Method | Wrap existing method to add behavior |\n| Extract Interface | Break dependency on concrete class |\n\n**Seam Types** (places to inject test behavior):\n- **Object seams**: Override in subclass\n- **Compile seams**: Swap at build time\n- **Link seams**: Swap libraries\n\n**Use When**: Adding tests to existing codebase, modifying untested code.\n\n---\n\n### Bach & Bolton's Exploratory Testing\n\n**Source**: James Bach & Michael Bolton - Rapid Software Testing\n\n**Core Idea**: Skilled, intentional exploration guided by heuristics, not scripts.\n\n**Key Concepts**:\n- **Testing vs. Checking**: Testing = exploration, Checking = verification\n- **Heuristics**: Guidelines, not rules\n- **Session-based**: Timeboxed, focused exploration\n- **Charter**: Goal for exploration session\n\n**SFDPOT Heuristic** (what to test):\n| Letter | Category | Questions |\n|--------|----------|-----------|\n| S | Structure | What is it made of? |\n| F | Function | What does it do? |\n| D | Data | What data does it process? |\n| P | Platform | What does it depend on? |\n| O | Operations | How is it used? |\n| T | Time | How does it change over time? |\n\n**Use When**: Need human judgment, can't specify all cases, exploring new features.\n\n## Selection Matrix\n\n| Your Context | Primary Framework | Supporting |\n|--------------|------------------|------------|\n| New feature development | Beck TDD | Freeman GOOS |\n| Complex system design | Freeman GOOS | Beck |\n| Test suite maintenance | Meszaros | Feathers |\n| Legacy codebase | Feathers | Meszaros |\n| Manual testing guidance | Bach/Bolton | - |\n| Clear requirements | Beck | Meszaros |\n| Discovering requirements | Freeman GOOS | Bach/Bolton |\n\n## TDD Workflow Template\n\nBlended from Beck and Freeman:\n\n```markdown\n## Feature: [Name]\n\n### Acceptance Criteria (Outer Loop)\n- [ ] Given [context], when [action], then [outcome]\n\n### Implementation Plan\n\n#### Cycle 1\n**RED**:\n- Test: `test_[what]_[scenario]`\n- Assertion: [expected behavior]\n- Status: FAILING\n\n**GREEN**:\n- Minimal implementation: [approach]\n- Status: PASSING\n\n**REFACTOR**:\n- Improvement: [what cleaned up]\n- Tests still passing: YES\n\n#### Cycle 2\n[Continue...]\n```\n\n## Test Quality Checklist\n\nBased on Meszaros patterns:\n\n```markdown\n## Test Review Checklist\n\n### Structure\n- [ ] Clear arrange/act/assert phases\n- [ ] One logical assertion per test\n- [ ] Descriptive test name (what_when_then)\n\n### Independence\n- [ ] No test depends on another's side effects\n- [ ] Can run in any order\n- [ ] Clean setup/teardown\n\n### Readability\n- [ ] Test tells a story\n- [ ] No mystery guests (unexplained values)\n- [ ] Relevant data visible in test\n\n### Maintainability\n- [ ] No fragile assertions (over-specification)\n- [ ] Uses appropriate test doubles\n- [ ] DRY via helpers, not copy-paste\n```\n\n## Anti-Patterns to Avoid\n\n- **Test after**: Writing tests after code removes design benefits\n- **Testing implementation**: Coupling tests to internal structure\n- **Slow tests**: Not isolating from slow dependencies\n- **Test-per-method**: Testing methods instead of behaviors\n- **100% coverage worship**: Coverage doesn't equal quality\n- **Commented tests**: Delete or fix, never comment out\n\nFile v1.9.18:skill-card.md\n\n## Description:\n\nSurface expert frameworks.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and skill authors use this skill to select established expert frameworks before creating, reviewing, or evaluating skills, hooks, agents, and methodology-heavy work. It helps compare existing work against recognized approaches and identify gaps in terminology, process, or evaluation criteria.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad trigger terms may activate the skill in contexts where a methodology review is not needed.\n\nMitigation: Apply the skill only when the task benefits from an initial methodology brief or a gap analysis against established expert frameworks.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-abstract-methodology-curator)\n- [Metadata Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/abstract)\n- [Instruction Design Module](modules/instruction-design.md)\n- [Code Review Module](modules/code-review.md)\n- [Debugging Module](modules/debugging.md)\n- [Testing Module](modules/testing.md)\n- [Knowledge Management Module](modules/knowledge-management.md)\n- [Decision Making Module](modules/decision-making.md)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown, Analysis]\n\n**Output Format:** [Markdown guidance with framework summaries, selection matrices, and methodology brief templates]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Markdown-only reference content; no commands, tools, secrets, or software installation behavior.]\n\n## Skill Version(s):\n\n1.9.18 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.17: 9 files, 23665 bytes\n\nFiles: modules/code-review.md (6241b), modules/debugging.md (7053b), modules/decision-making.md (8095b), modules/instruction-design.md (6372b), modules/knowledge-management.md (7318b), modules/testing.md (7955b), skill-card.md (2008b), SKILL.md (5000b), _meta.json (151b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: methodology-curator\ndescription: Surface expert frameworks\nversion: 1.9.8\ntriggers:\n  - methodology\n  - frameworks\n  - expertise\n  - curation\n  - design\n  - evaluation\n  - creating or evaluating skills\n  - hooks\n  - or agents\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/abstract\", \"emoji\": \"\\ud83e\\udde0\"}}\nsource: claude-night-market\nsource_plugin: abstract\n---\n\n> **Night Market Skill** — ported from [claude-night-market/abstract](https://github.com/athola/claude-night-market/tree/master/plugins/abstract). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Overview](#overview)\n- [Workflow Integration](#workflow-integration)\n- [Domain Modules](#domain-modules)\n- [When to Skip](#when-to-skip)\n- [Masters Overview](#masters-overview)\n- [Selection Matrix](#selection-matrix)\n\n# Methodology Curator\n\n## Overview\n\nIdentifying 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.\n\n## Workflow Integration\n\nWhen 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.\n\nFor 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.\n\n## Domain Modules\n\nEach 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.\n\n- **Instruction Design**: `modules/instruction-design.md` - Teaching techniques and behavioral objectives.\n- **Code Review**: `modules/code-review.md` - Review methodologies and feedback patterns.\n- **Debugging**: `modules/debugging.md` - Systematic troubleshooting frameworks.\n- **Testing**: `modules/testing.md` - TDD masters and test design patterns.\n- **Knowledge Management**: `modules/knowledge-management.md` - Note-taking and knowledge systems.\n- **Decision Making**: `modules/decision-making.md` - Mental models and decision frameworks.\n\n## When to Skip\n\n### Skip for Creation when:\n- You're implementing a well-defined spec\n- The domain is highly specific to your codebase\n- You've already researched methodologies externally\n- Creating a simple utility with no pedagogical component\n\n### Skip for Evaluation when:\n- Fixing syntax/structural issues (use `/validate-plugin` instead)\n- The work is purely mechanical (no methodology to ground)\n- Already performed a recent methodology audit\n- Quick bug fixes that don't change the approach\n\n## Domain Modules\n\nEach module contains:\n- **Masters**: Recognized experts in the domain\n- **Key Works**: Essential books/papers/talks\n- **Frameworks**: Actionable methodologies\n- **Selection Guide**: When to use each approach\n- **Anti-patterns**: What to avoid\n\n### Adding New Domains\n\nTo expand the masters database, create a new module following this template:\n\n```markdown\n# [Domain Name] Masters\n\n## Masters Overview\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Name   | Framework/Book  | Context  |\n\n## Detailed Frameworks\n\n### [Framework 1]\n**Source**: [Expert] - [Work]\n**Core Idea**: [One sentence]\n**Key Principles**:\n- Principle 1\n- Principle 2\n**Use When**: [Context]\n**Avoid When**: [Anti-context]\n\n## Selection Matrix\n[Decision guide for choosing between frameworks]\n```\n\n## Integration with Skill Authoring\n\nAfter curating methodologies, the skill authoring workflow benefits from:\n\n1. **Grounded TDD scenarios**: Test against the methodology's expected behaviors\n2. **Principled anti-rationalization**: Counter excuses using the methodology's logic\n3. **Authoritative references**: Cite masters in skill documentation\n4. **Consistent terminology**: Use the methodology's vocabulary\n\n## Related\n\n### For Creation\n- `/create-skill` - Skill creation workflow (use after this)\n- `/create-hook` - Hook creation workflow\n- `superpowers:brainstorming` - Refine approach after methodology selection\n- `skill-authoring` - Detailed skill writing guidance\n\n### For Evaluation\n- `/skills-eval` - Evaluate skill quality (complements methodology audit)\n- `/analyze-skill` - Analyze skill complexity\n- `/bulletproof-skill` - Harden against rationalization\n- `pensive:code-reviewer` - Code review (uses code-review domain)\n\nFile v1.9.17:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-abstract-methodology-curator\",\n  \"version\": \"1.9.17\",\n  \"publishedAt\": 1785389267102\n}\n\nFile v1.9.17:modules/code-review.md\n\n# Code Review Masters\n\nExpert frameworks for conducting effective code reviews, providing constructive feedback, and improving code quality through review processes.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Google Engineering | Google's Code Review Guidelines | Scalable team practices |\n| Martin Fowler | Refactoring Catalog | Identifying improvement patterns |\n| Michael Feathers | Working with Legacy Code | Safe modification strategies |\n| Karl Wiegers | Peer Reviews in Software | Process optimization |\n| Trisha Gee | Code Review Best Practices | Practical JetBrains wisdom |\n\n## Detailed Frameworks\n\n### Google's Code Review Standards\n\n**Source**: Google Engineering Practices Documentation (public)\n\n**Core Idea**: Reviews should improve code health while enabling progress.\n\n**Key Principles**:\n- **Speed matters**: Review within 24 hours, ideally same day\n- **Small changes**: Prefer small, focused CLs (changelists)\n- **Approve if better**: Don't block for perfection\n- **Distinguish severity**: Nit vs. suggestion vs. blocker\n\n**The Standard**:\n> \"Reviewers should approve a CL once it definitely improves overall code health, even if it isn't perfect.\"\n\n**Comment Prefixes**:\n```\nNit:      Minor style preference, optional\nSuggest:  Improvement idea, author decides\nConsider: Worth thinking about, not blocking\nBLOCKING: Must fix before approval\n```\n\n**Use When**: Establishing team review standards, training reviewers.\n\n**Avoid When**: Security-critical code (needs stricter process).\n\n---\n\n### Fowler's Refactoring Patterns\n\n**Source**: Martin Fowler - \"Refactoring\" (1999, 2nd ed. 2018)\n\n**Core Idea**: Catalog of named transformations for improving code structure.\n\n**Review Application**: Use pattern names as shared vocabulary in reviews.\n\n**High-Value Patterns for Reviews**:\n| Smell | Refactoring | Review Comment |\n|-------|-------------|----------------|\n| Long function | Extract Method | \"This could be extracted into `calculateTotal()`\" |\n| Repeated code | Extract Method/Class | \"Duplicated in lines 45, 89—extract?\" |\n| Long parameter list | Introduce Parameter Object | \"Consider grouping these into a config object\" |\n| Feature Envy | Move Method | \"This method uses more of Order than Cart\" |\n| Primitive Obsession | Replace with Value Object | \"A Money type would prevent currency bugs\" |\n\n**Use When**: Providing actionable refactoring suggestions.\n\n---\n\n### Feathers' Legacy Code Strategies\n\n**Source**: Michael Feathers - \"Working Effectively with Legacy Code\" (2004)\n\n**Core Idea**: \"Legacy code is code without tests.\" Review for testability.\n\n**Key Review Questions**:\n1. **Seams**: Are there places to substitute behavior for testing?\n2. **Dependencies**: Can this be tested in isolation?\n3. **Characterization**: Would a test capture current behavior?\n\n**The Legacy Change Algorithm**:\n1. Identify change points\n2. Find test points\n3. Break dependencies\n4. Write tests\n5. Make changes\n\n**Review Comments for Legacy**:\n```\n\"Before modifying this, consider adding a characterization test\"\n\"This method has too many dependencies—can we inject the database?\"\n\"Consider introducing a seam here for testability\"\n```\n\n**Use When**: Reviewing changes to untested code.\n\n---\n\n### Wiegers' Peer Review Types\n\n**Source**: Karl Wiegers - \"Peer Reviews in Software\" (2002)\n\n**Core Idea**: Match review intensity to risk level.\n\n**Review Spectrum**:\n| Type | Effort | When to Use |\n|------|--------|-------------|\n| **Ad-hoc** | Lowest | Quick questions, pair checks |\n| **Passaround** | Low | Routine changes, docs |\n| **Walkthrough** | Medium | Knowledge sharing, onboarding |\n| **Team Review** | Medium-High | Design decisions, complex logic |\n| **Inspection** | Highest | Safety-critical, core algorithms |\n\n**Defect Detection Rates**:\n- Inspection: 60-90% of defects found\n- Walkthrough: 20-40%\n- Testing alone: 25-35%\n\n**Use When**: Deciding review depth for different code types.\n\n---\n\n### Gee's Practical Code Review\n\n**Source**: Trisha Gee - Various talks and articles (JetBrains)\n\n**Core Idea**: Reviews should be humane and focused on learning.\n\n**Key Principles**:\n- **Automate the boring stuff**: Linting, formatting, style → CI\n- **Focus human attention**: Logic, design, readability\n- **Be kind**: Criticize code, not people\n- **Ask questions**: \"What was the thinking here?\" vs \"This is wrong\"\n\n**Comment Formulas**:\n```\nInstead of: \"This is wrong\"\nTry:        \"I'm curious—what led to this approach?\"\n\nInstead of: \"Use X pattern\"\nTry:        \"Have you considered X? It might help with Y\"\n\nInstead of: \"This will break\"\nTry:        \"What happens if input is null here?\"\n```\n\n**Feedback Categories**:\n1. **Bugs**: Logic errors, edge cases\n2. **Design**: Coupling, cohesion, patterns\n3. **Readability**: Naming, structure, comments\n4. **Learning**: Knowledge sharing opportunities\n\n**Use When**: Writing constructive review feedback, training reviewers.\n\n## Selection Matrix\n\n| Your Context | Primary Framework | Supporting |\n|--------------|------------------|------------|\n| High-velocity team | Google Standards | Gee |\n| Improving existing code | Fowler | Feathers |\n| Safety-critical systems | Wiegers | Feathers |\n| Team culture improvement | Gee | Google |\n| Legacy codebase | Feathers | Fowler |\n\n## Review Checklist Template\n\nBased on blended frameworks:\n\n```markdown\n## Quick Checks (Automate These)\n- [ ] Passes linting\n- [ ] Passes tests\n- [ ] No merge conflicts\n\n## Human Review Focus\n### Correctness\n- [ ] Logic handles edge cases\n- [ ] Error handling appropriate\n\n### Design (Fowler)\n- [ ] No obvious code smells\n- [ ] Single responsibility followed\n- [ ] Dependencies reasonable\n\n### Testability (Feathers)\n- [ ] New code has tests\n- [ ] Changes don't break test isolation\n- [ ] Can test in isolation\n\n### Readability (Gee)\n- [ ] Names reveal intent\n- [ ] Comments explain \"why\" not \"what\"\n- [ ] Complexity appropriate\n```\n\n## Anti-Patterns to Avoid\n\n- **Nitpick storms**: Dozens of style comments (use linters)\n- **Rubber stamping**: Approving without reading\n- **Gatekeeping**: Using reviews to block or control\n- **Scope creep**: Requesting unrelated changes\n- **Delayed reviews**: Blocking progress for days\n\nFile v1.9.17:modules/debugging.md\n\n# Debugging Masters\n\nExpert frameworks for systematic troubleshooting, root cause analysis, and efficient bug resolution.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Andreas Zeller | Scientific Debugging | Systematic hypothesis testing |\n| David Agans | Nine Rules of Debugging | Universal debugging principles |\n| Diomidis Spinellis | Effective Debugging | Comprehensive toolkit |\n| Rob Miller | Debugging by Asking | Root cause questioning |\n| John Regehr | Compiler/Systems Debugging | Low-level issues |\n\n## Detailed Frameworks\n\n### Zeller's Scientific Debugging\n\n**Source**: Andreas Zeller - \"Why Programs Fail\" (2009)\n\n**Core Idea**: Apply scientific method to debugging—hypothesis, experiment, conclusion.\n\n**The Scientific Debugging Process**:\n```\n1. OBSERVE failure\n2. HYPOTHESIZE cause (be specific!)\n3. PREDICT behavior if hypothesis true\n4. EXPERIMENT to test prediction\n5. CONCLUDE: confirmed or refuted\n6. REPEAT with new hypothesis\n```\n\n**Key Principle**: Never change code to \"see if it fixes it.\" That's guessing, not debugging.\n\n**Hypothesis Quality**:\n```\nBAD:  \"Something's wrong with the database\"\nGOOD: \"The query times out because it scans all rows without index\"\n```\n\n**Delta Debugging** (Zeller's technique):\n- Minimize failing input\n- Find smallest change that triggers bug\n- Isolate exactly what causes failure\n\n**Use When**: Complex bugs, intermittent failures, need systematic approach.\n\n---\n\n### Agans' Nine Rules\n\n**Source**: David Agans - \"Debugging: The 9 Indispensable Rules\" (2002)\n\n**Core Idea**: Universal rules that apply to any debugging scenario.\n\n**The Nine Rules**:\n\n| # | Rule | Application |\n|---|------|-------------|\n| 1 | **Understand the System** | Read docs, trace data flow before assuming |\n| 2 | **Make It Fail** | Reproduce reliably before investigating |\n| 3 | **Quit Thinking and Look** | Actually read error messages, logs, state |\n| 4 | **Divide and Conquer** | Binary search to isolate |\n| 5 | **Change One Thing at a Time** | Controlled experiments only |\n| 6 | **Keep an Audit Trail** | Log what you tried and results |\n| 7 | **Check the Plug** | Verify assumptions, environment, obvious things |\n| 8 | **Get a Fresh View** | Rubber duck, ask colleague, sleep on it |\n| 9 | **If You Didn't Fix It, It Ain't Fixed** | Verify root cause, not just symptoms |\n\n**Most Violated Rules**:\n- #3: Jumping to hypotheses without reading the actual error\n- #5: Changing multiple things hoping something works\n- #9: Seeing issue disappear and assuming it's fixed\n\n**Use When**: Any debugging situation—these are universal.\n\n---\n\n### Spinellis' Debugging Strategies\n\n**Source**: Diomidis Spinellis - \"Effective Debugging\" (2016)\n\n**Core Idea**: Comprehensive toolkit organized by debugging phase.\n\n**Strategy Categories**:\n\n**High-Level Strategies**:\n| Strategy | When to Use |\n|----------|-------------|\n| Reproduce consistently | First step, always |\n| Simplify input | Large inputs, complex state |\n| Minimize code | Isolate to smallest failing example |\n| Add instrumentation | Need visibility into behavior |\n| Review recent changes | \"It was working yesterday\" |\n\n**Technical Strategies**:\n| Strategy | Application |\n|----------|-------------|\n| Printf debugging | Quick visibility, any environment |\n| Debugger stepping | Complex control flow |\n| Core dump analysis | Crashes, post-mortem |\n| Profiling | Performance issues |\n| Tracing | System call, network issues |\n\n**Process Strategies**:\n| Strategy | When to Use |\n|----------|-------------|\n| Pair debugging | Stuck for >30 minutes |\n| Take a break | Tunnel vision, frustration |\n| Explain to rubber duck | Can't articulate problem |\n| Search error message | May be known issue |\n\n**Use When**: Need specific technique for specific problem type.\n\n---\n\n### Miller's Debugging Questions\n\n**Source**: Rob Miller (MIT) - Debugging lectures\n\n**Core Idea**: Systematic questioning reveals root cause.\n\n**The Question Ladder**:\n\n1. **What did you expect to happen?**\n2. **What actually happened?**\n3. **What's the difference?**\n4. **When did it last work?**\n5. **What changed since then?**\n6. **Where exactly does behavior diverge from expectation?**\n\n**Localization Questions**:\n- At what point does the state become incorrect?\n- What is the last known good state?\n- What is the first known bad state?\n\n**Use When**: Starting any debugging session, structuring investigation.\n\n---\n\n### Regehr's Low-Level Debugging\n\n**Source**: John Regehr - Embedded Systems & Compiler Expert\n\n**Core Idea**: Systems-level bugs need systems-level thinking.\n\n**Principles**:\n- **Trust nothing**: Verify compiler output, hardware state\n- **Reduce**: Minimize to smallest reproducer\n- **Isolation**: Test components independently\n- **Invariants**: Assert what must be true\n\n**Common Systems Bug Categories**:\n| Category | Symptoms | Approach |\n|----------|----------|----------|\n| Memory corruption | Crashes, weird values | Valgrind, ASan |\n| Race conditions | Intermittent, timing-dependent | Thread sanitizer, logging |\n| Resource leaks | Slow degradation | Monitor, profiling |\n| Undefined behavior | \"Works on my machine\" | UBSan, static analysis |\n\n**Use When**: Low-level, systems, or intermittent bugs.\n\n## Selection Matrix\n\n| Bug Type | Primary Framework | Supporting |\n|----------|------------------|------------|\n| Any bug (start here) | Agans' 9 Rules | Miller Questions |\n| Complex/subtle bugs | Zeller Scientific | Agans #5, #6 |\n| \"It was working\" | Spinellis Review Changes | Agans #1 |\n| Intermittent failures | Zeller Delta Debug | Regehr |\n| Performance issues | Spinellis Profiling | Agans #4 |\n| Unknown territory | Agans #1, #7 | Miller Questions |\n\n## Debugging Workflow Template\n\nBlended from all frameworks:\n\n```markdown\n## Bug: [Brief description]\n\n### 1. Understand & Reproduce (Agans #1, #2)\n- System understanding: [What should happen]\n- Reproduction steps:\n  1. [Step]\n  2. [Step]\n- Reproduction rate: [Always/Sometimes/Rare]\n\n### 2. Observe (Agans #3, Miller)\n- Expected: [What should happen]\n- Actual: [What happens]\n- Difference: [Gap]\n- Last working: [When/version]\n\n### 3. Hypothesize (Zeller)\n| # | Hypothesis | Prediction | Test | Result |\n|---|------------|------------|------|--------|\n| 1 | | | | |\n| 2 | | | | |\n| 3 | | | | |\n\n### 4. Isolate (Agans #4, #5)\n- Binary search log:\n  - [✓] Works at commit abc123\n  - [✗] Fails at commit def456\n  - Narrowed to: [specific change]\n\n### 5. Fix & Verify (Agans #9)\n- Root cause: [Actual cause]\n- Fix: [What changed]\n- Verification: [How confirmed]\n- Regression test added: [Yes/No]\n```\n\n## Anti-Patterns to Avoid\n\n- **Shotgun debugging**: Changing random things hoping to fix it\n- **Assumption debugging**: Not verifying basic assumptions (Agans #7)\n- **Tunnel vision**: Fixating on one hypothesis without testing others\n- **History blindness**: Not checking what recently changed\n- **Solo heroics**: Not asking for help when stuck (Agans #8)\n- **Premature celebration**: Assuming it's fixed without proof (Agans #9)\n\nFile v1.9.17:modules/decision-making.md\n\n# Decision Making Masters\n\nExpert frameworks for making better decisions, avoiding cognitive biases, and developing reliable judgment.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Charlie Munger | Mental Models, Inversion | Investment/business decisions |\n| Daniel Kahneman | System 1/2, Biases | Understanding cognitive limitations |\n| Gary Klein | Recognition-Primed Decision | Expert intuition, time pressure |\n| Annie Duke | Thinking in Bets | Decisions under uncertainty |\n| Ray Dalio | Principles, Radical Transparency | Organizational decisions |\n\n## Detailed Frameworks\n\n### Munger's Mental Models\n\n**Source**: Charlie Munger - \"Poor Charlie's Almanack\", Berkshire letters\n\n**Core Idea**: Build a latticework of mental models from multiple disciplines; use them in combination.\n\n**Key Mental Models**:\n\n| Model | Discipline | Application |\n|-------|------------|-------------|\n| **Inversion** | Mathematics | \"What would make this fail?\" |\n| **Second-Order Effects** | Physics | \"What happens next? Then what?\" |\n| **Circle of Competence** | Self-knowledge | \"What do I actually understand?\" |\n| **Margin of Safety** | Engineering | \"What's the buffer for error?\" |\n| **Opportunity Cost** | Economics | \"What am I giving up?\" |\n| **Incentives** | Psychology | \"What are people rewarded for?\" |\n\n**Inversion Technique**:\n```\nInstead of: \"How do I succeed?\"\nAsk:        \"How would I guarantee failure?\"\nThen:       Avoid those things\n\nInstead of: \"How do I make a great skill?\"\nAsk:        \"What makes skills terrible?\"\nThen:       Eliminate those patterns\n```\n\n**Use When**: Complex decisions, need diverse perspectives, avoiding blind spots.\n\n---\n\n### Kahneman's System 1/System 2\n\n**Source**: Daniel Kahneman - \"Thinking, Fast and Slow\" (2011)\n\n**Core Idea**: Two thinking systems with different strengths and failure modes.\n\n**The Two Systems**:\n| System 1 (Fast) | System 2 (Slow) |\n|-----------------|-----------------|\n| Automatic | Effortful |\n| Intuitive | Analytical |\n| Parallel | Serial |\n| Emotional | Logical |\n| Error-prone | Accurate but lazy |\n\n**Key Biases to Counter**:\n| Bias | Description | Countermeasure |\n|------|-------------|----------------|\n| **Anchoring** | First number influences | Generate own estimate first |\n| **Availability** | Recent = likely | Ask \"What am I not seeing?\" |\n| **Confirmation** | Seek supporting evidence | Actively seek disconfirming |\n| **Overconfidence** | Certainty exceeds accuracy | Estimate confidence intervals |\n| **Hindsight** | \"I knew it all along\" | Record predictions beforehand |\n| **Sunk cost** | Continue because invested | \"Would I start this now?\" |\n\n**Pre-Mortem Technique**:\n```\nImagine the project has failed spectacularly.\nWrite the story of why it failed.\nNow prevent those things.\n```\n\n**Use When**: Need to check intuitions, high-stakes decisions, avoiding biases.\n\n---\n\n### Klein's Recognition-Primed Decision (RPD)\n\n**Source**: Gary Klein - \"Sources of Power\" (1998)\n\n**Core Idea**: Experts don't compare options; they recognize patterns and simulate actions.\n\n**How Experts Decide**:\n```\n1. Recognize situation type (pattern match)\n2. Identify typical action for situation\n3. Mental simulation: \"If I do this, what happens?\"\n4. If simulation works → act\n5. If problems → modify or consider next option\n```\n\n**Key Insight**: Experts rarely compare options analytically. They satisfice, not optimize.\n\n**When to Trust Intuition**:\n| Trust intuition when: | Don't trust when: |\n|----------------------|-------------------|\n| High experience in domain | Novel domain |\n| Regular, rapid feedback | Delayed/noisy feedback |\n| Stable, predictable environment | Chaotic, random environment |\n\n**Use When**: Time pressure, experienced domain, need fast action.\n\n---\n\n### Duke's Thinking in Bets\n\n**Source**: Annie Duke - \"Thinking in Bets\" (2018)\n\n**Core Idea**: Decisions are bets about the future; separate decision quality from outcome quality.\n\n**Key Principles**:\n- **Resulting**: Judging decision by outcome is wrong\n- **Uncertainty**: All decisions are probabilistic\n- **Expected value**: Probability × payoff\n\n**Decision Quality vs. Outcome Quality**:\n```\n                    OUTCOME\n                Good        Bad\n         Good   Deserved    Bad luck\nDECISION        win         (learn nothing)\n         Bad    Good luck   Deserved\n                (dangerous) loss\n```\n\n**The 10-10-10 Rule**:\n```\nHow will I feel about this decision:\n- 10 minutes from now?\n- 10 months from now?\n- 10 years from now?\n```\n\n**Decision Groups**:\n- Find truth-seeking group\n- Agree to criticize ideas, not people\n- Reward process, not outcome\n- Update beliefs openly\n\n**Use When**: Uncertain outcomes, need to separate luck from skill.\n\n---\n\n### Dalio's Principles\n\n**Source**: Ray Dalio - \"Principles\" (2017)\n\n**Core Idea**: Make decisions through explicit principles; radical transparency.\n\n**The Idea Meritocracy**:\n```\nBest ideas win, regardless of source\nBelievability-weighted voting\nRadical transparency in reasoning\n```\n\n**Decision-Making Process**:\n1. **Perceive** problems accurately\n2. **Diagnose** root causes\n3. **Design** solutions (principles)\n4. **Do** (execute)\n5. **Document** as principle for future\n\n**Believability Weighting**:\n```\nNot all opinions equal. Weight by:\n- Track record in relevant area\n- Demonstrated reasoning ability\n- Appropriate confidence level\n```\n\n**Radical Transparency Questions**:\n- What don't I know?\n- Who can help me see blind spots?\n- What would change my mind?\n\n**Use When**: Team decisions, building organizational processes, documenting decisions.\n\n## Selection Matrix\n\n| Decision Context | Primary Framework | Supporting |\n|------------------|------------------|------------|\n| Strategic/business | Munger | Dalio |\n| Individual bias check | Kahneman | Duke |\n| Time pressure | Klein RPD | Munger (prepared models) |\n| Uncertain outcomes | Duke | Kahneman |\n| Team decisions | Dalio | Duke |\n| Building expertise | Klein | Kahneman |\n\n## Decision Framework Template\n\nBlended approach for important decisions:\n\n```markdown\n## Decision: [Brief statement]\n\n### 1. Frame (Munger + Kahneman)\n- What's the actual decision?\n- Inversion: How would I guarantee failure?\n- What am I not seeing? (availability bias check)\n\n### 2. Generate Options\n- Option A: [description]\n- Option B: [description]\n- Option C: Do nothing / wait\n\n### 3. Evaluate (Duke + Klein)\n| Option | Probability of Success | Upside | Downside | Expected Value |\n|--------|----------------------|--------|----------|----------------|\n| A | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |\n| B | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |\n| C | [0-100%] | [Best case outcome] | [Worst case outcome] | [Prob x Upside - (1-Prob) x Downside] |\n\n### 4. Pre-Mortem (Kahneman)\nIf this fails, it will be because:\n1. [Risk 1]\n2. [Risk 2]\nMitigations: [How to prevent]\n\n### 5. Decide & Document (Dalio)\n**Decision**: [Choice]\n**Reasoning**: [Why this option]\n**Confidence**: [High/Medium/Low]\n**Review date**: [When to evaluate]\n\n### 6. Post-Decision (Duke)\n**Outcome**: [What happened]\n**Was decision quality good?**: [Separate from outcome]\n**What to learn**: [Principle for future]\n```\n\n## For Scope-Guard / Imbue Plugin\n\nSpecific applications:\n\n| Decision Need | Methodology Application |\n|--------------|------------------------|\n| Worthiness scoring | Expected value (Duke) |\n| Anti-overengineering | Inversion (Munger) |\n| Scope decisions | Pre-mortem (Kahneman) |\n| Feature prioritization | Opportunity cost (Munger) |\n| Review evidence logging | Principles documentation (Dalio) |\n\n## Anti-Patterns to Avoid\n\n- **Analysis paralysis**: Perfect information doesn't exist\n- **Resulting**: Judging decisions by outcomes alone\n- **Consensus seeking**: Agreement ≠ correctness\n- **Confidence = competence**: Loudest isn't rightest\n- **Single model thinking**: One mental model isn't enough\n- **Ignoring base rates**: Your situation probably isn't special\n\nFile v1.9.17:modules/instruction-design.md\n\n# Instruction Design Masters\n\nExpert frameworks for teaching techniques, writing effective instructions, and creating behavioral change through documentation.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Robert Mager | Behavioral Objectives | Measurable skill outcomes |\n| Benjamin Bloom | Taxonomy of Learning | Cognitive level targeting |\n| Robert Gagné | Nine Events of Instruction | Structured lesson design |\n| John Sweller | Cognitive Load Theory | Reducing mental overhead |\n| Ruth Clark | Evidence-Based Training | Practical instructional design |\n\n## Detailed Frameworks\n\n### Mager's Behavioral Objectives\n\n**Source**: Robert Mager - \"Preparing Instructional Objectives\" (1962)\n\n**Core Idea**: Objectives must specify observable behavior, conditions, and criteria.\n\n**Key Principles**:\n- **Performance**: What the learner will DO (observable verb)\n- **Conditions**: Under what circumstances (tools, constraints)\n- **Criterion**: How well (accuracy, speed, quality threshold)\n\n**Formula**: \"Given [conditions], the learner will [performance] to [criterion].\"\n\n**Example for Skills**:\n```\nBAD:  \"Understand TDD methodology\"\nGOOD: \"Given a failing test, implement minimal code to pass within 3 iterations\"\n```\n\n**Use When**: Creating technique skills, defining success criteria, writing \"Use when\" clauses.\n\n**Avoid When**: Teaching abstract concepts, pattern recognition, creative tasks.\n\n---\n\n### Bloom's Taxonomy (Revised)\n\n**Source**: Benjamin Bloom et al., revised by Anderson & Krathwohl (2001)\n\n**Core Idea**: Learning has hierarchical levels; target the right cognitive level.\n\n**Levels (lowest to highest)**:\n1. **Remember**: Recall facts → Reference skills, checklists\n2. **Understand**: Explain concepts → Pattern skills, mental models\n3. **Apply**: Use in new situations → Technique skills, workflows\n4. **Analyze**: Break down, find patterns → Debugging skills, code review\n5. **Evaluate**: Judge, critique → Assessment frameworks, quality gates\n6. **Create**: Produce new work → Design skills, architecture guidance\n\n**Use When**: Determining skill type, structuring progressive disclosure, setting appropriate depth.\n\n**Skill Mapping**:\n| Skill Type | Target Level | Verbs to Use |\n|-----------|--------------|--------------|\n| Reference | Remember | List, recall, identify |\n| Pattern | Understand | Explain, compare, summarize |\n| Technique | Apply/Analyze | Implement, execute, debug |\n\n---\n\n### Gagné's Nine Events of Instruction\n\n**Source**: Robert Gagné - \"The Conditions of Learning\" (1965)\n\n**Core Idea**: Effective instruction follows nine sequential events.\n\n**The Nine Events**:\n1. **Gain attention**: Hook with problem or scenario\n2. **Inform objectives**: State what they'll learn (Use when clause)\n3. **Stimulate recall**: Connect to prior knowledge\n4. **Present content**: The actual instruction\n5. **Provide guidance**: Examples, worked problems\n6. **Elicit performance**: Practice opportunity\n7. **Provide feedback**: Correct/reinforce\n8. **Assess performance**: Verify learning\n9. **Enhance retention**: Transfer to real contexts\n\n**Skill Structure Mapping**:\n```\nSKILL.md Structure           Gagné Event\n─────────────────────────────────────────\nOverview/Problem statement → 1. Gain attention\n\"Use when\" clause          → 2. Inform objectives\nRelated skills/prereqs     → 3. Stimulate recall\nCore content               → 4. Present content\nExamples                   → 5. Provide guidance\nWorkflows/checklists       → 6. Elicit performance\nAnti-patterns/red flags    → 7. Provide feedback\nValidation commands        → 8. Assess performance\nReal-world scenarios       → 9. Enhance retention\n```\n\n**Use When**: Designing complete skill structure, ensuring nothing essential is missing.\n\n---\n\n### Cognitive Load Theory\n\n**Source**: John Sweller - \"Cognitive Load Theory\" (1988)\n\n**Core Idea**: Working memory is limited; reduce unnecessary load.\n\n**Three Types of Load**:\n- **Intrinsic**: Complexity inherent to the material (can't reduce)\n- **Extraneous**: Poor presentation adding confusion (ELIMINATE)\n- **Germane**: Effort building mental models (MAXIMIZE)\n\n**Techniques for Skills**:\n| Principle | Application |\n|-----------|-------------|\n| Chunking | Progressive disclosure, modular files |\n| Worked examples | Complete code samples, not pseudocode |\n| Split attention | Keep related info together (no \"see also\" mid-flow) |\n| Redundancy | Don't repeat same info in text AND diagram |\n| Expertise reversal | Advanced users need less scaffolding |\n\n**Use When**: Optimizing token efficiency, structuring modules, deciding what to cut.\n\n---\n\n### Clark's Evidence-Based Training\n\n**Source**: Ruth Clark - \"Evidence-Based Training Methods\" (2019)\n\n**Core Idea**: Use research-proven methods, not intuition.\n\n**Key Findings**:\n- **Examples beat descriptions**: Show, don't tell\n- **Practice with feedback**: Interactive > passive reading\n- **Spaced learning**: Break into digestible chunks\n- **Relevant context**: Real scenarios > abstract theory\n\n**Anti-patterns** (feel effective but aren't):\n- Long prose explanations\n- Comprehensive coverage without practice\n- Learning styles myths (visual/auditory)\n- Information dumps\n\n**Use When**: Reviewing skills for effectiveness, cutting unnecessary content.\n\n## Selection Matrix\n\n| Your Goal | Primary Framework | Supporting |\n|-----------|------------------|------------|\n| Define clear outcomes | Mager | Bloom |\n| Structure complete skill | Gagné | Cognitive Load |\n| Reduce skill complexity | Cognitive Load | Clark |\n| Choose skill type | Bloom | Mager |\n| Validate effectiveness | Clark | Gagné |\n\n## Blending Example\n\nCreating a debugging skill:\n1. **Bloom**: Target \"Analyze\" level (break down, identify patterns)\n2. **Mager**: \"Given error output, identify root cause within 3 hypotheses\"\n3. **Cognitive Load**: Use worked examples, progressive modules\n4. **Gagné**: Structure with attention hook → examples → practice workflow\n\n## Anti-Patterns to Avoid\n\n- **Covering everything**: Cognitive overload, low retention\n- **Vague objectives**: \"Understand debugging\" (not measurable)\n- **Missing practice**: All theory, no application\n- **Wrong level**: Teaching \"remember\" when \"apply\" is needed\n\nFile v1.9.17:modules/knowledge-management.md\n\n# Knowledge Management Masters\n\nExpert frameworks for capturing, organizing, connecting, and retrieving knowledge effectively.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Niklas Luhmann | Zettelkasten (Slip-box) | Connected notes, emergent thinking |\n| Sönke Ahrens | Smart Notes Method | Writing-focused knowledge work |\n| Vannevar Bush | Memex Concept | Associative trails, hypertext thinking |\n| David Allen | GTD (Getting Things Done) | Action-oriented knowledge capture |\n| Tiago Forte | PARA and Building a Second Brain | Digital organization, progressive summarization |\n\n## Detailed Frameworks\n\n### Luhmann's Zettelkasten\n\n**Source**: Niklas Luhmann - Sociologist, 70+ books, 90,000+ notes\n\n**Core Idea**: Atomic notes with explicit links create a \"conversation partner\" that surfaces unexpected connections.\n\n**Key Principles**:\n- **Atomicity**: One idea per note\n- **Linking**: Notes connect to other notes, not just categories\n- **Own words**: Rewrite in your understanding, never copy\n- **Unique identifiers**: Every note has permanent address\n- **Emergence**: Structure emerges from links, not imposed hierarchy\n\n**Note Types**:\n| Type | Purpose | Example |\n|------|---------|---------|\n| Fleeting | Quick capture | \"Idea: cognitive load applies to skills\" |\n| Literature | Reference to source | \"Sweller 1988 argues...\" |\n| Permanent | Processed, atomic insight | \"Cognitive load limits skill file size\" |\n| Structure | Index/hub notes | \"MOC: Skill Design Principles\" |\n\n**The Process**:\n```\n1. Capture fleeting notes throughout day\n2. Process into permanent notes (rewrite, atomize)\n3. Link to existing notes (where does this connect?)\n4. Add to structure notes (entry points)\n5. Review and discover connections\n```\n\n**Use When**: Building long-term knowledge base, research, writing projects.\n\n---\n\n### Ahrens' Smart Notes\n\n**Source**: Sönke Ahrens - \"How to Take Smart Notes\" (2017)\n\n**Core Idea**: Writing is thinking; note-taking should support writing output.\n\n**Key Principles**:\n- **Writing as thinking**: You don't write up ideas, you think through writing\n- **Bottom-up structure**: Let topics emerge from notes\n- **Slip-box as partner**: External thinking system\n- **Focus on output**: Notes serve future writing\n\n**The Workflow**:\n```\nReading → Fleeting Notes → Literature Notes → Permanent Notes → Writing\n```\n\n**Quality Criteria for Permanent Notes**:\n- Could someone else understand it without context?\n- Is it written in complete sentences?\n- Does it stand on its own?\n- Does it connect to existing notes?\n\n**Writing Process**:\n1. Collect relevant permanent notes\n2. Arrange in sequence\n3. Turn sequence into draft\n4. Edit and refine\n\n**Use When**: Academic writing, knowledge synthesis, developing arguments.\n\n---\n\n### Bush's Memex & Associative Trails\n\n**Source**: Vannevar Bush - \"As We May Think\" (1945)\n\n**Core Idea**: Human mind works by association; tools should support trails of thought.\n\n**Key Concepts**:\n- **Associative indexing**: Link by meaning, not alphabet\n- **Trails**: Paths through information, shareable\n- **Personal library**: All knowledge accessible, connected\n- **Selection vs. creation**: Value in curating paths\n\n**Modern Applications**:\n| Memex Concept | Modern Implementation |\n|---------------|----------------------|\n| Associative links | Hyperlinks, backlinks |\n| Trails | Curated reading paths, playlists |\n| Personal library | Personal wikis, note apps |\n| Selection devices | Search, tags, filters |\n\n**Use When**: Designing knowledge systems, understanding hypertext principles.\n\n---\n\n### Allen's GTD (Getting Things Done)\n\n**Source**: David Allen - \"Getting Things Done\" (2001)\n\n**Core Idea**: Capture everything; mind is for having ideas, not holding them.\n\n**The Five Steps**:\n```\n1. CAPTURE    - Get everything out of your head\n2. CLARIFY    - What is it? Is it actionable?\n3. ORGANIZE   - Put it where it belongs\n4. REFLECT    - Review regularly\n5. ENGAGE     - Do with confidence\n```\n\n**The Two-Minute Rule**: If it takes less than 2 minutes, do it now.\n\n**Clarify Decision Tree**:\n```\nIs it actionable?\n├── NO → Reference, Someday/Maybe, or Trash\n└── YES → What's the next action?\n    ├── Multi-step? → It's a Project\n    └── Single step?\n        ├── <2 min? → Do it now\n        ├── Delegate? → Waiting For\n        └── Defer? → Next Actions (by context)\n```\n\n**Use When**: Action-oriented knowledge, task management, reducing cognitive load.\n\n---\n\n### Forte's PARA & Second Brain\n\n**Source**: Tiago Forte - \"Building a Second Brain\" (2022)\n\n**Core Idea**: Organize by actionability, not topic. Progressive summarization for retrieval.\n\n**PARA System**:\n| Folder | Contains | Timeframe |\n|--------|----------|-----------|\n| **P**rojects | Active outcomes | Weeks |\n| **A**reas | Ongoing responsibilities | Indefinite |\n| **R**esources | Useful references | As needed |\n| **A**rchive | Inactive items | Done |\n\n**Progressive Summarization**:\n```\nLayer 0: Original source\nLayer 1: Bolded passages (10-20%)\nLayer 2: Highlighted from bold (10-20% of bold)\nLayer 3: Executive summary (your words)\nLayer 4: Remix (original synthesis)\n```\n\n**CODE Method**:\n- **C**apture: Save resonant information\n- **O**rganize: Put in PARA folder\n- **D**istill: Progressive summarization\n- **E**xpress: Create output\n\n**Use When**: Digital knowledge management, balancing capture and retrieval.\n\n## Selection Matrix\n\n| Your Goal | Primary Framework | Supporting |\n|-----------|------------------|------------|\n| Long-term knowledge building | Zettelkasten | Ahrens |\n| Writing/research output | Ahrens | Zettelkasten |\n| Task/action management | GTD | PARA |\n| Digital organization | PARA | GTD |\n| System design | Bush Memex | Zettelkasten |\n| Reducing overwhelm | GTD | PARA |\n\n## Knowledge System Template\n\nBlended approach for a knowledge base:\n\n```markdown\n## Knowledge System Design\n\n### Capture Layer (GTD + PARA)\n- Inbox: Quick capture without friction\n- Two-minute rule for processing\n- Daily processing to zero\n\n### Organization (PARA + Zettelkasten)\n- Projects: Active work with deadlines\n- Areas: Ongoing responsibilities\n- Notes: Atomic, linked permanent notes\n- Archive: Completed/inactive\n\n### Connection (Zettelkasten)\n- Every note links to 2+ existing notes\n- Structure notes (MOCs) for entry points\n- Tags for cross-cutting themes\n- Regular gardening/review\n\n### Output (Ahrens + Progressive Summary)\n- Progressive summarization of sources\n- Assemble notes for projects\n- Write from accumulated notes\n```\n\n## For Memory-Palace Plugin\n\nSpecific applications:\n\n| Memory-Palace Feature | Methodology Source |\n|----------------------|-------------------|\n| Knowledge nodes | Zettelkasten atomicity |\n| Backlinks | Luhmann's linking |\n| Daily notes | GTD capture |\n| MOC/Index notes | Zettelkasten structure notes |\n| Project organization | PARA |\n| Search/retrieval | Progressive summarization |\n\n## Anti-Patterns to Avoid\n\n- **Collector's fallacy**: Saving without processing\n- **Tagging obsession**: Tags without links\n- **Hierarchy prison**: Rigid folders killing discovery\n- **Perfect system seeking**: Setup > usage\n- **Copy-paste notes**: No rewriting = no understanding\n- **Orphan notes**: Notes without connections die\n\nFile v1.9.17:modules/testing.md\n\n# Testing & TDD Masters\n\nExpert frameworks for test-driven development, test design, and building confidence in code through systematic verification.\n\n## \n\nArchive v1.9.16: 9 files, 23820 bytes\n\nFiles: modules/code-review.md (6241b), modules/debugging.md (7053b), modules/decision-making.md (8095b), modules/instruction-design.md (6372b), modules/knowledge-management.md (7318b), modules/testing.md (7955b), skill-card.md (2338b), SKILL.md (5000b), _meta.json (151b)\n\nArchive v1.9.15: 9 files, 23661 bytes\n\nFiles: modules/code-review.md (6241b), modules/debugging.md (7053b), modules/decision-making.md (8095b), modules/instruction-design.md (6372b), modules/knowledge-management.md (7318b), modules/testing.md (7955b), skill-card.md (1892b), SKILL.md (5000b), _meta.json (151b)\n\nArchive v1.9.14: 9 files, 23894 bytes\n\nFiles: modules/code-review.md (6241b), modules/debugging.md (7053b), modules/decision-making.md (8095b), modules/instruction-design.md (6372b), modules/knowledge-management.md (7318b), modules/testing.md (7955b), skill-card.md (2623b), SKILL.md (5000b), _meta.json (151b)\n\nArchive v1.9.13: 9 files, 23836 bytes\n\nFiles: modules/code-review.md (6241b), modules/debugging.md (7053b), modules/decision-making.md (8095b), modules/instruction-design.md (6372b), modules/knowledge-management.md (7318b), modules/testing.md (7955b), skill-card.md (2593b), SKILL.md (5000b), _meta.json (151b)\n\nArchive v1.9.12: 9 files, 23674 bytes\n\nFiles: modules/code-review.md (6241b), modules/debugging.md (7053b), modules/decision-making.md (8095b), modules/instruction-design.md (6372b), modules/knowledge-management.md (7318b), modules/testing.md (7955b), skill-card.md (1992b), SKILL.md (5000b), _meta.json (151b)\n\nArchive v1.8.6: 9 files, 23704 bytes\n\nFiles: modules/code-review.md (6241b), modules/debugging.md (7053b), modules/decision-making.md (8095b), modules/instruction-design.md (6372b), modules/knowledge-management.md (7318b), modules/testing.md (7955b), skill-card.md (2221b), SKILL.md (5000b), _meta.json (150b)\n\nArchive v1.8.5: 9 files, 23720 bytes\n\nFiles: modules/code-review.md (6241b), modules/debugging.md (7053b), modules/decision-making.md (8095b), modules/instruction-design.md (6372b), modules/knowledge-management.md (7316b), modules/testing.md (7953b), skill-card.md (2103b), SKILL.md (5018b), _meta.json (150b)","readmeExcerpt":"Skill: methodology-curator Owner: athola Summary: Surface expert frameworks Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:03:31.291Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:27:54.111Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:27:47.102Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:44:41.928Z | user Release v1.9.16 v1.9.15 | 2026-07-04T21:19:18.229Z | user Release v1.9.15 v1.9.14 | 2026-06","codeSnippets":[],"executableExamples":[{"language":"markdown","snippet":"# [Domain Name] Masters\n\n## Masters Overview\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Name   | Framework/Book  | Context  |\n\n## Detailed Frameworks\n\n### [Framework 1]\n**Source**: [Expert] - [Work]\n**Core Idea**: [One sentence]\n**Key Principles**:\n- Principle 1\n- Principle 2\n**Use When**: [Context]\n**Avoid When**: [Anti-context]\n\n## Selection Matrix\n[Decision guide for choosing between frameworks]"},{"language":"text","snippet":"Nit:      Minor style preference, optional\nSuggest:  Improvement idea, author decides\nConsider: Worth thinking about, not blocking\nBLOCKING: Must fix before approval"},{"language":"text","snippet":"\"Before modifying this, consider adding a characterization test\"\n\"This method has too many dependencies—can we inject the database?\"\n\"Consider introducing a seam here for testability\""},{"language":"text","snippet":"Instead of: \"This is wrong\"\nTry:        \"I'm curious—what led to this approach?\"\n\nInstead of: \"Use X pattern\"\nTry:        \"Have you considered X? It might help with Y\"\n\nInstead of: \"This will break\"\nTry:        \"What happens if input is null here?\""},{"language":"markdown","snippet":"## Quick Checks (Automate These)\n- [ ] Passes linting\n- [ ] Passes tests\n- [ ] No merge conflicts\n\n## Human Review Focus\n### Correctness\n- [ ] Logic handles edge cases\n- [ ] Error handling appropriate\n\n### Design (Fowler)\n- [ ] No obvious code smells\n- [ ] Single responsibility followed\n- [ ] Dependencies reasonable\n\n### Testability (Feathers)\n- [ ] New code has tests\n- [ ] Changes don't break test isolation\n- [ ] Can test in isolation\n\n### Readability (Gee)\n- [ ] Names reveal intent\n- [ ] Comments explain \"why\" not \"what\"\n- [ ] Complexity appropriate"},{"language":"text","snippet":"1. OBSERVE failure\n2. HYPOTHESIZE cause (be specific!)\n3. PREDICT behavior if hypothesis true\n4. EXPERIMENT to test prediction\n5. CONCLUDE: confirmed or refuted\n6. REPEAT with new hypothesis"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: methodology-curator\ndescription: Surface expert frameworks\nversion: 1.9.8\ntriggers:\n  - methodology\n  - frameworks\n  - expertise\n  - curation\n  - design\n  - evaluation\n  - creating or evaluating skills\n  - hooks\n  - or agents\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/abstract\", \"emoji\": \"\\ud83e\\udde0\"}}\nsource: claude-night-market\nsource_plugin: abstract\n---\n\n> **Night Market Skill** — ported from [claude-night-market/abstract](https://github.com/athola/claude-night-market/tree/master/plugins/abstract). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Overview](#overview)\n- [Workflow Integration](#workflow-integration)\n- [Domain Modules](#domain-modules)\n- [When to Skip](#when-to-skip)\n- [Masters Overview](#masters-overview)\n- [Selection Matrix](#selection-matrix)\n\n# Methodology Curator\n\n## Overview\n\nIdentifying 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.\n\n## Workflow Integration\n\nWhen 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.\n\nFor 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.\n\n## Domain Modules\n\nEach 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.\n\n- **Instruction Design**: `modules/instruction-design.md` - Teaching techniques and behavioral objectives.\n- **Code Review**: `modules/code-review.md` - Review methodologies and feedback patterns.\n- **Debugging**: `modules/debugging.md` - Systematic troubleshooting frameworks.\n- **Testing**: `modules/testing.md` - TDD masters and test design patterns.\n- **Knowledge Management**: `modules/knowledge-management.md` - Note-taking and knowledge systems.\n- **Decision Making**: `modules/decision-making.md` - Mental models and decision frameworks.\n\n## When to Skip\n\n### Skip for Creation when:\n- You're implementing a well-defined spec\n- The domain is highly specific to your codebase\n- You've already researched methodologies externally\n- Creating a simple utility with no pedagogical component\n\n### Skip for Eva"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-abstract-methodology-curator\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749411291\n}"},{"path":"modules/code-review.md","content":"# Code Review Masters\n\nExpert frameworks for conducting effective code reviews, providing constructive feedback, and improving code quality through review processes.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Google Engineering | Google's Code Review Guidelines | Scalable team practices |\n| Martin Fowler | Refactoring Catalog | Identifying improvement patterns |\n| Michael Feathers | Working with Legacy Code | Safe modification strategies |\n| Karl Wiegers | Peer Reviews in Software | Process optimization |\n| Trisha Gee | Code Review Best Practices | Practical JetBrains wisdom |\n\n## Detailed Frameworks\n\n### Google's Code Review Standards\n\n**Source**: Google Engineering Practices Documentation (public)\n\n**Core Idea**: Reviews should improve code health while enabling progress.\n\n**Key Principles**:\n- **Speed matters**: Review within 24 hours, ideally same day\n- **Small changes**: Prefer small, focused CLs (changelists)\n- **Approve if better**: Don't block for perfection\n- **Distinguish severity**: Nit vs. suggestion vs. blocker\n\n**The Standard**:\n> \"Reviewers should approve a CL once it definitely improves overall code health, even if it isn't perfect.\"\n\n**Comment Prefixes**:\n```\nNit:      Minor style preference, optional\nSuggest:  Improvement idea, author decides\nConsider: Worth thinking about, not blocking\nBLOCKING: Must fix before approval\n```\n\n**Use When**: Establishing team review standards, training reviewers.\n\n**Avoid When**: Security-critical code (needs stricter process).\n\n---\n\n### Fowler's Refactoring Patterns\n\n**Source**: Martin Fowler - \"Refactoring\" (1999, 2nd ed. 2018)\n\n**Core Idea**: Catalog of named transformations for improving code structure.\n\n**Review Application**: Use pattern names as shared vocabulary in reviews.\n\n**High-Value Patterns for Reviews**:\n| Smell | Refactoring | Review Comment |\n|-------|-------------|----------------|\n| Long function | Extract Method | \"This could be extracted into `calculateTotal()`\" |\n| Repeated code | Extract Method/Class | \"Duplicated in lines 45, 89—extract?\" |\n| Long parameter list | Introduce Parameter Object | \"Consider grouping these into a config object\" |\n| Feature Envy | Move Method | \"This method uses more of Order than Cart\" |\n| Primitive Obsession | Replace with Value Object | \"A Money type would prevent currency bugs\" |\n\n**Use When**: Providing actionable refactoring suggestions.\n\n---\n\n### Feathers' Legacy Code Strategies\n\n**Source**: Michael Feathers - \"Working Effectively with Legacy Code\" (2004)\n\n**Core Idea**: \"Legacy code is code without tests.\" Review for testability.\n\n**Key Review Questions**:\n1. **Seams**: Are there places to substitute behavior for testing?\n2. **Dependencies**: Can this be tested in isolation?\n3. **Characterization**: Would a test capture current behavior?\n\n**The Legacy Change Algorithm**:\n1. Identify change points\n2. Find test points\n3. Break dependencies\n4. Write tests\n5. Make changes\n\n**Review "},{"path":"modules/debugging.md","content":"# Debugging Masters\n\nExpert frameworks for systematic troubleshooting, root cause analysis, and efficient bug resolution.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Andreas Zeller | Scientific Debugging | Systematic hypothesis testing |\n| David Agans | Nine Rules of Debugging | Universal debugging principles |\n| Diomidis Spinellis | Effective Debugging | Comprehensive toolkit |\n| Rob Miller | Debugging by Asking | Root cause questioning |\n| John Regehr | Compiler/Systems Debugging | Low-level issues |\n\n## Detailed Frameworks\n\n### Zeller's Scientific Debugging\n\n**Source**: Andreas Zeller - \"Why Programs Fail\" (2009)\n\n**Core Idea**: Apply scientific method to debugging—hypothesis, experiment, conclusion.\n\n**The Scientific Debugging Process**:\n```\n1. OBSERVE failure\n2. HYPOTHESIZE cause (be specific!)\n3. PREDICT behavior if hypothesis true\n4. EXPERIMENT to test prediction\n5. CONCLUDE: confirmed or refuted\n6. REPEAT with new hypothesis\n```\n\n**Key Principle**: Never change code to \"see if it fixes it.\" That's guessing, not debugging.\n\n**Hypothesis Quality**:\n```\nBAD:  \"Something's wrong with the database\"\nGOOD: \"The query times out because it scans all rows without index\"\n```\n\n**Delta Debugging** (Zeller's technique):\n- Minimize failing input\n- Find smallest change that triggers bug\n- Isolate exactly what causes failure\n\n**Use When**: Complex bugs, intermittent failures, need systematic approach.\n\n---\n\n### Agans' Nine Rules\n\n**Source**: David Agans - \"Debugging: The 9 Indispensable Rules\" (2002)\n\n**Core Idea**: Universal rules that apply to any debugging scenario.\n\n**The Nine Rules**:\n\n| # | Rule | Application |\n|---|------|-------------|\n| 1 | **Understand the System** | Read docs, trace data flow before assuming |\n| 2 | **Make It Fail** | Reproduce reliably before investigating |\n| 3 | **Quit Thinking and Look** | Actually read error messages, logs, state |\n| 4 | **Divide and Conquer** | Binary search to isolate |\n| 5 | **Change One Thing at a Time** | Controlled experiments only |\n| 6 | **Keep an Audit Trail** | Log what you tried and results |\n| 7 | **Check the Plug** | Verify assumptions, environment, obvious things |\n| 8 | **Get a Fresh View** | Rubber duck, ask colleague, sleep on it |\n| 9 | **If You Didn't Fix It, It Ain't Fixed** | Verify root cause, not just symptoms |\n\n**Most Violated Rules**:\n- #3: Jumping to hypotheses without reading the actual error\n- #5: Changing multiple things hoping something works\n- #9: Seeing issue disappear and assuming it's fixed\n\n**Use When**: Any debugging situation—these are universal.\n\n---\n\n### Spinellis' Debugging Strategies\n\n**Source**: Diomidis Spinellis - \"Effective Debugging\" (2016)\n\n**Core Idea**: Comprehensive toolkit organized by debugging phase.\n\n**Strategy Categories**:\n\n**High-Level Strategies**:\n| Strategy | When to Use |\n|----------|-------------|\n| Reproduce consistently | First step, always |\n| Simplify input | Large inputs, complex"},{"path":"modules/decision-making.md","content":"# Decision Making Masters\n\nExpert frameworks for making better decisions, avoiding cognitive biases, and developing reliable judgment.\n\n## Masters Overview\n\n| Expert | Key Contribution | Best For |\n|--------|-----------------|----------|\n| Charlie Munger | Mental Models, Inversion | Investment/business decisions |\n| Daniel Kahneman | System 1/2, Biases | Understanding cognitive limitations |\n| Gary Klein | Recognition-Primed Decision | Expert intuition, time pressure |\n| Annie Duke | Thinking in Bets | Decisions under uncertainty |\n| Ray Dalio | Principles, Radical Transparency | Organizational decisions |\n\n## Detailed Frameworks\n\n### Munger's Mental Models\n\n**Source**: Charlie Munger - \"Poor Charlie's Almanack\", Berkshire letters\n\n**Core Idea**: Build a latticework of mental models from multiple disciplines; use them in combination.\n\n**Key Mental Models**:\n\n| Model | Discipline | Application |\n|-------|------------|-------------|\n| **Inversion** | Mathematics | \"What would make this fail?\" |\n| **Second-Order Effects** | Physics | \"What happens next? Then what?\" |\n| **Circle of Competence** | Self-knowledge | \"What do I actually understand?\" |\n| **Margin of Safety** | Engineering | \"What's the buffer for error?\" |\n| **Opportunity Cost** | Economics | \"What am I giving up?\" |\n| **Incentives** | Psychology | \"What are people rewarded for?\" |\n\n**Inversion Technique**:\n```\nInstead of: \"How do I succeed?\"\nAsk:        \"How would I guarantee failure?\"\nThen:       Avoid those things\n\nInstead of: \"How do I make a great skill?\"\nAsk:        \"What makes skills terrible?\"\nThen:       Eliminate those patterns\n```\n\n**Use When**: Complex decisions, need diverse perspectives, avoiding blind spots.\n\n---\n\n### Kahneman's System 1/System 2\n\n**Source**: Daniel Kahneman - \"Thinking, Fast and Slow\" (2011)\n\n**Core Idea**: Two thinking systems with different strengths and failure modes.\n\n**The Two Systems**:\n| System 1 (Fast) | System 2 (Slow) |\n|-----------------|-----------------|\n| Automatic | Effortful |\n| Intuitive | Analytical |\n| Parallel | Serial |\n| Emotional | Logical |\n| Error-prone | Accurate but lazy |\n\n**Key Biases to Counter**:\n| Bias | Description | Countermeasure |\n|------|-------------|----------------|\n| **Anchoring** | First number influences | Generate own estimate first |\n| **Availability** | Recent = likely | Ask \"What am I not seeing?\" |\n| **Confirmation** | Seek supporting evidence | Actively seek disconfirming |\n| **Overconfidence** | Certainty exceeds accuracy | Estimate confidence intervals |\n| **Hindsight** | \"I knew it all along\" | Record predictions beforehand |\n| **Sunk cost** | Continue because invested | \"Would I start this now?\" |\n\n**Pre-Mortem Technique**:\n```\nImagine the project has failed spectacularly.\nWrite the story of why it failed.\nNow prevent those things.\n```\n\n**Use When**: Need to check intuitions, high-stakes decisions, avoiding biases.\n\n---\n\n### Klein's Recognition-Primed Decision (RPD)\n\n**Source**: Gary Klein - \"Sources of "}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Surface expert frameworks Skill: methodology-curator Owner: athola Summary: Surface expert frameworks Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:03:31.291Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:27:54.111Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:27:47.102Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:44:41.928Z | user Release v1.9.16 v1.9.15 | 2026-07-04T21:19:18.229Z | user Release v1.9.15 v1.9.14 | 2026-06","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1702,"uniquenessScore":57,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T00:17:52.100Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T00:17:52.100Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T10:02:18.365Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}