work-pattern-memory

name

work-pattern-memory

description

The knowledge layer for the learning loop. Explains how to read and act on the work-pattern snapshot that glm-learning-loop injects at SessionStart — what the verification ratio means, what tool over-reliance signals, how to adapt behavior based on past-session telemetry. ROUTE BY INTENT — load when the model receives a work-pattern snapshot and needs to interpret it, when the user asks "how do I work?" / "내 작업 패턴 뭐야" / "am I verifying enough?", or when adapting this session based on past behavior. Also load when the user wants to inspect or clear the telemetry that drives the loop. NOT a stats viewer (that's /session-stats) — this is the interpretive layer that turns numbers into behavioral change.

Work pattern memory — how to read and act on your own telemetry

The glm-learning-loop plugin injects a work-pattern snapshot at SessionStart (via additionalContext). This skill is the interpretive layer: what the numbers mean and how to act on them.

Why this exists

A self-evolving harness doesn't just measure — it adapts based on measurement. ai-showhost's equivalent was embedding-based feedback retrieval (161 feedback files semantically matched to the current task). That needs an embedding API. This does the same adapt-based-on-past-measurement job with zero external dependencies, using the telemetry that session-telemetry already writes.

The loop:

session-telemetry writes tools.jsonl/turns.jsonl (measure)
  -> glm-learning-loop reads them at next SessionStart (learn)
  -> injects a snapshot + adaptive hints (adapt)
  -> this skill tells the model how to interpret the hints (apply)
  -> the model behaves differently this session (the evolution)

The snapshot fields and what they mean

The injected snapshot has three sections:

1. Tool distribution (top 5)

The raw count of which tools you used most. Healthy sign: a spread across Read/Grep/Glob (exploration), Edit/Write (production), Bash (verification). Unhealthy sign: one tool dominating (>60%) — often a loop.

2. Verification ratio

verify_count / total_tools where verify = Bash calls (running something to check), edit = Edit/Write/MultiEdit. This is the verify-before-claim doctrine in numbers:

Ratio	Interpretation	Action
> 40%	Healthy — you verify before claiming	Keep it up
15-40%	Moderate — some verification but gaps	Before any "done" claim this session, run the test/command
< 15%	Low — you edit a lot but run little	Load verify-before-claim skill; treat every completion claim as a hypothesis until a command confirms it

3. Adaptive hints

Concrete, behavior-level hints computed from the snapshot. Examples:

• "Low verification ratio (12%)... Before claiming 'done', run the test suite."
• "Heavy reliance on Edit (65%)... If you catch yourself repeating, step back."
• "You tend to work around hours [14, 15, 22]."

These are not commands — they are context. Use them to calibrate this session's behavior, not to mechanically obey.

How to act on the snapshot

When you see a snapshot at session start:

1. Acknowledge it silently. Don't start the session by reciting the snapshot to the user — that's noise. Internalize the hints and let them shape your behavior.
2. If verification ratio is low, make verification your default this session. When you're about to say "done", stop and run the test/command first.
3. If a single tool dominates, watch for loop-behavior. If you've called the same tool 3+ times in a row without progress, stop and reconsider the approach (this is the §0.5 progress-discipline rule).
4. If the hints say you work at certain hours, that's just orientation — no action needed unless the user asks.

Inspecting and clearing the telemetry

The loop reads from ${ZCODE_PROJECT_DIR}/.zcode-state/:

• tools.jsonl — one row per tool call (ts, session, tool, cwd)
• turns.jsonl — one row per turn (ts, session, response_chars)

To inspect: cat .zcode-state/tools.jsonl | python3 -m json.tool | head -50 To clear (reset the loop): rm .zcode-state/tools.jsonl .zcode-state/turns.jsonl — the loop will honest-degrade to silence until enough data accumulates again (minimum 10 rows). The .zcode-state/ directory is NOT automatically gitignored in your project repo. The fleet's own .gitignore only protects the fleet repo itself. You must add .zcode-state/ to each project repo's .gitignore manually (see README §4), or you will commit telemetry scratch to your project history.

Honest-degrade

The loop stays silent (no injection) when:

• Fewer than 10 tool calls have been recorded (not enough signal)
• The jsonl files don't exist (telemetry plugin not installed, or fresh repo)
• The window (7 days) has no data

Silence is correct here — injecting a snapshot from 3 data points would be noise. The loop earns its voice by accumulating real measurement.

What this is NOT

• Not a recommendation engine. It doesn't tell you WHICH skill to load — that's the design-fleet routing spine's job. It tells you HOW you tend to work, so you can correct course.
• Not a score. There is no aggregate "you're a 7/10 developer" number. The snapshot is dimensional (verification ratio, tool spread, peak hours) — each dimension is actionable on its own.
• Not permanent memory across repos. The telemetry is per-repo (.zcode-state/ lives in the project dir). Your pattern in repo A doesn't bleed into repo B. This is intentional — work patterns differ by stack.