Add spec-quality-first philosophy to autonomous workflow

.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"]
     }
   ]

.cursor/rules/autonomous-development-workflow.mdc

@@ -1,18 +1,29 @@
 ---
 description: When completing tasks autonomously without human supervision
 alwaysApply: false
-version: 2.0.0
+version: 3.0.0
 ---
 
 # Autonomous Development Workflow
 
 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.

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",

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,41 +107,63 @@ For worktree creation, use /setup-environment. When the right choice isn't obvio
 <context-preservation>
 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. </context-preservation>
 
 <task-preparation>
-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.
 </task-preparation>
 
 <planning>
 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. </planning>
+**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. </planning>
 
 <implementation>
 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. </create-pr>
 
 <bot-feedback-loop>
-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.
 
 </bot-feedback-loop>
 
@@ -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:
 </completion-verification>
 
 <error-recovery>
-**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. </error-recovery>
-
-## 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. </error-recovery>