hypershift / rules

We split this 100-go-mistakes.mdc into the rules it gives an agent

37 rules. About 0 are common, 26 are distinctive, and 11 are very specific to this project.

• ≈0

  Common · estimate

  Many files like this have a rule of this kind.

• ≈26

  Distinctive · estimate

  This author's own choices. Worth a look.

• 11

  Very specific

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

• Common
• Distinctive
• Very specific

1. Very specific:

   Do not over-nest control flow (e.g., nested if or for blocks).

   line 8
2. Very specific:

   Avoid init() functions unless absolutely necessary.

   line 9
3. Distinctive:

   Keep functions small and focused.

   line 10
4. Distinctive:

   Prefer composition over inheritance (via embedding).

   line 11
5. Distinctive:

   Use the functional options pattern for constructors where flexibility is needed.

   line 12
6. Distinctive:

   Avoid defining interfaces until you need them.

   line 16
7. Distinctive:

   Do not return interfaces from constructors or public APIs.

   line 17
8. Distinctive:

   Keep interfaces small and focused (generally 1–2 methods).

   line 19
9. Distinctive:

   Avoid embedding pointer types unless necessary.

   line 23
10. Distinctive:

    Use value receivers when the method doesn't mutate state or require pointer semantics.

    line 25
11. Very specific:

    Do not use util, common, or similarly vague package names.

    line 29
12. Distinctive:

    Avoid package name collisions by using clear, unique names.

    line 30
13. Distinctive:

    Do not expose unnecessary symbols (keep exported API minimal).

    line 31
14. Distinctive:

    Avoid memory leaks from slicing large arrays.

    line 36
15. Distinctive:

    Always check the capacity when copying or appending slices.

    line 37
16. Distinctive:

    Always initialize maps before use.

    line 42
17. Very specific:

    Check existence with the two-value assignment (val, ok := m[key]).

    line 43
18. Distinctive:

    Always check errors — don’t ignore them.

    line 48
19. Distinctive:

    Avoid panics except in truly unrecoverable cases.

    line 50
20. Very specific:

    Use errors.Is and errors.As for error comparison in Go 1.20+.

    line 51
21. Very specific:

    Always defer cancel() when using context.WithCancel.

    line 55
22. Distinctive:

    Do not leak goroutines — ensure they exit cleanly.

    line 56
23. Distinctive:

    Avoid data races — use mutexes or channels appropriately.

    line 57
24. Distinctive:

    Never close a channel from the receiving side.

    line 58
25. Distinctive:

    Use table-driven tests where possible.

    line 63
26. Distinctive:

    Avoid global state in tests.

    line 64
27. Very specific:

    Use t.Helper() in helper functions to improve error tracebacks.

    line 65
28. Distinctive:

    Keep imports grouped and ordered: stdlib, external, internal.

    line 69
29. Distinctive:

    Avoid magic numbers — use named constants.

    line 70
30. Distinctive:

    Prefer explicit over implicit — especially in exported APIs.

    line 71
31. Distinctive:

    Only use generics when they simplify code or add real flexibility.

    line 75
32. Distinctive:

    Avoid over-engineering with type parameters.

    line 76
33. Very specific:

    Avoid using default int unless the size is appropriate.

    line 81
34. Very specific:

    Avoid precision issues with float32/float64 — prefer math/big if needed.

    line 83
35. Very specific:

    Prefer any to interface{} in Go 1.18+, but avoid both unless necessary

    line 87
36. Very specific:

    Do not rely on map or slice comparison — use reflect.DeepEqual or a library.

    line 88
37. Distinctive:

    Avoid relying on goroutine scheduling or map iteration order.

    line 89

≈ “Common” is an estimate: at least 1 in 5 of the 6,668 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.