| name | brief |
| version | 2.0.0 |
| description | /brief - Write session brief, commit, and push. Run at end of session to checkpoint all work. |
Session Brief
Run this at the end of a session to capture context and checkpoint all work to GitHub.
Steps
1. Review Existing Brief
Read /brief/session-brief.md to understand what was there from last session.
2. Write the New Brief
Overwrite /brief/session-brief.md with a comprehensive brief covering:
- Date, time (EST), and session number at the top
- Important progress made in the current session
- Key decisions and architectural changes
- Unfinished tasks and next steps
- Technical details that need to be preserved
- Any context that would be lost between sessions
This is NOT about brevity — be as thorough as needed to retain all important context.
2.5. Reflect on Skills
After writing the brief, run the reflect skill to scan the conversation for learnings. This is a delegation, not a repeat of the reflect instructions. Load and follow the reflect skill.
- If learnings are found: present them to the user alongside the brief, before asking about git
- If no learnings: report "no new skill learnings detected" in one line and continue to Step 3
- Any approved skill updates will be committed together with the brief in Step 4
3. Ask About Git
After writing the brief, always ask the user which option they want:
- Commit + push — full checkpoint to GitHub
- Commit only — local save point, push later
- Brief only — just the file update, no git operations
Present these as a quick choice. Do NOT assume commit+push.
4. If Committing (options 1 or 2)
- Run
git status to see all changes (staged + unstaged + untracked)
- Run
git log --oneline -3 to match commit message style
- Stage all relevant files (
git add — use specific paths, not -A)
- Commit with message format:
Session [N]: [1-2 sentence summary of session work]
- If option 1, push to origin:
git push
Commit rules:
- Do NOT stage files that look like secrets (
.env, credentials, tokens)
- If there are uncommitted changes unrelated to this session, ask the user before including them
- If push fails (e.g., remote is ahead), stop and ask the user — do not force push
When to Use
- At the end of significant sessions
- When important decisions have been made
- Before ending a session where critical details might be lost
- When the user explicitly requests
/brief
Read-Only Mode
When asked to "read the brief" (typically at session start via /start), just read the file without modifying it. Do not commit or push in read-only mode.