@zigrivers/scaffold 2.1.2 → 2.28.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (97) hide show
  1. package/README.md +272 -59
  2. package/knowledge/core/adr-craft.md +53 -0
  3. package/knowledge/core/ai-memory-management.md +246 -0
  4. package/knowledge/core/api-design.md +4 -0
  5. package/knowledge/core/claude-md-patterns.md +254 -0
  6. package/knowledge/core/coding-conventions.md +246 -0
  7. package/knowledge/core/database-design.md +4 -0
  8. package/knowledge/core/design-system-tokens.md +465 -0
  9. package/knowledge/core/dev-environment.md +223 -0
  10. package/knowledge/core/domain-modeling.md +4 -0
  11. package/knowledge/core/eval-craft.md +1008 -0
  12. package/knowledge/core/multi-model-review-dispatch.md +250 -0
  13. package/knowledge/core/operations-runbook.md +37 -226
  14. package/knowledge/core/project-structure-patterns.md +231 -0
  15. package/knowledge/core/review-step-template.md +247 -0
  16. package/knowledge/core/{security-review.md → security-best-practices.md} +5 -1
  17. package/knowledge/core/task-decomposition.md +57 -34
  18. package/knowledge/core/task-tracking.md +225 -0
  19. package/knowledge/core/tech-stack-selection.md +214 -0
  20. package/knowledge/core/testing-strategy.md +63 -70
  21. package/knowledge/core/user-stories.md +69 -60
  22. package/knowledge/core/user-story-innovation.md +57 -0
  23. package/knowledge/core/ux-specification.md +5 -148
  24. package/knowledge/finalization/apply-fixes-and-freeze.md +165 -14
  25. package/knowledge/product/prd-craft.md +55 -34
  26. package/knowledge/review/review-adr.md +32 -0
  27. package/knowledge/review/{review-api-contracts.md → review-api-design.md} +34 -1
  28. package/knowledge/review/{review-database-schema.md → review-database-design.md} +27 -1
  29. package/knowledge/review/review-domain-modeling.md +33 -0
  30. package/knowledge/review/review-implementation-tasks.md +50 -0
  31. package/knowledge/review/review-operations.md +55 -0
  32. package/knowledge/review/review-prd.md +33 -0
  33. package/knowledge/review/review-security.md +53 -0
  34. package/knowledge/review/review-system-architecture.md +28 -0
  35. package/knowledge/review/review-testing-strategy.md +51 -0
  36. package/knowledge/review/review-user-stories.md +54 -0
  37. package/knowledge/review/{review-ux-spec.md → review-ux-specification.md} +37 -1
  38. package/methodology/custom-defaults.yml +32 -3
  39. package/methodology/deep.yml +32 -3
  40. package/methodology/mvp.yml +32 -3
  41. package/package.json +2 -1
  42. package/pipeline/architecture/review-architecture.md +18 -6
  43. package/pipeline/architecture/system-architecture.md +14 -2
  44. package/pipeline/consolidation/claude-md-optimization.md +73 -0
  45. package/pipeline/consolidation/workflow-audit.md +73 -0
  46. package/pipeline/decisions/adrs.md +14 -2
  47. package/pipeline/decisions/review-adrs.md +18 -5
  48. package/pipeline/environment/ai-memory-setup.md +70 -0
  49. package/pipeline/environment/automated-pr-review.md +70 -0
  50. package/pipeline/environment/design-system.md +73 -0
  51. package/pipeline/environment/dev-env-setup.md +65 -0
  52. package/pipeline/environment/git-workflow.md +71 -0
  53. package/pipeline/finalization/apply-fixes-and-freeze.md +1 -1
  54. package/pipeline/finalization/developer-onboarding-guide.md +1 -1
  55. package/pipeline/finalization/implementation-playbook.md +3 -3
  56. package/pipeline/foundation/beads.md +68 -0
  57. package/pipeline/foundation/coding-standards.md +68 -0
  58. package/pipeline/foundation/project-structure.md +69 -0
  59. package/pipeline/foundation/tdd.md +60 -0
  60. package/pipeline/foundation/tech-stack.md +74 -0
  61. package/pipeline/integration/add-e2e-testing.md +65 -0
  62. package/pipeline/modeling/domain-modeling.md +14 -2
  63. package/pipeline/modeling/review-domain-modeling.md +18 -5
  64. package/pipeline/parity/platform-parity-review.md +70 -0
  65. package/pipeline/planning/implementation-plan-review.md +56 -0
  66. package/pipeline/planning/{implementation-tasks.md → implementation-plan.md} +29 -9
  67. package/pipeline/pre/create-prd.md +13 -4
  68. package/pipeline/pre/innovate-prd.md +37 -8
  69. package/pipeline/pre/innovate-user-stories.md +38 -7
  70. package/pipeline/pre/review-prd.md +18 -6
  71. package/pipeline/pre/review-user-stories.md +23 -6
  72. package/pipeline/pre/user-stories.md +12 -2
  73. package/pipeline/quality/create-evals.md +102 -0
  74. package/pipeline/quality/operations.md +38 -13
  75. package/pipeline/quality/review-operations.md +17 -5
  76. package/pipeline/quality/review-security.md +17 -5
  77. package/pipeline/quality/review-testing.md +20 -8
  78. package/pipeline/quality/security.md +25 -3
  79. package/pipeline/quality/story-tests.md +73 -0
  80. package/pipeline/specification/api-contracts.md +17 -2
  81. package/pipeline/specification/database-schema.md +17 -2
  82. package/pipeline/specification/review-api.md +18 -6
  83. package/pipeline/specification/review-database.md +18 -6
  84. package/pipeline/specification/review-ux.md +19 -7
  85. package/pipeline/specification/ux-spec.md +29 -10
  86. package/pipeline/validation/critical-path-walkthrough.md +34 -7
  87. package/pipeline/validation/cross-phase-consistency.md +34 -7
  88. package/pipeline/validation/decision-completeness.md +34 -7
  89. package/pipeline/validation/dependency-graph-validation.md +34 -7
  90. package/pipeline/validation/implementability-dry-run.md +34 -7
  91. package/pipeline/validation/scope-creep-check.md +34 -7
  92. package/pipeline/validation/traceability-matrix.md +34 -7
  93. package/skills/multi-model-dispatch/SKILL.md +326 -0
  94. package/skills/scaffold-pipeline/SKILL.md +195 -0
  95. package/skills/scaffold-runner/SKILL.md +465 -0
  96. package/pipeline/planning/review-tasks.md +0 -38
  97. package/pipeline/quality/testing-strategy.md +0 -42
