We split this skill into the rules it gives an agent

12 rules. 0 are common, 6 are distinctive, and 6 are very specific to this project.

• 0

  Common

  Most of the 37 edited versions we read keep these.

• 6

  Distinctive

  This author's own choices. Worth a look.

• 6

  Very specific

  Tied to their project's names, files or tools. Probably skip.

• Common
• Distinctive
• Very specific

1. Very specific:

   Test public behavior and API contracts through the public API.

   line 18
2. Distinctive:

   Use test utilities to control collaborators and state.

   line 21
3. Very specific:

   When a test needs more control, expose test-only public APIs behind a non-default test-util feature.

   line 24
4. Distinctive:

   Use unit tests for implementation details that a supported public API cannot exercise.

   line 29
5. Distinctive:

   Prefer these workspace tools:

   line 37
6. Very specific:

   Use fakeable to create controlled fakes and mocks.

   line 39
7. Very specific:

   Use future_assert to test future behavior without starting a runtime.

   line 40
8. Very specific:

   Use a frozen tick clock and advance time explicitly.

   line 41
9. Very specific:

   Use insta snapshots for exact string and structured output.

   line 42
10. Distinctive:

    If a refactor or performance change preserves public behavior, do not rewrite existing integration tests to match internal implementation …

    line 49
11. Distinctive:

    If a change intentionally alters public behavior, update the affected tests.

    line 53
12. Distinctive:

    Do not weaken assertions, skip tests, or delete coverage to make a change pass.

    line 56

“Common” is measured: kept by at least 6 in 10 of the 37 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

• Other versions37 projects use a version of this.

  Word for word · 0

  None found.

  Edited · 0

  None found.

  Wrote their own version · 37

  1. remotion-dev/remotion★ 70ksame name
  2. PostHog/posthog★ 40ksame name
  3. JetBrains/intellij-community★ 21ksame name
  4. quarkusio/quarkus★ 16ksame name
  5. DetachHead/rebased★ 6.3ksame name
  6. chattocorp/chatto★ 2.9ksame name
  7. starkware-libs/cairo★ 1.9ksame name
  8. bholmesdev/hubble.md★ 1.5ksame name
  9. amplifthq/openmeld★ 1.4ksame name
  10. amplifthq/opentag★ 1.4ksame name

  27 more not listed

  How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

• Used alongsideProjects with it also use reviewing-code, commits and 5 more.

  Other files people use alongside this one.

  How we pick theseFiles found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.

  • witi-projectsSkill

    reviewing-code

    Perform a thorough code review focused on correctness, maintainability, performance, and best practices. Use when the user says "/reviewing-code", "reviewing code", or asks about reviewing code.

    Also in 4 projects that use this

  • JetBrainsSkill

    commits

    Use this skill whenever the user asks to commit changes, write or fix a commit message, amend or rename a commit, or do a workflow that includes committing in the IntelliJ repository. This is a thin repo-specific overlay: use IntelliJ commit format, write full commit messages by default, and keep requested suffixes such as IJ-MR trailers in a final separate paragraph.

    Also in 3 projects that use this

  • OpenAISkill

    running-tests

    Guide for running tests in the openai-dotnet repository. Use this when asked to run, debug, or validate tests, or when writing new tests. Explains test modes (Playback, Record, Live), how to identify recorded vs non-recorded tests, environment variable configuration, and what to do when recordings are missing or stale.

    Also in 3 projects that use this

  • BlockSkill

    debugging

    Debugging guidelines and best practices

    Also in 5 projects that use this

  • VercelSkill

    technical-writing

    Write, edit, review, or audit user-facing documentation for the eve repository. Use for changes under docs/, documentation tied to eve APIs or CLI behavior, docs work based on Slack or support feedback, and requests to make eve docs clearer, more natural, or less AI-patterned while verifying claims against current source, tests, CLI help, public releases, and repository conventions.

    Also in 3 projects that use this

  • SentrySkill

    security-review

    Finds exploitable application security vulnerabilities in code changes. Use for Warden security scans, appsec review, OWASP-style checks, authentication or authorization bugs, injection, XSS, SSRF, path traversal, secrets, unsafe crypto, webhook verification, open redirects, or sensitive data exposure.

    Also in 3 projects that use this

• In this repository9 other files it gives its agents.

  • AGENTS.mdAGENTS.md
  • crates/arty/AGENTS.mdAGENTS.md
  • crates/bytesbuf/AGENTS.mdAGENTS.md
  • crates/fetch/AGENTS.mdAGENTS.md
  • crates/seatbelt/AGENTS.mdAGENTS.md
  • crates/seatbelt/examples/AGENTS.mdAGENTS.md
  • cargo-anvil-adoptionSkill
  • code-reviewSkill
  • simple-englishSkill