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 griddynamics/rosetta --skill post-mortemgit clone --depth 1 https://github.com/griddynamics/rosettaWrote 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/griddynamics/rosetta/post-mortem)<a href="https://agentmods.dev/skills/griddynamics/rosetta/post-mortem"><img src="https://agentmods.dev/badge/skills/griddynamics/rosetta/post-mortem/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/skills/griddynamics/rosetta/post-mortem"><img src="https://agentmods.dev/badge/skills/griddynamics/rosetta/post-mortem.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.02076 |
| Opus 5.5 | $0.00007 | $0.00830 |
| Sonnet 5.5 | $0.00003 | $0.00415 |
| Haiku 4.5 | $0.00002 | $0.00208 |
Grade A, and why
post-mortem 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 — 135 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<post_mortem>
<core_concepts>
- All Rosetta prep steps MUST be FULLY completed, load-context skill loaded and fully executed
- Explicit user invocation only; never auto-runs. Reviews the ENTIRE harness that produced the outcome — user prompt · workspace files (docs/rules/plans/memory) · repo-local instructions/config · Rosetta instructions (skills/agents/workflows/rules) · tooling — NOT the user's artifact.
- Root cause, not symptoms: the defect is in the harness, not the artifact it produced. Fix = GENERALIZED, REUSABLE preventive rule — not an incident-specific patch.
- Attribute every defect to a layer: prompt | workspace files | local config | Rosetta instruction | tooling. Most failures are local; do NOT default to blaming Rosetta.
- Tone: direct, blunt, harsh on defects — no sugarcoating, hedging, or diplomatic filler. Call broken prompts, files, and instructions broken. Critique the harness, never people.
- 2 phases, hard gate between: ① post-mortem report with recommendations per layer → ② GitHub issue to
griddynamics/rosetta, offered ONLY when a defect is attributed to Rosetta instructions. ② NEVER starts without explicit opt-in. - Submission MUST be sanctioned: question/suggestion/edit/"fix it" = review ≠ approval. Unclear answer ≠ "no" → ASK AGAIN directly. Re-asking is allowed and expected; unsanctioned submitting is not.
- Issue is PUBLIC: Rosetta instruction feedback ONLY · zero target-repo IP/data.
- Outputs are required as checkpoints and to finalize thinking and to prevent failures we saw in practice.
- Severity: P0 unsafe/false/unusable · P1 quality/reliability/cost/token consumption/privacy risk · P2 friction/duplication/variance · P3 nice-to-have.
</core_concepts>
① Post-mortem (always), strictly in this order:
- Collect evidence from available context only: request · instructions used · workspace files read · tool calls · retries · blockers · artifacts · output. Run not in context → ask for it; NEVER invent history.
- OUTPUT evidence inventory — available vs missing. ONLY THEN proceed.
- Assess every layer: prompt clarity/completeness · inferred-vs-told requirements · workspace files (stale, wrong, missing, contradictory) · repo-local instructions/config · Rosetta instruction ambiguity/gaps · execution errors · repeated same-approach retries · duplicated effort · tooling/context friction · validation gaps · user-input timing · handoff quality (per subagent if multi-agent).
- OUTPUT candidate issue list — one line each, suspected layer. ONLY THEN proceed.
- Take ONE candidate: drill to ROOT CAUSE and attribute the layer: symptom → which prompt phrase / file section / instruction line caused it → why (ambiguity/gap/contradiction/missing gate/stale data). Quote the source; state expected vs actual behavior. Ambiguous → ask 1-3 clarifying questions, do not guess.
- OUTPUT that candidate's verdict — root cause + verbatim proofs, confirmed or dropped. ONLY THEN take the next candidate: repeat 5-6 until none remain.
- ONLY AFTER all candidates concluded: convert each confirmed root cause into a generalized preventive change: local layers → concrete edit the user should make (exact file/section + proposed content); Rosetta layer → instruction change proposal (exact file/section + proposed rule + failure mode prevented).
- OUTPUT recommended changes per layer. ONLY THEN proceed.
- Store generalized rules in AGENT MEMORY.md (init if missing): what worked and what failed — logically, architecturally, technically. Concise, organized, reusable.
- OUTPUT final report via template — assembled ONLY from steps 2/4/6/8 outputs, no new findings. Material/recurring issues only; uncertain → label low-confidence. RECOMMEND local fixes to the user; apply NOTHING.
② GitHub issue (only if ≥1 defect attributed to Rosetta instructions; otherwise state "nothing Rosetta-attributable" and stop):
- GATE A: ask directly — "File the Rosetta-attributed finding(s) as a GitHub issue to griddynamics/rosetta?" Clear no → stop ②. Unclear/partial answer → RE-ASK directly until clear yes/no. NEVER proceed on silence or assumption.
- ONLY AFTER a clear yes: sanitize — strip ALL target-repo IP and sensitive data — code · file contents/names · business logic · product/client/company names · internal URLs/hosts/datasets · usernames · emails · tickets · secrets/credentials/tokens/keys · PII · etc. Unavoidable refs →
<project>,<file>. Keep: Rosetta component, release, IDE/agent, model. - OUTPUT COMPLETE draft verbatim — final title + body, fenced — with sanitization checklist result. ONLY THEN proceed.
- GATE B: submit ONLY when sanctioned by the exact sentence
Submit the issue as drafted. Question → answer it, then RE-ASK. Comment/edit → revise → re-OUTPUT full draft → RE-ASK. Unclear → ask directly "Approve submission, or revise?". Loop until sanctioned or declined. - ONLY AFTER sanction: submit —
gh issue create --repo griddynamics/rosetta --title <t> --body <b>.ghmissing/unauthed → hand user the draft +https://github.com/griddynamics/rosetta/issues/new; NO other channels. - Report issue URL. Change NOTHING else — this skill fixes nothing.
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 · 135 lines · 17 tokens per session scan A 8eedc34de3dd
post-mortem is a skill published in the GitHub repository griddynamics/rosetta (362 stars, last pushed yesterday), licensed Apache-2.0. It adds 17 tokens to every session and 2,076 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 skills, from other repositories
memorix-troubleshooting
Use when Memorix MCP, setup, project binding, HTTP control plane, hooks, skills, or agent integration is missing, stale, or failing.
systemic-issue-triage
Trigger: new issue, bug report, triage, backlog, issue flood, community report, root cause, dead-end, blocked user. Attack issues by root class, never one-by-one; fixes must shrink the system, not grow it.
issue-root-resolution
Trigger: root audit, atacar la raíz, issue roots, backlog roots, mechanism map, deletion-driven fix, resolver issues de raíz, close outdated issues. Audit and resolve issue clusters by verified root cause.
debug-remote
Attach to a running Windows process through a WinDbg debug server and inspect it live. Use when the user wants to debug a process on another machine, or one already under a .server session, rather than a crash dump.
windbg-doctor
Check that this machine can actually debug - MCP connection reachable, debugger present, symbols configured - and explain how to fix whatever is missing. Use when mcp-windbg tools fail, when a session will not open, or before a first debugging session.
debug-live
Guides root-cause investigations with debugging capabilities by setting breakpoints, starting a debug session, stepping through execution, inspecting variables, and tracing symptoms back to their origin. Prefer it for runtime bugs, failing tests, exceptions, crashes, hangs, wrong/null values, and unexpected output…