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.
npx skills add CoralGame/Claude-Code-Game-Studios --skill retrospectivegit clone --depth 1 https://github.com/CoralGame/Claude-Code-Game-StudiosWrote 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/coralgame/claude-code-game-studios/retrospective)<a href="https://agentmods.dev/skills/coralgame/claude-code-game-studios/retrospective"><img src="https://agentmods.dev/badge/skills/coralgame/claude-code-game-studios/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.00032 | $0.01462 |
| Opus 5 | $0.00016 | $0.00731 |
| Sonnet 5 | $0.00006 | $0.00292 |
| Haiku 4.5 | $0.00003 | $0.00146 |
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 5d 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.
This is a copy
100% identical to retrospective — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 159 lines — stays where its author put it; the contents beside it link to each section on GitHub.
When this skill is invoked:
-
Read the argument to determine whether this is a sprint retrospective (
sprint-N) or a milestone retrospective (milestone-name). -
Read the sprint or milestone plan from the appropriate location:
- Sprint plans:
production/sprints/ - Milestone definitions:
production/milestones/
Extract: planned tasks, estimated effort, owners, and goals.
- Sprint plans:
-
Read the git log for the period covered by the sprint or milestone to understand what was actually committed and when.
-
Scan for completed and incomplete tasks by comparing the plan against actual deliverables. Check for:
- Tasks completed as planned
- Tasks completed but modified from the plan
- Tasks carried over (not completed)
- Tasks added mid-sprint (unplanned work)
- Tasks removed or descoped
-
Scan the codebase for TODO/FIXME trends:
- Count current TODO/FIXME/HACK comments
- Compare to previous sprint counts if available (check previous retrospectives)
- Note whether technical debt is growing or shrinking
-
Read previous retrospectives (if any) from
production/sprints/orproduction/milestones/to check:- Were previous action items addressed?
- Are the same problems recurring?
- How has velocity trended?
-
Generate the retrospective:
## Retrospective: [Sprint N / Milestone Name]
Period: [Start Date] -- [End Date]
Generated: [Date]
### Metrics
| Metric | Planned | Actual | Delta |
|--------|---------|--------|-------|
| Tasks | [X] | [Y] | [+/- Z] |
| Completion Rate | -- | [Z%] | -- |
| Story Points / Effort Days | [X] | [Y] | [+/- Z] |
| Bugs Found | -- | [N] | -- |
| Bugs Fixed | -- | [N] | -- |
| Unplanned Tasks Added | -- | [N] | -- |
| Commits | -- | [N] | -- |
### Velocity Trend
| Sprint | Planned | Completed | Rate |
|--------|---------|-----------|------|
| [N-2] | [X] | [Y] | [Z%] |
| [N-1] | [X] | [Y] | [Z%] |
| [N] (current) | [X] | [Y] | [Z%] |
**Trend**: [Increasing / Stable / Decreasing]
[One sentence explaining the trend]
### What Went Well
- [Observation backed by specific data or examples]
- [Another positive observation]
- [Recognize specific contributions or decisions that paid off]
### What Went Poorly
- [Specific issue with measurable impact -- e.g., "Feature X took 5 days
instead of estimated 2, blocking tasks Y and Z"]
- [Another issue with impact]
- [Do not assign blame -- focus on systemic causes]
### Blockers Encountered
| Blocker | Duration | Resolution | Prevention |
|---------|----------|------------|------------|
| [What blocked progress] | [How long] | [How it was resolved] | [How to prevent recurrence] |
### Estimation Accuracy
| Task | Estimated | Actual | Variance | Likely Cause |
|------|-----------|--------|----------|--------------|
| [Most overestimated task] | [X] | [Y] | [+Z] | [Why] |
| [Most underestimated task] | [X] | [Y] | [-Z] | [Why] |
**Overall estimation accuracy**: [X%] of tasks within +/- 20% of estimate
[Analysis: Are we consistently over- or under-estimating? For which types of
tasks? What adjustment should we apply?]
### Carryover Analysis
| Task | Original Sprint | Times Carried | Reason | Action |
|------|----------------|---------------|--------|--------|
| [Task that was not completed] | [Sprint N-X] | [N] | [Why] | [Complete / Descope / Redesign] |
### Technical Debt Status
- Current TODO count: [N] (previous: [N])
- Current FIXME count: [N] (previous: [N])
- Current HACK count: [N] (previous: [N])
- Trend: [Growing / Stable / Shrinking]
- [Note any areas of concern]
### Previous Action Items Follow-Up
| Action Item (from Sprint N-1) | Status | Notes |
|-------------------------------|--------|-------|
| [Previous action] | [Done / In Progress / Not Started] | [Context] |
### Action Items for Next Iteration
| # | Action | Owner | Priority | Deadline |
|---|--------|-------|----------|----------|
| 1 | [Specific, measurable action] | [Who] | [High/Med/Low] | [When] |
| 2 | [Another action] | [Who] | [Priority] | [When] |
### Process Improvements
- [Specific change to how we work, with expected benefit]
- [Another improvement -- keep it to 2-3 actionable items, not a wish list]
### Summary
[2-3 sentence overall assessment: Was this a good sprint/milestone? What is
the single most important thing to change going forward?]
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.
- 5d ago First seen · 159 lines · 32 tokens per session scan A fa9de8f3d762
retrospective is a skill published in the GitHub repository CoralGame/Claude-Code-Game-Studios (19 stars, last pushed 5mo ago), licensed MIT. It adds 32 tokens to every session and 1,462 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to retrospective, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
recipe-create-meet-space
Create a Google Meet meeting space and share the join link.
workthreads
SpecStory Workthreads - a weekly work-thread rollup across a team's repos from SpecStory coding histories (any agent - Claude Code, Codex, Cursor, Gemini, and more). It groups the window's sessions into threads of work per project and labels each new / open / recently closed, so a lead sees what shipped, what is still…
atmos-config
Atmos root configuration: atmos.yaml discovery, precedence, deep merging, basepath, imports, minimal bootstrap, and routing to narrower Atmos skills.
story-readiness
Validate that a story file is implementation-ready. Checks for embedded GDD requirements, ADR references, engine notes, clear acceptance criteria, and no open design questions. Produces READY / NEEDS WORK / BLOCKED verdict with specific gaps. Use when user says 'is this story ready', 'can I start on this story', 'is…
autotask-creator
Rules for automation CRUD from the group-chat commander. The commander does not call mutation tools and does not edit cloud/autotasks files directly. It emits one or more top-level ... containers in its final text; the bus parses and applies them after the turn.
monorepo-management
Master monorepo management with Turborepo, Nx, and pnpm workspaces to build efficient, scalable multi-package repositories with optimized builds and dependency management. Use when setting up monorepos, optimizing builds, or managing shared dependencies.