Browse skills

One file, one job, and short enough to hold in your head. Covers the size policy (hard-split over 300 lines, split 200 to 300 at a seam, aim for 150), what a natural seam is and where to cut, the exemptions, the dependency rules that decide where the split lands, and the signals that a file is already two files. Use before adding to a file that is already long, when naming a new file, when a function has nowhere obvious to live, or when a review says a file is doing too much. Triggers - "this file is too long", "where should this go", "split this file", "is this file too big", "one responsibility".

The English summary is being prepared. Showing the original description.

Cut AI tells from any writing. Use for every piece of prose that ships - docs, READMEs, commit messages, PR descriptions, release notes, changelogs, UI copy, chat answers - and as a final pass before handing work back. Triggers - "unslop", "de-slop", "remove the slop", "sounds like ChatGPT", "make it sound human", "too wordy", "cut the fluff". Must always apply.

The English summary is being prepared. Showing the original description.

What things get called. A file is named after its export in the project's case convention, a suffix is a resolution instruction rather than decoration, an index file only re-exports, and some symbol names are always wrong (utils, helpers, V2, Enhanced, New). Covers learning a tree's local vocabulary before adding to it, test and platform-variant naming, and the per-language conventions. Use when creating a file or directory, naming a test file, adding a platform variant, or when a name has to change. Triggers - "what should I call this file", "where does this file go", "naming convention", "kebab or camel", "name this test".

The English summary is being prepared. Showing the original description.

Spawn the comment hunter, fix accepted findings, and offer encodings for claimed constraints.

The English summary is being prepared. Showing the original description.

Write a short release note people finish reading. Picks the few changes a user will notice from the pull requests since the last release, names each by what the reader can now do, keeps to a length budget, writes every language from the intent instead of translating, and traces every line to a PR. Use when cutting a release, or filling a GitHub Release body, a store "what's new", a package changelog or an in-app what's new screen. Triggers - "write the release notes", "release notes for 0.4.0", "what's new", "changelog for this release", "notes de version".

The English summary is being prepared. Showing the original description.

Rust best practices. Use when reading or editing any .rs file, designing a crate's public API, choosing an error type, splitting a workspace, or writing async code on tokio. Triggers - "rust best practices", "is this idiomatic", "should this be a newtype", "anyhow or thiserror", "why does the borrow checker", "review this Rust".

The English summary is being prepared. Showing the original description.

Write cargo tests. A test name is a sentence, the body is setup, mock, test and verify blocks separated by blank lines with no comments, and shared setup lives in a named test-support module rather than in each test. Covers naming, the block shape, where a test file goes, async and time, workspaces, and running one crate or one filter. Use when adding or changing any #[test] or #[tokio::test], or when Rust coverage has to come up. Triggers - "write a rust test", "cargo test", "test this crate", "cover this handler".

The English summary is being prepared. Showing the original description.

Security guidance and vulnerability review for codebases, APIs, services, CLI tools, libraries, and daemons. Use for security questions, focused reviews, vulnerability research, security audits, or pen tests. Run the complete workflow only for explicit codebase audit or pen-test requests, full/comprehensive/end-to-end reviews, or requested report artifacts.

The English summary is being prepared. Showing the original description.

Drive a PR to a green quality gate and keep it there. Loops on SonarCloud for the project's targets, no new issues, no duplication on new code, and coverage on new logic as close to 100% as the code allows, then watches the PR checks until every one passes. Use when a quality gate blocks a merge, when coverage or duplication has to come up, or before asking for review. Triggers - "fix the sonar issues", "quality gate", "get coverage up", "zero duplication", "loop until CI is green", "watch the checks".

The English summary is being prepared. Showing the original description.

Write and change a product spec. Covers what belongs in the spec rather than in architecture, the status vocabulary, requirement IDs and how to keep them stable, and how to size a requirement so it becomes one story. Use when adding or editing a spec chapter, when a PR changes behaviour and the spec has to move with it, or when asked what the product should do. Triggers - "write the spec", "add a requirement", "spec this out", "update the spec", "what should this do".

The English summary is being prepared. Showing the original description.

Write the failing test before the code that satisfies it, for new behaviour and for bug fixes, and stop when the test path is not worth its cost. Covers the red-green loop, what a first test should assert, when to skip the loop honestly, and the evidence to report. Use when starting behaviour that has a cheap test path, or fixing a bug that can be reproduced in a test. Triggers - "tdd", "write a failing test first", "regression test", "reproduce this in a test", "test first".

The English summary is being prepared. Showing the original description.

Write GitHub issues and PR descriptions. Covers the epic and sub-issue structure, linking a requirement instead of copying spec text, reading the project's label set and templates rather than guessing them, title format, and what a reviewer needs in a PR body. Use when opening an issue, turning a spec requirement into work, filing a bug, or writing a PR description. Triggers - "open an issue", "write a ticket", "file a bug", "turn this into work", "write the PR description".

The English summary is being prepared. Showing the original description.

TypeScript best practices. Use when reading or editing any .ts or .tsx file, designing a module's public types, fixing a type error, choosing between type and interface, or setting up tsconfig, and whenever a diff reaches for any, as, ! or @ts-ignore. Triggers - "typescript best practices", "is this type safe", "how should I type this", "review this TS", "any vs unknown".

The English summary is being prepared. Showing the original description.

Write TypeScript tests. A test name is a sentence, the body is setup, mock, test and verify blocks separated by blank lines with no comments, and the runner's config decides where the file goes. Covers naming, the block shape, size, fixtures, what not to assert, DOM opt-in, multiple runner projects, coverage, and running one test. Use when adding or changing any .test.ts or .test.tsx, or when coverage has to come up. Triggers - "write a test", "add tests", "test this", "vitest", "jest", "how do I test", "cover this file".

The English summary is being prepared. Showing the original description.