القائمة
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.
التثبيت باستخدام 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.
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.
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.
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 | conceptual-pca |
| description | 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. |
Building a software project is akin to building a vocabulary. Each abstraction, be it a type or an interface, is a concept in that vocabulary. Sometimes, we get ahead of ourselves and make too many concepts that are partially overlapping, overly coupled, or exist at the wrong level of abstraction.
We can solve this by analogy to Principal Component Analysis, where data is projected across its major orthogonal axes of variation. There is an art to interpreting those orthogonal axes, but the point is to have found the axes at all and quantify how much variation in the data they explain.
Often, what we need is a "conceptual PCA" of our codebase vocabulary, where we boil down all the noise to those few, orthogonal axes that really count. Loading this skill is in effect assigning you this task.
