菜单
Use when proposing, reviewing, or comparing API designs, refactors, architecture changes, or implementation plans with code sketches. Requires sketches to cover internals, callsites, docs/teaching cost, and library-vs-application API tradeoffs instead of ad hoc snippets.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Conflict microscope for Jujutsu repos: use when preemptively resolving future rebase conflicts, moving a commit under an active stack, making a later rebase clean, or deciding how to jj absorb/squash conflict resolutions into semantic owners without rebasing the whole stack.
Use when the vocabulary of a codebase is getting too muddy, too difficult to teach, or too difficult to update and is in need of refactoring.
Efficient codebase search using a tiered strategy — ast-grep (structural) and ripgrep (textual fallback) — with VCS-aware tooling. Teaches agents to find information in codebases with minimal token overhead by choosing the right level of search abstraction rather than defaulting to text grep.
Write production logging that actually helps you debug. Teaches the wide event / canonical log line pattern — one rich, structured event per request per service instead of scattered log lines. Covers business context, deployment context, single logger setup, middleware enrichment, tail sampling, and idioms for Rust, Python, Go, and TypeScript. Use when adding logging, instrumentation, or observability to any codebase.
Jujutsu (jj) version control for the user's preferred workflow — graph-aware, describe-first, split-oriented, with stacked PRs. Use when working with jj repositories, manipulating the commit graph, creating PRs, or any version control operation in a jj repo.
This skill is simply the TigerStyle document from the TigerBeetle project. It is self-describing and should be treated with reverence.
| name | code-sketches |
| description | Use when proposing, reviewing, or comparing API designs, refactors, architecture changes, or implementation plans with code sketches. Requires sketches to cover internals, callsites, docs/teaching cost, and library-vs-application API tradeoffs instead of ad hoc snippets. |
Code sketches are not miscellaneous snippets. Use them to test a design across three axes:
internals -> what changes behind the seam?
callsites -> what changes for callers, or what stays unchanged?
docs -> how would we teach this API after the change?
For each proposed design, cover all three axes.
If the proposal changes internals, sketch the internal shape: key types, functions, data flow, invariants, or hidden complexity. If internals do not change, say so.
Sketch caller code. If public callsites remain unchanged, explicitly say that and show the unchanged callsite as a reminder.
Sketch how the API would be explained to someone learning the codebase:
Use X when...
Provide Y because...
Avoid Z because...
Then state whether the proposal makes the API easier or harder to teach. Treat extra teaching burden as evidence against the design unless it buys clear leverage.
Ask whether the API is mainly for making libraries, making applications, or both. Where relevant, sketch both usage modes:
// library author
pub fn extension<T: Trait>(input: T) -> impl LibraryThing<T> { ... }
// application author
let thing = Thing::new(config);
thing.run()?;
Name the tradeoff directly. In generic-heavy languages, a design can make library creation easier while making application code harder, or vice versa.
### Sketch: <proposal>
Internals:
<code sketch, or "unchanged">
Callsites:
<code sketch, including unchanged callsites if unchanged>
Docs:
<how we would teach this>
Teaching cost: easier / harder / mixed because...
Library/app impact:
- Library authors:
- Application authors:
Keep sketches small and disposable and always provide more than one. They are a design instrument, not an implementation commitment.