feat(plugin/claude-code): mandate mem_context at session start to prevent blind sessions

[franbaigorria]

🔍 Problem Description

When a Claude Code session starts, session-start.sh already fetches and injects recent memory context via /context. However, the Claude Code SKILL.md only instructs the agent to search memory conditionally — when the user explicitly asks about past work or when the first message "references a project, a feature, or a problem."

This condition is ambiguous in practice. Real sessions often start with something unrelated to prior work: a build log paste, a system error, an unrelated question. The agent interprets this as "no prior context needed" and proceeds blind — even though relevant memory exists.

Real example: A session working on a multi-session feature (CLI scaffolding tool) started with the user pasting an unrelated build error. The agent resolved it. Then the user asked to "create a branch for the first version of the CLI." Instead of loading 7 existing session summaries and 20+ observations about that exact feature, the agent launched a full codebase exploration from scratch.

Result: duplicated work, lost context, blind session. The memory was there. The agent just never loaded it.

💡 Proposed Solution

Add a ## SESSION START (mandatory) section to plugin/claude-code/skills/memory/SKILL.md that explicitly mandates calling mem_context as the first action of every session — unconditionally, before responding to the user.

## SESSION START (mandatory)

Your FIRST action in every session — before responding to any user message — is to call `mem_context`.

Do this even if the first message seems unrelated to prior work (a pasted error, a build log, a greeting).
One call. Two seconds. Prevents a blind session.

If context shows prior work relevant to what the user is asking → use it immediately, don't re-explore what's already known.
If context is empty or irrelevant → proceed normally.

Do NOT skip this step. The cost of one call is negligible. The cost of a blind session is losing everything the previous session built.

📦 Affected Area

Skills (agent skills)

🔄 Alternatives Considered

Three alternatives were evaluated before choosing this approach:

Option A — FTS search fallback with individual term matching (internal/store/store.go)
When mem_search returns 0 results, split the query into individual terms and retry. Reduces the impact of semantic mismatches between how memory was saved vs. how the user phrases queries. Discarded as primary fix because it addresses a symptom (bad search recall) rather than the root cause (agent not loading context at all). Valid as a follow-up improvement.

Option B — Proactive context injection via UserPromptSubmit hook (shell script)
Auto-trigger a context search on the first user prompt via the existing hook, without relying on the agent's judgment. Discarded because it adds latency on every first prompt, requires the hook to determine relevance heuristically, and duplicates what mem_context already does — with less flexibility.

Option C — Improve SKILL.md protocol (chosen)
Remove conditionality from the session-start memory rule. Make mem_context unconditionally mandatory on every session start. Zero infrastructure changes, zero risk, immediate behavioral improvement. The right fix at the right layer: the agent's instructions, not the plumbing.

📎 Additional Context

The session-start.sh hook already does the right thing at the infrastructure level — it fetches /context and injects it as additionalContext. This PR complements that by ensuring the agent also calls mem_context itself, which returns richer data (full observation summaries, session history) than what the hook injects. Both layers working together maximize context at session start.