architecture-refiner

Name: architecture-refiner
Author: techygarg

165stars12forks

How to install architecture-refiner?

techygarg/lattice/architecture-refiner

$npx -y skills add techygarg/lattice --skill architecture-refiner

Installs into the current project.

Summary

Facilitate a structured conversation to define architecture principles for a repository. Supports multiple architecture styles: clean architecture (default), hexagonal / ports & adapters, modular monolith, or custom. Produces a formal architecture document that the corresponding

Files · 1

View on GitHub

SKILL.md

1	# Architecture Refiner
2
3	## Step 0: Style Selection
4
5	Before anything else, ask the user which architecture style their team uses:
6
7	"What architecture style does your team use?
8
9	1. Clean Architecture (default) — layers (Domain, Application, Interface, Infrastructure), dependency inversion, command/query separation
10	2. Hexagonal / Ports & Adapters — core domain surrounded by ports, adapters on the outside
11	3. Modular Monolith — vertical slices, each module owns its own layers
12	4. Custom / Define from scratch — you describe the layers and rules"
13
14	Branching:
15
16	- Option 1 → proceed to the clean architecture flow below (existing interview). Template: `./assets/template-clean-arch.md`. Output: `.lattice/standards/architecture.md`. Config key: `paths.architecture`. No `architecture_mode` key needed (defaults to `clean`).
17	- Options 2–4 → proceed to the generic architecture flow. Template: `./assets/template-generic.md`. Output: `.lattice/standards/architecture.md`. Config key: `paths.architecture`. Additionally, set `architecture_mode: custom` in `.lattice/config.yaml`.
18
19	The rest of this document describes the clean architecture flow (Option 1). For the generic flow (Options 2–4), read `./assets/template-generic.md` and follow its `<!-- INTERVIEW GUIDANCE: -->` comments. The facilitation approach, conversation style, output assembly, and document quality checks below apply to both flows — substitute the appropriate template, output path, and config key.
20
21	## What This Produces
22
23	For clean architecture (Option 1):
24
25	- Output: `.lattice/standards/architecture.md` (or custom path from `.lattice/config.yaml` → `paths.architecture`)
26	- Two modes:
27	- Overlay (`mode: overlay`): A slim document containing only sections that differ from the defaults. The architecture atom reads its embedded clean-architecture defaults first, then applies this document's sections on top. This is the expected common case.
28	- Override (`mode: override`): A comprehensive standalone document that fully replaces the atom's embedded defaults. For teams that want to define clean architecture from scratch.
29	- Default mode: Overlay -- produces only what the user wants to change
30	- Config key: `paths.architecture` in `.lattice/config.yaml`
31	- Template: Read `./assets/template-clean-arch.md` for the full document structure, default content, and interview guidance comments
32
33	For other styles (Options 2–4):
34
35	- Output: `.lattice/standards/architecture.md` (or custom path from `.lattice/config.yaml` → `paths.architecture`)
36	- Mode: Always `override` — there are no embedded defaults to overlay onto for non-clean-architecture styles
37	- Config key: `paths.architecture` in `.lattice/config.yaml`
38	- Additional config: Sets `architecture_mode: custom` in `.lattice/config.yaml`
39	- Template: Read `./assets/template-generic.md` for the document structure and interview guidance comments
40
41	## Before You Begin
42
43	### Check for existing documents
44
45	Before starting the interview, check whether a custom document already exists:
46
47	1. Read `.lattice/config.yaml` — check `paths.architecture`.
48	2. If the relevant path exists (based on the style selected in Step 0), read that file. Ask the user:
49	- "You already have a custom architecture document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it (add new sections)?"
50	- Revise: Load the existing document, walk through only the sections the user wants to change, and update in place.
51	- Start fresh: Proceed with the full interview flow below.
52	- Add to it: Skip to the "New Sections" part of the interview.
53	3. If no config or no existing document, proceed with the full interview flow.
54
55	### Scan the repository
56
57	Look for signals that inform the conversation:
58
59	- Directory structure: Does `src/` (or equivalent) already have layers? What are they named?
60	- Existing patterns: Are there existing controllers, services, repositories, providers? What naming conventions are in use?
61	- DI patterns: Is there a DI container, manual injection, or framework-provided injection?
62	- Architecture docs: Any existing architecture documentation (ADRs, README sections)?
63	- Framework: What framework is in use? (NestJS, Spring, Django, etc.) This affects naming conventions and

