菜单
Use when code should match a team's real conventions the user keeps correcting the AI toward — "make it match our codebase", "follow our patterns", "you keep writing it wrong" — or when repeated corrections should become durable rules. Private, Lab-gated. For writing in a named public engineer's style, use `persona`.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | signature |
| description | Use when code should match a team's real conventions the user keeps correcting the AI toward — "make it match our codebase", "follow our patterns", "you keep writing it wrong" — or when repeated corrections should become durable rules. Private, quarantine-gated. For writing in a named public engineer's style, use `persona`. |
A codebase has a real style that's rarely written down — people can't list their own conventions, but recognize a violation instantly. This skill surfaces that tacit style and makes it durable: a correction you give once becomes a permanent rule, not a repeated fix. Two phases — capture (private, in the quarantine), then distil (name-free, into a field pack).
The rule that never bends: patterns, not people. Describe what the code does ("this codebase resolves X by Y"), never rate a person ("so-and-so writes bad code"). The artifact is the pattern; the person is incidental — and a file that judges a named person is a career-risk if it leaks. Group by contributor only as a source of signal, phrased neutrally.
lab/ (gitignored) — if there's no Lab, set one up (quarantine skill) first.lab/analysis/: pattern · frequency · source · first-pass
kind (convention | correctness | unsure). Neutral wording is not optional — if you can't phrase it
about the pattern, drop it.Gate 1 — Classify: convention or correctness.
Gate 2 — Promotion bar (keep the pack lean). A candidate graduates only if it recurs across more than one source/author — the antidote to encoding one loud voice as team law, and to bloat. Replay it against recent examples to confirm it holds. Use all three signals: corrections (add a rule), approvals (confirm an existing rule is right — stop second-guessing it), and implicit edits (human shipped it differently than proposed — the richest source of unstated conventions).
Gate 3 — Sanitize (identities never leave the quarantine). Strip every project/product/person/package/host name and replace with a generic description before anything reaches a field pack. If a rule can't be expressed without an internal name, it stays in the quarantine. The guards are the backstop, not a license.
Hand surviving rules to levelup as proposed pack edits (category · kind · generic rule · why [+citation]). Show the user the diff; never auto-commit or push. Convention → lessons/stack-defaults;
correctness-with-citation → same, tagged for the code-reviewer audit. Frontend today; the gates apply to any field.
code-reviewer finds defects; this captures style. Keep the layers separate.persona. persona is for public figures with a documented body of work; a real coworker's style is Mode-A material and never leaves the quarantine.Use when implementing any non-trivial feature, change, or fix — "build me X", "add this feature", "implement this", "make this work", "can you create". Covers new functionality, meaningful changes to existing code, and anything where quality matters. Not for a one-line diff — just do that.
Use when a bug isn't obvious, resists a quick fix, keeps coming back, or you're about to start guessing — "why is this broken", "this keeps happening", intermittent or flaky failures, a crash you can't explain, behaviour that makes no sense. Not for a typo or an obvious mistake.
Use when something has to be removed or retired — a feature, endpoint, table column, config key, feature flag, package or whole service; migrating consumers off an old API or version; code that looks dead but might not be. Symptoms: "can we delete this?", "is anything still using this?", "we need everyone off v1", "kill the old one". Not for restructuring that keeps the interface — that's the `refactorer` agent.
Use when you are about to tell the user something works, hand over a decision you feel confident about, or make a change that can't be undone — and when a review came back suspiciously clean. Symptoms: "are you sure?", "you said that was fixed last time", nothing to report, the answer feels too tidy. Not for a routine small change; not for reviewing a finished diff — that's `code-reviewer`; not for driving a finished change end-to-end to get evidence — that's `qa`. Doubt tests a claim (a diagnosis, a design call, an answer), which is often not runnable code.
Use when an internal package, module, or shared component has little or no usage documentation and people (or future AI sessions) keep using it wrong — "document this", "write docs for our library", onboarding someone onto an internal API, or handing a package to another team.
Use when work needs to survive losing context — before a /clear on a long task, when pausing something unfinished, when handing over to a teammate or the next session, when the context window is filling up on multi-day work, or when a long multi-step task starts re-covering ground it already finished. Not the project's decision history across weeks — that's `roadmap`.