clean-code-refiner

Name: clean-code-refiner
Author: techygarg

165stars12forks

How to install clean-code-refiner?

techygarg/lattice/clean-code-refiner

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

Installs into the current project.

Summary

Facilitate a structured conversation to define clean code principles for a repository. Produces a formal clean-code.md document that the clean-code atom will use as its override. Use when setting up coding standards, defining code quality rules, or when the user says 'setup clean

Files · 1

View on GitHub

SKILL.md

1	# Clean Code Refiner
2
3	## What This Produces
4
5	- Output: `.lattice/standards/clean-code.md` (or custom path from `.lattice/config.yaml` -> `paths.clean_code`)
6	- Two modes:
7	- Overlay (`mode: overlay`): A slim document containing only sections that differ from the defaults. The clean-code atom reads its embedded defaults first, then applies this document's sections on top. This is the expected common case.
8	- Override (`mode: override`): A comprehensive standalone document that fully replaces the atom's embedded defaults. For teams with fundamentally different coding standards.
9	- Default mode: Overlay -- produces only what the user wants to change
10	- Config key: `paths.clean_code` in `.lattice/config.yaml`
11	- Template: Read `./assets/template.md` for the full document structure, default content, and interview guidance comments
12
13	## Scope Clarification
14
15	This skill defines the rules of code craftsmanship -- how individual functions, classes, and modules should be written. It does not define architecture (that is the architecture-refiner) or domain modeling (that is the ddd-refiner). The boundaries:
16
17	- Clean code -- function size, naming, complexity, error handling, testability, abstraction discipline
18	- Clean architecture -- layers, dependency direction, command/query flows, structural placement
19	- DDD -- aggregates, entities, value objects, domain events, repository patterns
20
21	## Before You Begin
22
23	### Check for existing documents
24
25	Before starting the interview, check whether a custom document already exists:
26
27	1. Read `.lattice/config.yaml` -- does `paths.clean_code` point to a file?
28	2. If yes, read that file. Ask the user:
29	- "You already have a custom clean code document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it (add new sections)?"
30	- Revise: Load the existing document, walk through only the sections the user wants to change, and update in place.
31	- Start fresh: Proceed with the full interview flow below.
32	- Add to it: Skip to the "New Sections" part of the interview.
33	3. If no config or no existing document, proceed with the full interview flow.
34
35	### Scan the repository
36
37	Look for signals that inform the conversation:
38
39	- Linter configs: ESLint, Pylint, Rubocop, etc. -- what rules are already enforced? What complexity thresholds are configured?
40	- Formatter configs: Prettier, Black, gofmt -- what formatting decisions are already automated?
41	- Existing code style: Are functions generally short or long? Imperative or functional? Heavy on comments or sparse?
42	- Test patterns: What testing framework? Co-located or separate? Mocking patterns?
43	- Language: TypeScript, Python, Go, Java, etc. -- language idioms affect naming conventions and error handling patterns.
44
45	Share relevant findings with the user at the start: "I noticed your project has ESLint configured with max-complexity: 15 and uses Prettier for formatting. I'll use that as context."
46
47	If the project is new with no code, proceed with pure defaults as the starting point.
48
49	## Choosing the Mode
50
51	The first decision in the conversation. Present the three options:
52
53	"How would you like to define your clean code principles?
54
55	1. Customize specific sections (overlay) -- Keep the defaults and change only what differs for your project. This produces a slim document. Most teams choose this.
56	2. Define everything from scratch (override) -- Walk through all sections and produce a comprehensive standalone document.
57	3. Add project-specific sections only (overlay with additions) -- Keep all defaults as-is and add new sections for your team's specific rules.
58
59	The defaults cover standard clean code practices well. Option 1 is recommended unless your coding standards are fundamentally different."
60
61	Map the choice:
62	- Options 1 and 3 -> `mode: overlay`
63	- Option 2 -> `mode: override`
64
65	## Facilitation Approach
66
67	### Conversation style
68
69	- One section at a time. Do not dump all questions at once. Walk through the template sequentially.
70	- Defaults-first. For each section, briefly summarize the default, then ask if it matches. Do not read the entire default verbatim -- summarize the key points and ask.
71	- Record decisions, not discussion. The output document reads as a specification, not meeting notes. "We discussed X and decided Y" is wrong. "Y" is right.
72	- Probe, don't interrogate. Use the probing questions in the template guidance comments as follow-ups when the user's answer is ambiguous,

