Use when analyzing randomized algorithms, probabilistic analysis, indicator random variables, hiring and secretary problems, random permutations, balls-and-bins, birthday paradox, streaks, or average-case versus expected-time reasoning.
Use when solving, proving, implementing, or reviewing weighted shortest-path problems, including single-source or all-pairs shortest paths, relaxation, negative edges or cycles, Dijkstra, Bellman-Ford, DAG paths, Floyd-Warshall, Johnson, difference constraints, transitive closure, arbitrage, or graph-path reductions.
Use when choosing or analyzing sorting, heaps, priority queues, linear-time integer/distribution sorting, quicksort, selection, medians, quantiles, top-k, or order-statistic algorithms under practical engineering constraints.
CSAPP; "Computer Systems A Programmer's Perspective" by Randal E. Bryant and David R. O'Hallaron, covering computer architecture, systems programming, and performance optimization.
TaPL; the foundational computer science textbook "Types and Programming Languages" by Benjamin Pierce, covering type systems, programming language theory, lambda calculus, and more.
Use when removing dead code, renaming symbols, or refactoring — any change with no external consumers. Triggers on deprecating dead code, wrapper shims, compatibility aliases, TODO-future-cleanup, or refactors that patch structure instead of simplifying.
Use when writing new React components that involve state derived from props, event-driven side effects, or external subscriptions. Also use when auditing existing code for unnecessary useEffect calls, reviewing useEffect-heavy components, or refactoring to eliminate cascading renders. Applies to React 18+ codebases.
Use when about to make git commits, when tempted to bundle unrelated changes behind a single message, or when commit history needs to support git bisect, revert, and cherry-pick workflows. Also use when reviewing a branch before creating a PR. If you are writing a plan, specify that the executor must load this skill…
Use when configuring or enhancing oxlint rules for a JavaScript/TypeScript project, when deciding which lint rules to enable beyond the default correctness category, or when evaluating whether a lint rule's autofix status and noise level make it worth enabling. Also use when bulk-enabling pedantic or style categories…
Use when implementing or debugging agents, tool-calling assistants, or multi-step AI runtimes and you need correct message conversion, tool-call handling, replayed history, loop continuation, or provider/API compatibility across SDKs, proxies, or direct upstream model APIs.
Use when a user provides examples prefixed by "for example", "such as", "e.g.", "like", or ends a list with "etc." / "and so on". For architecture/design tasks, abstract first to identify the concept, then enumerate. For research/clarification tasks, enumerate first — the concept organizes the output but the list is…
Use when linearizing a git branch that has merge commits, flattening topological history into a single linear chain, removing merge commits while preserving all work and the final tree state. Triggers on "linearize", "flatten history", "remove merge commits", "rebase to linear", "squash merges out of history".
Use when explaining how an existing system works by modeling it as objects and processes — answering "what does this thing actually do?", writing down system knowledge that only lives in your head, onboarding your human partner onto a fast-growing system, or preventing cognitive debt with Object-Process Methodology…
Use when explaining an existing system's architecture to your human partner — answering "how does this work?", onboarding them to an unfamiliar area, giving context before a decision, writing down what only lives in your head, or preventing cognitive debt by scoping explanations with ISO/IEC/IEEE 42010.
Use when extracting reusable patterns from session history to create skills, analyzing completed work to identify generalizable workflows, or when writing skill trigger descriptions that need to be concept-anchored rather than example-based.
Use when the partner asks for manual frontend QA, hand-testing, or step-by-step UI verification, or when you finish a frontend change and want to offer manual verification proactively. Especially when Playwright/Cypress/Selenium is unavailable, not worth setup, or the partner said "just check it manually." Requires…
Use when skill documents are too long, bloated with repetitive prose, or the user asks to compress/shorten/tighten/trim a SKILL.md. Also use when a skill has overlapping sections, duplicate explanations, or verbose examples that inflate word count without adding behavioral content.