progress-tracking

Progress Tracking

Pick up a person's development program cold and move it forward: read the program and its check-ins from their personal memory scope, report where they stand, then write the next check-in chained to the last. The point is continuity — a fresh session reconstructs goals, milestone status, next actions and open questions from the record alone.

individual-program-design owns the program record; this skill reads it and owns the check-in record. Underneath, memory-search owns read discipline, memory-capture write discipline, graph-traversal multi-hop questions, and agent-memory-protocol identity for when an agent runs this — all four from the gutt-pro plugin. Without it, follow the rules below and note the gap in one line.

Hard rules (non-negotiable — read first)

1. Scope every personal read explicitly, and mind the asymmetry. There is no search_personal_memory tool. Pass group_ids: ["personal"] — plural, an array — to search_memory_nodes, search_memory_facts, fetch_lessons_learned and list_entities; get_episodes takes singular group_id: "personal". That scope is the authenticated user's own, derived from the login — so you are always reading and writing your own program, never someone else's.
2. Chain the check-in explicitly with previous_episodes=["<predecessor id>"] from the read — an episode UUID or semantic ID, never an entity id. last_n_episodes applies only when previous_episodes is omitted — a list you supply is used as given, and last_n_episodes is then not read at all — and its default of 3 chains you to whatever was written most recently in that person's personal scope, not to this program's last check-in. Pass only an id the read actually returned — resolution happens before the write, so a wrong or ambiguous id fails the whole check-in rather than just losing the chain.
3. 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.
4. 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).
5. Report the record; never fill in its gaps. A milestone is done only because the record or the user says so — inferring one corrupts every later summary. No program found → say so and hand off to individual-program-design; never rebuild one from what you were just told.
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.