SKILL.md

name	auto-dev
description	Autonomous development loop. Continuously develops, tests, reviews, and commits code toward PRD goals. Enforces minimum work duration per invocation. Prioritizes fixing existing defects over new features. Use when the user says auto-dev, /auto-dev, autonomous dev, or continuous development.

Auto-Dev — Autonomous Development Loop

Continuously develop a codebase toward its PRD goals. Each invocation works for a specified duration: assessing state, fixing defects, building features, testing, reviewing, and committing. Fully autonomous — no user interaction required.

Argument Parsing

Accept /auto-dev [duration] or via loop: /loop 2h /auto-dev 1.5h

Parse duration:

• 1.5h or 1.5H → 90 minutes
• 2h → 120 minutes
• 90m or 90M → 90 minutes
• 45m → 45 minutes
• No argument → default 60 minutes

Store as MIN_DURATION_MIN (integer minutes).

---

CONTEXT DISCOVERY (First 2 minutes)

On every invocation, discover the project context. Do NOT hardcode paths or tech stacks — detect them.

Step 1: Locate Project Root

Check these in order for the project root:

1. $AUTODEV_PROJECT environment variable
2. Current working directory if it contains a known project marker
3. The workspace root

Project markers (any one is sufficient): package.json, Cargo.toml, pyproject.toml, go.mod, Makefile, CMakeLists.txt, pom.xml, build.gradle, .git

Step 2: Discover PRD

Search the project root for a requirements document: PRD.md, prd.md, SPEC.md, spec.md, DESIGN.md, design.md, REQUIREMENTS.md, requirements.md, ARCHITECTURE.md

If none found, check docs/ subdirectory. If still none, the session operates in defect-fix-only mode (skip Phase 4 feature work).

Step 3: Discover Tech Stack

Detect from project files:

• package.json → Node.js/TypeScript (check for next, react, vue, etc.)
• Cargo.toml → Rust
• pyproject.toml / requirements.txt → Python
• go.mod → Go
• CMakeLists.txt / Makefile → C/C++
• Other → infer from file extensions

Step 4: Discover Test & Build Commands

Check package.json scripts, Makefile targets, Cargo.toml, etc. for:

• Build: npm run build, cargo build, make, go build, etc.
• Test: npm test, cargo test, pytest, go test, etc.
• Lint: npm run lint, cargo clippy, ruff, golangci-lint, etc.
• Type-check: tsc --noEmit, mypy, etc.
• Dev server: npm run dev, cargo run, etc.

Step 5: Read Session Log

Check for auto-dev-session.md in the project root. If it exists, read it to understand what was done in previous invocations. This provides continuity across sessions.

---

TIME-LOCK PROTOCOL (MANDATORY)

On Entry

echo "AUTODEV_START=$(date +%s)" > /tmp/auto-dev-session.env
echo "MIN_DURATION_MIN=${MIN_DURATION_MIN}" >> /tmp/auto-dev-session.env

Before Any Attempt to Finish

source /tmp/auto-dev-session.env
ELAPSED=$(( $(date +%s) - AUTODEV_START ))
ELAPSED_MIN=$(( ELAPSED / 60 ))
echo "Elapsed: ${ELAPSED_MIN}/${MIN_DURATION_MIN} minutes"
if [ $ELAPSED_MIN -lt $MIN_DURATION_MIN ]; then
  echo "TIME-LOCK ACTIVE: ${ELAPSED_MIN}/${MIN_DURATION_MIN} min — MUST CONTINUE"
else
  echo "TIME-LOCK CLEARED: ${ELAPSED_MIN} min — may finish if cycle complete"
fi

• If < MIN_DURATION_MIN → DO NOT STOP. Start another development cycle.
• If ≥ MIN_DURATION_MIN → You MAY finish, but only after completing the current cycle.

NEVER STOP BEFORE MIN_DURATION_MIN. THERE IS ALWAYS MORE TO IMPROVE.

---

DEVELOPMENT CYCLE

Execute phases sequentially. After Phase 7, check the time-lock. If locked, restart from Phase 1.

Phase 1 — Assess Current State

1. Git status: Check for uncommitted changes, current branch
2. Build health: Run the build command. Record pass/fail.
3. Test health: Run the test suite. Record pass/fail and coverage if available.
4. Lint/type-check: Run linter and type checker. Record issues.
5. PRD progress: Compare implemented features against PRD milestones

Produce a mental assessment:

• What's broken right now?
• What's the highest-priority defect?
• What's the next PRD milestone that isn't started?

Phase 2 — Fix Defects (PRIORITY)

This phase takes priority over new features. Fix defects in this order:

P0 — Build breakers: Code that doesn't compile or build.

P1 — Test failures: Failing tests. Write missing test assertions.

P2 — Lint/type errors: Fix type errors, lint violations.

P3 — Logic bugs: Code that builds but behaves incorrectly. Look for:

• Unchecked edge cases
• Missing error handling
• Race conditions
• Memory leaks (in applicable languages)
• Dead code paths
• Unreachable branches

P4 — Code quality: Inconsistent naming, duplicated logic, oversized functions, missing abstractions, poor separation of concerns.

Rules for fixing:

• Read the target code before editing. Understand context.
• Make surgical changes. Don't refactor unrelated code.
• After each fix, run the relevant test/build to verify.
• If a fix introduces a regression, revert it.

Phase 3 — Add/Improve Tests

