Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/ThierryN/fire-flowWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/thierryn/fire-flow/fire-session-summary)<a href="https://agentmods.dev/commands/thierryn/fire-flow/fire-session-summary"><img src="https://agentmods.dev/badge/commands/thierryn/fire-flow/fire-session-summary/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/thierryn/fire-flow/fire-session-summary"><img src="https://agentmods.dev/badge/commands/thierryn/fire-flow/fire-session-summary.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00017 | $0.01802 |
| Opus 5.5 | $0.00007 | $0.00721 |
| Sonnet 5.5 | $0.00003 | $0.00360 |
| Haiku 4.5 | $0.00002 | $0.00180 |
Grade A, and why
fire-session-summary scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 253 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/fire-session-summary
Compact forward-looking session summary — fills the gap between full WARRIOR handoffs and the memory system
Purpose
Generate a lightweight session summary capturing what the memory system doesn't: aggregate status, readiness assessment, forward planning, and concrete next steps. Saved as a searchable memory point (source type: session_summary), indexed automatically by the session-end consolidation hook.
Not a replacement for /fire-5-handoff. Use handoffs for milestones. Use this for every session — it's fast, compact, and auto-indexed.
Arguments
arguments: none
optional_flags:
--project: "Override project name detection"
--no-save: "Display summary without saving to file"
Process
Step 1: Gather Context (30 seconds)
Quickly scan what happened this session. Do NOT re-read entire files — use what you already know from conversation context.
Collect from conversation context:
- What tasks/features were worked on
- What was completed vs left partial
- What blockers were hit
- What decisions were made
- What files were created/modified
IF in a git repo:
git log --oneline --since="4 hours ago" 2>/dev/null | head -10
IF .planning/CONSCIENCE.md exists:
Read current phase and status (first 20 lines only)
Step 2: Detect Project Name
Priority order:
1. --project flag if provided
2. .planning/VISION.md project name
3. Git repo name (basename of git root)
4. Current directory name
5. "general" (fallback for System32/multi-project sessions)
Step 3: Generate Summary
Write the summary using EXACTLY this template. Keep each section to 2-4 lines max.
---
session: {YYYY-MM-DD}
project: {detected project name}
type: session_summary
---
# Session Summary: {YYYY-MM-DD}
## Status
| Item | State | Detail |
|------|-------|--------|
| {work item 1} | DONE / PARTIAL / BLOCKED | {one-line detail} |
| {work item 2} | DONE / PARTIAL / BLOCKED | {one-line detail} |
## Readiness
- **Ready:** {what next session can immediately start on}
- **Blocked:** {external blockers, or "None"}
- **Needs first:** {prerequisites before main work, or "Nothing"}
## Outlook
- **Trajectory:** {on-track / behind / ahead / exploratory}
- **Risk:** {key risk, or "Low"}
- **Momentum:** {what's going well — one line}
## Next Steps
1. **{Priority 1}** — {specific actionable description}
2. **{Priority 2}** — {specific actionable description}
3. **{Priority 3}** — {specific actionable description}
## Decisions Made
- {Decision — rationale in 10 words or less}
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 253 lines · 17 tokens per session scan A 56866328e7ad
fire-session-summary is a command published in the GitHub repository ThierryN/fire-flow (78 stars, last pushed 2mo ago), licensed MIT. It adds 17 tokens to every session and 1,802 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
pull-learnings
Pulls shared organization patterns into local org-patterns.toon.
recall-loop
Periodic memory digest — designed for use with Claude Code's /loop scheduler. Shows recent memories and pending to-dos in a compact, scannable format.
end
End a session — log what happened and propose durable memory updates.
start
Start a session — load context + memory and brief yourself on current state.
update
Mid-session checkpoint — save progress without ending the session.
mem-worklog
Turn a week of session archives into a worklog — daily hours table prorated over a fixed daily amplitude, plus an activity report and next-week objectives.