# Update

> Save all session decisions, conclusions, and context to memory and STATUS.md so the team stays current across instances. Use when you say /update, "save this", "update yourselves", or at the end of any significant session.

- Skill: `eugenezhangco-spec/update` (Agent Skill)
- Install (CLI): `npx skillmds@latest add eugenezhangco-spec/update`
- Raw SKILL.md: https://api.skillmd.com/api/skills/eugenezhangco-spec/update/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: eugenezhangco-spec (https://skillmd.com/u/eugenezhangco-spec)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/eugenezhangco-spec/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:

| Type of memory | Room |
|---|---|
| Architectural decision (chose X over Y) | `decisions` |
| User preference ("I always want X", "never do Y") | `preferences` |
| Stakeholder constraint (deadline, requirement, scope limit) | `stakeholders` |
| Bug discovered + root cause | `bugs` |
| Feature scope decision (in/out, MVP cut) | `features` |
| Performance optimization or bottleneck found | `performance` |
| Security decision or compliance requirement | `security` |
| Deployment / hosting / CI choice | `deployment` |
| Database / pipeline / migration choice | `data` |
| Anything else worth remembering | `architecture` (catch-all) |

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"