Update

/update — Team State Sync

When this skill is triggered, perform ALL of the following steps:

Step 1: Review the conversation

Scan the current conversation for:

• Decisions made (technical, architectural, scope, business)
• New context learned (from documents, verbal context, or Q&A)
• Action items identified (including casual mentions like "we should also fix X", "don't forget to Y", "we'll need to Z eventually")
• User's knowledge growth (new concepts now understood)
• Open questions that still need answers
• Changes to project direction or priorities
• Completed work that may resolve existing action items

Step 2: Update memory files

For each relevant memory file in the memory directory:

• Read the current content
• Update with new information from this session
• If a new memory is needed (new topic not covered by existing files), create it
• Update MEMORY.md index if new files were created

Memory types to check:

• user_[name]_profile.md — Did the user demonstrate new knowledge or preferences?
• project_[name]_status.md — Did the project status, phase, or timeline change?
• project_[stakeholder]_context.md — Did we learn anything new about a key stakeholder or their expectations?
• project_technical_decisions_[phase].md — Were any technical decisions made or refined?
• feedback_*.md — Did the user give any feedback on how the team should operate?

Step 3: Update Backlog (context/backlog/)

The backlog is one markdown file per item. See .claude/rules/backlog-protocol.md for the full discipline. During /update, perform ALL of the following:

3a: Capture new backlog items

Scan the conversation for work that needs doing:

• Explicit requests ("we need to build X")
• Casual mentions ("we should also fix Y", "eventually we'll want Z")
• Open questions needing follow-up
• Bugs discovered during the session
• Technical debt identified
• Follow-ups from code review or testing

For each new item:

1. Copy context/backlog/_template.md to context/backlog/<YYYY-MM-DD-slug>.md (slug is short kebab-case)
2. Fill the frontmatter (status: Drafted to start, priority, type, owner, source, created, last_touched)
3. Fill at minimum: Title, Business Why, Scope: Doing, Scope: Not Doing
4. If Type=Feature/Bug/Refactor: query Graphify and fill Codebase Context
5. If the user approved scope live in chat: bump status to Approved AND set enrichment_status: enriched (only after all required fields are filled per backlog-protocol.md)
6. Otherwise leave as Drafted and tell the user the new items need approval

3b: Update items worked on this session

For each item touched:

• Update last_touched in frontmatter
• Add a Last Session Summary entry (newest on top) with what was done, file refs, and what's next
• If status changed (Approved → Building, Building → Verifying, etc.), update status: in frontmatter
• If completed: status = Shipped, move file to context/backlog/archive/
• If blocked mid-session: status = Blocked, add the blocker to Open Questions

3c: Resolve completions

• For items where the work is done, status = Shipped, move to archive/
• Mention shipped items in STATUS.md

3d: Staleness flag

• Items with last_touched older than 60 days get a one-line note: "Stale — review queue." No automatic move; the user decides whether to refresh, kill, or accept staleness

Step 4: Update STATUS.md

Read context/STATUS.md and update:

• Last updated date
• Current Status section if phase or timeline changed
• App Build Status table if any development work was done
• Engineering Team Decisions section if new decisions were made
• What's Coming Next section if priorities shifted
• Add any new sections needed

Step 5: Process inbox (if applicable)

Check context/inbox/ for unprocessed files. If any exist:

• Read and analyze each file
• Brief on contents
• Move to appropriate folder (requirements/, communications/, archive/*, etc.)
• Update STATUS.md with new information
• Extract any work items and draft them into context/backlog/ (per Step 3a)

Step 6: Log decisions

If significant decisions were made this session, create or update files in context/decisions/ with:

• The decision
• Why it was made
• Who was involved
• Date
• Impact on the build

Step 7: Save to MemPalace (REQUIRED if installed)

There is no auto-mining — explicit calls during /update are the ONLY way memories persist across sessions. Skipping this step means the next session starts blind to anything important from this one.

First check availability: call mempalace_status. If it returns an error or "not configured", skip this step. If it returns OK, proceed:

For each significant item from this session, call mempalace_add_drawer with the appropriate room:

For each call:

• agent_name: which team member is saving (e.g., "Sara", "Maya", "Jake")
• entry: 2-3 sentences capturing the WHAT and WHY (not the how — that's in the code)
• room: from the table above

Then for any structured fact-relationships worth indexing (e.g., "AuthMiddleware depends on JWT", "BillingService uses Stripe"), call mempalace_kg_add with subject/predicate/object.

Do NOT save: code snippets, command output, transient state, or anything already captured in STATUS.md or ADRs. MemPalace is for the "why" and "what was rejected" — not the "what is".

Step 8: Confirm

After updating, provide a brief summary:

• What was saved/updated
• Backlog: N new items drafted, N updated, N shipped, N total live
• Any open items that need attention next session
• Current project state in one sentence

When to trigger automatically

This skill should also run automatically (without being asked) when:

• A significant decision point is reached
• New context from inbox has been processed
• A build phase or milestone is completed
• The session is clearly winding down
• User says anything like "save this", "remember this", "update yourselves", "don't forget"