feat(context): Context Engineering Configurator + consolidated guide (v3.34.0)

New: interactive configurator at cc.bruniaux.com/context/ that generates a
personalized CLAUDE.md starter kit based on team size, stack, and current setup.
Multi-step flow (profile, current state, stack, results) with maturity scoring
(Level 1-5), copy-to-clipboard artifacts, localStorage persistence.

Guide content:
- guide/core/context-engineering.md (1,188 lines, 8 sections): context budget,
  150-instruction ceiling, modular architecture, team assembly, ACE pipeline,
  quality measurement, context reduction techniques
- examples/context-engineering/ (10 templates): assembler.ts, profile-template.yaml,
  skeleton-template.md, canary-check.sh, ci-drift-check.yml, eval-questions.yaml,
  context-budget-calculator.sh, rules/knowledge-feeding.md, rules/update-loop-retro.md
- tools/context-audit-prompt.md (543 lines): 8-dimension scoring /100

Navigation: guide/README.md, machine-readable/reference.yaml (24 new entries)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

examples/context-engineering/rules/knowledge-feeding.md

@@ -0,0 +1,93 @@
+# Knowledge Feeding Protocol
+
+Context engineering is not a one-time setup — it accumulates value over time as Claude learns what works for your project. This file defines when and how to capture that learning back into your `CLAUDE.md`.
+
+## When to Feed Knowledge
+
+Run this protocol at the end of any session that:
+
+- Completed a feature or meaningful code change
+- Discovered a new pattern that worked well and should become standard
+- Hit a mistake that required correction (especially if the mistake was repeated)
+- Made an architectural decision that will affect future work
+- Established a preference for a library, tool, or approach
+
+Skip it for trivial sessions (typo fixes, doc edits, minor config changes).
+
+## The Knowledge Feed Prompt
+
+Paste this into Claude at the end of qualifying sessions:
+
+```
+Before we close this session, run a knowledge feed:
+
+1. What patterns did we establish that should become permanent rules?
+2. What did I correct or redirect that should be a rule to prevent recurrence?
+3. Were any architectural decisions made that CLAUDE.md should record?
+4. Is there anything in CLAUDE.md that this session proved wrong or outdated?
+
+Output only high-signal items (3-5 max). Use the knowledge feed format below.
+Skip anything obvious or already covered.
+```
+
+## Knowledge Feed Output Format
+
+Claude should output discoveries in this structure:
+
+```markdown
+## Knowledge Feed — [YYYY-MM-DD]
+
+### New Pattern (if applicable)
+**What**: [One sentence describing the pattern]
+**Why**: [Why this is the right approach for this project]
+**Rule to add**:
+> [Exact text to paste into CLAUDE.md, ready to copy]
+
+### Anti-Pattern Found (if applicable)
+**What happened**: [What Claude did wrong or what was corrected]
+**Why it's wrong here**: [Project-specific reason, not generic best practice]
+**Rule to add**:
+> Never: [specific behavior to avoid and why]
+
+### Architecture Decision (if applicable)
+**Decision**: [What was decided]
+**Rationale**: [Why — especially if it goes against common practice]
+**Rule to add**:
+> [Exact text to paste into CLAUDE.md]
+
+### Stale Rule to Remove (if applicable)
+**Rule**: [Current rule in CLAUDE.md]
+**Why remove**: [What changed that makes this obsolete]
+```
+
+## Integration Workflow
+
+After receiving the knowledge feed:
+
+1. **Review before adding** — not all patterns generalize. Ask: "Would a new team member need to know this, or is it context-specific to this session?"
+2. **Copy relevant rules** into the appropriate section of `CLAUDE.md`
+3. **Remove any rules** Claude flagged as stale
+4. **Commit the update** with a meaningful message:
+
+```bash
+git add CLAUDE.md
+git commit -m "context: [short description of what was learned]"
+
+# Examples:
+# context: add zod validation rule after form refactor
+# context: remove Redux rule — migrated to Zustand
+# context: document payment webhook idempotency pattern
+```
+
+## Quality Filter
+
+Before adding any rule to `CLAUDE.md`, check:
+
+- **Is it specific to this project?** Generic best practices don't belong here — Claude already knows them.
+- **Is it actionable?** "Be careful with async code" is useless. "Always check for race conditions in the order state machine" is useful.
+- **Is it already covered?** Search for similar rules before adding. Duplicates dilute adherence.
+- **Will it still be true in 6 months?** Avoid rules tied to temporary states ("we're migrating to X so don't use Y yet").
+
+## Ownership
+
+Knowledge feeding works best when it's a team habit, not one person's job. Any team member who works with Claude can contribute a knowledge feed. The person who reviews the PR for `CLAUDE.md` changes is responsible for quality filtering.

