Autodev Pipeline Generator

Overview

This skill generates a complete Autodev automated development pipeline from a structured todolist.md file. The output is a self-contained directory that runs

autodev.sh

to drive Claude Code through a gated, TDD-enforced, card-by-card development workflow — fully automated, no human in the loop.

Trigger phrases: "帮我生成 xxx 的 autodev 文件", "create autodev for", "generate autodev pipeline"

What is Autodev?

Autodev is a spec-anchored, gate-guarded, TDD-enforced automated development methodology. It:

Splits a task list into sequential Task Cards (one AI session per card)
Enforces TDD 5-step closure per card (RED → GREEN → SPEC → LINT → GATE)
Runs automated gate checks between phases
Auto-repairs test failures (up to 10 retries per card)
Tracks progress in a state file for resumable execution
Independent acceptance verification per card (separate AI verifies ACs)
AI mutual review for high-risk decisions (SPEC-DECISION / AI-REVIEW / AI-GATE 三级)
Decision audit trail (
```
decisions.jsonl
```
) for cross-card traceability
Pipeline completion summary — auto-generates structured report: what was implemented, files changed, decisions made, test results
Bug Hunt phase — multi-round bug scanning + fixing after development: independent auditor finds P0/P1/P2 bugs, developer AI fixes with regression tests, loops until clean (up to 15 rounds)

Checklist

You MUST complete these steps in order:

