diff --git a/SKILL.md b/SKILL.md
index d5ba372..4c99c3c 100644
--- a/SKILL.md
+++ b/SKILL.md
@@ -264,33 +264,99 @@ stdlib should produce 50-200+ patterns across all topics.
 
 **Output structure — one file per topic:**
 
-`patterns/<topic>.md` — topics include:
-- Error handling
-- Naming conventions
-- Concurrency patterns
-- Testing patterns
-- Interface/protocol design
-- Module organization
-- Documentation conventions
-- Performance idioms
-- Configuration patterns
-- Extension/plugin patterns
+`patterns/<topic>.md` — topics include (but aren't limited to):
+- Error handling (sentinel errors, error types, wrapping, multi-error)
+- Naming conventions (packages, types, functions, receivers)
+- Concurrency patterns (goroutines, channels, mutexes, sync primitives)
+- Testing patterns (table-driven, helpers, fixtures, benchmarks, examples)
+- Interface/protocol design (size, composition, assertion, extension)
+- Module/package organization (layout, internal/, visibility)
+- Documentation conventions (godoc, deprecation, package-level)
+- Performance idioms (pooling, preallocate, append, zero-alloc)
+- Configuration patterns (functional options, config structs, defaults)
+- Extension/plugin patterns (registration, middleware, hooks)
+- Struct patterns (constructors, zero values, embedding, tags)
+- API design (backwards compat, versioning, deprecation strategy)
 
-Each pattern entry:
-- Name (short, linkable heading)
-- Rule (one sentence: "Do X" or "Never Y")
-- Example (real code from the source, not invented)
-- Why (the force that makes this the right choice)
-- When to use (the trigger condition — what situation calls for this)
-- When NOT to use (where the pattern breaks down)
-- Source (hyperlinked to the commit or file on the forge, e.g.
-  `[src/io/io.go#L86](https://github.com/golang/go/blob/master/src/io/io.go#L86)`.
-  Use permalink format with commit SHA when possible for stability.)
+**Start with 8–10 topics for a language stdlib; add more if the
+source shows distinct patterns in additional areas.** Each topic
+should map to a real problem domain that developers face.
+
+**File naming:** Use lowercase, hyphenated names that describe the
+topic clearly: `error-handling.md`, `testing-advanced.md`,
+`api-conventions.md`, `concurrency.md`.
+
+**Each pattern entry requires ALL of these sections:**
+
+### `## N. Pattern Name`
+
+Short, linkable heading (no generic names like "Pattern 1").
+
+### `### Source:`
+
+Hyperlinked to the exact file and line on the forge.
+Format: `[src/io/io.go#L86](https://github.com/golang/go/blob/COMMIT_SHA/src/io/io.go#L86)`
+Use permalink format (commit SHA) for stability.
+
+### Real source example
+
+The actual code from the source, with file:line comments. Not
+simplified, not invented. This IS the evidence.
+
+### `### Why`
+
+The force that makes this the right choice. Not "because the
+stdlib does it" — explain the FORCE (testability, allocation
+cost, readability under diff, composability).
+
+### `### When to Use`
+
+**Triggers:** — bullet list of specific situations that call for this.
+
+**Example — before:** — code showing the problem WITHOUT the pattern.
+This is critical. Readers must recognize their own bad code here.
+
+**Example — after:** — code showing the same problem WITH the pattern.
+The before/after pair is what makes patterns teachable.
+
+### `### When NOT to Use`
+
+**Don't use this when:** — bullet list of boundary conditions.
+
+**Over-application example:** — code showing what happens when you
+use this pattern where it doesn't belong. This prevents cargo-culting.
+
+**Better alternative:** — what to do instead in those cases.
+
+### `### Anti-pattern` (when relevant)
+
+Explicit `DON'T:` block showing the wrong approach with a comment
+explaining why it's wrong, followed by `DO:` showing the fix.
+
+---
+
+**Each topic file ALSO needs:**
+
+- **Summary/Decision Tree at the end** — "If X, use pattern A. If Y,
+  use pattern B." Readers should be able to skip to the decision
+  tree and find their situation.
+- **Cross-references** — link to related patterns in other topic files.
+  e.g., error-handling links to interfaces when discussing error types.
+
+---
+
+**Quality bar:** Each pattern entry should be 40–80 lines including
+code examples. A topic file with 10 patterns should be 500–900 lines.
+If entries are shorter than 40 lines, they're missing before/after
+examples or anti-patterns.
+
+---
 
 **`smells.md`** — anti-patterns found in the source:
-- What it looks like
-- Why it exists (technical debt? deliberate tradeoff?)
-- What to do instead
+- What it looks like (with real code)
+- Why it exists (technical debt? deliberate tradeoff? historical?)
+- What to do instead (with code showing the fix)
+- How to detect it (grep pattern or linter rule)
 
 **Tone:** Prescriptive. "Write it this way because X."
 
@@ -300,7 +366,9 @@ inform HOW to write code. Focus on patterns a user should copy.
 
 **Done criteria:** You've scanned every major directory in the source.
 No new patterns emerge from further grep/read. Each topic file has
-15+ patterns with real examples. Edge cases are documented.
+10–15+ patterns, each with before/after examples, anti-patterns,
+and decision guidance. Total output for a language stdlib should be
+5,000–10,000+ lines across all topic files.
 
 ---