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/barisercan/cursorrulesWrote 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/barisercan/cursorrules/atomic-task-planning)<a href="https://agentmods.dev/rules/barisercan/cursorrules/atomic-task-planning"><img src="https://agentmods.dev/badge/rules/barisercan/cursorrules/atomic-task-planning/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/barisercan/cursorrules/atomic-task-planning"><img src="https://agentmods.dev/badge/rules/barisercan/cursorrules/atomic-task-planning.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.00783 | $0.00783 |
| Opus 5.5 | $0.00313 | $0.00313 |
| Sonnet 5.5 | $0.00157 | $0.00157 |
| Haiku 4.5 | $0.00078 | $0.00078 |
Grade A, and why
atomic-task-planning 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.
What it actually says
description: Break down all work into smallest possible atomic tasks and execute them sequentially globs: "**/*" alwaysApply: true
Atomic Task Planning
Divide every job into the smallest possible atomic tasks and execute them one by one.
actions:
-
type: enforce message: | ATOMIC TASK PLANNING PROTOCOL
MANDATORY WORKFLOW:
-
PLANNING PHASE REQUIRED:
- NEVER start work without atomic task breakdown
- Divide ALL jobs into smallest possible tasks
- Tasks can be as small as writing a single method
- Tasks can be as small as renaming a variable
- Present complete task list before starting
-
ATOMIC TASK CRITERIA:
- Each task must be independently completable
- Should take minimal time to execute
- Must have clear, measurable outcome
- Cannot be broken down further meaningfully
-
EXECUTION RULES:
- Execute tasks ONE BY ONE only
- Complete current task before starting next
- Never work on multiple tasks simultaneously
- Stop after each task completion
-
TASK EXAMPLES:
- "Write getUserById method"
- "Add email validation"
- "Rename variable 'data' to 'userData'"
- "Add error handling to login function"
- "Update import statement"
- "Add single test case for edge condition"
-
NO TASK TOO SMALL:
- Prefer smaller tasks over larger ones
- When in doubt, break it down further
- Single line changes are valid tasks
- Micro-improvements are encouraged
WORKFLOW:
- Receive request
- Break into atomic tasks
- Present task list for approval
- Execute task 1
- Stop and confirm completion
- Execute task 2
- Repeat until all tasks done
-
examples:
-
input: | User: "Add user authentication"
Correct approach:
"I'll break this into atomic tasks:
- Create User model
- Add password hashing method
- Create login endpoint
- Add authentication middleware
- Add logout functionality
Should I proceed with task 1?" output: "Proper atomic task breakdown with sequential execution"
-
input: | User: "Fix the bug in calculation"
Correct approach:
"I'll break this into atomic tasks:
- Identify the calculation error
- Write test that reproduces bug
- Fix the specific calculation line
- Verify test passes
Should I start with task 1?" output: "Bug fix broken into atomic steps"
metadata: priority: high version: 1.0 enforcement: strict dependencies: ["minimal-changes-policy", "test-driven-development"]
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 · 112 lines · 783 tokens per session scan A 5f201ef70aa6
atomic-task-planning is a cursor rule published in the GitHub repository barisercan/cursorrules (35 stars, last pushed 1y ago), licensed MIT. It adds 783 tokens to every session, about $0.0031 per session on Opus 5.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
ponytail
Ponytail, lazy senior dev mode. Always pick the simplest solution that works.
angular-20
This rule provides comprehensive best practices and coding standards for Angular development, focusing on modern TypeScript, standalone components, signals, and performance optimizations.
dev-standard
Apache Superset development standards and guidelines for Cursor IDE.
prefer-assertions-over-defensive-checks
Prefer assertions over defensive checks when data is guaranteed to be valid.
prefer-direct-imports-over-module-mocks
Prefer extracting a testable core over vi.mock / vi.resetModules when unit tests need to reach production logic entangled with config, env, or singletons.
shared-plane-packages
Pattern for creating shared plane packages that serve both migration and runtime planes.