Read the todolist — understand groups, tasks, phases, dependencies, test commands
Gather project context — identify spec doc, source files, test paths, key constraints
Design the pipeline — map todolist groups → phases → cards, define gate checks
Generate all files — autodev.sh, system_prompt.md, gate_check.sh, cards/*.md, phase_gate.md, state, decisions.jsonl
Verify — dry-run the script, confirm all card files exist, paths resolve correctly

Step 1: Read the Todolist

Read the todolist.md file completely. Extract:

Item	What to look for
Groups	Top-level sections (Group 1, Group 2...) — these become Phases
Tasks	Individual numbered items within groups — these become Cards (or get merged into Cards)
Dependencies	Which tasks depend on others — determines Card ordering
Execution phases	If the todolist defines phases (Phase A, B, C...) — use them directly
Test commands	How to run tests — becomes the test verification step
Key constraints	Backward compatibility, safety rules, P1 fixes — become system_prompt constraints
Source files	Which files are being modified — becomes Card "read existing code" sections
Spec/design docs	Referenced design documents — becomes the "single source of truth"

Step 2: Gather Project Context

Resolve context autonomously (no human confirmation in runtime):

1. What is the spec/design document path?
   → This is the "single source of truth" referenced by all cards

2. What is the test command?
   → e.g., "python3 -m pytest tests/test_foo.py -q" or "npm test"

3. Are there any interactive/manual tests that must be excluded?
   → CRITICAL: Scan the test directories for tests that require interactive input
     (stdin prompts, private keys, manual confirmation, GUI interaction, network
     services that won't be available in CI). These MUST be excluded from the test
     command via --ignore or path filtering.
   → Common patterns to look for:
     - input(), getpass(), prompt(), readline() calls in test files
     - Tests under directories named: live/, manual/, interactive/, e2e/, integration/
     - Tests that connect to external wallets, require API keys at runtime, or need
       running services
   → Add --ignore flags for each such directory/file. The generated test command must
     be fully non-interactive and able to run unattended.

4. What are the core source files being modified?
   → Listed in system_prompt as "project files"

5. What are the project-specific constraints?
   → e.g., "backward compatible", "no breaking changes", "量纲一致性"

6. Where should the Autodev directory live?
   → Convention: Autodev/{project_name}/

7. If anything is unclear, how should ambiguity be resolved?
   → Infer from repo evidence (todolist, spec, tests, git history, existing patterns),
     choose the most conservative backward-compatible option, and record assumptions in
     system_prompt.md ("Assumptions & Defaults"). Do NOT block for user confirmation.

Step 3: Design the Pipeline

Mapping Groups to Phases

Each Group in the todolist becomes a Phase. Each Phase ends with a GATE.

Group 1 → Phase A → GATE:A
Group 2 → Phase B → GATE:B
...
Last Group → Phase N → GATE:FINAL

Mapping Tasks to Cards

Merge small related tasks into single Cards. Keep complex tasks as their own Card. Target: 2-5 tasks per Card, 3-7 Cards per Phase.

Heuristics for merging:

Same source file → merge
Sequential dependency with no external dependency → merge
Total estimated complexity < 1 Claude session → merge

Heuristics for splitting:

Different source files → separate
Independent testable unit → separate
High complexity (e.g., "MC simulation core") → own Card

Card ID scheme

Use

{Phase}.{Sequence}

format:

Alphanumeric phases: A.1, A.2, B.1, C.1
Numeric phases: 0.1, 0.2, 1.1, 2.1

Adding verification Cards

Add a verification Card at the end of each Phase (before the GATE) that:

Runs all tests for that phase
Checks test coverage against the todolist
Runs full regression

Gate checks

Design gate_check.sh with:

Universal checks (always include):
- Unit tests pass
- Full regression tests pass
- SPEC-DECISION audit (grep for AI decisions)
Project-specific checks (customize):
- Backward compatibility verification
- Contract/interface checks
- Config consistency
- Import validation

Step 4: Generate All Files

Directory Structure

Autodev/{project_name}/
├── autodev.sh              # Main pipeline script
├── system_prompt.md        # AI session prompt
├── gate_check.sh           # Automated gate checks
├── state                   # Progress tracker (empty file)
├── decisions.jsonl         # Decision audit trail (empty file, runtime populated)
├── logs/                   # Runtime logs (empty dir)
├── bug_reports/            # Bug Hunt reports per round (runtime populated)
└── cards/
    ├── {A.1}.md            # Task cards
    ├── {A.2}.md
    ├── ...
    └── phase_gate.md       # Phase gate audit template

summary.md

is a runtime artifact. Do NOT pre-create it during scaffolding.

File Templates

Generate each file using the corresponding template reference. Read the template, customize all

{PLACEHOLDER}

values for the project, and write the complete file.

File	Template Reference	Description
`autodev.sh`	references/autodev-template.md	Main pipeline script with card execution, testing, AC verification, Bug Hunt
`system_prompt.md`	references/system-prompt-template.md	AI session prompt with TDD flow, decision protocol, safety rules
`cards/{ID}.md`	references/card-template.md	Task card with context, tasks, acceptance criteria
`gate_check.sh`	references/gate-check-template.md	Automated gate checks (tests, audit, coverage)
`cards/phase_gate.md`	references/phase-gate-template.md	Phase gate audit template for AI auditor

IMPORTANT: Do NOT use templates literally. Generate FULL files with all

{PLACEHOLDER}

values replaced for the specific project. The autodev.sh template shows the structure -- the actual output must be a complete, runnable bash script with all functions expanded.

Step 5: Verify

After generating all files:

```
chmod +x autodev.sh gate_check.sh
```
Run
```
./autodev.sh --dry-run
```
— verify all steps listed correctly
Run
```
./autodev.sh --status
```
— verify display works
Run
```
./autodev.sh --help
```
— verify help text
Verify all card files exist:
```
ls cards/
```
Verify state file is empty:
```
cat state
```

Verify decisions.jsonl exists and is empty:

test -f decisions.jsonl && [ ! -s decisions.jsonl ]

Verify summary.md does NOT exist yet (it's auto-generated at runtime)

Verify generated files contain no unresolved placeholders/stubs:

! rg -n '\{(PROJECT|SPEC|TODOLIST|TEST_CMD|ALL_STEPS_CONTENT|FIRST_CARD_ID|SOURCE_DIRS|AUTODEV_PATH|AUTODEV_DIR|ENV_PREFIX|ADDITIONAL_FILES|RELEVANT|EXISTING_FILES|ACCEPTANCE_CRITERION|CARD_TITLE|CARD_ID|ALLOWED_PATHS|FORBIDDEN_PATHS|TASKS_WITH)[^}]*\}' autodev.sh gate_check.sh system_prompt.md cards/*.md

Note:
```
{REVIEWER_ROLE}
```
in system_prompt.md is a runtime placeholder (filled by AI during AI-REVIEW execution), not a generation-time placeholder — do NOT flag it.

! rg -n 'show_help\(\) \{ \.\.\. \}|show_status\(\) \{ \.\.\. \}' autodev.sh

Key Principles

Todolist is the source of truth — every Card traces back to todolist tasks
P1/P2 fixes become constraints — embed audit corrections into Card acceptance criteria
Test command is sacred — must match what the todolist specifies
Test command must be non-interactive — the generated test command must run fully unattended with no stdin prompts. Scan the test directory for interactive tests (input(), getpass(), wallet prompts, manual e2e) and add --ignore flags to exclude them. A test command that hangs waiting for input will block the entire pipeline.
Backward compatibility — if todolist mentions fallback/compatibility, enforce in gate checks
No gold-plating — Cards only implement what the todolist describes
Each Card is self-contained — reads its own context, doesn't assume prior Card output was read

Generator Self-Check

After generating all files, verify these cross-cutting concerns:

system_prompt.md contains the full 3-level decision protocol (copy from template verbatim)
Reviewer role table is customized for the project (add/remove roles as needed; severity levels BLOCK/WARN/SUGGEST are universal — never modify)
gate_check.sh includes decisions.jsonl audit checks
phase_gate.md includes decision audit as step 5
All fix prompts include: test output verbatim, spec/todolist references, "no extra changes", backward compatibility reminder
decisions.jsonl
path flows correctly: config var →
```
build_prompt()
```
injects
```
DECISIONS_FILE:
```
→ Card AI reads it from prompt

auto-dev

NPX Install

Tags

SKILL.md Content