autonomous-dev

TDD Development Workflow

A complete development workflow enforcing test-driven development, git worktree isolation, code review, CI verification, and E2E testing. Works in two modes: interactive (default) for human-guided sessions, and autonomous for fully unattended GitHub issue implementation.

NON-NEGOTIABLE RULES — every step marked MANDATORY is required. Do not skip, defer, or ask the user whether to run these steps. Execute them automatically as part of the workflow. This covers creating PRs, waiting for CI, running E2E tests, and addressing reviewer findings.

Mode Detection

Interactive Mode (default)

Used when a developer is present. The workflow:

• Asks the user for design approval before proceeding to implementation
• Presents design canvases and waits for feedback
• Pauses at key decision points for user input
• Reports final status and lets the user decide when to merge

Autonomous Mode

Triggered when running inside the scripts/autonomous-dev.sh wrapper. The workflow:

• Makes all decisions autonomously (see "Decision Making Guidelines" below)
• Posts progress comments to the GitHub issue instead of asking questions
• Creates design docs but skips interactive approval
• Stops after verification -- does not merge (the review agent handles that)
• Marks requirement checkboxes in the issue body as work progresses

Cross-Platform Notes

This skill works across IDEs that support skills.sh. Map generic verbs in this doc to your IDE's tools (Claude Code's Bash → terminal in Cursor, etc.). Hook-based enforcement is available on Claude Code, Codex CLI, and Kiro CLI; on clients without installed hooks, follow each step manually — the discipline is the same.

For the full IDE table + verb-to-tool map, see references/cross-platform.md.

Development Workflow Overview

Follow this workflow for all feature development and bug fixes:

Step 1:  DESIGN CANVAS (Pencil MCP, if available)
Step 2:  CREATE GIT WORKTREE (MANDATORY)
Step 3:  WRITE TEST CASES (TDD)
Step 4:  IMPLEMENT CHANGES
Step 5:  LOCAL VERIFICATION
Step 6:  CODE SIMPLIFICATION
Step 7:  COMMIT AND CREATE PR          -- MANDATORY
Step 8:  PR REVIEW AGENT               -- MANDATORY
Step 9:  WAIT FOR ALL CI CHECKS        -- MANDATORY
Step 10: ADDRESS REVIEWER BOT FINDINGS -- MANDATORY
Step 11: ITERATE UNTIL NO FINDINGS
Step 12: E2E TESTS & READY FOR MERGE   -- MANDATORY
Step 13: CLEANUP WORKTREE

Step 1: Design Canvas

Create a design canvas for new UI work, user-facing features, architecture decisions, and complex data flows. Skip for trivial fixes or refactors that don't change behavior.

• IDEs with Pencil MCP: create docs/designs/<feature>.pen.
• IDEs without Pencil MCP: create docs/designs/<feature>.md.

For the full Pencil MCP call sequence, the markdown canvas template, and the per-mode (interactive vs autonomous) approval gate, see references/design-canvas.md.

Step 2: Create Git Worktree (MANDATORY)

Every change MUST be developed in an isolated git worktree. Never develop directly on the main workspace.

Enforced by block-commit-outside-worktree.sh hook (if hooks are installed). Commits outside worktrees are automatically blocked. Direct pushes to main are blocked by block-push-to-main.sh.

Why Worktrees?

• Isolation: Each feature/fix gets its own directory, preventing cross-contamination
• Parallel work: Multiple features can be in progress simultaneously
• Clean main workspace: The main checkout stays on main, ready for quick checks
• Safe rollback: Discard a worktree without affecting the main workspace

Worktree Creation Process

Execute in your terminal:

# 1. Determine branch name based on change type
#    feat/<name>, fix/<name>, refactor/<name>, etc.
BRANCH_NAME="feat/my-feature"

# 2. Create worktree with new branch from main
git worktree add .worktrees/$BRANCH_NAME -b $BRANCH_NAME

# 3. Enter the worktree
cd .worktrees/$BRANCH_NAME

# 4. Install dependencies (use your project's package manager)
npm install  # or: bun install, yarn install, pnpm install

# 5. Verify clean baseline
npm run build && npm test

Directory Convention

Safety Checks

Before creating any worktree, verify .worktrees/ is in .gitignore:

git check-ignore -q .worktrees 2>/dev/null || echo "WARNING: .worktrees not in .gitignore!"

All Subsequent Steps Run INSIDE the Worktree

After creating the worktree, all development commands (test, lint, build, commit, push) are executed from within the worktree directory. The main workspace is not touched until cleanup.

Step 3: Write Test Cases (TDD)

Before writing any implementation code:

