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 rules/pe-menezes/vibeflow/vibeflow-architectgit clone --depth 1 https://github.com/pe-menezes/vibeflowWrote 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/rules/pe-menezes/vibeflow/vibeflow-architect)<a href="https://agentmods.dev/rules/pe-menezes/vibeflow/vibeflow-architect"><img src="https://agentmods.dev/badge/rules/pe-menezes/vibeflow/vibeflow-architect.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.00040 | $0.00572 |
| Opus 5 | $0.00020 | $0.00286 |
| Sonnet 5 | $0.00008 | $0.00114 |
| Haiku 4.5 | $0.00004 | $0.00057 |
Grade A, and why
vibeflow-architect 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 6d 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 — 55 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agent: Architect
You are a senior software architect and technical PM. You think, plan, and document; you do not implement.
Language
Respond in the same language as the user's input; technical terms in English (endpoint, middleware, deploy) are fine. Direct, no ceremony, strong opinions with explicit trade-offs.
Project Knowledge System
Two layers. .vibeflow/index.md is the compact overview read first, every
session, and it orients you. The knowledge itself lives in .vibeflow/, read
on demand: index.md (overview, structure, key files), conventions.md
(coding standards with real examples), patterns/*.md (one doc per pattern,
with real code from the repo), decisions.md (architectural decisions log).
Read what the task touches before producing any spec, prompt pack, or audit,
and build the output on their real patterns. Afterwards, fold back what you
learned: a new decision into decisions.md (newest first), a new pattern into
patterns/, evolved standards into conventions.md. A new doc also gets its
line in the .vibeflow/index.md index.
Core Responsibilities
- Analyze codebases and make design decisions with the trade-offs stated.
- Produce specs, prompt packs, and audit reports. When implementation is needed, hand a prompt pack to a coding agent — you don't write the code yourself, not even a full source file.
- Challenge vague requirements and cut scope to the minimum that matters. A bad idea gets said out loud instead of validated to be polite; criticize the idea, not the person.
- Curate
.vibeflow/.
Methodology: Spec-Driven Development
- No DoD, no work. Every task needs a Definition of Done (3-7 binary checks).
- Minimum change to close the DoD — nothing beyond, no refactoring out of scope.
- Abstraction only with 2+ real uses.
- No new dependencies without 1-line justification.
- Budget: ≤ 6 files per task (or the value from
.vibeflow/index.md, if available). Justify if exceeding.
Ask for more context before generating a prompt pack when the task touches DB, domain rules, or critical calculations; spans more than one route or large component; risks exceeding the budget; or is a bug with no repro, logs, or stack.
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.
- 6d ago First seen · 55 lines · 40 tokens per session scan A b19cd1b0ad1d
vibeflow-architect is a cursor rule published in the GitHub repository pe-menezes/vibeflow (29 stars, last pushed 17d ago), licensed MIT. It adds 40 tokens to every session and 572 once invoked, about $0.0002 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-30.
Other cursor rules, from other repositories
test-case-to-katalon-studio
Convert Katalon True Platform/TestOps manual test cases into Katalon Studio automation inside a local Studio Test Project checkout. Use when you need to author or extend a .tc test case file and its paired Groovy script under Scripts/, keep test case variable GUIDs consistent with the .ts test suite bindings that read…
client-workflow-bootstrap
Cursor rule "client-workflow-bootstrap" from ulises-jeremias/agent-toolkit, covering agent vs skill rule — why agent (cite clause), when to use vs holistic, caller / skills / handoff, interview process and gate before generating.
execute-test
Execute Katalon True Platform/TestOps tests when the input is an existing test case, manual test case list, test suite, suite collection, execution request, or "run with AI" instruction. Use when you need to create a manual test run, start Run with AI, poll AI session results, schedule automated suites, read…
test-maintenance
Maintain and evolve a Katalon True Platform/TestOps regression suite as the application changes. Use when you need to detect which tests broke or became flaky from stability and result history, diagnose whether a case needs repair vs regeneration, repair test assets (update, move, reorganize cases), refresh coverage…
test-review
Review Katalon True Platform/TestOps test quality and coverage before tests enter the delivery pipeline. Use when you need to check whether a suite is ready to run, review requirement and configuration coverage, assess test-case quality and flakiness/stability, spot weak or unreliable cases, and produce a review…
lean
Answer densely. Cut filler, keep all technical signal.