@@ -0,0 +1,246 @@
1
+ ---
2
+ name: ai-memory-management
3
+ description: AI memory and context management patterns for Claude Code projects including modular rules, MCP memory servers, lifecycle hooks, decision logging, and external context integration
4
+ topics: [ai-memory, claude-code, claude-rules, mcp-servers, lifecycle-hooks, context-management, session-handoff, decision-logging, mcp-knowledge-graph, context7]
5
+ ---
6
+
7
+ # AI Memory Management
8
+
9
+ AI coding agents forget everything between sessions. Memory management is the practice of making that forgetting graceful — ensuring the right context is available at the right time without drowning the agent in irrelevant information. This knowledge covers the full spectrum from lightweight rule files to persistent memory servers.
10
+
11
+ ## Summary
12
+
13
+ ### The Memory Hierarchy
14
+
15
+ AI memory operates in layers, each with different persistence and token cost:
16
+
17
+ | Layer | Persistence | Token Cost | Examples |
18
+ |-------|------------|------------|----------|
19
+ | **Context window** | Current session only | High (1:1) | Files read, conversation history |
20
+ | **CLAUDE.md / rules** | Permanent (git-tracked) | Medium (loaded at start) | Conventions, commands, workflow |
21
+ | **Auto-memory** | Cross-session (local) | Low (loaded on demand) | User preferences, project patterns |
22
+ | **MCP memory server** | Cross-session (structured) | Low (queried on demand) | Decisions, lessons, error patterns |
23
+ | **External docs** | Always current | Zero until queried | Library APIs, framework docs |
24
+
25
+ ### Core Principle: Signal Over Volume
26
+
27
+ ETH Zurich research (2026) found that dumping context into AI sessions hurts more than it helps — 3% performance decrease with 20% cost increase for LLM-generated context files. The key insight: **only store what cannot be derived from the code itself.** Custom build commands, project-specific conventions, decision rationale, and team agreements are high-signal. Code patterns, file structure, and API shapes are low-signal (the agent can read the code).
28
+
29
+ ### The Three-Tier Memory Stack
30
+
31
+ **Tier 1 — Modular Rules** (`.claude/rules/`): Path-scoped convention files loaded automatically based on what files the agent is working with. Zero manual effort after setup. Keeps CLAUDE.md lean.
32
+
33
+ **Tier 2 — Persistent Memory** (MCP server + hooks): Structured cross-session memory that captures decisions, lessons, and error patterns automatically via lifecycle hooks. Survives session boundaries.
34
+
35
+ **Tier 3 — External Context** (library doc servers): Version-specific documentation for project dependencies, queried on demand. Prevents API hallucination.
36
+
37
+ ## Deep Guidance
38
+
39
+ ### Tier 1: Modular Rules
40
+
41
+ #### `.claude/rules/` Architecture
42
+
43
+ Claude Code loads rule files from `.claude/rules/` based on path-scoping defined in YAML frontmatter. This replaces the pattern of stuffing everything into CLAUDE.md.
44
+
45
+ **File structure:**
46
+ ```
47
+ .claude/
48
+ rules/
49
+ code-style.md # Always active — naming, formatting, imports
50
+ testing.md # Active when working in test files
51
+ api-endpoints.md # Active when working in API route files
52
+ database.md # Active when working with schema/migration files
53
+ frontend.md # Active when working in UI component files
54
+ memory-hygiene.md # Always active — what to save/not save in memory
55
+ ```
56
+
57
+ **Rule file format:**
58
+ ```markdown
59
+ ---
60
+ description: TypeScript naming and import conventions
61
+ globs: ["src/**/*.ts", "src/**/*.tsx"]
62
+ ---
63
+
64
+ - Use camelCase for variables/functions, PascalCase for types/classes
65
+ - Import order: external packages, then internal modules, then relative imports
66
+ - Prefer named exports over default exports
67
+ ```
68
+
69
+ **Key principles:**
70
+ - Each rule file targets a specific concern and file pattern
71
+ - Rules activate only when the agent works on matching files — no wasted tokens
72
+ - Total rule content across all files should stay under 500 lines
73
+ - Rules state what to do differently from defaults — don't restate obvious conventions
74
+ - Extract rules from existing docs (coding-standards.md, tech-stack.md, git-workflow.md) rather than writing from scratch
75
+
76
+ #### CLAUDE.md Optimization
77
+
78
+ After creating rules, CLAUDE.md should use the pointer pattern:
79
+
80
+ ```markdown
81
+ ## Coding Conventions
82
+ See `docs/coding-standards.md` for full reference. Key rules in `.claude/rules/code-style.md`.
83
+ ```
84
+
85
+ This replaces inline convention blocks, keeping CLAUDE.md under 200 lines (the empirically-validated adherence threshold).
86
+
87
+ ### Tier 2: Persistent Memory
88
+
89
+ #### MCP Memory Servers
90
+
91
+ **Recommended: MCP Knowledge Graph** (`@modelcontextprotocol/server-memory`)
92
+ - Official MCP server from the Model Context Protocol project
93
+ - Stores entities, relations, and observations in a local JSON file
94
+ - Zero setup: `npx -y @modelcontextprotocol/server-memory`
95
+ - Entities persist across sessions — decisions, patterns, project facts
96
+ - Best for: All projects (stable, official, zero dependencies beyond Node)
97
+
98
+ **Alternative: Custom MCP server**
99
+ - If the user has a preferred MCP memory server already installed, use it
100
+ - The key requirement is that it exposes MCP tools for storing and retrieving structured memory
101
+ - Examples from the ecosystem: Engram (if installed), hmem (if installed), ContextVault
102
+
103
+ **Configuration pattern** (`.claude/settings.json`):
104
+ ```json
105
+ {
106
+ "mcpServers": {
107
+ "memory": {
108
+ "command": "npx",
109
+ "args": ["-y", "@modelcontextprotocol/server-memory"],
110
+ "env": {
111
+ "MEMORY_FILE_PATH": ".claude/memory-graph.json"
112
+ }
113
+ }
114
+ }
115
+ }
116
+ ```
117
+
118
+ #### Lifecycle Hooks
119
+
120
+ Hooks automate memory capture at key session events:
121
+
122
+ **PreCompact** (highest value) — Triggers before context compression. Logs when compaction occurs for debugging context loss.
123
+
124
+ ```json
125
+ {
126
+ "hooks": {
127
+ "PreCompact": [{
128
+ "type": "command",
129
+ "command": "echo \"$(date '+%Y-%m-%d %H:%M:%S') — Context compacting\" >> .claude/compaction-log.txt",
130
+ "timeout": 5000
131
+ }]
132
+ }
133
+ }
134
+ ```
135
+
136
+ File-logging for compaction events:
137
+ ```json
138
+ {
139
+ "hooks": {
140
+ "PreCompact": [{
141
+ "type": "command",
142
+ "command": "date '+%Y-%m-%d %H:%M' >> .claude/compaction-log.txt && echo 'Context compacted' >> .claude/compaction-log.txt",
143
+ "timeout": 5000
144
+ }]
145
+ }
146
+ }
147
+ ```
148
+
149
+ **Stop** — Triggers when a session ends. Good for capturing session-level summaries.
150
+
151
+ **PreToolUse** — Triggers before tool calls. Can log decisions about file modifications. Use sparingly — high frequency means high overhead.
152
+
153
+ **Hook selection guidance:**
154
+ - Start with PreCompact only — it captures the most value with least noise
155
+ - Hook commands must produce a side effect (write to MCP server, append to file) — echoing to `/dev/null` provides zero value
156
+ - Add Stop if sessions frequently end with unrecorded decisions
157
+ - Avoid PreToolUse unless you have a specific logging need — it fires constantly
158
+
159
+ #### Decision Logging
160
+
161
+ Decisions are the highest-value memory type because they cannot be derived from code. A decision log captures what was chosen, what was rejected, and why.
162
+
163
+ **Structure:**
164
+ ```
165
+ docs/decisions/
166
+ DECISIONS.md # Index of all decisions
167
+ 001-auth-strategy.md # Individual decision records
168
+ 002-database-choice.md
169
+ ```
170
+
171
+ **Decision entry format:**
172
+ ```markdown
173
+ ## DEC-001: JWT over session cookies for auth
174
+
175
+ **Date:** 2026-03-27
176
+ **Context:** Need stateless auth for API-first architecture
177
+ **Decision:** Use JWT with short-lived access tokens + refresh tokens
178
+ **Rejected:** Session cookies (requires sticky sessions), OAuth-only (too complex for MVP)
179
+ **Consequences:** Need token refresh logic in frontend, need secure token storage
180
+ ```
181
+
182
+ This complements ADRs (which cover architecture-level decisions) by capturing day-to-day implementation decisions that would otherwise be lost between sessions.
183
+
184
+ #### Session Handoff Patterns
185
+
186
+ When context hits limits, structured handoff preserves continuity:
187
+
188
+ 1. **Before compaction**: Save current task state, open questions, and recent decisions
189
+ 2. **After compaction**: Claude Code auto-reloads CLAUDE.md and auto-memory, but loses working context
190
+ 3. **Recovery**: Agent reads decision log and memory server to reconstruct working state
191
+
192
+ The `/compact` command is the natural handoff point. A PreCompact hook that saves session state ensures nothing critical is lost.
193
+
194
+ ### Tier 3: External Context
195
+
196
+ #### Library Documentation Servers
197
+
198
+ AI agents hallucinate APIs — they generate plausible but incorrect function signatures, especially for rapidly-evolving libraries. External doc servers solve this by providing current, version-specific documentation on demand.
199
+
200
+ **Context7** (by Upstash) — Most popular, fetches current library docs via MCP
201
+ - Covers major frameworks (React, Next.js, Vue, Angular, etc.)
202
+ - Free tier: 1,000 requests/month
203
+ - Caution: had a security vulnerability (patched) — review before enabling
204
+
205
+ **Nia** (by Nozomio) — Indexes codebases + 3,000+ pre-indexed packages
206
+ - Cross-session context persistence
207
+ - Deep research agent for complex questions
208
+ - Y Combinator backed, more comprehensive than Context7
209
+
210
+ **Docfork** — 9,000+ libraries, MIT license
211
+ - "Cabinets" for project-specific documentation isolation
212
+ - Self-hostable
213
+
214
+ **Configuration pattern:**
215
+ ```json
216
+ {
217
+ "mcpServers": {
218
+ "context7": {
219
+ "command": "npx",
220
+ "args": ["-y", "@upstash/context7-mcp@latest"]
221
+ }
222
+ }
223
+ }
224
+ ```
225
+
226
+ **When to enable:** Projects with 3+ external dependencies, especially rapidly-evolving frameworks (React, Next.js, Svelte). Skip for standard library-only projects or well-established stable APIs.
227
+
228
+ ### Anti-Patterns
229
+
230
+ | Anti-Pattern | Why It Fails | Instead |
231
+ |-------------|-------------|---------|
232
+ | Dumping entire codebase into context | Drowns signal in noise, costs tokens | Let the agent read files on demand |
233
+ | Storing code patterns in memory | Duplicates what's in the code; goes stale | Store decisions and rationale only |
234
+ | Huge CLAUDE.md (500+ lines) | Adherence drops sharply above 200 lines | Use .claude/rules/ for specifics |
235
+ | Memory without structure | Unstructured notes become unsearchable noise | Use categories (decision, lesson, error) |
236
+ | Capturing everything | Token cost with diminishing returns | Capture what can't be derived from code |
237
+ | Multiple overlapping memory tools | Conflicting context, duplicated entries | Pick one MCP server, use it consistently |
238
+
239
+ ### Integration with Beads
240
+
241
+ When Beads is configured, memory complements task tracking:
242
+ - **Beads** tracks what work to do (tasks, dependencies, status)
243
+ - **Memory** tracks how to do work better (patterns, decisions, lessons)
244
+ - Decision log entries can reference Beads task IDs for traceability
245
+ - `tasks/lessons.md` remains the cross-session learning file; MCP memory adds structured queryability
246
+ - Don't duplicate: if a pattern is in `tasks/lessons.md`, don't also store it in the MCP server
@@ -499,3 +499,7 @@ Design APIs so that transient failures can be safely retried:
499
499
  **Missing rate limiting.** No protection against abusive or buggy clients sending excessive requests. Fix: implement rate limiting on all public endpoints. Return 429 with `Retry-After` header.
