Auto-Dev Skill

WHEN TO USE: Task requires building, modifying, or fixing software, tools, or systems and requirements are clear (confidence: MEDIUM or HIGH).

Development Philosophy

Task Classification

dev/architecture-first

bugfix/hypothesis-driven

addition/lightweight

enhancement/delta-design

enhancement/delta-design

Paradigm System

Phases

phases/

Paradigms

Shared Protocols

How to Use

1. Classify the task — use the Task Classification table above
2. Select the paradigm — the table maps signals to paradigms
3. Announce your phase sequence — state which phases you will follow before starting. This announcement is your commitment. In the best-performing sessions, this step alone ensured full adherence.
4. Follow the phase sequence — read each phase file when you enter that phase, not all upfront
5. Check for parallel execution — if M/L/XL with >=2 independent modules, see parallel-execution
6. Respect quality gates — each phase defines what must be true before proceeding
7. Escalate if needed — if quality gates reveal the paradigm doesn't fit, switch to the appropriate one
8. Re-evaluate complexity — if during implementation you discover 3+ files need changes or >50 lines of modification beyond initial estimate, stop and re-classify

Key Constraints

• Don't start coding from LOW confidence requirements
• Don't skip design thinking — use the appropriate paradigm for the task type
• Don't mark complete without runnable, verifiable result
• Don't run destructive commands without asking

What Coding Agents Get Wrong

• Code-first impulse. The default is to start editing immediately. Even when told to follow a process, agents revert to inline coding within minutes. In sessions where the agent announced its phase sequence upfront, outcomes were measurably better. The phases exist to prevent this — skipping them is the single largest source of rework.
• Patch-and-pray. Instead of reading a file completely and making one correct change, agents make small local edits, test, find a secondary issue, patch that, test again — each fix shifting the bug elsewhere. A file edited 10+ times usually needed 1-2 edits with proper upfront understanding. Before editing, re-read the file — your in-context memory drifts from reality after each change.
• First-diagnosis anchoring. The agent commits to its first interpretation and filters subsequent evidence to confirm it. When evidence contradicts, it patches within the same mental frame rather than re-examining the frame itself. Wrong architectural layer, wrong hook point, wrong root cause — all from committing too early. State your assumptions explicitly and check each one.
• Test theater. Two forms: (a) running the same failing test repeatedly with speculative micro-fixes instead of deeply reading the assertion failure; (b) tests that pass but don't verify actual user-facing behavior. Unit tests passing while the deployed feature returns 500s. "Tests pass" ≠ "it works."
• Complexity ratchet. When a simple approach would work, agents reach for a sophisticated one — more abstraction, more indirection, more configuration. Timestamp comparison becomes git-stash SHA diffing. The result is harder to debug and often doesn't work on the first attempt. Ask: what is the simplest thing that solves this correctly?
• Scope absorption. Agents never say "that's a separate task." Every request gets folded into the current work. A bugfix becomes a bugfix + refactor + new feature + test rewrite. One task at a time — finish before starting the next.
• Environment amnesia. Agents run commands without verifying environment assumptions: wrong working directory, missing dependencies, wrong paths, wrong API endpoints. They also guess instead of reading — when a config file would give the answer immediately, agents probe blindly. Read configs and docs before running commands in unfamiliar environments.
• Reasoning over reading. After reading a file once, agents prefer to reason from stale in-context memory rather than re-reading the current state. Files change between edits. Error messages contain the answer if you actually read them. Re-read, don't theorize.

Project Experience

references/project-patterns/

ls references/project-patterns/ 2>/dev/null | sed 's/\.md$//' || echo "none yet"

---
project: project-name
aliases: [alt-name-1, alt-name-2]
updated: YYYY-MM-DD
---
## Codebase Conventions
Naming, directory structure, error handling, import patterns

## Build & Test
Commands, frameworks, runners, what works

## Architecture Decisions
Key design choices and rationale

## Known Pitfalls
What breaks and why — environment quirks, platform issues, recurring review findings

Design Principles

principles/

References

phases/{phase}.md

paradigms/{type}/{name}.md

principles/{name}.md

paradigms/parallel-execution.md

references/project-patterns/{project}.md

config/defaults.json

examples/