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 pactflow/pactflow-agent-skills --skill contract-testing-flywheelgit clone --depth 1 https://github.com/pactflow/pactflow-agent-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/pactflow/pactflow-agent-skills/contract-testing-flywheel)<a href="https://agentmods.dev/skills/pactflow/pactflow-agent-skills/contract-testing-flywheel"><img src="https://agentmods.dev/badge/skills/pactflow/pactflow-agent-skills/contract-testing-flywheel.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.00144 | $0.03449 |
| Opus 5 | $0.00072 | $0.01724 |
| Sonnet 5 | $0.00029 | $0.00690 |
| Haiku 4.5 | $0.00014 | $0.00345 |
Grade A, and why
contract-testing-flywheel 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 7d 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 — 205 lines — stays where its author put it; the contents beside it link to each section on GitHub.
contract-testing-flywheel
Generates a one-shot onboarding backlog for a team's contract-testing rollout, modelled on the 7-stage Contract Testing Flywheel (with the Maintenance phase replaced by Lessons-Learned + an optional Management Dashboard, per the plugin's design). Works with Jira, GitHub Issues/Projects, or Azure DevOps — or, if none of those is connected, renders the whole backlog as a markdown export for manual import.
Step 1 — Choose the scrum tool
Ask: "Which tool should this backlog go into? Jira · GitHub Issues/Projects · Azure DevOps · Other/manual export"
Use $ARGUMENTS to skip this question only if it unambiguously names one of the three tools (e.g. --tool=github); otherwise ask.
Then check that tool's availability check in lib/scrum-tool-adapters.md:
- Available → note the adapter row (hierarchy terms, idempotency query, create/link/comment mechanism) and continue to Step 2 in live-creation mode.
- Not available (tool chosen but its MCP/CLI isn't connected), or "Other/manual export" chosen → continue to Step 2 in manual-export mode. This is not an error: if a specific tool was chosen but isn't connected, mention once that connecting it (Atlassian MCP for Jira,
gh auth loginor a GitHub MCP for GitHub,az login+az extension add --name azure-devopsor an Azure DevOps MCP for Azure DevOps) would enable live creation next time, then proceed with the export anyway. Do not hard-stop.
When both an MCP server and a CLI could serve the chosen tool, prefer the MCP's equivalent tools when one is connected; use the CLI otherwise.
Step 2 — Gather inputs
Resolve each input in order. Use $ARGUMENTS for input 1 if present; only ask for what is not already known.
| # | Input | How to resolve |
|---|---|---|
| 1 | Project / workspace identifier | $ARGUMENTS first; otherwise ask, shaped by the Step 1 tool: Jira project key (e.g. PACT) · GitHub owner/repo · Azure DevOps org/project. Skip if manual-export mode with no tool chosen. |
| 2 | Team / unit name | Ask. Used to title the root item and label tickets. |
| 3 | Consumer system name | Ask. Single value. |
| 4 | Provider system name | Ask. Single value. |
| 5 | Primary language / stack | Single-choice ask: Node/TS · JVM · Python · Go · .NET · Ruby · Rust · Other |
| 6 | CT mode | Single-choice ask: CDCT · BDCT · Both |
| 7 | Broker URL (optional) | Ask, allow blank. If blank, ticket wording uses "your Pact Broker or PactFlow tenant". |
| 8 | CI tool | Single-choice ask: GitHub Actions · GitLab CI · Buildkite · Jenkins · CircleCI · Other |
| 9 | Include optional Phase 8 (management dashboard)? | Yes/no. |
| 10 | (Azure DevOps only) Process template | Single-choice ask: Agile (default) · Scrum · Basic — resolves {{delivery_term}} per lib/scrum-tool-adapters.md. Skip entirely for every other tool. |
What ships with it
15 files 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.
- lib/ci-snippet-pointers.md 928 B
- lib/drift-helpful-links.md 1.3 KB
- lib/scrum-tool-adapters.md 4.6 KB
- lib/stack-pact-libraries.md 835 B
- templates/00-root-epic.md 2.0 KB
- templates/01-planning.md 2.1 KB
- templates/02-requirements.md 1.9 KB
- templates/03a-design-knowledge.md 2.1 KB
- templates/03b-design-demo.md 2.4 KB
- templates/04-implementation-consumer.md 3.9 KB
- templates/04b-implementation-provider.md 4.8 KB
- templates/05-testing.md 2.7 KB
- templates/06-deployment.md 2.5 KB
- templates/07-lessons-learned.md 2.1 KB
- templates/08-management-dashboard.md 3.1 KB
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.
- 7d ago First seen · 205 lines · 144 tokens per session scan A 4dd273fb67ba
contract-testing-flywheel is a skill published in the GitHub repository pactflow/pactflow-agent-skills (6 stars, last pushed 7d ago), licensed MIT. It adds 144 tokens to every session and 3,449 once invoked, about $0.0007 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
create-request
Create, update, or scan per-task request tickets for progress tracking. These are date-prefixed non-lifecycle docs under requests/, NOT feature-level requirements (use /req-analyze for those). Use when: tracking task progress, updating completion status, scanning incomplete requests, checking request status dashboard.…
req-analyze
A requirements-analysis tool that breaks a problem into needs, stakeholders, and priorities before a technical solution is chosen.
feature-verify
Feature verification (READ-ONLY, P0-P5). Use when: verifying feature behavior after deployment, validating API responses, diagnosing production issues, post-deploy smoke test. Not for: modifying data (use feature-dev), code review (use codex-review-fast), writing tests (use codex-test-gen), security audit (use…
recap-ask
Interactive Q&A over an existing recap document. Use when: user wants to ask follow-up questions about a briefing-recap- .md produced by /recap-doc, with recap-bounded context + out-of-scope redirect + optional promote-to-request. Not for: generating a new recap (use /recap-doc), general project Q&A (use /ask), code…
recap-doc
Post-development recap document generator. Use when: AI/Codex has implemented a feature and the user needs a guided walkthrough of what changed and why, with blind-spot detection and anticipated questions. Not for: Q&A follow-up (use /recap-ask), technical share-out for teammates (use /tech-brief), or generic code…
runbook
Generate and update feature release runbooks from existing docs and codebase. Use when: creating operational runbook, release handbook, deployment checklist, pre-release preparation. Not for: incident response (v2), code review (use codex-code-review), architecture design (use architecture).