After fixing defects, improve test coverage:

1. Identify untested code paths (functions, branches, edge cases)
2. Write tests for the highest-risk untested code first
3. Run the test suite to verify new tests pass
4. Check for flaky tests and stabilize them

Priority: test critical business logic > test utilities > test UI components.

Phase 4 — Feature Development (PRD-Driven)

Only enter this phase if Phase 2 produced zero P0–P2 defects.

1. Read the PRD. Identify the next unimplemented milestone.
2. If the feature is complex (> 100 lines, multiple files, architectural):
   • Write a brief design plan in the session log (3-5 bullet points)
   • Implement incrementally, testing after each step
3. If the feature is simple:
   • Implement directly
   • Write tests alongside the implementation
4. After implementation, run full build + test suite

Phase 5 — Visual Inspection (when applicable)

If the project has a UI (web app, desktop app):

1. Start the dev server (if not already running)
2. Use browser tools to take a screenshot of the relevant page
3. Visually verify: layout correctness, text readability, component alignment, responsive behavior, dark/light theme consistency
4. Fix any visual issues found

Skip this phase for backend-only / CLI / library projects.

Phase 6 — Code Review (Self-Review)

Review all changes made in this cycle:

1. git diff — read every changed line
2. Check for:
   • Unnecessary changes (formatting, comments, imports not related to the task)
   • Hardcoded values that should be configurable
   • Missing error handling
   • Inconsistency with existing code style
   • Performance issues (N+1 queries, unnecessary re-renders, etc.)
   • Security issues (injection, XSS, exposed secrets)
3. Fix anything found during review
4. Re-run build + tests after review fixes

Phase 7 — Commit & Log

If meaningful changes were made (not just exploratory reads):

1. Stage relevant files (git add — be selective, not git add .)
2. Commit with a descriptive message following the repo's commit style
3. Update the session log

Session log entry (append to auto-dev-session.md in project root):

### Auto-Dev Session [YYYY-MM-DD HH:MM]
- **Duration**: XX minutes
- **Defects found**: N (P0: x, P1: y, P2: z, P3: w, P4: v)
- **Defects fixed**: M
- **Tests added**: K
- **Features implemented**: [list or "none"]
- **Commits**: [hash] [message]
- **PRD progress**: [current milestone status]
- **Next priority**: [what the next invocation should focus on]

Phase 8 — Time-Lock Check & Loop

source /tmp/auto-dev-session.env
ELAPSED=$(( $(date +%s) - AUTODEV_START ))
ELAPSED_MIN=$(( ELAPSED / 60 ))
echo "Elapsed: ${ELAPSED_MIN}/${MIN_DURATION_MIN} minutes"

• If < MIN_DURATION_MIN → Restart from Phase 1 with deeper scrutiny:
  • Cycle 2: Focus on edge case testing and error handling
  • Cycle 3: Focus on code quality and refactoring
  • Cycle 4: Focus on performance and optimization
  • Cycle 5+: Deep PRD feature work or architectural improvements
• If ≥ MIN_DURATION_MIN → Proceed to final summary.

Phase 9 — Final Summary

Print a concise summary:

Auto-dev session complete (N cycles, XX minutes).
Defects: found X, fixed Y, remaining Z.
Tests: added K, total passing T.
Features: [list or "none"].
Commits: N commits.
Next priority: [what to focus on next].

---

Loop Usage

/loop 2h /auto-dev 1.5h

Loop interval	Duration arg	Effective
/loop 1h	45m	Work 45 min, rest 15 min
/loop 2h	1.5h	Work 90 min, rest 30 min
/loop 3h	2.5h	Work 150 min, rest 30 min

---

INTERACTION PROTOCOL OVERRIDE

This skill is a task-internal loop. It overrides durable-request, feynman-flow, and any other checkpoint/continuation skill within its execution scope.

• DO NOT call AskQuestion — fully autonomous workflow.
• DO NOT present checkpoints — the time-lock governs termination.
• DO NOT invoke durable-request checkpoint protocol — Phase 8 is the sole gate.
• DO NOT call deep-sleep — the skill uses its full duration actively.
• When the time-lock clears, print the Phase 9 summary and end the turn. The /loop scheduler handles re-invocation.

This override is consistent with durable-request's rule: "Task-specific loops > durable-request (at task boundaries only)."

---

CRITICAL RULES

1. NEVER STOP BEFORE MIN_DURATION_MIN. Check the time-lock before finishing.
2. NEVER ASK FOR CONFIRMATION. All decisions are autonomous.
3. ALWAYS READ BEFORE EDITING. Use Read tool before StrReplace.
4. ALWAYS BUILD AND TEST AFTER CHANGES. Never leave the project broken.
5. ALWAYS UPDATE THE SESSION LOG. Every invocation leaves an audit trail.
6. DEFECTS BEFORE FEATURES. Phase 2 takes absolute priority over Phase 4.
7. SURGICAL CHANGES ONLY. Touch only what needs changing. Match existing style.
8. EACH CYCLE MUST FIND NEW WORK. If nothing is found, you're not looking hard enough. Read the PRD again. Profile the code. Check edge cases. There is ALWAYS more to improve.
9. NO INTERACTIVE TOOLS. No AskQuestion, no checkpoint.sh, no blocking prompts.
10. COMPLEX FEATURES NEED DESIGN. Features touching 3+ files or requiring architectural decisions must have a brief design plan logged before implementation.