| description | Execute development task autonomously from description to PR-ready - handles implementation, testing, and git workflow without supervision |
|---|---|
| version | 2.3.0 |
Complexity determines how much planning, review, and validation the task receives.
Analyze the task to determine appropriate complexity. Consider:
- Scope: How many files likely affected? Single file → quick. Multi-file → balanced. Cross-cutting → deep.
- Risk: Does it touch auth, payments, data migrations, core abstractions? Higher risk → deeper review.
- Novelty: Established patterns → lighter touch. New patterns or architecture → deeper analysis.
- Ambiguity: Clear requirements → move fast. Fuzzy requirements → plan more.
Precedence: Explicit user signals (quick, balanced, deep) override auto-detection. Risk factors can escalate complexity but never reduce it below what the user specified.
When in doubt, err toward balanced. Quick is for genuinely trivial changes. Deep is for genuinely complex ones.
Single-file changes, clear requirements, no design decisions.
- Skip heavy planning
- Implement directly
- Trust git hooks for validation
- Single self-review pass
- Create PR, brief bot wait, address feedback
Signals: "quick fix", "simple change", trivial scope, typo, single function
Standard multi-file implementation, some design decisions.
- Light planning with /load-rules
- Delegate exploration to agents
- Targeted testing for changed code
- /multi-review with 2-3 domain-relevant agents
- Create PR → /address-pr-comments → completion
Signals: Most tasks land here when auto-detected
Architectural changes, new patterns, high-risk, multiple valid approaches.
- Full exploration via agents
- Use /brainstorm-synthesis for hard architectural decisions during exploration
- Create detailed plan document incorporating synthesis results
- Review the PLAN with /multi-review before implementation (architecture-auditor, domain experts)
- Full implementation with comprehensive testing
- /verify-fix to confirm behavior
- /multi-review with 5+ agents on the implementation
- Create PR → wait for all bots → /address-pr-comments → iterate until clean
Signals: "thorough", "deep", "ultrathink", architectural scope, new patterns
If context compaction occurs mid-task, save your todos to the todo list before compaction completes. The TodoWrite tool persists across compaction when you actively maintain it. After compaction, check git state (branch, commits, PR status) to re-orient and continue from where you left off.
Read @rules/git-worktree-task.mdc for environment setup guidance.
Determine where to work based on current git state:- Clean working tree → Work in place
- Dirty tree with multi-repo pattern → Ask user preference
- Dirty tree, no multi-repo → Suggest worktree, confirm first
- Already in worktree → Work in place
For worktree creation, use /setup-environment. When the right choice isn't obvious, ask.
Your context window is precious. Preserve it through delegation.Delegate to agents: codebase exploration, pattern searching, documentation research, multi-file analysis, any task requiring multiple search/read rounds.
Keep in main context: orchestration, decision-making, user communication, synthesizing results, state management, phase transitions.
Agents work with fresh context optimized for their task and return concise results. Doing exploratory work yourself fills context with raw data. This is about working at the right level.
Spec quality determines implementation quality. Ambiguous specs produce software that fills gaps with AI guesses instead of user-centric decisions.Before implementation, evaluate the task description:
- Problem clarity: Can you articulate what user pain this solves? If not, you don't understand the task yet.
- Acceptance criteria: What does "done" look like? Not "it works" — specific behavioral expectations.
- Edge cases: What inputs, states, or conditions could break the expected behavior?
- Unstated assumptions: What are you assuming about the system, the user, or the context? Document them.
quick: If the task has no behavioral impact and is a localized change (typo fixes, comment updates), proceed without deep evaluation. Otherwise, treat as balanced.
balanced: Verify you can describe the expected behavior in concrete terms before writing code. If you can't, clarify with the user.
deep: Write a brief spec (problem, expected behavior, edge cases, acceptance criteria) and validate it before implementation. This is the most valuable step in the entire workflow — a precise spec saves rewrites.
If ambiguity remains after evaluation, use AskUserQuestion before proceeding.
Scale planning to complexity:quick: Skip to implementation.
balanced: Load relevant rules with /load-rules. Brief exploration via agent if needed. Create implementation outline.
deep: Full exploration via agents. Create detailed plan document. Run /multi-review on the PLAN with architecture-focused agents. Incorporate feedback before writing code. Document design decisions with rationale.
Execute using appropriate agents based on task type:- debugger: Root cause analysis, reproduces issues
- autonomous-developer: Implementation work, writes tests
- ux-designer: User-facing text, UX consistency
- architecture-auditor: Architecture review, design patterns
- security-reviewer: Security analysis, injection, auth
- prompt-engineer: Prompt optimization
- Explore: Investigation, research, trade-off evaluation
Launch agents in parallel when independent, sequentially when dependent. Provide targeted context: task requirements, implementation decisions, relevant standards, specific focus area.
Capture decisions made and any blockers encountered for the PR description.
Pause only for deal-killers: security risks, data loss potential, fundamentally unclear requirements. For everything else, make a reasonable choice and document it in the PR.The executing model knows when to ask versus when to decide and document.
Scale validation to complexity:quick: Trust git hooks. If hooks pass, proceed.
balanced: Run targeted tests for changed code. Brief self-review. Fix obvious issues.
deep: /verify-fix to confirm behavior works from user perspective. Comprehensive test suite. Security scan if applicable. Performance check if applicable.
Scale review to complexity:quick: Single self-review pass.
balanced: /multi-review with 2-3 agents selected by domain:
- Changed API → security-reviewer
- Changed UI → ux-designer, design-reviewer
- Changed logic → logic-reviewer
- Changed tests → test-analyzer
deep: /multi-review with 5+ agents:
- architecture-auditor
- security-reviewer
- performance-reviewer
- error-handling-reviewer
- logic-reviewer
- Domain-specific reviewers as needed
Fix issues found before creating PR.
Create PR with commits following .cursor/rules/git-commit-message.mdc.PR description includes:
Summary: What was implemented and why. How it addresses requirements.
Design Decisions (if any): Each decision with rationale. Alternatives considered. Why this approach.
Complexity Level: quick|balanced|deep and why.
Validation Performed: Tests run. Verification steps taken.
Bot feedback catches issues the author missed — security vulnerabilities, real bugs, style violations. Addressing it before declaring completion prevents shipping known defects. This phase completes the autotask workflow.After PR creation, poll for bot analysis using gh pr checks:
- quick: Poll for up to 2 minutes
- balanced: Poll for up to 5 minutes
- deep: Poll for up to 15 minutes, wait for all configured checks
If checks complete sooner, proceed immediately. If timeout reached with checks still pending, proceed with available feedback and note incomplete checks.
Execute /address-pr-comments on the PR. Fix valuable feedback (security issues, real bugs, good suggestions). Decline with WONTFIX and rationale where bot lacks context. Iterate until critical issues resolved.
Autotask is complete when ALL are true:- PR created with proper description
- Review bots have completed (or confirmed none configured)
- /address-pr-comments executed
- All "Fix" items resolved or documented
- The implementation solves the stated problem (not just passes tests)
Before reporting completion, step back and evaluate: If a user encounters this feature tomorrow, will it make sense? Does it do what was asked, or did implementation drift from the original intent? Tests verify correctness — this final check verifies value.
Report format:
## Autotask Complete
**PR:** #[number] - [title]
**Branch:** [branch-name]
**Worktree:** [path if applicable]
**Complexity:** [quick|balanced|deep]
**What was accomplished:**
- Core functionality delivered
- Design decisions made autonomously
- Obstacles overcome
**Bot feedback addressed:**
- Fixed: [count]
- Declined: [count with reasons]
When blocked on something you cannot resolve autonomously (merge conflicts requiring human judgment, auth failures, persistent CI issues), inform the user with clear options and context.