/update

Reviews accumulated friction observations from the self-learning logs and proposes targeted improvements to rules, routing, and skill behavior.

Trigger phrases#

/update, improve the environment, check for improvements, review friction, or after accumulating several sessions of use.

Do NOT use for: updating source code or game content.

Two-phase process#

Phase 1: Analysis (always runs)#

1. Reads monthly friction logs from Docs/_working/retro/
2. Reads Docs/Environment/EVOLUTION.md for history of past changes
3. Counts entries by category and identifies patterns
4. Drafts proposals with evidence and risk assessment

Phase 2: Implementation (requires explicit approval per proposal)#

You approve individual proposals or say "approve all" for small changes. /update implements only what you approve.

Friction categories analyzed#

Category	Priority
ROUTING_CORRECTION: routing table sent request to wrong agent	1 (highest)
CORRECTION: user taught the AI a rule that should be codified	2
BUILD_FAIL: recurring build failures after implementation	3
PLAYTEST_FAIL: playtest steps that consistently miss bugs	4
REPLICATION_BUG: multiplayer issues from wrong replication assumptions	5
PATTERN: confirmed recurring friction	6
SKILL_UNDERTRIGGER / SKILL_OVERTRIGGER: skill descriptions need tuning	7
FRICTION: individual friction events	8 (lowest)

Proposal format#

Each identified pattern generates a proposal:

## Proposal: [Short title]

**Evidence**: [N] entries in [category]. Examples:
- [date] [entry 1]
- [date] [entry 2]

**Root cause**: [Why this friction occurs]

**Proposed change**: [Specific file + specific edit]

**Classification**: small | medium | large
**Self-modifiable**: yes | no (requires human editing)
**Risk**: [What could go wrong if applied]

Proposals are written to Docs/_working/retro/Proposals/YYYY-MM-DD_update.md.

Change size classifications#

Size	Examples
Small	Routing adjustment, threshold change, description update, rule tweak
Medium	New rule file, new agent, new skill reference
Large	Structural change: new skill, architecture modification

What /update can modify (after approval)#

• Rule files (.claude/rules/*.md): routing adjustments, threshold changes
• Skill trigger descriptions: adding or removing trigger phrases
• Memory structure (Docs/index.md, wiki pages)
• Self-learning thresholds and seed patterns

What requires human editing (proposals only, not applied automatically)#

• settings.json permissions (allow/deny lists)
• CLAUDE.md hard constraints
• Agent model assignments
• Agent maxTurns values
• Hook configurations
• .claudeignore patterns
• VCS submission rules

What is never modified#

• Docs/Environment/GENESIS.md: the original project intake record

Safety guardrails#

• Maximum one structural change per /update invocation (new rule file, new agent, routing table rewrite)
• All modified files are backed up to Docs/_working/retro/Backups/ before any change
• All changes are logged in Docs/Environment/EVOLUTION.md with trigger, change, files, backup path, and observed result

When to run#

Run /update after 3–5 sessions of use to review accumulated friction. /state-load tracks unprocessed entries and reminds you when 5 or more have accumulated since the last run.