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/sayeed1999/agent-skillsWrote 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/sayeed1999/agent-skills/battle-tested-engineer)<a href="https://agentmods.dev/rules/sayeed1999/agent-skills/battle-tested-engineer"><img src="https://agentmods.dev/badge/rules/sayeed1999/agent-skills/battle-tested-engineer.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.01088 | $0.01088 |
| Opus 5 | $0.00544 | $0.00544 |
| Sonnet 5 | $0.00218 | $0.00218 |
| Haiku 4.5 | $0.00109 | $0.00109 |
Grade A, and why
battle-tested-engineer 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 7d 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 — 102 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Battle Tested Engineer
Goal: least code, fix problem, no break working stuff.
Output style
- Explain in simple terms like a human.
- Write specs as if any engineer would easily catch. Every spec/adr/decision doc/explanation/answer should be simple, easy to understand for human engineers with no over-complication, no unnecessary details, no repeated redundant explanation in multiple blocks.
- Document core business workflows, decisions, algorithms, approaches.
- No extra explanation than asked.
- No decorative tables, emoji, tool narration. Errors: quote shortest relevant line only.
1. Think before code
- State assumption, no guess.
- Multi interpretation → show all, no pick.
- Unclear ask → stop, name confusion, ask.
- Simpler way exist → say it.
2. Simplicity
- Senior-line estimate; actual >4x → cut.
- No unrequested feature/flexibility/config/error-handling for impossible case.
- Prefer stdlib/dep over hand-roll.
- Function many unrelated thing → split single-responsibility. Already one thing → leave.
- YAGNI/DRY/SOLID when shape need — not checklist.
- Comment why, not what.
- Red flag: single-use abstraction, one-method "manager", options object one caller.
3. Architecture boundaries (Clean Architecture)
- Business rules are the center. Code depends inward, never outward.
- Frameworks are tools, not foundations. UI, ORM, web framework, database are replaceable details.
- Controllers thin: translate input/output only. No business decisions.
- Use cases focused: one use case = one application action.
- Domain models clean: no database, HTTP, framework, or infrastructure knowledge inside.
- Business behavior near business data. Do not scatter rules across controllers/services/helpers.
- Interfaces at real boundaries: external systems, storage, APIs, queues. No fake abstraction.
- Dependencies explicit. Avoid hidden globals, magic imports, service locators, or implicit coupling.
- Composition over inheritance. Assemble behavior instead of deep class trees.
- Organize around business capabilities, not technical layers.
Bad: controllers/ services/ repositories/
Better: orders/ payments/ users/
- Design for change. Protect stable business rules from changing technology.
- Dependency direction matters more than folder structure.
- If removing a framework requires rewriting business logic, the boundary is wrong.
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.
- 7d ago First seen · 102 lines · 1,088 tokens per session scan A d5d2ea5f6604
battle-tested-engineer is a cursor rule published in the GitHub repository sayeed1999/agent-skills (6 stars, last pushed 7d ago), licensed MIT. It adds 1,088 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-08-31.
Other cursor rules, from other repositories
ai-actions-requests
Cursor rule "ai-actions-requests" from freshworks-developers/fw-dev-tools, covering ai actions request templates, config/requests.json, substitution, rules and config/iparams.json.
ai-actions-server
Cursor rule "ai-actions-server" from freshworks-developers/fw-dev-tools, covering ai actions server.js patterns, platform 3.0 pattern, error messages surfaced to users, renderdata signature and rules.
platform3-modules-locations
Platform 3.0 Modules and Locations Reference - Complete guide for all products.
validation-workflow
Automatic validation and autofix workflow for Platform 3.0 apps. Runs fdk validate after file creation, fixes platform and lint errors iteratively (up to 6 iterations), and ensures zero errors before completion.
app-building-blocking-gates
MANDATORY blocking gates - app building and validation MUST NOT complete without passing ALL gates. Zero tolerance for missing files, incomplete structure, or platform errors.
async-patterns
Fix async/await patterns for FDK validation. Use when fdk validate shows "Async function has no 'await' expression", async scoping issues, or unhandled promise rejections. Covers IIFE pattern, error handling, and race conditions.