knowledge-mcp: Skill for Claude Code

SELECT-PATTERNS — what the planner will faithfully build to

Tickets carry two independent pattern lists: pattern_ids (architecture — PRESCRIPTIVE: the planner BUILDS to whatever is attached) and language_patterns (language anti-patterns — DEFENSIVE: vigilance markers shaping review, not the build).

Attachment discipline

Attach pattern_ids when the pattern is structurally load-bearing — the work IS an instance of the pattern, or the planner needs it as the canonical shape. Use no_patterns_reason when none is. Don't ask permission to attach an obvious match — and don't pile on mediocre matches to look thorough, because the planner WILL build to whatever is attached.

Discovery fans out: patterns live across multiple practice graphs — search them as a set (search({graph:"practice", language:"all", queries:[...]})). Never conclude "no pattern fits" from a single-graph miss.

The failure this table exists for: a ticket attached a registry pattern because it "kind of fit"; the planner faithfully built exported Register/Unregister with panic-on-duplicate, a mutex, and dedicated tests — for a closed set of three ops where a plain switch was one screen of code.

language_patterns (defensive)

When the ticket's language has an anti-pattern corpus, enumerate deterministically (query({graph:"practice", language:"<lang>", type:"finding", meta:{"dsl_pattern":"*"}, fields:[...]})). Attach only when the implementation surface plausibly touches the anti-pattern AND the user agrees — 3-4 strong matches is plenty; never bulk-attach. No language surface → leave empty; the empty case is the default.