People who liked this also viewed

6 picks

Type

architecture-refiner

165stars12forks

View on GitHub

How to install architecture-refiner?

techygarg/lattice/architecture-refiner

$npx -y skills add techygarg/lattice --skill architecture-refiner

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Architecture Refiner
2
3	## Step 0: Style Selection
4
5	Before anything else, ask the user which architecture style their team uses:
6
7	"What architecture style does your team use?
8
9	1. Clean Architecture (default) — layers (Domain, Application, Interface, Infrastructure), dependency inversion, command/query separation
10	2. Hexagonal / Ports & Adapters — core domain surrounded by ports, adapters on the outside
11	3. Modular Monolith — vertical slices, each module owns its own layers
12	4. Custom / Define from scratch — you describe the layers and rules"
13
14	Branching:
15
16	- Option 1 → proceed to the clean architecture flow below (existing interview). Template: `./assets/template-clean-arch.md`. Output: `.lattice/standards/architecture.md`. Config key: `paths.architecture`. No `architecture_mode` key needed (defaults to `clean`).
17	- Options 2–4 → proceed to the generic architecture flow. Template: `./assets/template-generic.md`. Output: `.lattice/standards/architecture.md`. Config key: `paths.architecture`. Additionally, set `architecture_mode: custom` in `.lattice/config.yaml`.
18
19	The rest of this document describes the clean architecture flow (Option 1). For the generic flow (Options 2–4), read `./assets/template-generic.md` and follow its `<!-- INTERVIEW GUIDANCE: -->` comments. The facilitation approach, conversation style, output assembly, and document quality checks below apply to both flows — substitute the appropriate template, output path, and config key.
20
21	## What This Produces
22
23	For clean architecture (Option 1):
24
25	- Output: `.lattice/standards/architecture.md` (or custom path from `.lattice/config.yaml` → `paths.architecture`)
26	- Two modes:
27	- Overlay (`mode: overlay`): A slim document containing only sections that differ from the defaults. The architecture atom reads its embedded clean-architecture defaults first, then applies this document's sections on top. This is the expected common case.
28	- Override (`mode: override`): A comprehensive standalone document that fully replaces the atom's embedded defaults. For teams that want to define clean architecture from scratch.
29	- Default mode: Overlay -- produces only what the user wants to change
30	- Config key: `paths.architecture` in `.lattice/config.yaml`
31	- Template: Read `./assets/template-clean-arch.md` for the full document structure, default content, and interview guidance comments
32
33	For other styles (Options 2–4):
34
35	- Output: `.lattice/standards/architecture.md` (or custom path from `.lattice/config.yaml` → `paths.architecture`)
36	- Mode: Always `override` — there are no embedded defaults to overlay onto for non-clean-architecture styles
37	- Config key: `paths.architecture` in `.lattice/config.yaml`
38	- Additional config: Sets `architecture_mode: custom` in `.lattice/config.yaml`
39	- Template: Read `./assets/template-generic.md` for the document structure and interview guidance comments
40
41	## Before You Begin
42
43	### Check for existing documents
44
45	Before starting the interview, check whether a custom document already exists:
46
47	1. Read `.lattice/config.yaml` — check `paths.architecture`.
48	2. If the relevant path exists (based on the style selected in Step 0), read that file. Ask the user:
49	- "You already have a custom architecture document. Would you like to revise it (update specific sections), start fresh (new interview), or add to it (add new sections)?"
50	- Revise: Load the existing document, walk through only the sections the user wants to change, and update in place.
51	- Start fresh: Proceed with the full interview flow below.
52	- Add to it: Skip to the "New Sections" part of the interview.
53	3. If no config or no existing document, proceed with the full interview flow.
54
55	### Scan the repository
56
57	Look for signals that inform the conversation:
58
59	- Directory structure: Does `src/` (or equivalent) already have layers? What are they named?
60	- Existing patterns: Are there existing controllers, services, repositories, providers? What naming conventions are in use?
61	- DI patterns: Is there a DI container, manual injection, or framework-provided injection?
62	- Architecture docs: Any existing architecture documentation (ADRs, README sections)?
63	- Framework: What framework is in use? (NestJS, Spring, Django, etc.) This affects naming conventions and

People who liked this also viewed

6 picks

Type