Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/joris887/exosuitnpx agentmods add skills/joris887/exosuit/retrospectiveWrote 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/skills/joris887/exosuit/retrospective)<a href="https://agentmods.dev/skills/joris887/exosuit/retrospective"><img src="https://agentmods.dev/badge/skills/joris887/exosuit/retrospective.svg" alt="Measured on agentmods" 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.00030 | $0.02751 |
| Opus 5 | $0.00015 | $0.01375 |
| Sonnet 5 | $0.00006 | $0.00550 |
| Haiku 4.5 | $0.00003 | $0.00275 |
Grade A, and why
retrospective 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 8d 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 — 260 lines — stays where its author put it; the contents beside it link to each section on GitHub.
retrospective
Run a sprint or weekly retrospective:
1. Gather Data
Read sprint specs and progress to build a complete picture:
- Read
docs/progress.md→## Sprint Historytable for trend data - Read the sprint spec(s) being reviewed:
docs/sprints/sprint-N.md— especially the## Outcomeand## Decisionssections - Git log for commits and their messages
- Any blockers or issues encountered (from sprint spec
## Notesand## Decisions)
2. Metrics Dashboard
2.1. Progress Metrics (single source of truth)
Read docs/progress.md → ## Metrics table and display it directly — sprint-end already computed these values.
| Metric | Current | Target | Trend | Status |
|---|---|---|---|---|
| [Copy all rows from progress.md Metrics table] |
Sprint note: [Copy from progress.md if present]
2.2. Sprint-over-Sprint Comparison
Read docs/progress.md → ## Sprint History table. Extract the last 2 rows (current and previous sprint):
| Metric | This Sprint | Previous | Δ | Direction |
|---|---|---|---|---|
| Goal achieved | [✅/❌] | [✅/❌] | — | [streak] |
| Tasks completed | [X] | [Y] | [+/-] | [↑/↓/→] |
| Cycle time | [X.Xd] | [Y.Yd] | [+/-] | [↑/↓/→] |
| Change failure rate | [X%] | [Y%] | [+/-] | [↑/↓/→] |
| Test coverage Δ | [+X%] | [+Y%] | [+/-] | [↑/↓/→] |
| Code churn ratio | [0.XX] | [0.YY] | [+/-] | [↑/↓/→] |
| AI effectiveness | [0.XX] | [0.YY] | [+/-] | [↑/↓/→] |
| Sprint satisfaction | [X/5] | [Y/5] | [+/-] | [↑/↓/→] |
Also extract from sprint spec (docs/sprints/sprint-N.md → ## Outcome):
- Sprint churn: % stories added/removed mid-sprint (target <20%, >40% = broken planning)
- Done-to-commit ratio: completed/planned (80% healthy, >95% = under-committing, <65% = over-committing)
2.3. Leading vs Lagging Analysis
Read references/metrics-analysis.md for the leading/lagging classification.
From the Sprint History's last 3 rows, assess the trend direction for each group:
- Leading indicators (churn, coverage Δ, satisfaction): [improving / stable / degrading]
- Lagging indicators (CFR, tasks): [improving / stable / degrading]
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 8d ago First seen · 260 lines · 30 tokens per session scan A 2badc714adf1
retrospective is a skill published in the GitHub repository joris887/exosuit (4 stars, last pushed 18d ago), licensed MIT. It adds 30 tokens to every session and 2,751 once invoked, about $0.0002 per session on Opus 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-31.
Other skills, from other repositories
issue-triage
3-phase issue backlog management with audit, deep analysis, and validated triage actions. Use when triaging GitHub issues, sorting bug reports, cleaning up stale tickets, or detecting duplicate issues. Args: 'all' to analyze all, issue numbers to focus (e.g. '42 57'), 'en'/'fr' for language, no arg = audit only.
orchestrator-lanes
A file-based project-management playbook for a specific Claude Code development orchestrator. It organizes work into lanes, plans, dependency steps, validation phases, and shipping stages.
project-life
A system for keeping project ideas, tasks, plans, progress, decisions, and lessons in one place. A monorepo-style project workflow is implied, but the input does not define the storage format in full.
lane-contract
A file-based task contract system for describing coding tasks in YAML, including which files a task owns and how it must be checked.
plan-pipeline
Orchestrates the complete planning pipeline: product direction (ceo-review) -> architecture (eng-review) -> implementation plan (start) -> validation (validate) -> execution (execute). Run stages individually or let the orchestrator coordinate the full flow.
seo-project-life
A guide to the files, commands, stages, and working process of an SEO project. SEO, or search-engine optimization, is the work of improving a site's visibility in search results.