context-anchoring

Name: context-anchoring
Author: techygarg

165stars12forks

How to install context-anchoring?

techygarg/lattice/context-anchoring

$npx -y skills add techygarg/lattice --skill context-anchoring

Installs into the current project.

Summary

Manage per-feature living documents that capture decisions, constraints, and reasoning across AI sessions during active development. Scoped to feature-level work — design, implementation, bugfix, refactor — not for codebase-wide assessments or product-wide specifications (those d

Files · 1

View on GitHub

SKILL.md

1	# Context Anchoring
2
3	## Scope
4
5	> Feature-level only — anchors decisions as a feature flows from design → implementation → bugfix → refactor.
6
7	## Config Resolution
8
9	Skill manage dir of per-feature context docs. Resolution order:
10
11	1. Look `.lattice/config.yaml` in repo root
12	2. If found, check `paths.context_base` for custom dir path
13	3. If custom path exist, use that dir for context docs
14	4. If no config/path/path not found, use default `.lattice/context/`
15
16	Each feature get one doc at `<context_base>/<feature-name>.md`. No default principles, no overlay modes, no override files -- just thin template and per-feature docs that grow through enrichment.
17
18	## Problem
19
20	AI no persistent memory. Context decay real: by message 30+, early decisions contradicted, naming inconsistent, "why" evaporate. Damage compound -- forgotten decision become potential contradiction, lost constraint become violation, unresolved question become silent assumption.
21
22	Context anchor docs solve:
23
24	- Feature-bound -- one doc per feature, scoped decisions only
25	- Decision-focused -- capture what, why, what-else-considered for every choice
26	- Append-only -- decisions never removed/rewritten, only added chronologically
27	- Session-spanning -- doc outlive conversation, carry context forward
28	- Git-native -- live in repo, versioned alongside code
29
30	Two docs per feature: requirement doc (static, written upfront, not managed by this skill) and context anchor doc (living, evolving, managed by this skill). Requirement doc define what build. Context anchor doc capture how and why -- decisions, constraints, reasoning that emerge during development.
31
32	The requirement doc may live in this repo, or in whatever system the team already tracks requirements in (Jira, Linear, a wiki) -- this atom never writes to it regardless of where it lives.
33
34	## Document Lifecycle
35
36	Three behaviors govern context anchor doc lifecycle. Each triggered reactively (user ask) or proactively (AI suggest). Both cases, AI always confirm before acting -- propose, user dispose.
37
38	\| Behavior \| Purpose \| Reactive Trigger \| Proactive Trigger \|
39	\|----------\|---------\|-----------------\|-------------------\|
40	\| Create \| Start new context doc \| User ask create one \| AI detect feature work beginning without doc \|
41	\| Load \| Restore context from existing doc \| User ask load/resume \| AI detect existing docs and suggest loading \|
42	\| Enrich \| Add new decision, constraint, resolution \| User ask capture something \| AI detect decision made in conversation \|
43
44	## Status Lifecycle
45
46	Every context doc carries a `status` frontmatter field. Never infer status from body prose.
47
48	\| Value \| Set by \|
49	\|---\|---\|
50	\| `draft` \| `context-anchoring` Create — design not yet complete \|
51	\| `approved` \| `design-blueprint` Step 3 — L1–L4 complete, design reviewed \|
52	\| `complete` \| `code-forge` Step 5 — implementation done \|
53
54	STOP: Check this field before acting on a context doc. `draft` ≠ approved. `approved` ≠ complete. Deviation from approved design: update doc and re-approve — no new status values.
55
56	## Create Behavior
57
58	Always confirm before creating.
59
60	Steps:
61
62	1. Identify feature name. Derive kebab-case filename from feature name (e.g., "User Authentication" → `user-authentication.md`). Confirm name with user.
63	2. Ask about requirement doc. If user has a requirement document, capture it for the `requirement_doc` frontmatter field -- a local file path, or an external reference (URL, ticket ID, or other identifier resolvable via a connected MCP tool). If neither, leave `null`.
64	3. Create dir if `<context_base>/` not already exist.
65	4. Generate from template. Read `./assets/feature-doc-template.md` and fill in:
66	- Frontmatter: `feature`, `requirement_doc`, `created` (today date), `status: draft`
67	- H1 heading: feature name
68	- Summary: one-line description (ask user or derive from context)
69	- If template file not found, generate doc using this minimal structure:
70	```
71	---
72	feature: <feature-name>
73	requirement_doc: <local path, external reference, or null>
74	created: <today's date>
75	status: draft
76	---
77	# <Feature Name>
78	<one-line summary>
79	## Decis

People who liked this also viewed

6 picks

Type

context-anchoring

165stars12forks

View on GitHub

How to install context-anchoring?

techygarg/lattice/context-anchoring

$npx -y skills add techygarg/lattice --skill context-anchoring

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Context Anchoring
2
3	## Scope
4
5	> Feature-level only — anchors decisions as a feature flows from design → implementation → bugfix → refactor.
6
7	## Config Resolution
8
9	Skill manage dir of per-feature context docs. Resolution order:
10
11	1. Look `.lattice/config.yaml` in repo root
12	2. If found, check `paths.context_base` for custom dir path
13	3. If custom path exist, use that dir for context docs
14	4. If no config/path/path not found, use default `.lattice/context/`
15
16	Each feature get one doc at `<context_base>/<feature-name>.md`. No default principles, no overlay modes, no override files -- just thin template and per-feature docs that grow through enrichment.
17
18	## Problem
19
20	AI no persistent memory. Context decay real: by message 30+, early decisions contradicted, naming inconsistent, "why" evaporate. Damage compound -- forgotten decision become potential contradiction, lost constraint become violation, unresolved question become silent assumption.
21
22	Context anchor docs solve:
23
24	- Feature-bound -- one doc per feature, scoped decisions only
25	- Decision-focused -- capture what, why, what-else-considered for every choice
26	- Append-only -- decisions never removed/rewritten, only added chronologically
27	- Session-spanning -- doc outlive conversation, carry context forward
28	- Git-native -- live in repo, versioned alongside code
29
30	Two docs per feature: requirement doc (static, written upfront, not managed by this skill) and context anchor doc (living, evolving, managed by this skill). Requirement doc define what build. Context anchor doc capture how and why -- decisions, constraints, reasoning that emerge during development.
31
32	The requirement doc may live in this repo, or in whatever system the team already tracks requirements in (Jira, Linear, a wiki) -- this atom never writes to it regardless of where it lives.
33
34	## Document Lifecycle
35
36	Three behaviors govern context anchor doc lifecycle. Each triggered reactively (user ask) or proactively (AI suggest). Both cases, AI always confirm before acting -- propose, user dispose.
37
38	\| Behavior \| Purpose \| Reactive Trigger \| Proactive Trigger \|
39	\|----------\|---------\|-----------------\|-------------------\|
40	\| Create \| Start new context doc \| User ask create one \| AI detect feature work beginning without doc \|
41	\| Load \| Restore context from existing doc \| User ask load/resume \| AI detect existing docs and suggest loading \|
42	\| Enrich \| Add new decision, constraint, resolution \| User ask capture something \| AI detect decision made in conversation \|
43
44	## Status Lifecycle
45
46	Every context doc carries a `status` frontmatter field. Never infer status from body prose.
47
48	\| Value \| Set by \|
49	\|---\|---\|
50	\| `draft` \| `context-anchoring` Create — design not yet complete \|
51	\| `approved` \| `design-blueprint` Step 3 — L1–L4 complete, design reviewed \|
52	\| `complete` \| `code-forge` Step 5 — implementation done \|
53
54	STOP: Check this field before acting on a context doc. `draft` ≠ approved. `approved` ≠ complete. Deviation from approved design: update doc and re-approve — no new status values.
55
56	## Create Behavior
57
58	Always confirm before creating.
59
60	Steps:
61
62	1. Identify feature name. Derive kebab-case filename from feature name (e.g., "User Authentication" → `user-authentication.md`). Confirm name with user.
63	2. Ask about requirement doc. If user has a requirement document, capture it for the `requirement_doc` frontmatter field -- a local file path, or an external reference (URL, ticket ID, or other identifier resolvable via a connected MCP tool). If neither, leave `null`.
64	3. Create dir if `<context_base>/` not already exist.
65	4. Generate from template. Read `./assets/feature-doc-template.md` and fill in:
66	- Frontmatter: `feature`, `requirement_doc`, `created` (today date), `status: draft`
67	- H1 heading: feature name
68	- Summary: one-line description (ask user or derive from context)
69	- If template file not found, generate doc using this minimal structure:
70	```
71	---
72	feature: <feature-name>
73	requirement_doc: <local path, external reference, or null>
74	created: <today's date>
75	status: draft
76	---
77	# <Feature Name>
78	<one-line summary>
79	## Decis

People who liked this also viewed

6 picks

Type