1. Read the design canvas and requirements
2. Identify all user scenarios, edge cases, and error handling paths
3. Create or edit the test case document: docs/test-cases/<feature>.md
   • List all test scenarios (happy path, edge cases, error handling)
   • Assign test IDs (e.g., TC-AUTH-001)
   • Define expected results and acceptance criteria
4. Create unit test skeletons
5. Create E2E test cases if applicable

Step 4: Implement Changes

• Write code following the test cases (inside the worktree)
• Write new unit tests for new functionality
• Update existing tests if behavior changed
• Ensure implementation covers all test scenarios

Step 5: Local Verification

Execute in your terminal:

timeout 1800 bash -lc 'npm run build && npm run test' > /tmp/verify.log 2>&1; rc=$?; [ $rc -ne 0 ] && tail -100 /tmp/verify.log; exit $rc

Fix any failures before proceeding. Deploy and verify locally if applicable.

How to run long verification

Run your project's build/test suite as one synchronous command with a generous timeout — never background it and poll across turns:

1. Run the top-level suite command synchronously with an explicit generous timeout. One blocking call (or a few sequential blocking calls, e.g. build then test) that returns the full result within the turn. Capture output and replay only the tail on failure:

   timeout 1800 bash -lc '<your project's build & test command>' > /tmp/verify.log 2>&1; rc=$?; [ $rc -ne 0 ] && tail -100 /tmp/verify.log; exit $rc
   

2. Never background the top-level suite (no &, no background task mode — whatever the host CLI calls it, e.g. run_in_background) and then poll its log across agent turns. Each poll is a full model round-trip; collective polling cost can exceed the suite's own runtime by orders of magnitude.
3. If the tool's max timeout genuinely cannot cover the suite, split by directory/prefix into a few sequential synchronous calls — still no polling.
4. Prefer a project-provided parallel runner when one exists.

Scope: the ban is on backgrounding the TOP-LEVEL verification command. Tests/scripts that internally spawn child processes or local servers are unaffected, as are genuinely event-driven waits (CI checks in Step 9, bot reviews in Steps 10-11).

Step 6: Code Simplification

1. Run an independent simplification pass using the strongest native option:
   • Codex CLI: ask Codex to spawn a native reviewer subagent focused on unnecessary complexity, duplication, and repository conventions. Keep the subagent advisory; the main session applies any changes.
   • Claude Code: use code-simplifier:code-simplifier when the plugin is installed.
   • Other clients: use an available review subagent or perform the same review manually.
2. Address simplification suggestions.
3. Mark complete (if hooks are installed):

   hooks/state-manager.sh mark code-simplifier
   

Step 7: Commit and Create PR (MANDATORY)

Commit

Execute in your terminal:

git add <files>
git commit -m "type(scope): description"
git push -u origin <branch-name>

Create PR

GitHub lane (CODE_HOST=github) — the example below uses the GitHub CLI. On the GitLab lane, the wrapper opens the merge request via the chp_create_pr provider seam; agents don't hand-roll the platform API call. Substitute glab mr create --title … --description … if you must invoke the CLI directly.

gh pr create --title "type(scope): description" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points describing the change>

## Design
- [ ] Design canvas created (`docs/designs/<feature>.pen`)
- [ ] Design approved

## Test Plan
- [ ] Test cases documented (`docs/test-cases/<feature>.md`)
- [ ] Build passes (`npm run build`)
- [ ] Unit tests pass (`npm run test`)
- [ ] CI checks pass
- [ ] Code simplification review passed
- [ ] PR review agent review passed
- [ ] Reviewer bot findings addressed (no new findings)
- [ ] E2E tests pass

## Checklist
- [ ] New unit tests written for new functionality
- [ ] E2E test cases updated if needed
- [ ] Documentation updated if needed
EOF
)"

Update PR Checklist

After completing each step, update the PR/MR description. Fetch the current body, mark items as [x], and write it back.

# GitHub lane (CODE_HOST=github):
gh pr view {pr_number} --json body --jq '.body' > /tmp/pr_body.md
# Edit the checklist (mark items as [x])
gh pr edit {pr_number} --body "$(cat /tmp/pr_body.md)"

# GitLab lane (CODE_HOST=gitlab):
glab mr view {mr_number} -F json | jq -r .description > /tmp/pr_body.md
# Edit the checklist (mark items as [x])
glab mr update {mr_number} --description "$(cat /tmp/pr_body.md)"

Step 8: PR Review Agent (MANDATORY)

1. Run an independent dev-side review:
   • Codex CLI: use a native reviewer subagent, or run codex review --uncommitted before the first commit and codex review --base <base-branch> for the committed branch d

Content truncated.