We split this skill into the rules it gives an agent

13 rules. 0 are common, 8 are distinctive, and 5 are very specific to this project.

• 0

  Common

  Most of the 157 edited versions we read keep these.

• 8

  Distinctive

  This author's own choices. Worth a look.

• 5

  Very specific

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

• Common
• Distinctive
• Very specific

1. Distinctive:

   All imports at file top — no lazy imports inside functions

   line 12
2. Very specific:

   No confusing renames — use qualified access (x25519.X25519PublicKey)

   line 13
3. Very specific:

   Never quote annotations when from __future__ import annotations is present

   line 18
4. Very specific:

   Prefer narrow domain types (Bytes32, PeerId, RequestId) over raw bytes

   line 19
5. Distinctive:

   No example code in docstrings — unit tests serve as examples

   line 26
6. Very specific:

   No section separator comments (# ====, # ----)

   line 27
7. Distinctive:

   Never use explicit function or method names in docs — names change

   line 32
8. Distinctive:

   Write short, scannable sentences — one idea per line

   line 33
9. Distinctive:

   Use bullet points or numbered lists for multiple items

   line 34
10. Distinctive:

    Never remove existing documentation unless directly invalidated by a code change

    line 35
11. Very specific:

    Use pytest.raises(ExceptionType, match=r"...") for error tests

    line 41
12. Distinctive:

    No backward compatibility code — no shims, aliases, or re-exports

    line 46
13. Distinctive:

    No unnecessary abstractions — inline is often better for spec code

    line 47

“Common” is measured: kept by at least 6 in 10 of the 157 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.