code-quality

Name: code-quality
Author: sordi-ai

17stars3forks

How to install code-quality?

sordi-ai/skill-everything/code-quality

$npx -y skills add sordi-ai/skill-everything --skill code-quality

Installs into the current project.

Summary

Apply when writing or refactoring code. Generic rules to prevent the most common review comments — function length, naming, error handling, security, and tooling.

Files · 1

View on GitHub

SKILL.md

1	# Sub-Skill: Code Quality & Common Mistakes
2	<!-- target: ~1800 tokens (real tiktoken count, see tools/render_readme_table.py) \| 28 rules with severity classification -->
3
4	Purpose: Prevents the 20 % of mistakes that cause 80 % of review comments. Concrete rules from real projects — no boilerplate.
5
6	## Rule classification
7
8	- MUST — load-bearing. Violating causes bugs, security issues, or cross-team confusion. Never break.
9	- SHOULD — default behavior. Deviation needs a documented reason in the code or PR.
10	- AVOID — usually wrong; documented exception inline where needed.
11
12	Where these rules don't strictly apply: test fixtures, generated code (parser tables, codegen output, schema-derived types), CLI bootstrap scripts, framework adapters, and migration scripts may legitimately differ. The rules below apply to production code paths unless an inline exception says otherwise.
13
14	---
15
16	## Rules
17
18	### Functions & Logic
19
20	1. SHOULD: Functions under ~30 lines. Longer → split where practical. Reduces cognitive load.
21	2. AVOID: Boolean as last argument. `render(true)` is unreadable. Use enum or named-property: `render({ withHeader: true })`.
22	3. SHOULD: Early return over nested if-blocks. Nesting depth > 2 is a warning sign.
23	4. SHOULD: No magic numbers. `if (status === 3)` → `if (status === OrderStatus.SHIPPED)`.
24	5. AVOID: Double negation. `if (!isNotValid)` → `if (isValid)`.
25
26	### Variables & Naming
27
28	6. SHOULD: Variable names describe content, not type. `userList` instead of `arr`, `activeUserId` instead of `id`.
29	7. SHOULD: Temporary variables for complex expressions. `const isEligible = age >= 18 && !isBanned;` instead of cramming it all into an `if`.
30	8. AVOID: Abbreviations except established ones (`id`, `url`, `ctx`, `req`, `res`). `usr`, `cfg`, `tmp` → spell out.
31
32	### Error Handling
33
34	9. MUST: Every `async` call needs `try/catch` or `.catch()`. Unhandled promise rejections crash Node processes.
35	10. MUST: Never silently swallow error objects. `catch (e) {}` is forbidden. At minimum: `logger.warn(e)`.
36	11. MUST: Error messages must include context. `throw new Error('User not found: ' + userId)` not `throw new Error('Not found')`.
37	12. SHOULD: Catch specific exception types, not broad categories. Catch `ConnectionError` not `Exception`. Broad catches mask unrelated bugs and make debugging harder.
38	13. SHOULD: Use exponential backoff with jitter for retry logic. Never retry in a tight loop. Each retry should wait longer than the last with randomization to prevent thundering herds.
39	14. MUST: Never retry non-idempotent operations without explicit safeguards. A retried POST that creates a resource can produce duplicates. Use idempotency keys or check-before-retry patterns.
40	15. SHOULD: Propagate errors with context rather than swallowing and re-raising generic exceptions. Use `raise NewError("context") from original_error` to preserve the chain. Reference: ERR-2026-016.
41
42	### Imports & Dependencies
43
44	16. SHOULD: No circular imports. When in doubt: run `madge --circular src/`.
45	17. SHOULD: External dependencies only in dedicated adapter files. No direct `axios.get()` in business logic — always wrap through an interface.
46	18. MUST: Remove `console.log` before commit. Use a pre-commit hook or linter rule `no-console`. Exception: debug helpers behind a build-time `__DEV__` flag.
47
48	### Tests
49
50	19. MUST: Every new function needs at least one happy-path test. No merge without test coverage for new logic. Exception: pure projection wrappers, single-line getters, and deprecated shims may rely on integration tests.
51
52	### Performance
53
54	20. MUST: No DB queries in loops (N+1 problem). Instead of `for (item of items) { await db.find(item.id) }` → use a JOIN or `WHERE id IN (...)` query.
55	21. MUST: Paginate large datasets. Never `SELECT * FROM table` without `LIMIT`. API endpoints with lists need `?page=` and `?limit=`.
56	22. SHOULD: New `WHERE` clauses need indexes. Before every new query: is there a matching DB index? Without index → full table scan on growing data.
57	23. SHOULD: Lazy loading for heavy operations. Load data only when needed, not "just in case".
58
59	### Security
60
61	24. MUST: Never use user input directly in queries. Always use prepared statements or ORM query builders. Applies to SQL, NoSQL, shell commands, and template engines.
62	25. MUST: New API endpoints need auth. No endpoint without authentication and authorization — not even "internal" endpoints. Exception: documented public-asset / health-check routes that explicitly opt out in code comments.
63	26. MUST: Never put secrets in code. No

People who liked this also viewed

6 picks

Type

tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026501k181k
test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026175k259k
qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026153k259k
webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026120k163k
playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 202664k338

code-quality

17stars3forks

View on GitHub

How to install code-quality?

sordi-ai/skill-everything/code-quality

$npx -y skills add sordi-ai/skill-everything --skill code-quality

Installs into the current project.

Summary

Apply when writing or refactoring code. Generic rules to prevent the most common review comments — function length, naming, error handling, security, and tooling.

Files · 1

View on GitHub

SKILL.md

1	# Sub-Skill: Code Quality & Common Mistakes
2	<!-- target: ~1800 tokens (real tiktoken count, see tools/render_readme_table.py) \| 28 rules with severity classification -->
3
4	Purpose: Prevents the 20 % of mistakes that cause 80 % of review comments. Concrete rules from real projects — no boilerplate.
5
6	## Rule classification
7
8	- MUST — load-bearing. Violating causes bugs, security issues, or cross-team confusion. Never break.
9	- SHOULD — default behavior. Deviation needs a documented reason in the code or PR.
10	- AVOID — usually wrong; documented exception inline where needed.
11
12	Where these rules don't strictly apply: test fixtures, generated code (parser tables, codegen output, schema-derived types), CLI bootstrap scripts, framework adapters, and migration scripts may legitimately differ. The rules below apply to production code paths unless an inline exception says otherwise.
13
14	---
15
16	## Rules
17
18	### Functions & Logic
19
20	1. SHOULD: Functions under ~30 lines. Longer → split where practical. Reduces cognitive load.
21	2. AVOID: Boolean as last argument. `render(true)` is unreadable. Use enum or named-property: `render({ withHeader: true })`.
22	3. SHOULD: Early return over nested if-blocks. Nesting depth > 2 is a warning sign.
23	4. SHOULD: No magic numbers. `if (status === 3)` → `if (status === OrderStatus.SHIPPED)`.
24	5. AVOID: Double negation. `if (!isNotValid)` → `if (isValid)`.
25
26	### Variables & Naming
27
28	6. SHOULD: Variable names describe content, not type. `userList` instead of `arr`, `activeUserId` instead of `id`.
29	7. SHOULD: Temporary variables for complex expressions. `const isEligible = age >= 18 && !isBanned;` instead of cramming it all into an `if`.
30	8. AVOID: Abbreviations except established ones (`id`, `url`, `ctx`, `req`, `res`). `usr`, `cfg`, `tmp` → spell out.
31
32	### Error Handling
33
34	9. MUST: Every `async` call needs `try/catch` or `.catch()`. Unhandled promise rejections crash Node processes.
35	10. MUST: Never silently swallow error objects. `catch (e) {}` is forbidden. At minimum: `logger.warn(e)`.
36	11. MUST: Error messages must include context. `throw new Error('User not found: ' + userId)` not `throw new Error('Not found')`.
37	12. SHOULD: Catch specific exception types, not broad categories. Catch `ConnectionError` not `Exception`. Broad catches mask unrelated bugs and make debugging harder.
38	13. SHOULD: Use exponential backoff with jitter for retry logic. Never retry in a tight loop. Each retry should wait longer than the last with randomization to prevent thundering herds.
39	14. MUST: Never retry non-idempotent operations without explicit safeguards. A retried POST that creates a resource can produce duplicates. Use idempotency keys or check-before-retry patterns.
40	15. SHOULD: Propagate errors with context rather than swallowing and re-raising generic exceptions. Use `raise NewError("context") from original_error` to preserve the chain. Reference: ERR-2026-016.
41
42	### Imports & Dependencies
43
44	16. SHOULD: No circular imports. When in doubt: run `madge --circular src/`.
45	17. SHOULD: External dependencies only in dedicated adapter files. No direct `axios.get()` in business logic — always wrap through an interface.
46	18. MUST: Remove `console.log` before commit. Use a pre-commit hook or linter rule `no-console`. Exception: debug helpers behind a build-time `__DEV__` flag.
47
48	### Tests
49
50	19. MUST: Every new function needs at least one happy-path test. No merge without test coverage for new logic. Exception: pure projection wrappers, single-line getters, and deprecated shims may rely on integration tests.
51
52	### Performance
53
54	20. MUST: No DB queries in loops (N+1 problem). Instead of `for (item of items) { await db.find(item.id) }` → use a JOIN or `WHERE id IN (...)` query.
55	21. MUST: Paginate large datasets. Never `SELECT * FROM table` without `LIMIT`. API endpoints with lists need `?page=` and `?limit=`.
56	22. SHOULD: New `WHERE` clauses need indexes. Before every new query: is there a matching DB index? Without index → full table scan on growing data.
57	23. SHOULD: Lazy loading for heavy operations. Load data only when needed, not "just in case".
58
59	### Security
60
61	24. MUST: Never use user input directly in queries. Always use prepared statements or ORM query builders. Applies to SQL, NoSQL, shell commands, and template engines.
62	25. MUST: New API endpoints need auth. No endpoint without authentication and authorization — not even "internal" endpoints. Exception: documented public-asset / health-check routes that explicitly opt out in code comments.
63	26. MUST: Never put secrets in code. No

People who liked this also viewed

6 picks

Type