Session reset
Preserve session-specific state in PROMPT.md across a /clear, then restore afterwards.
PROMPT.md captures only session-specific state — current task, method, and progress. Persistent knowledge (user preferences, codebase patterns, dev quirks, workflow lessons) is handled separately by auto-memory and must NOT be included in PROMPT.md.
Workflow
1. Commit and push
Check git status for uncommitted changes. If there are any:
Security check — before staging, scan changed files for secrets. Flag and exclude any files matching common sensitive patterns (.env*, *.key, *.pem, credentials.*, *secret*, *.token). Warn the user if any are found and never stage them without explicit confirmation.
Then ask the user:
- Commit and push — stage safe changes, commit with a concise message, and push to the current branch
- Commit only — stage and commit without pushing
- Skip — leave changes as-is
If the user chooses to commit, use /commit. If they also want to push, push after the commit succeeds.
If the working tree is already clean, tell the user "Working tree is clean — nothing to commit." and move on.
2. Write PROMPT.md
Generate PROMPT.md at the project root by reviewing the current session state. PROMPT.md is ephemeral and must never be committed.
# PROMPT.md
## Current task
<!-- What we're working on - the goal, feature, or fix -->
## Method
<!-- Which workflow/approach is active (e.g. OpenSpec, manual, etc.) -->
<!-- Include any active change IDs, branch names, or tracking references -->
## Progress
<!-- Where we are in the process -->
<!-- What's done, what's in flight, what's next -->
<!-- Any blocking issues or open questions -->Guidelines:
- Do NOT include user preferences, codebase patterns, dev quirks, or general knowledge — auto-memory handles that
- Do include task-specific context: current branch, active OpenSpec change, what's done, what's next, blocking issues
- Be specific and actionable — include file paths, branch names, change IDs, and concrete references
- Keep it concise — typically 20-40 lines
3. Tear down team (if active)
If a team is active (check for team config in $CONFIG_DIR/teams/):
- Read the team config to discover all active members
- List the active members to the user and confirm they want to tear down the team
- Send
shutdown_requestto each teammate - Wait for confirmations
- Delete the team with
TeamDelete
If no team is active, tell the user "No active team — skipping teardown." and move on.
4. Guide the user
After teardown, output this message exactly:
Session state saved to PROMPT.md. All agents shut down.
Run `/clear` now, then tell me: **read PROMPT.md**5. Restore (post-clear)
When the user says "read PROMPT.md" after a /clear:
- Read PROMPT.md from the project root
- Summarise the restored context to the user
- Resume work based on the progress section