clean-code

Name: clean-code
Author: techygarg

165stars12forks

How to install clean-code?

techygarg/lattice/clean-code

$npx -y skills add techygarg/lattice --skill clean-code

Installs into the current project.

Summary

Apply clean code principles when generating or modifying implementation code. Enforces function focus, naming clarity, complexity management, error handling, and self-documenting style. Use during code generation, refactoring, or when the user mentions 'clean code', 'code quality

Files · 1

View on GitHub

SKILL.md

1	# Clean Code
2
3	## Config Resolution
4
5	Skill support project custom. Order:
6
7	1. Look `.lattice/config.yaml` in repo root
8	2. If found, check `paths.clean_code` for custom doc path
9	3. If custom path exist, read doc and check YAML frontmatter for `mode`:
10	- `mode: override` (or no mode): Custom doc full precedence. Use instead embedded default. Must be comprehensive -- sole reference.
11	- `mode: overlay`: Read embedded `./references/defaults.md` first, then apply custom doc sections on top. Custom sections replace matching sections in default (matched by heading). New sections appended after default.
12	4. If no config/path/file, read `./references/defaults.md`
13	5. Language adaptation: If `paths.language_idioms` exist in config, read that document and adapt defaults using these sections:
14	- "Error Handling" → adapt §8 (Error Handling) patterns to language idioms. Language idioms take precedence over pseudocode defaults.
15	- "Type System & Object Model" → adapt §1 (Single Responsibility) cohesion guidance to language constructs (e.g., struct vs class).
16	- "Naming Conventions" → adapt §4 (Meaningful Naming) patterns to language conventions.
17	- "Parameter & Function Design" → adapt §2 (Small, Focused Functions) and §5 (Parameter Design) to language capabilities.
18	- "Dependency Management" → adapt §9 (Test-Friendly Code) DI patterns to language idioms.
19
20	## Self-Validation Checklist
21
22	STOP after each component. Verify ALL. Fix any failed check before presenting. Judgment calls → flag with options (see Ambiguity Signals).
23
24	1. SINGLE RESPONSIBILITY: Describe each function without "and"? If not → extract separate function.
25	2. SIZE: Each function under size threshold per loaded doc (~20 lines default)? If not → extract sub-operation into named function.
26	3. COMPLEXITY: Cyclomatic complexity under threshold per loaded doc (~10 default)? If not → flatten with guard clause, extract branch.
27	4. ABSTRACTION LEVEL: Each function operate at one level? If high-level mixed with low-level → extract detail.
28	5. NAMING: Function/variable name reveal intent without context? If not → rename self-documenting.
29	6. PARAMETERS: Parameter count under threshold per loaded doc (4 default)? If not → group into object.
30	7. PRIMITIVE OBSESSION: String/number/boolean clearer as named type? If so → introduce parameter object or typed wrapper.
31	8. ERROR HANDLING: Every fail-able operation have explicit handling with actionable message? Handled at right level?
32
33	Project-specific checks: If loaded doc (from Config Resolution) contains a Validation Checklist section (§10), apply those checks as additional project-specific validation after the checklist above.
34
35	## Active Anti-Pattern Scan
36
37	After checklist, scan for these. If find, fix before present.
38
39	- [ ] God Function: Function exceed ~30 lines doing multiple thing; description need "and" → extract focused function
40	- [ ] Deep Nesting: Three+ level indentation → flatten with early return/guard clause
41	- [ ] Cryptic Naming: Variable like `d`, `tmp2`, `processData` → rename reveal intent
42	- [ ] Long Parameter Lists: Five+ parameter → group into object or split function
43	- [ ] Premature Abstraction: Utility extracted from only two similar block → inline until Rule of Three with same reason to change
44	- [ ] Swallowed Errors: Empty catch, generic "something went wrong," silently return null → handle explicitly
45	- [ ] Comments as Deodorant: Comment explain convoluted code instead refactor → rename self-documenting; keep only "why" comment, remove "what"
46	- [ ] Hidden Side Effects: Function named `getX` also write cache/send notification → rename or separate
47	- [ ] Dead Code: Commented-out block, unused import, unreachable branch → delete (version control preserve)
48	- [ ] Untestable Logic: Side effect tangled with business logic; unit test need mock I/O → push side effect to boundary, extract pure function, inject dependency
49
50	## Ambiguity Signals
51
52	Multiple valid outcome. Present option rather than silently choose. See `./references/defaults.md` for resolution guidance on each signal below.
53
54	- Single Responsibility: Two tightly-coupled sequential operation may be one responsibility (pipeline), not two. "And" test catch true violation AND false positive.
55	-

