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 vigneshbarani24/sap-superpowers --skill go-live-readinessgit clone --depth 1 https://github.com/vigneshbarani24/sap-superpowersWrote 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/vigneshbarani24/sap-superpowers/go-live-readiness)<a href="https://agentmods.dev/skills/vigneshbarani24/sap-superpowers/go-live-readiness"><img src="https://agentmods.dev/badge/skills/vigneshbarani24/sap-superpowers/go-live-readiness/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/vigneshbarani24/sap-superpowers/go-live-readiness"><img src="https://agentmods.dev/badge/skills/vigneshbarani24/sap-superpowers/go-live-readiness.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.00060 | $0.03340 |
| Opus 5 | $0.00030 | $0.01670 |
| Sonnet 5 | $0.00012 | $0.00668 |
| Haiku 4.5 | $0.00006 | $0.00334 |
Grade A, and why
go-live-readiness 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 12d 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 — 201 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SAP Go-Live Readiness Assessment
This skill enforces evidence-based go-live approval — blocking the "everything looks good" declaration and replacing it with a mandatory, dimension-by-dimension readiness checklist where every Green status requires attached evidence, not assertion.
Iron Laws
- NEVER DECLARE "GO-LIVE READY" WITHOUT COMPLETING EVERY CHECKLIST ITEM. Partial readiness is not readiness. A system that is 95% ready is not ready. Missing items are documented risks, not excuses to proceed.
- RED STATUS ITEMS BLOCK GO-LIVE — NO EXCEPTIONS, NO OVERRIDES. A Red item means the condition is unmet. No business pressure, no timeline argument, and no seniority overrides a Red status. Red = stop.
- EVERY READINESS CLAIM MUST HAVE ATTACHED EVIDENCE, NOT ASSERTION. "Training is complete" is an assertion. A signed training attendance register is evidence. "Data is loaded" is an assertion. A business-approved reconciliation report is evidence.
- NEVER SKIP BUSINESS SIGN-OFF ON DATA MIGRATION RECONCILIATION. Business owners — not technical teams — must confirm that migrated data is correct. A Basis consultant saying "data looks good" is not business sign-off.
- GO/NO-GO DECISION REQUIRES NAMED DECISION-MAKERS, NOT CONSENSUS. The decision must be owned by identified individuals who are accountable for it. "The team agreed" is not a Go/No-Go decision.
- AMBER STATUS REQUIRES FORMAL RISK ACCEPTANCE BEFORE PROCEEDING. An Amber item with no documented risk acceptance is a hidden Red. Every Amber must have a named risk owner, a mitigation action, and a written acceptance.
Rationalization Table
| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |
|---|---|---|---|
| Declare readiness based on gut feel | "The team has been working hard and things feel solid" | Go-live failures are not caused by team effort — they are caused by specific unmet conditions that feeling cannot detect. | Iron Law 1: Every dimension must be assessed on its checklist, not on team confidence. |
| Skip the security readiness dimension | "Security was handled during configuration; it's not a go-live item" | Role assignments frequently have errors discovered only at go-live. SoD conflicts undetected pre-go-live become audit findings post-go-live. Auth errors are the number one cause of day-one user escalations. | Checklist Step 6: Security readiness is a mandatory dimension with its own evidence requirements. |
| Accept "training is complete" without evidence | "The training team said it's done" | Training completion without attendance records means unknown users are untrained. Untrained users = day-one call volume spike and business process errors. | Iron Law 3: Training sign-off requires attendance register and assessment results. |
| Mark integration readiness Green without end-to-end test results | "The interfaces worked in the test system" | Test system interface configuration differs from production. DNS, RFC endpoints, credentials, and certificates change at cutover. Production integration must be tested post-cutover, not pre. | Checklist Step 5: Integration readiness requires production test results, not test-system results. |
| Allow Amber items to proceed without documentation | "We'll track them in the issues list" | An undocumented Amber is a concealed risk. If it materializes post-go-live, there is no record of the risk acceptance decision or who made it. | Iron Law 6: Every Amber requires written risk acceptance with named owner before proceeding. |
| Treat Go/No-Go as a project manager decision alone | "The PM owns the go-live decision" | Go-live decisions require functional sign-off (business), technical sign-off (Basis/architecture), and executive sign-off (sponsor). A PM cannot waive functional or technical readiness. | Iron Law 5: Named decision-makers across all three dimensions. |
| Skip performance verification because "SAP handles it" | "The system is SAP — it performs" | Custom Z-programs, background jobs, and reporting queries are not SAP standard. Volume testing results in ST05/ST12 must be confirmed against defined SLAs. | Checklist Step 1: Performance verification is evidence-based, with tcode-level monitoring data attached. |
| Rely on hypercare to catch what was missed | "If something breaks, hypercare will fix it" | Hypercare handles issues that arise from live use, not from unmet readiness conditions. Invoking hypercare as a substitute for readiness is a project governance failure. | Red Flag counter: Readiness gates exist precisely so hypercare is not used as a quality substitute. |
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.
- 12d ago First seen · 201 lines · 60 tokens per session scan A 89330ce09fe8
go-live-readiness is a skill published in the GitHub repository vigneshbarani24/sap-superpowers (9 stars, last pushed 19d ago), licensed MIT. It adds 60 tokens to every session and 3,340 once invoked, about $0.0003 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
add-linear
Add Linear channel integration via Chat SDK. Issue comment threads as conversations.
add-github
Add GitHub channel integration via Chat SDK. PR and issue comment threads as conversations.
slack-construct-agents
Standing context for Slack sibling agents — one room per team, creator-posted introductions, bot-to-bot hop discipline. Ships as instructions.md composed into the group's CLAUDE.md at spawn; there is no workflow to invoke.
sap-expert
Expert in SAP ERP systems, ABAP programming, SAP HANA, S/4HANA, Fiori applications, and SAP integration patterns including OData, RFC, and IDoc. Use when the user mentions ERP, enterprise, business apps, ABAP, HANA, or S/4HANA, or when the task involves SAP Ecosystem, ABAP Development, Integration Technologies, or…
roadmap-interview
Run a short product-discovery interview with a user of Kochab to surface what they actually need, then turn it into structured roadmap input. Use when someone says "interview me about features," "run the roadmap interview," "I have feedback on the tool," "what should this tool do next," or when a maintainer wants to…
eso-guild-social-manager
Creates, updates, and uses ESO GUILD.md files for guild discovery and social planning. Use when finding, evaluating, joining, tracking, or interacting with ESO guilds.