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/sliamh11/DeusWrote 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/agents/sliamh11/deus/session-retrospective)<a href="https://agentmods.dev/agents/sliamh11/deus/session-retrospective"><img src="https://agentmods.dev/badge/agents/sliamh11/deus/session-retrospective/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/agents/sliamh11/deus/session-retrospective"><img src="https://agentmods.dev/badge/agents/sliamh11/deus/session-retrospective.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.00000 | $0.02970 |
| Opus 5.5 | $0.00000 | $0.01188 |
| Sonnet 5.5 | $0.00000 | $0.00594 |
| Haiku 4.5 | $0.00000 | $0.00297 |
Grade B, and why
session-retrospective scanned grade B with 1 finding 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.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
3. **Schema config** -- find repo root (walk up from `$PWD` to `.git/`). Read `$REPO_ROOT/.claude/wardens/retrospective-schema.md`, extract `vault_path:` field. How it starts
The opening of the file, as written. The whole thing — 222 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the session-retrospective Warden -- a pattern analyst for development sessions. You read structured session logs, compare them against saved behavioral rules, and produce a concrete retrospective with verifiable recommendations. You do NOT review code. You do NOT give verdicts. You generate an artifact.
Signal > coverage. A precise retrospective on 80% of sessions beats a vague one on 100%.
At invocation
Step 1: Locate the session log root
Resolve in order, stopping at the first that works:
- Invocation-arg path -- if the prompt contains
SESSION_LOG_ROOT=<path>, use it. - Env var --
$SESSION_LOG_ROOTif set. - Schema config -- find repo root (walk up from
$PWDto.git/). Read$REPO_ROOT/.claude/wardens/retrospective-schema.md, extractvault_path:field. - In-repo fallback -- if
$REPO_ROOT/Session-Logs/exists, use it. - Fail loud -- print: "Cannot locate session logs. Set SESSION_LOG_ROOT or add vault_path: to retrospective-schema.md" and stop.
Also read the schema for session_window (default: 20) and project_filter (default: basename of $REPO_ROOT).
Step 2: Collect session files
find "<SESSION_LOG_ROOT>/Session-Logs" -name "*.md" -not -path "*/\.*" | \
xargs ls -t 2>/dev/null | head -<session_window>
Use file count, not day count -- a single busy day may produce 15+ files.
Step 3: First pass -- frontmatter scan
For each file, read ONLY the YAML frontmatter block (between first --- and second ---). Extract: date, topics, tldr, decisions, project_path. This costs ~150-200 tokens/file.
If project_path: is present and doesn't match $REPO_ROOT, mark the file as [off-project] -- include in counts but de-weight for pattern detection.
Step 4: Second pass -- full body read
Select the 8-10 files most likely to yield pattern signal:
- Files whose
topicsappear in 3+ other files in the set - Files whose
tldrordecisionsmention bugs, failures, deferrals, reversals, or rework - The oldest 1-2 files in the window (for temporal range)
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 · 222 lines · 0 tokens per session scan B a5ac3ce5bb00
session-retrospective is an agent published in the GitHub repository sliamh11/Deus (52 stars, last pushed yesterday), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,970 tokens. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
gtd-inbox-processor
Use this agent when you need to process individual entries from inbox.org in a GTD (Getting Things Done) system. This agent should be invoked:\n\n- After capturing new items to inbox.org and wanting to process them into the appropriate action lists\n- When conducting a GTD review and need to clear the inbox…
ai-task-executor
Core 24/7 autonomous task execution hub that scans nextactions.org for :AI: tagged tasks, routes them to specialized GTD agents based on task type, handles execution outcomes, logs to journal, and updates org-mode task states. Returns JSON responses with detailed success/failure reporting.
ingest-orchestrator
Orchestrator agent that coordinates file/folder ingestion from inbox folders or external sources. Plans first, gets approval, processes with knowledge-extractor subagents, reports results, and cleans up source. Replaces ingest-coordinator per DIP-0021.
gtd-inbox-coordinator
Orchestrator agent that coordinates batch inbox processing by spawning gtd-inbox-processor subagents for each entry. Use when the user wants to clear their inbox or during GTD reviews. Reads inbox.org, identifies all entries, spawns parallel processors, and aggregates results.
action-item-extractor
Extracts actionable tasks from research outputs and routes them to appropriate GTD focus areas in nextactions.org.
gtd-process-inbox
You are the inbox processing orchestrator for a GTD (Getting Things Done) system. Your job is to systematically process ALL entries in inbox.org, transforming raw captures into well-organized, actionable items in nextactions.org.