​

Built-in Workflows

​

Overview

# Interactive selection (shows all available workflows)
anyt worker start

# Specify workflow directly
anyt worker start --workflow local_dev
anyt worker start --workflow remote_dev
anyt worker start --workflow dry_run

anyt worker list-workflows

​

Workflow Comparison

​

Local Development (local_dev)

​

When to Use

• You’re already on a feature branch
• Quick bug fixes that don’t need PR review
• Iterating rapidly on a local feature
• Personal projects without PR workflow

​

What It Does

1. Fetch & Sync - Mark task active, pull task locally, read task.md
2. Plan - Create implementation plan if none exists (auto-approved)
3. Implement - Execute implementation with coding agent
4. Commit - Commit changes to current branch
5. Complete - Mark task as done

​

Usage

anyt worker start --workflow local_dev

# With project scope
anyt worker start --workflow local_dev --project-id 123

​

Requirements

• git - Version control
• Coding agent - Claude, Codex, Cursor, or Gemini
• Must be in a git repository

​

Remote Development (remote_dev)

​

When to Use

• Working on team projects with PR workflow
• Tasks in remote repositories you don’t have cloned
• When you want full automation from task to PR
• CI/CD environments running autonomous agents

​

What It Does

1. Clone - Automatically clones project repository
2. Branch - Creates task-specific branch
3. Fetch & Sync - Pull task locally, read task.md
4. Plan - Create implementation plan if none exists (auto-approved)
5. Implement - Execute implementation with coding agent
6. Commit & PR - Commit changes, push to remote, create PR
7. Complete - Mark task as done with PR link

​

Usage

anyt worker start --workflow remote_dev

# Keep workspace after execution (for debugging)
anyt worker start --workflow remote_dev --no-cleanup

​

Requirements

• git - Version control
• gh - GitHub CLI for PR creation
• Coding agent - Claude, Codex, Cursor, or Gemini
• Project must be linked to GitHub

​

PR Output

• Title: {TASK-ID}: {Task Title}
• Body: Task specification, implementation summary, files modified

​

Dry Run (dry_run)

​

When to Use

• First-time setup verification
• Testing workflow configuration
• CI/CD pipeline validation
• Debugging workflow issues without costs
• Training or demos

​

What It Does

1. Analyze (simulated) - Simulates task analysis
2. Post Analysis - Posts simulated analysis to task notes
3. Implement (simulated) - Simulates code implementation
4. Lint & Test (simulated) - Simulates quality checks
5. Commit (simulated) - Simulates git commit
6. Complete - Marks task as done

​

Usage

anyt worker start --workflow dry_run

​

Key Features

• No real file changes or commits
• No AI API calls (cost-free testing)
• Fast execution (~10 minutes max)
• Posts simulation results to task notes

​

PR Monitor (pr_monitor)

​

When to Use

• Periodic sync of PR statuses
• Batch updating task statuses based on PR outcomes
• Keeping AnyTask in sync with GitHub

​

What It Does

1. List - Lists all pending (open) PRs from AnyTask backend
2. Sync - Syncs each PR’s status from GitHub
3. Update - Updates linked tasks when PRs are merged (→ done) or closed (→ blocked)
4. Report - Posts summary of processed PRs

​

Usage

anyt worker start --workflow pr_monitor

​

Requirements

• gh - GitHub CLI (must be authenticated)
• Worker authentication token

​

Choosing the Right Workflow

​

Decision Tree

Do you need to create a PR?
├─ Yes → Use `remote_dev`
│         ├─ Clones repo automatically
│         ├─ Creates branch and PR
│         └─ Full automation
│
└─ No → Are you testing your setup?
        ├─ Yes → Use `dry_run`
        │         ├─ No real changes
        │         ├─ No API costs
        │         └─ Fast execution
        │
        └─ No → Use `local_dev`
                  ├─ Works on current branch
                  ├─ Commits directly
                  └─ Quick iterations

​

Quick Selection Guide

​

Common Workflow Phases

​

Phase 1: Fetch & Sync

1. Mark task as active status
2. Pull task to local .anyt/tasks/{ID}/ directory
3. Read task.md and context files

​

Phase 2: Plan Validation

1. Check if plan has changes_requested status → block if so
2. Check if plan is already approved → proceed to implementation
3. If no approved plan → create one and auto-approve

​

Phase 3: Implementation

# {Task Title}

## Problem Statement
Clear description of what needs to be done and why.

## Acceptance Criteria
- [ ] Specific, testable criterion 1
- [ ] Specific, testable criterion 2

## Implementation Plan
1. Concrete step 1
2. Concrete step 2

## Files to Modify
- `path/to/file1.ts` - What changes are needed

## Testing Checklist
- [ ] Unit tests added/updated
- [ ] Existing tests pass

​

Phase 4: Complete

1. Commit changes (and create PR for remote_dev)
2. Sync final task state to server
3. Mark task as done

​

Next Steps