examples/context-engineering/rules/update-loop-retro.md

@@ -0,0 +1,108 @@
+# Session Retrospective Template
+
+A structured prompt to run at the end of Claude Code sessions. The goal is to capture
+knowledge while it's fresh and turn it into durable rules — keeping your `CLAUDE.md`
+accurate as the project evolves.
+
+## The Prompt
+
+Copy this and paste it into Claude at the end of a session:
+
+```
+Session complete. Before we close, run a quick retrospective:
+
+1. What patterns did we establish that should be permanent rules in CLAUDE.md?
+2. What did I correct that Claude got wrong? Should a rule prevent that?
+3. What worked well that we should replicate in future sessions?
+4. Were any architectural decisions made that CLAUDE.md should record?
+5. Is there anything currently in CLAUDE.md that this session proved wrong or outdated?
+
+Output a knowledge feed — 3 to 5 bullets max, high-signal items only.
+Skip anything obvious, generic, or already in CLAUDE.md.
+Format each item as an actionable rule ready to copy in.
+```
+
+## When to Run It
+
+| Trigger | Run retro? |
+|---------|-----------|
+| Feature or major refactor completed | Yes |
+| Debugging session that uncovered a systemic gap | Yes |
+| Architectural decision made | Yes |
+| Onboarding session where someone flagged missing context | Yes |
+| Monthly, even if nothing major happened | Yes — catches accumulation |
+| Trivial session (typo fix, doc edit) | No |
+
+Monthly is the minimum cadence even for quiet projects. Small drifts accumulate silently.
+
+## What Good Output Looks Like
+
+Claude should return something like this (not verbatim — but this level of specificity):
+
+```
+Knowledge Feed — 2025-09-15
+
+1. Pattern established: All database queries go through the repository layer, never called
+   directly from route handlers. Rule to add: "Never call Prisma directly from route
+   handlers — use the repository functions in src/db/."
+
+2. Correction: I suggested lodash for array manipulation. You redirected to native array
+   methods. Rule to add: "Don't import lodash — use native JS array methods. The bundle
+   cost isn't worth it for our use case."
+
+3. Architecture decision: We decided to keep auth logic in middleware, not in individual
+   route handlers. Rule to add: "Auth checks belong in src/middleware/auth.ts — not in
+   route handlers. If a route needs special auth logic, extend the middleware."
+
+4. Stale rule: CLAUDE.md still references the old Express v4 error handler signature.
+   We're on v5. Remove: "Express error handlers take 4 arguments (err, req, res, next)."
+   Update to: "Express v5 error handlers: async errors propagate automatically — no need
+   to call next(err)."
+```
+
+## After the Retro
+
+### Review the output
+
+Not everything Claude surfaces belongs in `CLAUDE.md`. Ask:
+
+- Is this specific to our project, or generic advice Claude already knows?
+- Is it actionable? Would a new Claude session make the same mistake without this rule?
+- Is it already covered? Search before adding — duplicates reduce adherence.
+
+### Update CLAUDE.md
+
+Add new rules to the most relevant section. Remove any stale rules Claude flagged.
+
+### Commit with a traceable message
+
+```bash
+git add CLAUDE.md
+git commit -m "context: [what changed and why]"
+```
+
+Meaningful commit messages create a traceable history of how your AI context evolved. Useful
+for debugging: "Claude started doing X wrong after we made change Y" becomes diagnosable
+from git log.
+
+Examples of good commit messages:
+
+```
+context: add lodash ban — use native array methods
+context: clarify auth middleware pattern after refactor
+context: remove Express v4 error handler rule — now on v5
+context: document payment webhook idempotency requirement
+context: add Prisma-direct query ban after code review
+```
+
+## Team Usage
+
+When multiple people work with Claude on the same project, retros become especially valuable.
+Each developer may get different corrections — different gaps in `CLAUDE.md` surface from
+different angles. Consider:
+
+- Running a retro at the end of any PR that involved significant Claude-assisted work
+- Including `CLAUDE.md` in PR reviews as a standing agenda item
+- Doing a quarterly joint retro with the whole team to review accumulated changes
+
+The `CLAUDE.md` file is a shared asset. Its quality reflects how well the team maintains it.