菜单
Formalize a bug, audit finding, or incident root cause into a numbered Hard Rule in claude-context.md. Use after fixing a bug caused by a repeatable code pattern, after audits with findings rated 4+/10, or when the user says "make this a rule".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | extract-pattern |
| description | Formalize a bug, audit finding, or incident root cause into a numbered Hard Rule in claude-context.md. Use after fixing a bug caused by a repeatable code pattern, after audits with findings rated 4+/10, or when the user says "make this a rule". |
| argument-hint | ["issues-to-formalize"] |
I am requesting a POST-MORTEM PATTERN EXTRACTION.
Issues to formalize: $ARGUMENTS
Ref:
.dev-context/claude-context.mdfor build constraints, architecture, coding conventions, and the Hard Rules.
Act as a Principal Engineer performing a Post-Mortem. Transform recent bug fixes and audit findings into formal "Anti-Patterns & Lessons Learned" entries.
Mandatory after:
Threshold check first: a Hard Rule is for systemic patterns — mistakes that will plausibly recur in new code. A one-off bug gets a test, not a rule. A Seastar subtlety that is real but hasn't bitten us yet goes in .dev-context/seastar-pitfalls-reference.md instead (the "minor leagues" — promote it later if it bites).
Each entry must:
---
#### N. The [Descriptive-Name] Anti-Pattern
**THE PATTERN:** What was the "seemingly good" but incorrect approach used?
**THE CONSEQUENCE:** Why is this dangerous in our Seastar/shared-nothing environment? Be specific about failure modes.
**THE LESSON:** *Hard Rule: [One sentence imperative rule].* Provide implementation guidance with correct/incorrect code examples.
**PROMPT GUARD:** "[One-sentence instruction to prevent this pattern.]"
---
Take the next free number (rules are append-only; never renumber).
When adding Hard Rule #N, update all of:
.dev-context/claude-context.md — full anti-pattern entry (format above).dev-context/claude-context.md — Quick Reference table row at the bottom.dev-context/claude-context.md — Pre-Code Checklist item at the top, if the rule is checkable before writing code.claude/skills/review/SKILL.md — new row in the Compliance Table.claude/skills/debug-build/SKILL.md — symptom row, if the rule has a recognizable failure signaturesrc/? grep for the pattern; file [TECH-DEBT] BACKLOG items for any found (don't silently ignore them)If the finding shows an existing rule is wrong or incomplete (it has happened — see the *Corrected 2026-05-05* notes on Rules #2, #12, #13, #20): edit the rule in place, keep the number, and append a dated *Corrected YYYY-MM-DD: [what changed and why]* line. Never delete the correction trail.
/review compliance-table rowHostile security and robustness audit of src/ assuming malicious traffic and 100x load. Use before releases, after large feature merges, or when the user asks for a security audit, adversarial review, or "what breaks under attack".
Holistic system audit for architecture drift, Hard Rules compliance, and async integrity across recently changed code. Use after completing a batch of tasks, before a release, or when the user asks for a health check or audit.
Semantic-correctness audit of hot-path code - enumerate the invariants a component must maintain, then hunt code paths that violate them (wrong answers, not crashes). Use after changing routing, eviction, accounting, or counter logic, before a release, or when metrics drift without any crash.
Orientation for a session starting work on this codebase - reading order, where things live, which skill to use for which task, and the non-negotiable constraints. Use at the start of a session, when unsure where to look, or when the user asks how to approach a task here.
Plan, run, and interpret Locust load benchmarks (mock-backend and real-GPU) including A/B routing experiments. Use when the user wants to measure cache-hit ratio, TTFT, or throughput, compare routing modes, chase a benchmark regression, or design a benchmark experiment.
Triage build or runtime failures. Use when the user pastes a compile error, link error, runtime crash, test failure, or error log, or mentions a build failure.