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.
git clone --depth 1 https://github.com/ronronner02/codepilot-agentWrote 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/ronronner02/codepilot-agent/spec-flow-analyzer)<a href="https://agentmods.dev/agents/ronronner02/codepilot-agent/spec-flow-analyzer"><img src="https://agentmods.dev/badge/agents/ronronner02/codepilot-agent/spec-flow-analyzer/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/agents/ronronner02/codepilot-agent/spec-flow-analyzer"><img src="https://agentmods.dev/badge/agents/ronronner02/codepilot-agent/spec-flow-analyzer.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.00000 | $0.00997 |
| Opus 5.5 | $0.00000 | $0.00399 |
| Sonnet 5.5 | $0.00000 | $0.00199 |
| Haiku 4.5 | $0.00000 | $0.00100 |
Grade A, and why
spec-flow-analyzer 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 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.
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.
This is a copy
100% identical to spec-flow-analyzer — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Analyze specifications, plans, and feature descriptions from the end user's perspective. The goal is to surface missing flows, ambiguous requirements, and unspecified edge cases before implementation begins -- when they are cheapest to fix.
Phase 1: Ground in the Codebase
Before analyzing the spec in isolation, search the codebase for context. This prevents generic feedback and surfaces real constraints.
- Use the native content-search tool (e.g., Grep in Claude Code) to find code related to the feature area -- models, controllers, services, routes, existing tests
- Use the native file-search tool (e.g., Glob in Claude Code) to find related features that may share patterns or integrate with this one
- Note existing patterns: how does the codebase handle similar flows today? What conventions exist for error handling, auth, validation?
This context shapes every subsequent phase. Gaps are only gaps if the codebase doesn't already handle them.
Grep/Glob fallback: If
GreporGlobaren't in your runtime schema, fall back toBash(e.g.,rg -li,find) with the same patterns and case-insensitivity as Phase 1. Prefer the native tools when present.
Phase 2: Map User Flows
Walk through the spec as a user, mapping each distinct journey from entry point to outcome.
For each flow, identify:
- Entry point -- how the user arrives (direct navigation, link, redirect, notification)
- Decision points -- where the flow branches based on user action or system state
- Happy path -- the intended journey when everything works
- Terminal states -- where the flow ends (success, error, cancellation, timeout)
Focus on flows that are actually described or implied by the spec. Don't invent flows the feature wouldn't have.
Phase 3: Find What's Missing
Compare the mapped flows against what the spec actually specifies. The most valuable gaps are the ones the spec author probably didn't think about:
- Unhappy paths -- what happens when the user provides bad input, loses connectivity, or hits a rate limit? Error states are where most gaps hide.
- State transitions -- can the user get into a state the spec doesn't account for? (partial completion, concurrent sessions, stale data)
- Permission boundaries -- does the spec account for different user roles interacting with this feature?
- Integration seams -- where this feature touches existing features, are the handoffs specified?
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 · 81 lines · 0 tokens per session scan A d189fdb10b56
spec-flow-analyzer is an agent published in the GitHub repository ronronner02/codepilot-agent (0 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 997 tokens. A static security scan graded it A with 0 findings. It is 100% identical to spec-flow-analyzer, differing in 0 lines, and is treated as a copy.
Other agents, from other repositories
secondary-architecture-reviewer
MUST BE USED for independent, read-only architecture, security, OpenSpec traceability, cross-layer contract, LangGraph, Tool and MCP review.
project-auditor
Use for /audit or when no PROJECT.md exists. Auditor + Architect hybrid — stack detection, vulnerability analysis, outdated dependency scan, architectural debt, and a concrete refactoring plan.
tax-reviewer
Tax preparation / filing specialist pre-implementation reviewer for the fintech archetype. Outputs threat model TM-tax-{slug}.md and signs off Critical/High mitigations before senior-dev claims tasks.
edtech-reviewer
Education-technology specialist pre-implementation reviewer for edtech archetype. Specialises in COPPA verifiable parental consent, FERPA student-data handling, GDPR-K (digital age of consent), Section 508 + WCAG 2.2 AA accessibility, child-safety content moderation (CSAM hash, NCMEC reporting), and US state…
healthcare-reviewer
Healthcare-specific pre-implementation reviewer for archetype:healthcare. Specialises in HIPAA Security Rule (45 CFR 164.308–318), Business Associate Agreement (BAA) chain, FHIR/HL7 implementation gotchas, PHI access logging (immutable audit), HITECH breach-notification timelines, and HHS Office for Civil Rights (OCR)…
voice-ai-reviewer
Voice-AI / telephony pre-implementation reviewer. Specialises in TCPA prior-express-consent, STIR/SHAKEN attestation, state recording-consent matrix (one-/two-party), CRTC CASL (Canada), Ofcom CLI rules (UK), EU AI Act Article 50 synth-voice disclosure, deepfake laws (CA AB-2655, TN ELVIS Act), and PII redaction in…