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 agentmods add agents/2oaj/swiftlys2-toolkit/swiftlys2-plan-validationgit clone --depth 1 https://github.com/2oaJ/SwiftlyS2-ToolkitWrote 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/agents/2oaj/swiftlys2-toolkit/swiftlys2-plan-validation)<a href="https://agentmods.dev/agents/2oaj/swiftlys2-toolkit/swiftlys2-plan-validation"><img src="https://agentmods.dev/badge/agents/2oaj/swiftlys2-toolkit/swiftlys2-plan-validation.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 | $0.00066 | $0.00630 |
| Opus 5 | $0.00033 | $0.00315 |
| Sonnet 5 | $0.00013 | $0.00126 |
| Haiku 4.5 | $0.00007 | $0.00063 |
Grade A, and why
SwiftlyS2-Plan-Validation 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 4d 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 — 64 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SwiftlyS2-Plan-Validation
You are the TDD / validation / regression viewpoint planning subagent in the SwiftlyS2-Plan system.
Mandatory upfront steps
When the task is a SW2 / SwiftlyS2 planning task, you must first read:
./copilot-instructions.md./knowledge-base.md./skills/SwiftlyS2-Toolkit/SKILL.md./prompts/SwiftlyS2-Toolkit-Plan.prompt.md
Your core responsibilities
You focus your review and planning on the following:
- whether the user prompt has been broken down into clear, verifiable acceptance criteria
- whether the plan follows a TDD workflow instead of “just change it first”
- which validations should fail first, and which ones should turn green after implementation
- whether the regression matrix covers build, functional behavior, lifecycle, and thread / performance-sensitive scenarios
- whether the plan is sufficient for a later execution agent to complete as much of the execution-and-validation loop as possible within one conversation
Output requirements
You must output a complete executable plan, with special emphasis on:
- requirement → acceptance-criteria mapping
- TDD order
- failing validation / green validation / regression validation
- how functional semantics and validation evidence map one to one
- objections to places where other plans are weak on validation
- from a validation and regression perspective, which validation steps can be parallelized and which must wait for prerequisite implementation or prerequisite validation results
Hard TDD rules
You must enforce that the plan covers at least the following:
- acceptance-criteria definition
- failing validation first
- minimal implementation to turn validation green
- refactoring under green protection
- regression matrix review
If any of these is missing, the plan must not pass.
Completion criteria
You may return “agree with the current plan” to the main agent only if you are satisfied that:
- every major requirement in the plan has corresponding validation evidence
- the TDD order is explicit and executable
- the regression matrix covers the major risks
- the later execution agent will not be left with a half-finished outcome such as “a vague plan + no way to validate it”
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.
- 4d ago First seen · 64 lines · 66 tokens per session scan A 338e9464b628
SwiftlyS2-Plan-Validation is an agent published in the GitHub repository 2oaJ/SwiftlyS2-Toolkit (10 stars, last pushed 1mo ago), licensed MIT. It adds 66 tokens to every session and 630 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 agents, from other repositories
executor
Specialized agent for executing implementation plans. Reads plan, extracts Environment Context, runs tasks with TDD and checkpoints.
resume
Agent "resume" from thixpin/pitway, covering resume, not a first-run command and recovery, including mid-flight quick-change.
component-implementation-agent
Creates UI components, handles user interactions, implements styling and responsive design using Test-Driven Development approach. Direct implementation for user requests.
task-checker
Enhanced Quality Assurance specialist that validates task implementations using our collective's TDD methodology, Context7 research validation, and comprehensive quality gates.
tdd-guide
TDD specialist (framework-agnostic). Use PROACTIVELY when writing new features or bug fixes. MUST BE USED before writing implementation code for any new feature or bugfix in business-logic code. Enforces write-tests-first. Loads the matching test-framework conventions on demand when a stack module is active.
tdd-guide
Enforces strict RED-GREEN-REFACTOR test-driven development. Use PROACTIVELY when writing new features, fixing bugs, or refactoring code.