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 marcusgoll/Spec-Flow --skill staging-validation-phasegit clone --depth 1 https://github.com/marcusgoll/Spec-FlowWrote 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/marcusgoll/spec-flow/staging-validation-phase)<a href="https://agentmods.dev/skills/marcusgoll/spec-flow/staging-validation-phase"><img src="https://agentmods.dev/badge/skills/marcusgoll/spec-flow/staging-validation-phase/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/marcusgoll/spec-flow/staging-validation-phase"><img src="https://agentmods.dev/badge/skills/marcusgoll/spec-flow/staging-validation-phase.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.00056 | $0.05429 |
| Opus 5.5 | $0.00022 | $0.02172 |
| Sonnet 5.5 | $0.00011 | $0.01086 |
| Haiku 4.5 | $0.00006 | $0.00543 |
Grade A, and why
staging-validation-phase scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
const response = await fetch(baseURL); How it starts
The opening of the file, as written. The whole thing — 768 lines — stays where its author put it; the contents beside it link to each section on GitHub.
This skill orchestrates the staging validation phase, which occurs after /ship-staging and before /ship-prod in the staging-prod deployment workflow.
Core responsibilities:
- Run automated smoke tests on staging environment
- Test critical user flows manually (authentication, core features, payments)
- Verify data migrations executed successfully
- Test rollback capability (actual rollback + roll-forward)
- Document sign-off decision (approve/reject with justification)
- Update state.yaml with validation results
Inputs: Staging deployment (URL, deployment ID, migration results) Outputs: Validation report, sign-off decision, state.yaml update Expected duration: 30-60 minutes
<quick_start> Execute staging validation in 5 steps:
-
Run smoke tests - Execute automated smoke test suite on staging URL
npm run test:smoke -- --url=$STAGING_URLVerify: homepage loads (200), API health endpoint (200), database connection
-
Test critical user flows - Manual testing of core functionality
- Authentication (login, logout, password reset)
- Primary user workflow (feature-specific)
- Payment processing (if applicable)
- Data CRUD operations
-
Verify data migrations - Check staging database for migration results
# Connect to staging database psql $STAGING_DATABASE_URL -c "SELECT version FROM alembic_version;" # Verify tables, columns, constraints match expectations -
Test rollback capability - Execute actual rollback test
# Rollback to previous deployment vercel rollback $PREVIOUS_DEPLOYMENT_ID # Verify previous version is live # Roll forward to current deployment vercel promote $CURRENT_DEPLOYMENT_ID -
Document sign-off - Update state.yaml
manual_gates: staging_validation: status: approved # or rejected approver: "Your Name" timestamp: "2025-11-19T10:30:00Z" blockers: [] # or list of issues if rejected
Key principle: Test as if this is production. All failures must be fixed before production deployment. </quick_start>
<knowledge_requirements> Required understanding before validation:
- Smoke tests: What automated tests exist, how to run them, what they verify
- Critical user flows: Which workflows are essential for production (auth, core feature, payments)
- Data migrations: What schema changes were made, how to verify them
- Rollback procedure: How to rollback deployment, how to verify previous version, how to roll forward
- Sign-off criteria: What constitutes approval vs rejection (all tests pass, no blocking bugs)
See deployment-strategy.md in project docs for platform-specific rollback procedures. </knowledge_requirements>
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.
- 1mo ago First seen · 768 lines · 56 tokens per session scan A 6bd3828e0b37
staging-validation-phase is a skill published in the GitHub repository marcusgoll/Spec-Flow (97 stars, last pushed 1mo ago), licensed MIT. It adds 56 tokens to every session and 5,429 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
test-setup
Scaffold the test framework and CI — tests/ directory, engine test runner, GitHub Actions workflow. Once, before the first sprint.
skill-engineering-quality
Use when a repository needs a quality baseline or modernization across one or more detected application stacks, especially linting, formatting, type checking, tests, build validation, developer tooling, hooks, or CI consistency.
pin-guardrail
Pin a shell guardrail (a hook, a git hook, a checker script) with a behavioral test suite, prove the suite is real by mutating the code, and wire it into CI with its mutation ledger. Use when asked to "add tests for this hook", "pin that guard", "mutation-test this script", "this hook has no test", "wire the suite…
github-actions-workflows
GitHub Actions workflow patterns for CI/CD including matrix builds, reusable workflows, secrets management, and caching strategies. Use when setting up or optimizing GitHub Actions pipelines.
r-util-ci-gen
Generate a GitHub Actions CI workflow from the project's test.
gh-fix-tests
Fix failing GitHub CI checks on a PR.