500
500
 
501
501
  **Ignoring CORS.** Frontend can't call the API because CORS headers are missing. Fix: configure CORS at API design time. Be specific about allowed origins — don't use `*` in production.
502
+
503
+ ## See Also
504
+
505
+ - [testing-strategy](../core/testing-strategy.md) — Contract testing and API test patterns
@@ -0,0 +1,254 @@
1
+ ---
2
+ name: claude-md-patterns
3
+ description: Patterns for structuring CLAUDE.md files including section organization, rule authoring, pointer patterns, and merge strategies
4
+ topics: [claude-md, ai-configuration, rule-files, memory-management, project-setup]
5
+ ---
6
+
7
+ # CLAUDE.md Patterns
8
+
9
+ CLAUDE.md is the primary instruction file for AI coding agents. It is loaded at the start of every session and defines how the agent should behave within a project. A well-structured CLAUDE.md dramatically improves agent adherence; a poorly structured one gets ignored or causes conflicts. This knowledge covers structure, authoring, the pointer pattern, and the merge strategy for multi-step pipeline updates.
10
+
11
+ ## Summary
12
+
13
+ ### Purpose
14
+
15
+ CLAUDE.md is a project-level instruction file that AI agents (Claude Code, Codex, etc.) read at session start. It answers three questions:
16
+ 1. **What are the rules?** — Coding conventions, git workflow, testing requirements
17
+ 2. **How do I do common tasks?** — Key commands, PR workflow, deployment
18
+ 3. **What should I avoid?** — Anti-patterns, forbidden operations, common pitfalls
19
+
20
+ ### Section Organization
21
+
22
+ A well-structured CLAUDE.md follows this order, from most-referenced to least:
23
+
24
+ | Section | Purpose | Example Content |
25
+ |---------|---------|-----------------|
26
+ | **Core Principles** | 3-5 non-negotiable tenets | TDD, simplicity, no laziness |
27
+ | **Project Overview** | What this project is (1-2 sentences) | "Prompt pipeline for scaffolding projects" |
28
+ | **Key Commands** | Commands the agent runs constantly | `make check`, `make test`, `npm run dev` |
29
+ | **Workflow** | How to do common operations | Branch, commit, PR, merge flow |
30
+ | **Structure Quick Reference** | Where files go | Directory table with purpose |
31
+ | **Environment** | Dev setup specifics | Build tool, test runner, linter |
32
+ | **Rules** | Specific do/don't instructions | "Never push to main directly" |
33
+ | **Self-Improvement** | Learning feedback loop | Lessons file, correction capture |
34
+ | **Autonomous Behavior** | What the agent should do proactively | Fix bugs on sight, use subagents |
35
+ | **Doc Lookup Table** | Where to find detailed docs | Question-to-document mapping |
36
+
37
+ ### Rule Authoring Best Practices
38
+
39
+ Rules must be specific, actionable, and testable:
40
+
41
+ **Good rules:**
42
+ - "Run `make check` before every commit"
43
+ - "Never push directly to main — always use branch + PR"
44
+ - "Every commit message starts with `[BD-xxx]` task ID"
45
+
46
+ **Bad rules:**
47
+ - "Write clean code" — what does clean mean?
48
+ - "Be careful with git" — what specific actions to take/avoid?
49
+ - "Follow best practices" — which ones?
50
+
51
+ ### The Pointer Pattern
52
+
53
+ Reference external docs instead of duplicating content inline:
54
+
55
+ ```markdown
56
+ ## Coding Conventions
57
+ See `docs/coding-standards.md` for full reference. Key rules in `.claude/rules/code-style.md`.
58
+ ```
59
+
60
+ This keeps CLAUDE.md under 200 lines (the empirically-validated adherence threshold) while preserving access to detailed docs. The agent reads referenced docs on demand rather than processing everything at session start.
61
+
62
+ ## Deep Guidance
63
+
64
+ ### Section Organization — Extended
65
+
66
+ #### Front-Loading Critical Information
67
+
68
+ Agents skim CLAUDE.md. The first 50 lines get the most attention. Place the most violated rules and most-used commands at the top. Core Principles and Key Commands should appear before any detailed documentation.
69
+
70
+ #### The 200-Line Threshold
71
+
72
+ Research and practical experience show that agent adherence drops sharply when CLAUDE.md exceeds ~200 lines. Beyond that length, agents start selectively ignoring instructions — particularly those in the middle or bottom of the file.
73
+
74
+ Strategies to stay under 200 lines:
75
+ - Use the pointer pattern for anything longer than 5 lines
76
+ - Move path-scoped conventions to `.claude/rules/` files
77
+ - Keep tables compact (no verbose descriptions)
78
+ - Eliminate redundancy (same rule stated multiple ways)
79
+
80
+ #### Section Templates
81
+
82
+ **Core Principles** — 3-5 tenets, each a single sentence with a bold label:
83
+ ```markdown
84
+ ## Core Principles
85
+ - **Simplicity First**: Make every change as simple as possible.
86
+ - **TDD Always**: Write failing tests first, then make them pass.
87
+ - **Prove It Works**: Never mark a task complete without demonstrating correctness.
88
+ ```
89
+
90
+ **Key Commands** — Table format, sorted by frequency of use:
91
+ ```markdown
92
+ ## Key Commands
93
+ | Command | Purpose |
94
+ |---------|---------|
95
+ | `make check` | Run all quality gates |
96
+ | `make test` | Run test suite |
97
+ | `make lint` | Run linters |
98
+ ```
99
+
100
+ **Doc Lookup Table** — Question-to-document mapping:
101
+ ```markdown
102
+ ## When to Consult Other Docs
103
+ | Question | Document |
104
+ |----------|----------|
105
+ | How do I branch and commit? | `docs/git-workflow.md` |
106
+ | What are the coding conventions? | `docs/coding-standards.md` |
107
+ ```
108
+
109
+ ### Rule Authoring — Extended
110
+
111
+ #### The Testability Criterion
112
+
113
+ Every rule should be verifiable. If you cannot check whether the rule was followed, the rule is too vague.
114
+
115
+ | Rule | Testable? | Fix |
116
+ |------|-----------|-----|
117
+ | "Write good tests" | No | "Every new function has at least one unit test" |
118
+ | "Use proper naming" | No | "Use camelCase for variables, PascalCase for types" |
119
+ | "Run `make check` before commits" | Yes | — |
120
+ | "Never commit `.env` files" | Yes | — |
121
+
122
+ #### Conflict Resolution
123
+
124
+ Rules can conflict. When they do, the resolution order is:
125
+ 1. CLAUDE.md rules override general conventions
126
+ 2. More specific rules override more general rules
127
+ 3. Later rules override earlier rules (if truly contradictory)
128
+ 4. Project-specific rules override ecosystem defaults
129
+
130
+ Document known conflicts explicitly: "This project uses tabs despite the TypeScript convention of spaces — see `.editorconfig`."
131
+
132
+ #### Negative Rules vs. Positive Rules
133
+
134
+ Prefer positive rules ("always do X") over negative rules ("never do Y") when possible. Positive rules tell the agent what to do; negative rules only eliminate one option from an infinite set.
135
+
136
+ Exception: safety-critical negative rules are valuable. "Never push to main directly" and "Never commit secrets" are clearer as negatives.
137
+
138
+ ### Pointer Pattern — Extended
139
+
140
+ #### When to Inline vs. Point
141
+
142
+ | Content Type | Inline in CLAUDE.md | Point to External Doc |
143
+ |-------------|--------------------|-----------------------|
144
+ | Core principles | Yes | No |
145
+ | Key commands table | Yes | No |
146
+ | Workflow summary (5-10 lines) | Yes | Detailed version elsewhere |
147
+ | Coding conventions (full) | No | `docs/coding-standards.md` |
148
+ | Git workflow (full) | No | `docs/git-workflow.md` |
149
+ | Project structure (full) | No | `docs/project-structure.md` |
150
+ | Design system rules | No | `docs/design-system.md` |
151
+
152
+ The rule: if the content is referenced multiple times per session, inline a summary. If it is referenced occasionally, point to it.
153
+
154
+ #### Cross-Reference Format
155
+
156
+ Use consistent pointer format throughout:
157
+ ```markdown
158
+ See `docs/coding-standards.md` for full reference.
159
+ ```
160
+
161
+ Not:
162
+ ```markdown
163
+ Refer to the coding standards document for more details.
164
+ ```
165
+
166
+ The first format gives the agent an exact file path to read. The second requires the agent to search for the file.
167
+
168
+ ### Merge Strategy for Multi-Step Pipeline Updates
169
+
170
+ Seven pipeline steps modify CLAUDE.md during project scaffolding. Each step owns specific sections and must not overwrite sections owned by other steps. This section ownership model prevents destructive overwrites when steps execute sequentially.
171
+
172
+ #### Section Ownership Map
173
+
174
+ | Pipeline Step | CLAUDE.md Sections Owned | Operation |
175
+ |--------------|-------------------------|-----------|
176
+ | **beads** | Core Principles, Task Management (Beads commands), Self-Improvement, Autonomous Behavior | Creates initial skeleton |
177
+ | **project-structure** | Project Structure Quick Reference | Adds/updates directory table |
178
+ | **dev-env-setup** | Key Commands, Dev Environment | Adds/updates command table and env section |
179
+ | **git-workflow** | Committing and Creating PRs, Parallel Sessions (Worktrees) | Adds/updates workflow sections |
180
+ | **design-system** | Design System, Browser Testing | Adds/updates design system section |
181
+ | **ai-memory-setup** | Pointer restructuring (cross-cutting) | Replaces inline content with pointers to `.claude/rules/` |
182
+ | **automated-pr-review** | Code Review workflow | Adds/updates review workflow section |
183
+
184
+ #### Merge Rules
185
+
186
+ 1. **Additive by default.** Each step adds its sections without modifying sections owned by other steps. If a section does not exist, create it. If it exists and belongs to this step, update it in-place.
187
+
188
+ 2. **Never delete unrecognized sections.** If CLAUDE.md contains sections not in the ownership map (user customizations, project-specific sections), preserve them. Move them to the end if they conflict with the expected layout, but never remove them.
189
+
190
+ 3. **Beads goes first.** The `beads` step creates the initial CLAUDE.md skeleton. All subsequent steps add to this skeleton. If `beads` was skipped (project does not use Beads), subsequent steps must still create their sections — they just skip the Beads-specific content.
191
+
192
+ 4. **ai-memory-setup is cross-cutting.** Unlike other steps that add sections, `ai-memory-setup` restructures existing sections by replacing inline content blocks with pointer references to `.claude/rules/` files. It operates across sections owned by other steps but only changes the representation (inline → pointer), not the substance.
193
+
194
+ 5. **claude-md-optimization consolidates.** The final consolidation step (`claude-md-optimization`) reviews the accumulated CLAUDE.md, removes redundancy introduced by incremental additions, fixes inconsistencies in terminology, and reorders for scannability. It operates on all sections but does not add new workflow steps or rules — only consolidates and clarifies what exists.
195
+
196
+ 6. **Preserve tracking comments.** Steps that add tracking comments (`<!-- scaffold:step-name v1 YYYY-MM-DD -->`) must preserve comments from other steps. These comments enable update detection.
197
+
198
+ 7. **Update mode is the norm.** After initial creation by `beads`, all subsequent steps operate in update mode. They check for existing content, preserve customizations, and update in-place rather than replacing.
199
+
200
+ #### Conflict Scenarios
201
+
202
+ **Two steps reference the same command.** Example: `dev-env-setup` adds `make check` to Key Commands and `git-workflow` references `make check` in the PR workflow. Resolution: the Key Commands table (owned by `dev-env-setup`) is the single source of truth for command definitions. Other sections reference commands but do not redefine them.
203
+
204
+ **ai-memory-setup restructures a section another step just added.** This is expected and by design. The `ai-memory-setup` step runs after environment steps and converts verbose inline blocks to compact pointer references. The referenced docs must exist before the pointer is valid.
205
+
206
+ **User adds custom sections between pipeline runs.** Subsequent pipeline steps must detect and preserve custom sections. Use the tracking comment (`<!-- scaffold:step-name -->`) to identify pipeline-managed sections vs. user-added sections.
207
+
208
+ ### Update Mode Handling
209
+
210
+ #### Detecting Existing Content
211
+
212
+ Every pipeline step that modifies CLAUDE.md implements mode detection:
213
+ - If the file does not exist → create mode (write full skeleton)
214
+ - If the file exists → update mode (modify owned sections in-place)
215
+
216
+ Update mode is the common case. After the first `beads` run, every subsequent step encounters an existing CLAUDE.md.
217
+
218
+ #### Preserving Custom Sections
219
+
220
+ Users customize CLAUDE.md between pipeline runs. Common customizations:
221
+ - Adding project-specific rules
222
+ - Adding custom command aliases
223
+ - Adding team-specific workflow notes
224
+ - Adding integration-specific sections (deployment, monitoring)
225
+
226
+ Pipeline steps must preserve all content they do not own. The safest pattern is:
227
+ 1. Read the existing CLAUDE.md
228
+ 2. Identify sections owned by this step (by heading or tracking comment)
229
+ 3. Replace only those sections with updated content
230
+ 4. Leave everything else untouched
231
+
232
+ #### Additive Updates
233
+
234
+ When updating a section, prefer additive changes over destructive ones:
235
+ - Add new table rows rather than replacing the entire table
236
+ - Add new subsections rather than rewriting the section
237
+ - Append to lists rather than replacing them
238
+ - Only remove content if it is demonstrably wrong or duplicated
239
+
240
+ ### Common Anti-Patterns
241
+
242
+ **Inline everything.** CLAUDE.md becomes 500+ lines with full coding standards, complete git workflow, entire project structure. Agent adherence drops, load time increases, signal drowns in noise. Fix: use the pointer pattern. Keep CLAUDE.md under 200 lines.
243
+
244
+ **Stale commands.** Key Commands table references `npm test` but the project switched to `bun test` two months ago. The agent runs the wrong command and wastes a cycle. Fix: keep Key Commands in sync with actual build tool configuration. The `claude-md-optimization` step verifies this.
245
+
246
+ **Conflicting rules.** CLAUDE.md says "always use conventional commits" in one section and "use `[BD-xxx]` prefix" in another, with no guidance on which takes precedence. Fix: consolidate commit message rules in one place. If both apply, show the combined format: `[BD-42] feat(api): implement endpoint`.
247
+
248
+ **Redundant instructions.** The same rule appears in Core Principles, Workflow, and Rules sections with slightly different wording. The agent may follow one version and violate another. Fix: state each rule once in its canonical section. Other sections reference it.
249
+
250
+ **Missing doc lookup.** CLAUDE.md references "the git workflow" but does not specify the file path. The agent searches, guesses, or ignores the reference. Fix: always include exact file paths in references.
251
+
252
+ **No update mode.** A pipeline step blindly writes a complete CLAUDE.md, overwriting sections added by earlier steps. Fix: every step that modifies CLAUDE.md must read it first, identify its owned sections, and update only those sections.
253
+
254
+ **Over-specifying autonomous behavior.** CLAUDE.md micro-manages every agent decision: "If you see a typo, fix it. If you see a missing import, add it. If you see..." This wastes lines on things the agent would do anyway. Fix: autonomous behavior should cover non-obvious expectations — "fix bugs on sight," "use subagents for research," "re-plan when stuck." Skip obvious behaviors.