People who liked this also viewed

6 picks

Type

clean-code-refiner

165stars12forks

View on GitHub

How to install clean-code-refiner?

techygarg/lattice/clean-code-refiner

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Clean Code Refiner
2
3	## What This Produces
4
5	- Output: `.lattice/standards/clean-code.md` (or custom path from `.lattice/config.yaml` -> `paths.clean_code`)
6	- Two modes:
7	- Overlay (`mode: overlay`): A slim document containing only sections that differ from the defaults. The clean-code atom reads its embedded defaults first, then applies this document's sections on top. This is the expected common case.
8	- Override (`mode: override`): A comprehensive standalone document that fully replaces the atom's embedded defaults. For teams with fundamentally different coding standards.
9	- Default mode: Overlay -- produces only what the user wants to change
10	- Config key: `paths.clean_code` in `.lattice/config.yaml`
11	- Template: Read `./assets/template.md` for the full document structure, default content, and interview guidance comments
12
13	## Scope Clarification
14
15	This skill defines the rules of code craftsmanship -- how individual functions, classes, and modules should be written. It does not define architecture (that is the architecture-refiner) or domain modeling (that is the ddd-refiner). The boundaries:
16
17	- Clean code -- function size, naming, complexity, error handling, testability, abstraction discipline
18	- Clean architecture -- layers, dependency direction, command/query flows, structural placement
19	- DDD -- aggregates, entities, value objects, domain events, repository patterns
20
21	## Before You Begin
22
23	### Check for existing documents
24
25	Before starting the interview, check whether a custom document already exists:
26
27	1. Read `.lattice/config.yaml` -- does `paths.clean_code` point to a file?
28	2. If yes, read that file. Ask the user:
29	- "You already have a custom clean code document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it (add new sections)?"
30	- Revise: Load the existing document, walk through only the sections the user wants to change, and update in place.
31	- Start fresh: Proceed with the full interview flow below.
32	- Add to it: Skip to the "New Sections" part of the interview.
33	3. If no config or no existing document, proceed with the full interview flow.
34
35	### Scan the repository
36
37	Look for signals that inform the conversation:
38
39	- Linter configs: ESLint, Pylint, Rubocop, etc. -- what rules are already enforced? What complexity thresholds are configured?
40	- Formatter configs: Prettier, Black, gofmt -- what formatting decisions are already automated?
41	- Existing code style: Are functions generally short or long? Imperative or functional? Heavy on comments or sparse?
42	- Test patterns: What testing framework? Co-located or separate? Mocking patterns?
43	- Language: TypeScript, Python, Go, Java, etc. -- language idioms affect naming conventions and error handling patterns.
44
45	Share relevant findings with the user at the start: "I noticed your project has ESLint configured with max-complexity: 15 and uses Prettier for formatting. I'll use that as context."
46
47	If the project is new with no code, proceed with pure defaults as the starting point.
48
49	## Choosing the Mode
50
51	The first decision in the conversation. Present the three options:
52
53	"How would you like to define your clean code principles?
54
55	1. Customize specific sections (overlay) -- Keep the defaults and change only what differs for your project. This produces a slim document. Most teams choose this.
56	2. Define everything from scratch (override) -- Walk through all sections and produce a comprehensive standalone document.
57	3. Add project-specific sections only (overlay with additions) -- Keep all defaults as-is and add new sections for your team's specific rules.
58
59	The defaults cover standard clean code practices well. Option 1 is recommended unless your coding standards are fundamentally different."
60
61	Map the choice:
62	- Options 1 and 3 -> `mode: overlay`
63	- Option 2 -> `mode: override`
64
65	## Facilitation Approach
66
67	### Conversation style
68
69	- One section at a time. Do not dump all questions at once. Walk through the template sequentially.
70	- Defaults-first. For each section, briefly summarize the default, then ask if it matches. Do not read the entire default verbatim -- summarize the key points and ask.
71	- Record decisions, not discussion. The output document reads as a specification, not meeting notes. "We discussed X and decided Y" is wrong. "Y" is right.
72	- Probe, don't interrogate. Use the probing questions in the template guidance comments as follow-ups when the user's answer is ambiguous,

People who liked this also viewed

6 picks

Type