learning-harvest

Name: learning-harvest
Author: techygarg

165stars12forks

How to install learning-harvest?

techygarg/lattice/learning-harvest

$npx -y skills add techygarg/lattice --skill learning-harvest

Installs into the current project.

Summary

Manage the operational learnings lifecycle — load prior learnings to inform current work, harvest new patterns worth preserving, and keep the document tight over time. Provides a protocol for accumulating actionable patterns from practice that complement standards and defaults. U

Files · 1

View on GitHub

SKILL.md

1	# Learning Harvest
2
3	## Scope Boundary
4
5	Operational learnings are NOT rules. They are what you learn while applying rules.
6
7	\| Standards (refiner output, atom defaults) \| Operational Learnings (this document) \|
8	\|---\|---\|
9	\| "Domain layer must not import from infrastructure" \| "When adding a new aggregate, we keep forgetting to define the repository interface first — design interface before implementation" \|
10	\| "Functions should have single responsibility" \| "Service classes that start small grow past 500 lines within 3 features — split by command type proactively at ~200 lines" \|
11	\| "Value objects must validate in constructor" \| "Date range VOs without explicit inclusive/exclusive documentation cause boundary bugs every time — document semantics alongside validation" \|
12
13	The standard is the rule. The operational learning is what we discovered while applying the rule on this project.
14
15	If an entry reads like a rule that should always be followed, it belongs in a standards document (run the relevant refiner). If it reads like "here's what we keep learning the hard way" or "here's an approach that keeps working for us" — it belongs here.
16
17	Patterns that recur frequently may graduate to standards via a refiner. That promotion path is part of the Tighten behavior.
18
19	## Config Resolution
20
21	1. Check `.lattice/config.yaml` for `paths.operational_learnings`
22	2. If found, use that file path
23	3. If not, use default `.lattice/learnings/operational-learnings.md`
24
25	Backward compatibility: If default path not found, check these legacy paths in order:
26	- `.lattice/learnings.md` — flat file at root
27	- `.lattice/learnings/review-insights.md` — prior naming convention
28
29	If found, offer migration to canonical path and format. If user declines, read as flat input. STOP: do not write to it.
30
31	## Document Structure
32
33	```markdown
34	# Operational Learnings
35
36	Experiential patterns from practice. Complements standards (what should be) with experience (what we keep learning).
37
38	## Design Patterns
39	<!-- Decomposition, architecture choices, scope decisions that proved good or bad -->
40
41	## Implementation Craft
42	<!-- Coding approaches, library gotchas, design-to-reality gaps -->
43
44	## Quality Signals
45	<!-- Recurring quality issues that keep appearing despite rules -->
46
47	## Reliability
48	<!-- Bug root causes, failure modes, fragile areas, boundary condition gaps -->
49
50	## Structural Health
51	<!-- Architectural drift, debt accumulation, coupling issues, migration lessons -->
52	```
53
54	Entry format: `- YYYY-MM-DD [context] Pattern — actionable takeaway`
55
56	- `context`: type of session (e.g., "design", "implementation", "review", "bug fix", "refactoring"). Not a feature name — learnings are cross-cutting.
57	- Each entry ONE bullet, max 2 lines, scannable in under 10 seconds.
58
59	## Load Behavior
60
61	Invoked at session start. Composing workflow passes a focus hint (relevant categories).
62
63	1. Resolve file path per Config Resolution.
64	2. If file not found — "No operational learnings yet." Continue. Non-blocking.
65	3. If found — surface relevant entries (3-5 most recent from matching categories) as brief context. Treat as soft guidance, not hard constraints.
66
67	Active monitoring: Once loaded, maintain a silent harvest queue throughout the session. When a decision or trade-off passes the cross-cutting test below, add it to the queue. STOP: do not prompt immediately.
68
69	Cross-cutting test — a candidate must pass BOTH before queuing:
70	1. It names a pattern or approach, not a feature-specific fact.
71	2. A developer on a completely different feature could apply it without knowing this feature's context.
72
73	STOP: if either fails, skip entirely — do not queue.
74
75	Before queuing, check against entries loaded at session start. If the same pattern already exists — skip.
76
77	When to surface: Surface the queue as a single batch when EITHER condition is true — not at every level or layer:
78	- Queue reaches 3 candidates, OR
79	- A major phase completes (all design levels done, a full implementation layer done)
80
81	STOP: do not surface at every individual level approval or component completion — that is over-prompting. Once surfaced, clear the queue. Anything remaining at session end goes to Harvest.
82
83	> "I noted [N] potential harvest candidates — worth a quick review?"
84
85	Mid-session interrupt (rare exception): surface a single pattern immediately, outside the queue, o