People who liked this also viewed

6 picks

Type

clean-code

165stars12forks

View on GitHub

How to install clean-code?

techygarg/lattice/clean-code

$npx -y skills add techygarg/lattice --skill clean-code

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Clean Code
2
3	## Config Resolution
4
5	Skill support project custom. Order:
6
7	1. Look `.lattice/config.yaml` in repo root
8	2. If found, check `paths.clean_code` for custom doc path
9	3. If custom path exist, read doc and check YAML frontmatter for `mode`:
10	- `mode: override` (or no mode): Custom doc full precedence. Use instead embedded default. Must be comprehensive -- sole reference.
11	- `mode: overlay`: Read embedded `./references/defaults.md` first, then apply custom doc sections on top. Custom sections replace matching sections in default (matched by heading). New sections appended after default.
12	4. If no config/path/file, read `./references/defaults.md`
13	5. Language adaptation: If `paths.language_idioms` exist in config, read that document and adapt defaults using these sections:
14	- "Error Handling" → adapt §8 (Error Handling) patterns to language idioms. Language idioms take precedence over pseudocode defaults.
15	- "Type System & Object Model" → adapt §1 (Single Responsibility) cohesion guidance to language constructs (e.g., struct vs class).
16	- "Naming Conventions" → adapt §4 (Meaningful Naming) patterns to language conventions.
17	- "Parameter & Function Design" → adapt §2 (Small, Focused Functions) and §5 (Parameter Design) to language capabilities.
18	- "Dependency Management" → adapt §9 (Test-Friendly Code) DI patterns to language idioms.
19
20	## Self-Validation Checklist
21
22	STOP after each component. Verify ALL. Fix any failed check before presenting. Judgment calls → flag with options (see Ambiguity Signals).
23
24	1. SINGLE RESPONSIBILITY: Describe each function without "and"? If not → extract separate function.
25	2. SIZE: Each function under size threshold per loaded doc (~20 lines default)? If not → extract sub-operation into named function.
26	3. COMPLEXITY: Cyclomatic complexity under threshold per loaded doc (~10 default)? If not → flatten with guard clause, extract branch.
27	4. ABSTRACTION LEVEL: Each function operate at one level? If high-level mixed with low-level → extract detail.
28	5. NAMING: Function/variable name reveal intent without context? If not → rename self-documenting.
29	6. PARAMETERS: Parameter count under threshold per loaded doc (4 default)? If not → group into object.
30	7. PRIMITIVE OBSESSION: String/number/boolean clearer as named type? If so → introduce parameter object or typed wrapper.
31	8. ERROR HANDLING: Every fail-able operation have explicit handling with actionable message? Handled at right level?
32
33	Project-specific checks: If loaded doc (from Config Resolution) contains a Validation Checklist section (§10), apply those checks as additional project-specific validation after the checklist above.
34
35	## Active Anti-Pattern Scan
36
37	After checklist, scan for these. If find, fix before present.
38
39	- [ ] God Function: Function exceed ~30 lines doing multiple thing; description need "and" → extract focused function
40	- [ ] Deep Nesting: Three+ level indentation → flatten with early return/guard clause
41	- [ ] Cryptic Naming: Variable like `d`, `tmp2`, `processData` → rename reveal intent
42	- [ ] Long Parameter Lists: Five+ parameter → group into object or split function
43	- [ ] Premature Abstraction: Utility extracted from only two similar block → inline until Rule of Three with same reason to change
44	- [ ] Swallowed Errors: Empty catch, generic "something went wrong," silently return null → handle explicitly
45	- [ ] Comments as Deodorant: Comment explain convoluted code instead refactor → rename self-documenting; keep only "why" comment, remove "what"
46	- [ ] Hidden Side Effects: Function named `getX` also write cache/send notification → rename or separate
47	- [ ] Dead Code: Commented-out block, unused import, unreachable branch → delete (version control preserve)
48	- [ ] Untestable Logic: Side effect tangled with business logic; unit test need mock I/O → push side effect to boundary, extract pure function, inject dependency
49
50	## Ambiguity Signals
51
52	Multiple valid outcome. Present option rather than silently choose. See `./references/defaults.md` for resolution guidance on each signal below.
53
54	- Single Responsibility: Two tightly-coupled sequential operation may be one responsibility (pipeline), not two. "And" test catch true violation AND false positive.
55	-

People who liked this also viewed

6 picks

Type