| name | update-project-status |
| description | Use when summarizing a session and updating PROJECT_STATUS.md with important changes, decisions, active experiment state, new constraints, or new files. Triggers: update project status, summarize session, handoff, record changes, keep PROJECT_STATUS current, end of session. |
| argument-hint | Describe what was done this session, or leave empty to auto-detect from session memory and recent file changes. |
Update Project Status
Compact the important outcomes of the current session into PROJECT_STATUS.md. Do NOT write a diary. Replace stale bullets; add only what is new and durable.
When to Use
- At the end of a working session before switching context
- After code changes that affect architecture, data flow, or constraints
- After design decisions that future agents must respect
- After adding new scripts, files, or skills to the workspace
- After a running experiment reports early-phase metrics
Procedure
Step 1 — Gather session context
Read session memory if it exists:
/memories/session/plan.md or any file under /memories/session/
Then read the current PROJECT_STATUS.md in full to understand what is already there.
Step 2 — Identify what changed this session
Categorize each change into one of:
| Category | Goes Into |
|---|
| New or moved key file / script | Workspace Map |
| Code path added or behavior changed | Critical Code Paths |
| Algorithm rule, constraint, or "do not" | Algorithm Notes or Do Not Forget |
| Active run metrics / experiment state | Active Run And Monitoring |
| High-level focus shift | Current Focus |
Discard: timestamps, full log excerpts, chat history, API keys, W&B run IDs.
Step 3 — Decide what to write per section
Consult section-rules.md for per-section update rules.
The core rule: replace stale bullets, do not append history.
- If an existing bullet is now outdated, replace it.
- If new information belongs to an existing bullet's topic, extend that bullet.
- Add a new bullet only when the topic is genuinely absent.
- Never add more than 3 new bullets per session without removing an equal number of stale ones.
Step 4 — Apply edits
Use multi_replace_string_in_file for all edits in a single call when possible.
Include ≥ 3 lines of surrounding context in each oldString so replacements are unambiguous.
Do NOT rewrite entire sections. Make surgical replacements.
Step 5 — Verify
After writing, re-read the edited sections and confirm:
- No secrets, API keys, or private URLs were written
- No full log output or experiment transcript was written
- Every new bullet is ≤ 2 lines
- The file still reads as a current-state map, not a changelog
name field in this SKILL.md still matches the folder name (update-project-status)
