Description
Reusable skill that provides operations to manage the memory/ directory of a project. Memory files are condensed summaries (~1-2KB) that allow a workflow orchestrator to quickly orient itself when resuming work on an existing project, without consuming the tokens required by a full context ledger.
The memory file is a quick-start summary; the context ledger is the full record.
Input / Output
Input (common): memory_dir, project_name — varies by operation (see below).
Output: Created or updated memory file (for save) or a memory content block ready for injection (for load-last).
Operations
save — Write or update a session memory file
Creates or updates a condensed memory file for the current session. If a file with the same session timestamp already exists, it overwrites it. Otherwise, creates a new file.
Input:
| Field | Description |
|---|---|
| memory_dir | Path to the memory directory (default: memory/) |
| project_name | Name of the project (e.g. agsy-product-manager-aramis) |
| session_timestamp | Timestamp of the current session in YYYY-MM-DD-HH-MM format |
| mode | architect or express |
| status | in-progress / completed / paused (see status semantics below) |
| last_checkpoint | ID of the last approved checkpoint (e.g. CP-S2, CP-CLOSE) |
| checkpoints_approved | List of all approved checkpoints so far |
| checkpoint_decisions | (v3 — 4.2.2) Object: which option (A/B/C/D) the user picked at each checkpoint + optional note. See structure below. |
| target_dir | Path to the export directory for this project |
| session_summary | 2-3 line description of what was designed/generated in this session |
| steps_completed | Object with step summaries: { "S0": "...", "S1": "...", ... } |
| active_state | What is pending, open questions, next steps |
| key_decisions | List of key design decisions made |
| last_session_at | (v3 — 4.2.4) ISO 8601 timestamp of when this session started. Computed automatically. |
Output: File {memory_dir}/{session_timestamp}-{project_name}.md created with structure:
---
schema_version: 1.1
project-name: {project_name}
session: {session_timestamp}
mode: {mode}
status: {status}
last-checkpoint: {last_checkpoint}
checkpoints-approved: [{checkpoints_approved}]
checkpoint_decisions:
CP-S0: { option: A, note: "Approved as-is" }
CP-S1: { option: B, note: "Adjusted: added 2 triggers" }
CP-S2: { option: C, regenerated_count: 1 }
target-dir: {target_dir}
last_session_at: 2026-04-25T10:00:00Z
---
## Session summary
{session_summary}
## Steps completed
- S0: {steps_completed.S0}
- S1: {steps_completed.S1}
...
## Active state
{active_state}
## Key decisions
- {key_decisions[0]}
- {key_decisions[1]}
...
Schema version note (v3 — 4.2.1): The schema_version field distinguishes v3 Memory snapshots (1.1) from v2 baseline (absent or 1.0). When load-last reads a file without schema_version, treat it as v1.0 and silently migrate fields on the next save (back-compat).
Status semantics:
| Status | Meaning | Visible in load-last? |
|---|---|---|
in-progress |
Active session, mid-workflow | Yes |
paused |
Temporarily stopped, plans to resume soon | Yes |
completed |
Workflow reached CP-CLOSE, no pending work | Yes |
When: After each checkpoint approval and at session close.
load-last — Load the most recent memory for a project
Scans the memory directory for files matching the project name and returns the most recent one.
Input:
| Field | Description |
|---|---|
| memory_dir | Path to the memory directory (default: memory/) |
| project_name | Name of the project to search for |
Logic:
- List all files in
{memory_dir}/. - Filter files whose name ends with
-{project_name}.md. - Sort by timestamp prefix (descending) — the filename format
YYYY-MM-DD-HH-MM-guarantees lexicographic = chronological order. - Read the content of the first (most recent) match.
- Compute time-since-last-session: read
last_session_atfrom the loaded Memory; computetime_since_last_session_hours = now - last_session_at. Surface as part of the load output:"Resumingfoo-system(last touched 3 days ago, status: in-progress at CP-S2)".
- Return the content of the most recent memory file.
Output: Full content of the most recent memory file, or empty with message "No previous memory found for project '{project_name}'". When v3 verification triggers, also include a one-line summary of the resolution.
When: At workflow startup, before initializing a new session, to check for existing project context.
Procedure
Use operations in this order per workflow run:
load-last— at workflow start, check for existing contextsave— after each checkpoint approval (update in-progress state)save— at workflow close (final state with status=completed)
Usage notes
- The workflow is responsible for composing the memory content. This skill only handles the file mechanics.
- Memory files are designed to be small (~1-2KB). Do NOT dump the full context ledger into memory — use concise summaries.
- If
memory_dirdoes not exist, emit an error and notify the workflow. - Memory files are never deleted — they accumulate as a historical record of sessions.
- Multiple sessions for the same project are expected (different timestamps).
Error Handling
savecalled with missingmemory_dir: Emit error"memory directory not found at {memory_dir}"and halt.load-lastfinds no matching files: Return empty with informational message (not an error — new projects won't have memory).- Corrupted or unreadable file: Skip it and try the next most recent. If all fail, return empty with warning.