individual-program-design

Individual Program Design

Turn a person's stated goals into a program that survives the session: goals, milestones, a check-in cadence, and the questions still open — written once to their personal memory scope so any later session can reconstruct it without asking them to explain themselves again. Domain-neutral: this shapes the container, never the subject matter.

progress-tracking is the other half — it reads this record back and writes the check-ins against it. Underneath, memory-capture owns write discipline (classify, dedup, size caps, write-tool discovery, queued≠persisted), memory-search owns query phrasing and the relevance gate, and agent-memory-protocol owns identity for when an agent runs this. Those ship with the gutt-pro plugin; without it, follow the rules below and note the gap in one line.

Hard rules (non-negotiable — read first)

1. Personal scope, written with add_personal_memory. That tool takes no group_id at all — the namespace is derived server-side from the login and authorized on every call. Without an OAuth login carrying a stable user id the call is denied, not downgraded. Never write a person's program to an org group instead; hand the draft back (see Degradation). Because the namespace comes from the login, it is the authenticated user's own scope — there is no way to write into someone else's. This skill serves whoever is running it, for themselves; run on someone else's behalf it would file their program under your name, so say that rather than doing it.
2. No agent identity in personal scope. Do not pass agent_id on a personal read or write. Registration and tagging happen in org scope only, and that is agent-memory-protocol's business.
3. Privacy runs both ways. Never copy personal-scope content into an org-scope write or into an org-memory query string. And every org-scope read issued while program content is in context must pass explicit group_ids naming only org groups: omit it and the user's personal scope is already in the default search scope, so private notes leak into what may become a shared briefing. An org write carries nothing personal and passes last_n_episodes=0 (memory-capture).
4. The goals are the user's. Elicit them; never infer a program and write it. Read the filled-in skeleton back and get an explicit yes first. No confirmation → it stays a draft, and you say so.
5. One self-contained program episode, last_n_episodes=0. The program is the root of the thread and has nothing to chain to, and the server default of 3 would fold unrelated recent personal episodes into extraction. Use the naming and skeleton below, and do not invent a new typed name prefix — the five (Insight: through WorkingAgreement:) belong to org captures in memory-capture.
6. Never hardcode a tool prefix. The mcp__…__ prefix varies per install, so call add_personal_memory, get_episodes, etc. by whatever name your tool list actually surfaces — and never assume a write tool's name.