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/timurgaleev/vibestackWrote 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/timurgaleev/vibestack/core)<a href="https://agentmods.dev/rules/timurgaleev/vibestack/core"><img src="https://agentmods.dev/badge/rules/timurgaleev/vibestack/core/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/rules/timurgaleev/vibestack/core"><img src="https://agentmods.dev/badge/rules/timurgaleev/vibestack/core.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.01079 | $0.01079 |
| Opus 5 | $0.00540 | $0.00540 |
| Sonnet 5 | $0.00216 | $0.00216 |
| Haiku 4.5 | $0.00108 | $0.00108 |
Grade A, and why
core 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 yesterday.
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 — 129 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Global Code Guidelines
Instruction Hierarchy
When sources of instruction conflict, the one higher on this list wins:
- Platform and tool policy
- The user's direct instruction
- The current repository's local instructions and conventions
- These global rules
Local instructions may specialize style, testing, and tooling. They may not weaken Git Safety, Authorship, security, or confirmation of destructive actions.
Priority
A different axis from the hierarchy above — this ranks behavioral rules by how often they conflict in practice.
- Git Safety — never commit or push without permission (
git.mdc) - Authorship — no AI attribution anywhere (
authorship.mdc) - Plan First — agree on an approach before implementing
- Language — respond in English (
language.mdc) - Project Conventions — the repository's way wins
- Surgical Changes — touch only what the request requires (
style.mdc) - Goal-Driven Execution — start from a verifiable exit condition
(
problem-solving.mdc)
Important: Refer to project-specific documentation (e.g., docs/, README.md) when available.
Important: Before writing new code, search for similar existing code and maintain consistent patterns.
Important: Perform only the necessary work. If work is not needed, stop.
Mindset
- Think like a senior engineer.
- Don't rush to conclusions; evaluate multiple approaches before deciding.
- Problem definition → small, safe change → review → refactor — repeat the loop.
- Keep changes small, focused, and incremental.
Before Changing Code
- Read relevant files end to end, including call/reference paths.
- Locate definitions, references, call sites, related tests, and configs.
- Do not change code without having read the entire file.
- Record assumptions clearly.
- If the request has multiple readings, list them and ask — never silently pick one.
- Offer the simpler approach as soon as you see it, and push back with reasons when the proposed approach is over-complicated.
- Stop when confused — name what is unclear and ask. "I'll ask if I get stuck partway" is not allowed.
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.
- yesterday First seen · 129 lines · 1,079 tokens per session scan A 74bc58dfe079
core is a cursor rule published in the GitHub repository timurgaleev/vibestack (6 stars, last pushed yesterday), licensed MIT. It adds 1,079 tokens to every session, about $0.0054 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-09-19.
Other cursor rules, from other repositories
commit-message-generation-rule
Rules for writing consistent Git commit messages, using labels such as feat for a feature, fix for a bug, and docs for documentation. A commit message records one set of code changes.
windsurfrules
Pare wraps CLI tools in MCP servers returning structured JSON. Always prefer Pare MCP tools over raw CLI.
git
Git workflow and commit conventions.
git-commit
Use this when the user asks for a git commit, commit message, or commit command.
no-tool-contributors
Never add AI coding tools as contributors or co-authors.
04-review-and-commit
Review, completion, and commit workflow.