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 swan-gtm/gtm-skills --skill post-event-roi-reportgit clone --depth 1 https://github.com/swan-gtm/gtm-skillsWrote 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/swan-gtm/gtm-skills/post-event-roi-report)<a href="https://agentmods.dev/skills/swan-gtm/gtm-skills/post-event-roi-report"><img src="https://agentmods.dev/badge/skills/swan-gtm/gtm-skills/post-event-roi-report/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/swan-gtm/gtm-skills/post-event-roi-report"><img src="https://agentmods.dev/badge/skills/swan-gtm/gtm-skills/post-event-roi-report.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.00069 | $0.01902 |
| Opus 5.5 | $0.00028 | $0.00761 |
| Sonnet 5.5 | $0.00014 | $0.00380 |
| Haiku 4.5 | $0.00007 | $0.00190 |
Grade A, and why
post-event-roi-report 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 2d 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 — 112 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Post-event ROI report
Build a view that answers one question for the review meeting: what did {{EVENT_NAMES}} produce, and what is stuck? The lead list says who we met. The CRM says what became pipeline. When they disagree, the CRM wins.
Template placeholders
Replace every {{...}} before running.
{{EVENT_NAMES}}: the events being measured, exactly as they appear in the lead list's Event column{{EVENT_START_DATE}}: the first day of the first event; the cutoff for new versus pre-existing pipeline{{DAY_30_DATE}},{{DAY_60_DATE}}: the two checkpoint dates{{SPREADSHEET}}: where the event lead list lives{{ICP_FLOOR}}: the minimum employee count that counts toward the totals{{CURRENCY}}: currency for spend and pipeline{{TIER_LIST}}: your account tiers{{STALL_DEMO_DAYS}},{{STALL_STAGE_DAYS}}: stall thresholds (for example 10 and 14){{SPECIALIST_TEAM}}: a team follow-ups often wait on, such as RevOps
Inputs
Event lead list ({{SPREADSHEET}}, re-read on every load, never hardcoded). One row per account. Several people at one account stay on one row and count once. Columns used:
- Company, Person, Title, Employees, Tier, Owner, Priority
- Event (must match one of {{EVENT_NAMES}} or "Both")
- Meeting status, Demo held (date), Opp created (date), Opp amount, Opp stage
- Next step, Follow up by (date), Notes
Side tabs. Partners, community and investors go in their own section and stay out of every total. Accounts under {{ICP_FLOOR}} employees stay out of the totals and appear only as a count in a footnote.
CRM deals. Name, amount, stage, create date, close date, date entered current stage, closed-won and closed-lost flags. Fetch every deal created in the last year and match in code. Do not query one account at a time.
Manual input. Event spend in {{CURRENCY}}. The list does not hold it. Store it, and leave the ratios blank until someone enters it.
Attribution rules
- An account counts only if Event names one of {{EVENT_NAMES}} or "Both". Rows marked "Not an event lead" or "Unknown" go to a separate "Other leads needing a reply" list. They do not count toward ROI.
- Match accounts to deals by normalized company name (lowercase, letters and digits only). Handle parenthetical aliases. Accept a prefix match only when both names are six or more characters. Report unmatched event accounts so a person can check them.
- Exclude pre-existing pipeline. A deal created before {{EVENT_START_DATE}} is not event pipeline. Use the CRM create date first. Fall back to a note such as "already in pipeline before the events" or a status of "Existing deal". Show these accounts as "Influenced (existing pipeline)", with the reason, outside the headline.
- An account with both an old deal and a new deal created on or after the start date counts on the new deal.
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.
- 2d ago First seen · 112 lines · 69 tokens per session scan A d691194d60f0
post-event-roi-report is a skill published in the GitHub repository swan-gtm/gtm-skills (181 stars, last pushed 2d ago), licensed MIT. It adds 69 tokens to every session and 1,902 once invoked, about $0.0003 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-10-15.
Other skills, from other repositories
webhook-subscriptions
Webhook subscriptions: event-driven agent runs.
k8s-workload-inventory
List Kubernetes workloads and namespaces — pods with their node, phase and readiness, plus events. Use when asked what is running, where it is running, what is failing, or for a general inventory of a cluster.
luma-event-insights
Starter skill for analyzing Lu.ma events, attendees, invites, and engagement signals from organizer-provided API access, exports, or manual event inputs. Use this when a template or workflow needs a repeatable path to turn Lu.ma event data into an organizer-ready analysis brief.
huawei-cloud-cce-kubernetes-event-analyzer
Query and analyze Kubernetes Events in Huawei Cloud CCE clusters. Trigger when users ask about CCE events, Kubernetes warning events, FailedScheduling, FailedMount, ImagePullBackOff, event patterns, historical events in LTS, or event-based diagnosis for a CCE cluster or namespace.
cairo-contract-authoring
Cairo smart-contract authoring on Starknet. Trigger on "write a contract", "create a contract", "implement this in Cairo", "add storage/events/interface", "compose components". Guides structure, security patterns, and component wiring.
backend-event-sourcing
Use this skill when the user says 'event sourcing', 'event store', 'event stream', 'event sourced', 'rehydrate from events', 'event replay', 'projection rebuild', 'event log', 'append-only log', 'event history'. This skill enforces: events as the single source of truth, current state derived from event replay…