diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 5132963..5452f22 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -6,7 +6,7 @@ }, "metadata": { "description": "Professional AI coding configurations, agents, skills, and context for Claude Code and Cursor", - "version": "9.16.0", + "version": "9.17.0", "license": "MIT", "repository": "https://github.com/TechNickAI/ai-coding-config" }, @@ -15,7 +15,7 @@ "name": "ai-coding-config", "source": "./plugins/core", "description": "Commands, agents, skills, and context for AI-assisted development workflows", - "version": "9.16.0", + "version": "9.17.0", "tags": ["commands", "agents", "skills", "workflows", "essential"] } ] diff --git a/.cursor/rules/autonomous-development-workflow.mdc b/.cursor/rules/autonomous-development-workflow.mdc index 74980ba..26183db 100644 --- a/.cursor/rules/autonomous-development-workflow.mdc +++ b/.cursor/rules/autonomous-development-workflow.mdc @@ -1,7 +1,7 @@ --- description: When completing tasks autonomously without human supervision alwaysApply: false -version: 2.0.0 +version: 3.0.0 --- # Autonomous Development Workflow @@ -9,10 +9,21 @@ version: 2.0.0 For AI agents completing tasks without human supervision. The goal: deliver a clean pull request that passes all checks and gets merged without back-and-forth. +## Spec Quality Is the Bottleneck + +Invest more time understanding the problem than writing the implementation. A precise +understanding of the problem produces better code than any amount of iteration on an +ambiguous one. If the task description is ambiguous, clarify before implementing. Quick, +localized changes with no behavioral impact may proceed directly. + ## Before Implementation -Read all cursor rules in `rules/`. These define the project's standards. Every -applicable rule must be followed. +Assess whether you have enough clarity to implement correctly. Can you articulate the +problem being solved, what "done" looks like, the edge cases, and the assumptions you're +making? If not, ask before proceeding. + +Load project standards via `/load-rules`. If that's not available, fall back to reading +applicable rules directly. Every applicable rule must be followed. If `CLAUDE.md` or `AGENTS.md` exist in the project root, read those for additional context. @@ -41,20 +52,21 @@ ruff format . # Auto-format code pytest # Run tests ``` -If we added functionality, we add tests following project patterns. Aim for 95% -coverage - solid testing without obsessing over every edge case. +If we added functionality, we add tests following project patterns. Aim for 95% coverage +-- solid testing without obsessing over every edge case. -Only commit and push when all validation passes. Green checks make for happy merges! ✅ +Only commit and push when all validation passes. -## Self-Review +## Evaluate Outcomes -Run `git diff` and review every change, as a senior developer would. +Run `git diff` and review the changes at the feature level. The question isn't "is every +line correct" -- it's "does this changeset solve the problem cleanly?" -Read through ALL cursor rules again and verify our code follows each applicable -guideline. +Verify the implementation delivers what was asked for -- not just technically correct, but +useful. Check that no unnecessary complexity was introduced. -Would we approve this in code review? If not, keep iterating until it's something we're -pleased with. +Read through applicable rules and verify compliance. Document any assumptions or +non-obvious choices in the PR description so reviewers understand the decisions made. ## Submission @@ -72,6 +84,6 @@ Ask first: major architectural changes, changes that would result in data loss, ## Success -A successful autonomous PR means: all automated checks pass, code follows all cursor -rules, tests are green, and the developer merges it without requesting changes. Use the -tooling to get there - it's our friend! 🎉 +A successful autonomous PR means: the implementation solves the stated problem, all +automated checks pass, code follows project standards, and the developer merges it +without requesting changes. diff --git a/plugins/core/.claude-plugin/plugin.json b/plugins/core/.claude-plugin/plugin.json index 3bfc41f..ffe6e1c 100644 --- a/plugins/core/.claude-plugin/plugin.json +++ b/plugins/core/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "ai-coding-config", - "version": "9.16.0", + "version": "9.17.0", "description": "Commands, agents, skills, and context for AI-assisted development workflows", "author": { "name": "TechNickAI", diff --git a/plugins/core/commands/autotask.md b/plugins/core/commands/autotask.md index ac5703e..2f69a2f 100644 --- a/plugins/core/commands/autotask.md +++ b/plugins/core/commands/autotask.md @@ -1,7 +1,7 @@ --- # prettier-ignore description: "Execute development task autonomously from description to PR-ready - handles implementation, testing, and git workflow without supervision" -version: 2.1.0 +version: 2.3.0 --- # /autotask - Autonomous Task Execution @@ -59,7 +59,7 @@ 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 sub-agents +- Delegate exploration to agents - Targeted testing for changed code - /multi-review with 2-3 domain-relevant agents - Create PR → /address-pr-comments → completion @@ -70,7 +70,7 @@ Signals: Most tasks land here when auto-detected Architectural changes, new patterns, high-risk, multiple valid approaches. -- Full exploration via sub-agents +- 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, @@ -107,20 +107,41 @@ For worktree creation, use /setup-environment. When the right choice isn't obvio Your context window is precious. Preserve it through delegation. -Delegate to sub-agents: codebase exploration, pattern searching, documentation research, +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. -Sub-agents work with fresh context optimized for their task and return concise results. +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. -Ensure task clarity before implementation. If the task description is unclear or -ambiguous, use AskUserQuestion to clarify requirements. If clear, proceed to planning or -implementation based on complexity 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. @@ -128,20 +149,21 @@ Scale planning to complexity: **quick**: Skip to implementation. -**balanced**: Load relevant rules with /load-rules. Brief exploration via sub-agent if +**balanced**: Load relevant rules with /load-rules. Brief exploration via agent if needed. Create implementation outline. -**deep**: Full exploration via sub-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. +**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, accessibility, UX consistency -- code-reviewer: Architecture review, design patterns, security +- 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 @@ -208,7 +230,9 @@ Why this approach. **Validation Performed**: Tests run. Verification steps taken. -This phase is MANDATORY. Autotask is not complete without it. +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`: @@ -219,10 +243,9 @@ After PR creation, poll for bot analysis using `gh pr 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. This is not optional. - -Fix valuable feedback (security issues, real bugs, good suggestions). Decline with -WONTFIX and rationale where bot lacks context. Iterate until critical issues resolved. +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. @@ -233,6 +256,11 @@ Autotask is complete when ALL are true: - 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: @@ -258,48 +286,9 @@ Report format: -**Git failures**: Merge conflicts → pause for user resolution. Push rejected → pull and -rebase if safe, ask if not. Hook failures → fix the issue, never use --no-verify. - -**GitHub CLI failures**: Auth issues → run `gh auth status`, inform user. Rate limits → -log and suggest waiting. PR creation fails → check branch exists remotely, retry once. - -**Sub-agent failures**: Log which agent failed. Retry once with simplified scope. If -still fails, continue without that input and note the gap. - -For issues you cannot resolve autonomously, inform user with clear options and context. -Never swallow errors silently. - -## Key Principles - -- Feature branch workflow: Work on branch, deliver via PR -- Complexity scaling: Effort matches task scope -- Context preservation: Delegate exploration, orchestrate at top level -- Mandatory completion: Task not done until bot feedback addressed -- Smart environment detection: Auto-detect when worktree needed -- Git hooks do validation: Leverage existing infrastructure -- PR-centric: Everything leads to mergeable pull request -- Decision transparency: Every autonomous choice documented in PR - -## Requirements - -- GitHub CLI (`gh`) installed and authenticated -- Node.js/npm -- Project standards accessible via /load-rules - -## Configuration - -Adapts to project structure: - -- Detects git hooks (husky, pre-commit) -- Detects test runners (jest, mocha, vitest, etc.) -- Finds linting configs (eslint, prettier, etc.) -- Uses available build scripts -- Respects project-specific conventions - -## Notes +Recover from failures without bypassing safety checks. Never use --no-verify. Never +silently swallow errors. Retry once before escalating. -- Creates real commits and PRs -- Environment auto-detected; asks when ambiguous -- Recognizes multi-repo workflows and existing worktrees -- Bot feedback handling is autonomous and mandatory +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.