People who liked this also viewed

6 picks

Type

learning-harvest

165stars12forks

View on GitHub

How to install learning-harvest?

techygarg/lattice/learning-harvest

$npx -y skills add techygarg/lattice --skill learning-harvest

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Learning Harvest
2
3	## Scope Boundary
4
5	Operational learnings are NOT rules. They are what you learn while applying rules.
6
7	\| Standards (refiner output, atom defaults) \| Operational Learnings (this document) \|
8	\|---\|---\|
9	\| "Domain layer must not import from infrastructure" \| "When adding a new aggregate, we keep forgetting to define the repository interface first — design interface before implementation" \|
10	\| "Functions should have single responsibility" \| "Service classes that start small grow past 500 lines within 3 features — split by command type proactively at ~200 lines" \|
11	\| "Value objects must validate in constructor" \| "Date range VOs without explicit inclusive/exclusive documentation cause boundary bugs every time — document semantics alongside validation" \|
12
13	The standard is the rule. The operational learning is what we discovered while applying the rule on this project.
14
15	If an entry reads like a rule that should always be followed, it belongs in a standards document (run the relevant refiner). If it reads like "here's what we keep learning the hard way" or "here's an approach that keeps working for us" — it belongs here.
16
17	Patterns that recur frequently may graduate to standards via a refiner. That promotion path is part of the Tighten behavior.
18
19	## Config Resolution
20
21	1. Check `.lattice/config.yaml` for `paths.operational_learnings`
22	2. If found, use that file path
23	3. If not, use default `.lattice/learnings/operational-learnings.md`
24
25	Backward compatibility: If default path not found, check these legacy paths in order:
26	- `.lattice/learnings.md` — flat file at root
27	- `.lattice/learnings/review-insights.md` — prior naming convention
28
29	If found, offer migration to canonical path and format. If user declines, read as flat input. STOP: do not write to it.
30
31	## Document Structure
32
33	```markdown
34	# Operational Learnings
35
36	Experiential patterns from practice. Complements standards (what should be) with experience (what we keep learning).
37
38	## Design Patterns
39	<!-- Decomposition, architecture choices, scope decisions that proved good or bad -->
40
41	## Implementation Craft
42	<!-- Coding approaches, library gotchas, design-to-reality gaps -->
43
44	## Quality Signals
45	<!-- Recurring quality issues that keep appearing despite rules -->
46
47	## Reliability
48	<!-- Bug root causes, failure modes, fragile areas, boundary condition gaps -->
49
50	## Structural Health
51	<!-- Architectural drift, debt accumulation, coupling issues, migration lessons -->
52	```
53
54	Entry format: `- YYYY-MM-DD [context] Pattern — actionable takeaway`
55
56	- `context`: type of session (e.g., "design", "implementation", "review", "bug fix", "refactoring"). Not a feature name — learnings are cross-cutting.
57	- Each entry ONE bullet, max 2 lines, scannable in under 10 seconds.
58
59	## Load Behavior
60
61	Invoked at session start. Composing workflow passes a focus hint (relevant categories).
62
63	1. Resolve file path per Config Resolution.
64	2. If file not found — "No operational learnings yet." Continue. Non-blocking.
65	3. If found — surface relevant entries (3-5 most recent from matching categories) as brief context. Treat as soft guidance, not hard constraints.
66
67	Active monitoring: Once loaded, maintain a silent harvest queue throughout the session. When a decision or trade-off passes the cross-cutting test below, add it to the queue. STOP: do not prompt immediately.
68
69	Cross-cutting test — a candidate must pass BOTH before queuing:
70	1. It names a pattern or approach, not a feature-specific fact.
71	2. A developer on a completely different feature could apply it without knowing this feature's context.
72
73	STOP: if either fails, skip entirely — do not queue.
74
75	Before queuing, check against entries loaded at session start. If the same pattern already exists — skip.
76
77	When to surface: Surface the queue as a single batch when EITHER condition is true — not at every level or layer:
78	- Queue reaches 3 candidates, OR
79	- A major phase completes (all design levels done, a full implementation layer done)
80
81	STOP: do not surface at every individual level approval or component completion — that is over-prompting. Once surfaced, clear the queue. Anything remaining at session end goes to Harvest.
82
83	> "I noted [N] potential harvest candidates — worth a quick review?"
84
85	Mid-session interrupt (rare exception): surface a single pattern immediately, outside the queue, o

People who liked this also viewed

6 picks

Type