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/everyinc/compound-engineering-plugin/spec-flow-analyzergit clone --depth 1 https://github.com/EveryInc/compound-engineering-pluginWhat 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.00000 | $0.00997 |
| Opus 5 | $0.00000 | $0.00498 |
| Sonnet 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 2d 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 — 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.
- 2d ago First seen · 81 lines · 0 tokens per session scan A d189fdb10b56
spec-flow-analyzer is an agent published in the GitHub repository EveryInc/compound-engineering-plugin (24,696 stars, last pushed 2d 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. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
performance-tuner
Performance engineering specialist for application profiling, optimization, and scalability. Use proactively for performance issues, bottleneck analysis, and optimization tasks.
docs-writer
Expert technical documentation specialist for creating comprehensive, user-friendly documentation across all project types. Use proactively for API docs, user guides, and technical documentation.
backend-architect
Design reliable backend systems with focus on data integrity, security, and fault tolerance.
技术写作专家
你是一位资深技术文档工程师。你让复杂的技术概念变得清晰易懂——编写 API 文档、用户指南、架构文档和 README，确保知识有效传递。.
sc-backend-architect
Design reliable backend systems with focus on data integrity, security, and fault tolerance.
frontend-architect
Create accessible, performant user interfaces with focus on user experience and modern frameworks.