AI-Native Workflow Management System - A structured development workflow engine designed for AI-assisted software development.
- 한국어 README는 README.ko.md 참고
- Overview
- Key Features
- Quick Start
- Installation
- Configuration
- Commands Reference
- Workflow Concepts
- Tutorial
- Examples
- Advanced Usage
- Internationalization
- Troubleshooting
- Contributing
The AI Workflow Engine is a command-line tool that enforces structured development workflows. It's specifically designed to work with AI assistants (like Claude, GPT, etc.) to maintain discipline and consistency throughout the software development lifecycle.
When working with AI assistants on complex projects, several challenges arise:
- Context Loss: AI assistants may forget project state between sessions
- Process Skipping: Critical steps like reviews and testing get overlooked
- Documentation Drift: Specs and docs become outdated
- Technical Debt: Issues accumulate without tracking
The AI Workflow Engine solves these by:
- Enforcing Stage-Based Workflows: Each stage has mandatory checklists
- Providing State Awareness: AI can read current workflow state
- Requiring Explicit Transitions: Can't skip stages without completing requirements
- Logging All Actions: Complete audit trail of the development process
┌─────────────────────────────────────────────────────────────┐
│ CLI (flow) │
├─────────────────────────────────────────────────────────────┤
│ Commands: status | next | check | track | phase | review │
└─────────────────────────────┬───────────────────────────────┘
│
┌─────────────────────────────▼───────────────────────────────┐
│ Core Engine │
│ ┌────────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │
│ │ Controller │ │ State │ │ Scheduler│ │ Loader │ │
│ │ (Workflow │ │ (JSON │ │ (Phase │ │ (YAML │ │
│ │ logic) │ │ persist)│ │ DAG) │ │ config) │ │
│ └────────────┘ └──────────┘ └──────────┘ └────────────┘ │
└─────────────────────────────┬───────────────────────────────┘
│
┌─────────────────────────────▼───────────────────────────────┐
│ Plugin Layer │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ FileExistsValidator│ │ CommandValidator │ [Custom...] │
│ └──────────────────┘ └──────────────────┘ │
└─────────────────────────────────────────────────────────────┘
| Feature | Description |
|---|---|
| Stage-Based Workflow | Define stages (M0-M4, P1-P7) with checklists and transition rules |
| Enforced Transitions | Cannot advance without completing all checklist items |
| Plugin System | Extensible validators for custom conditions |
| State Persistence | JSON-based state tracking across sessions |
| Audit Logging | All actions are logged for accountability |
| Parallel Tracks | Run multiple workflow branches concurrently with flow track |
| Phase DAG | Define phase dependency graphs with automatic Fork/Join routing |
| Feature | Description |
|---|---|
| Status Command | AI can query current state at session start |
| USER-APPROVE | Certain actions require human verification |
| Sub-Agent Reviews | Record and track AI sub-agent reviews |
| Evidence Tracking | Attach justifications to completed items |
| Feature | Description |
|---|---|
| Bilingual Support | Full Korean/English i18n |
| Interactive Tutorial | Built-in learning system |
| Shell Alias | Easy flow command setup |
| YAML Configuration | Human-readable workflow definitions |
# 1. Clone and install
git clone https://github.com/hanyki111/workflow-tool.git
cd workflow-tool
pip install -e .
# 2. Check it works
flow --help
# 3. Initialize workflow in your project
cd /path/to/your-project
flow init --template simple # or "full" for advanced workflow
# 4. See current status
flow status
# 5. Start the tutorial
flow tutorialCreate workflow.yaml:
version: "2.0"
stages:
START:
id: "START"
label: "Project Start"
checklist:
- "Define project goals"
- "Set up development environment"
transitions:
- target: "DEVELOP"
DEVELOP:
id: "DEVELOP"
label: "Development"
checklist:
- "Write code"
- "Write tests"
- "Run tests"
transitions:
- target: "REVIEW"
REVIEW:
id: "REVIEW"
label: "Review"
checklist:
- "Code review completed"
- "[USER-APPROVE] Approve for merge"
transitions:
- target: "DONE"
DONE:
id: "DONE"
label: "Complete"
checklist:
- "Merge to main"
- "Update documentation"Create .workflow/state.json:
{
"current_stage": "START",
"checklist": []
}Now use it:
flow status # See current stage
flow check 1 2 # Mark items as done
flow next # Move to next stage- Python 3.10 or higher
- pip (Python package manager)
# Clone the repository
git clone https://github.com/hanyki111/workflow-tool.git
cd workflow-tool
# Create virtual environment (recommended)
python -m venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
# Install in editable mode
pip install -e .
# Verify installation
flow --helppip install ai-workflow-engine# Direct execution
python -m workflow --help
# Or set up an alias
alias flow='python -m workflow'For convenient access, install a shell alias:
# Automatic installation
flow install-alias --name flow
# Or manually add to ~/.bashrc or ~/.zshrc:
alias flow='python -m workflow'
# Reload shell config
source ~/.bashrc # or ~/.zshrc# Should display version and help
flow --help
# Should show "Workflow Management Tool"
python -m workflow --helpA typical project using workflow-tool:
my-project/
├── workflow.yaml # Workflow definition (required)
├── .workflow/
│ ├── state.json # Current state (auto-created)
│ ├── secret # Secret hash for USER-APPROVE (gitignored)
│ ├── audit/ # Action audit logs (gitignored)
│ │ └── workflow.log
│ └── ACTIVE_STATUS.md # AI status hook (auto-created, gitignored)
├── CLAUDE.md # AI agent instructions (optional)
└── ... (your project files)
Complete configuration reference:
# Version (required)
version: "2.0"
# Global variables (optional)
variables:
project_name: "my-project"
test_command: "pytest -v"
# Plugin registration (optional)
plugins:
fs: "workflow.plugins.fs.FileExistsValidator"
shell: "workflow.plugins.shell.CommandValidator"
# Path configuration (optional, all default to .workflow/)
audit_dir: ".workflow/audit" # Audit log directory
status_file: ".workflow/ACTIVE_STATUS.md" # AI status hook file
guide_file: "docs/WORKFLOW_GUIDE.md" # Guide file for checklist sync (optional)
# Phase cycle definition (optional, enables Phase DAG auto-routing)
phase_cycle:
start: "P1" # First stage in phase cycle
end: "P7" # Last stage in phase cycle
# Reusable condition sets (optional)
rulesets:
all_checked:
- rule: all_checked
fail_message: "Complete all checklist items first"
tests_pass:
- rule: shell
args:
cmd: "pytest"
expect_code: 0
fail_message: "Tests must pass"
# Stage definitions (required)
stages:
M0:
id: "M0" # Unique identifier
label: "Tech Debt Review" # Human-readable name
checklist: # Items to complete (string or object)
- "Review existing tech debt" # Simple string (manual check)
- "Prioritize debt items"
- "[USER-APPROVE] Approve debt plan" # Requires token
# Active Workflow: checklist item with auto-executed action
- text: "Run linter"
action: "npm run lint" # Executes on `flow check N`
# Action with required arguments
- text: "Record progress"
action: "echo 'Progress: {args}'" # {args} replaced by --args value
require_args: true # Fails if --args not provided
transitions: # Where can we go from here?
- target: "M1"
conditions:
- use_ruleset: all_checked # Reference a ruleset
- rule: fs # Or use a plugin directly
args:
path: "docs/debt-plan.md"
on_enter: # Actions on stage entry (optional)
- action: "log"
args:
message: "Starting tech debt review"
M1:
id: "M1"
label: "Planning"
# ... more stages.workflow/state.json:
{
"current_milestone": "M1",
"current_phase": "1.2",
"current_stage": "P3",
"active_module": "inventory-system",
"checklist": [
{
"text": "Write unit tests",
"checked": true,
"evidence": "All 15 tests passing",
"required_agent": null
},
{
"text": "[USER-APPROVE] Deploy to staging",
"checked": false,
"evidence": null,
"required_agent": null
}
],
"tracks": {
"auto-auth": {
"current_stage": "P4",
"active_module": "auth",
"checklist": [],
"label": "Authentication",
"status": "in_progress",
"phase_id": "auth",
"created_by": "auto"
}
},
"active_track": "auto-auth",
"phase_graph": {
"auth": {"id": "auth", "label": "Authentication", "module": "auth", "depends_on": [], "status": "active"},
"api": {"id": "api", "label": "API Layer", "module": "api", "depends_on": ["auth"], "status": "pending"}
}
}| Variable | Description | Default |
|---|---|---|
FLOW_LANG |
Display language (en, ko) |
System locale |
Initialize a new workflow in your project directory. Creates workflow.yaml, .workflow/ directory, and optionally generates CLAUDE.md for AI agents.
# Initialize with simple 4-stage workflow (recommended for beginners)
flow init --template simple
# Initialize with full M0-M4, P1-P7 dual-track workflow
flow init --template full
# Specify project name
flow init --template simple --name my-project
# Skip CLAUDE.md generation
flow init --no-claude-md
# Force overwrite existing files
flow init --force
# List available templates
flow init --list-templatesOptions:
| Option | Description |
|---|---|
--template, -t |
Template to use: simple or full (default: simple) |
--name, -n |
Project name (default: current directory name) |
--no-claude-md |
Don't generate CLAUDE.md file |
--no-guide |
Don't generate workflow guide file |
--force, -f |
Overwrite existing files |
--list-templates |
Show available templates and exit |
Display current workflow state.
# Full status display
flow status
# Output:
# Current Stage: M0 (Tech Debt Review)
# ========================================
# Active Module: core-engine
# ----------------------------------------
# 1. [x] Review existing tech debt
# 2. [x] Prioritize debt items
# 3. [ ] [USER-APPROVE] Approve debt plan
# Compact one-line format
flow status --oneline
# Output: M0 (Tech Debt Review) - 2/3Mark checklist items as completed. If the item has an action defined, it will be executed automatically.
# Check single item (1-based index)
flow check 1
# Check multiple items
flow check 1 2 3
# Add evidence/justification
flow check 1 --evidence "Reviewed with team on 2024-01-15"
# Check USER-APPROVE item with token
flow check 3 --token "your-secret-phrase"
# Check with both
flow check 3 --token "secret" --evidence "Approved by @alice after security review"
# Pass arguments to action (for items with require_args: true)
flow check 5 --args "feat(auth): add login validation"Active Workflow (Action Execution):
When a checklist item has an action field, the command is executed automatically:
$ flow check 1
✅ Action executed: npm run lint
Output: All files passed linting
Checked: Run linterIf the action fails (non-zero exit code), the item is NOT marked as checked:
$ flow check 2
❌ Action failed for item 2: Tests failed with 3 errorsRalph Loop Mode (Auto-Retry):
Items with ralph configuration will automatically retry via Task subagent on action failure:
# workflow.yaml - Basic usage (exit code based)
checklist:
- text: "Pass tests"
action: "pytest"
ralph:
enabled: true
max_retries: 5
hint: "Analyze failing tests and fix the code"Output-based success/failure detection (success_contains / fail_contains):
Useful when success/failure should be determined by output content, like agent review results:
# workflow.yaml - Output pattern matching
checklist:
- text: "Pass code review"
action: "cat .workflow/code_review.md"
ralph:
enabled: true
max_retries: 5
success_contains: # Success if output contains any of these
- "**PASS**"
- "**CONDITIONAL PASS**"
fail_contains: # Fail if output contains any of these (priority)
- "**FAIL**"
hint: "Run code-reviewer agent and fix FAIL issues"$ flow check 1
🔄 [RALPH MODE] Action failed (attempt 1/5)
Goal: Make `cat .workflow/code_review.md` succeed
Error: Fail pattern found in output: "**FAIL**"
📋 Instructions for Task subagent:
1. Analyze the error and fix the code
2. Run flow check 1 again
3. Repeat until successWhen Claude runs a Task subagent, it will fix the code and run flow check 1 again. This continues until success or max retries is reached.
Revert checked items to unchecked state:
# Uncheck items
flow uncheck 1 2
# Using alias
flow u 1
# Uncheck USER-APPROVE item (requires token)
flow u 3 --token "your-secret"Transition to the next stage.
# Auto-detect next stage (uses first valid transition)
flow next
# Specify target stage explicitly
flow next M1
# Skip plugin conditions (shell, fs) but still require all items checked
flow next --skip-conditions
# Force transition (bypasses all conditions, requires token)
flow next --force --token "your-secret" --reason "Emergency hotfix required"
# Possible outputs:
# Success: "✅ Transitioned to M1: Planning"
# Skip: "⚠️ [SKIP-CONDITIONS] Transitioned to P5"
# Blocked: "Cannot proceed. Unchecked items: ..."Options comparison:
| Option | Checklist Required | Plugin Conditions | Token Required |
|---|---|---|---|
| (none) | ✅ Yes | ✅ Yes | No |
--skip-conditions |
✅ Yes | ❌ Skipped | No |
--force |
❌ No | ❌ No | ✅ Yes |
Manually set current stage or module.
# Set stage only
flow set M2
# Set stage and active module
flow set P3 --module inventory-system
# Useful for:
# - Resuming after state corruption
# - Jumping to a specific point
# - Testing specific stagesChange active module without changing stage. Does not require --force even if there are unchecked items.
# Change module while keeping current stage
flow module set inventory-system
# Useful for:
# - Switching context at start of new phase (P1)
# - Working on different module without resetting checklistManage parallel workflow tracks for concurrent development.
# Create a parallel track
flow track create --id feat-auth --label "Authentication" --module auth
# Create with specific starting stage
flow track create --id feat-api --label "API Layer" --module api --stage P1
# List all tracks
flow track list
# Switch active track
flow track switch feat-auth
# Use --track flag with any command
flow check 1 2 --track feat-auth
flow status --track feat-auth
flow next --track feat-auth
# Join all completed tracks
flow track join
# Force join (even with incomplete tracks)
flow track join --force --token "your-secret"
# Delete a track
flow track delete feat-authTrack-Scoped Commands:
Most commands accept --track <id> to operate on a specific track:
| Command | With --track |
|---|---|
flow status |
Shows track's stage and checklist |
flow check |
Checks items in the track |
flow next |
Advances the track's stage |
flow review |
Records review for the track |
Manage Phase DAG (Directed Acyclic Graph) for automatic parallel routing.
# Add phases with dependencies
flow phase add --id auth --label "Authentication" --module auth
flow phase add --id api --label "API Layer" --module api --depends-on auth
flow phase add --id ui --label "UI Components" --module ui --depends-on auth
# View DAG as list
flow phase list
# View DAG level visualization
flow phase graph
# Output:
# Phase DAG (3 phases, 2 levels):
# Level 0: auth (Authentication) [pending]
# Level 1: api (API Layer) [pending], ui (UI Components) [pending]
# Remove a phase
flow phase remove --id uiHow Phase DAG Auto-Routing Works:
When phase_cycle is configured in workflow.yaml and phases are defined:
- On
flow nextat cycle end (e.g., P7 -> P1), the engine checks available phases - Sequential: One available phase -> advances to it automatically
- Fork: Multiple available phases -> creates auto-tracks for parallel execution
- Join/Wait: Phase complete but siblings still running -> waits
- All Complete: All phases done -> allows milestone transition (e.g., P7 -> M4)
# workflow.yaml - Enable Phase DAG routing
phase_cycle:
start: "P1"
end: "P7"
# Then define phases at runtime:
# flow phase add --id auth --label "Auth" --module auth
# flow phase add --id api --label "API" --module api --depends-on authRecord sub-agent review results.
flow review --agent "code-reviewer" --summary "All SOLID principles followed, no blocking issues found"
# Record review for a specific track
flow review --agent "code-reviewer" --summary "Review passed" --track feat-auth
# This creates an audit log entry that can be verified laterWhen checking an [AGENT:name] item, you can register the agent review inline:
# Instead of two commands:
flow review --agent plan-critic --summary "..."
flow check 1
# Use one command:
flow check 1 --agent plan-criticThis automatically registers the agent review before checking the item.
Create a secret for USER-APPROVE items.
** IMPORTANT !! ** : [USER-APPROVE] check, --force option requires secret token. If you send your secret by interactive shell running inside claude-cli or gemini-cli, secret token will be exposed to AI and then AI will bypass [USER-APPROVE] or --force option without your approve. you MUST send a secret token via additional terminal.
flow secret-generate
# Interactive prompts:
# Enter your secret phrase: ********
# Confirm secret phrase: ********
# Secret hash saved to .workflow/secretGenerate shell wrappers that automatically update checklist when CLI commands are executed.
# Install wrappers for auto-detected shell
flow install-wrappers
# Specify shell
flow install-wrappers --shell bash
flow install-wrappers --shell powershell
# Preview wrappers without installing
flow install-wrappers --list
# Dry run - show changes without applying
flow install-wrappers --dry-run
# Remove wrappers
flow install-wrappers --uninstallAdd tags to workflow.yaml:
stages:
P3:
checklist:
- "[CMD:pytest] Run tests"
- "[CMD:mypy] Type check"Generated wrapper (Bash/Zsh):
pytest() {
command pytest "$@"
local result=$?
[ $result -eq 0 ] && flow check --tag "CMD:pytest" 2>/dev/null
return $result
}Once installed, running pytest will automatically update the checklist on success.
Access the built-in tutorial system.
# List all sections
flow tutorial --list
# View specific section
flow tutorial --section 0
# Start interactive tutorial
flow tutorial
# Use alias
flow guide --section 2Install shell alias for easier access.
# Install with default name 'flow'
flow install-alias
# Install with custom name
flow install-alias --name wf# Set display language
flow --lang ko status
flow --lang en --help
# Get help
flow --help
flow status --helpStages are fully user-defined. The workflow engine uses a flat stage dictionary internally - there is no built-in hierarchy. "Depth" or "levels" are achieved purely through naming conventions.
stages:
START: { label: "Project Start", ... }
DEVELOP: { label: "Development", ... }
REVIEW: { label: "Review", ... }
DONE: { label: "Complete", ... }stages:
M1: { label: "Planning", ... }
M2: { label: "Execution", ... }
P1: { label: "Design", ... }
P2: { label: "Implementation", ... }stages:
P1_M1_T1: { label: "Project1 - Planning - Research", ... }
P1_M1_T2: { label: "Project1 - Planning - Design", ... }
P1_M2_T1: { label: "Project1 - Execution - Coding", ... }
P2_M1_T1: { label: "Project2 - Planning - Research", ... }Use flow init --template simple or flow init --template full to generate example workflows, then customize as needed.
The flow between stages is defined by transitions in workflow.yaml:
┌─────────────────────────────────────────────────────────────┐
│ EXAMPLE: LINEAR FLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ START ──► DEVELOP ──► REVIEW ──► DONE ──► (loop back) │
│ │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ EXAMPLE: MILESTONE + PHASE FLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ M0 → M1 → M2 → M3 → [P1 → P2 → ... → P7] → M4 → (loop) │
│ └─────── repeats ──────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ EXAMPLE: PHASE DAG (PARALLEL EXECUTION) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Phase DAG: auth ──► api ──► deploy │
│ └───► ui ──┘ │
│ │
│ Execution: [auth] → Fork → [api] + [ui] → Join → [deploy]│
│ (each phase runs P1→P7 cycle independently) │
│ │
└─────────────────────────────────────────────────────────────┘
Run multiple workflow branches concurrently. Each track maintains its own stage, module, and checklist independently.
Manual tracks (created with flow track create):
flow track create --id feat-auth --label "Auth Module" --module auth
flow track create --id feat-api --label "API Module" --module api
flow track switch feat-auth # Work on auth
flow check 1 2 3 # Check items in auth track
flow track switch feat-api # Switch to api
flow next # Advance api track
flow track join # Merge when all completeAuto-tracks (created by Phase DAG):
When a Phase DAG is active and multiple phases can run in parallel, the engine automatically creates tracks (named auto-<phase-id>) and routes work through them.
Define phase dependencies as a Directed Acyclic Graph. The engine automatically routes transitions through the DAG when completing phase cycles.
Setup:
# 1. Define phase cycle in workflow.yaml
phase_cycle:
start: "P1"
end: "P7"# 2. Add phases at runtime
flow phase add --id auth --label "Authentication" --module auth
flow phase add --id api --label "API" --module api --depends-on auth
flow phase add --id ui --label "UI" --module ui --depends-on auth
flow phase add --id deploy --label "Deploy" --module deploy --depends-on api,uiAuto-routing behavior:
| Scenario | What happens |
|---|---|
| Single available phase | Advances to it (sequential) |
| Multiple available phases | Creates auto-tracks (fork) |
| Phase complete, siblings running | Waits with status message |
| All siblings complete | Advances to next phase(s) |
| All phases complete | Allows milestone transition |
Each stage has a checklist of items that must be completed:
checklist:
- "Regular item - just check when done"
- "[USER-APPROVE] Requires human verification with token"
- "[AGENT:spec-validator] Requires sub-agent review"Checklist Item Types:
| Type | Syntax | Description |
|---|---|---|
| Regular | "Item text" |
AI can check freely |
| User Approve | "[USER-APPROVE] Text" |
Requires secret token |
| Agent Review | "[AGENT:name] Text" |
Requires sub-agent verification |
Transitions define how to move between stages:
transitions:
- target: "M1" # Where to go
conditions: # What must be true
- use_ruleset: all_checked # Use predefined ruleset
- rule: fs # Use plugin validator
args:
path: "docs/plan.md"
fail_message: "Plan document must exist"Transition Rules:
| Rule | Description |
|---|---|
all_checked |
All checklist items must be checked |
user_approved |
USER-APPROVE items must have valid token |
use_ruleset |
Apply a named ruleset |
| Plugin rules | Custom validators (fs, shell, etc.) |
Built-in plugins for transition conditions:
plugins:
fs: "workflow.plugins.fs.FileExistsValidator"
# Usage in conditions:
conditions:
- rule: fs
args:
path: "src/main.py" # File to check
not_empty: true # Must have content (optional)plugins:
shell: "workflow.plugins.shell.CommandValidator"
# Usage in conditions:
conditions:
- rule: shell
args:
cmd: "pytest tests/" # Command to run
expect_code: 0 # Expected exit code (default: 0)The workflow tool includes a comprehensive built-in tutorial:
# List all tutorial sections
flow tutorial --list
# Output:
# 0. Introduction
# 1. Installation & Setup
# 2. Basic Commands
# 3. Security & Secrets
# 4. Advanced Features
# 5. Best Practices
# View a specific section
flow tutorial --section 0
# Start interactive mode
flow tutorial| Section | Topics Covered |
|---|---|
| 0. Introduction | What is workflow-tool, key concepts, quick start |
| 1. Installation | pip install, shell alias, initial configuration |
| 2. Basic Commands | status, check, next, set - with examples |
| 3. Security | USER-APPROVE, secret generation, audit trail |
| 4. Advanced | Custom plugins, rulesets, variables, hooks |
| 5. Best Practices | Design tips, daily workflow, AI collaboration |
For New Users:
- Run
flow tutorialto start interactive tutorial - Follow sections 0-2 for basics
- Create a simple workflow for practice
- Advance to sections 3-5
For Experienced Users:
- Check
flow tutorial --section 4for advanced features - Review examples in
examples/directory - Create custom plugins for your needs
The examples/ directory contains ready-to-use workflow configurations:
Location: examples/simple/
A minimal 3-stage workflow for small projects:
cd examples/simple
flow statusLocation: examples/full-project/
Complete M0-M4, P1-P7 dual-track workflow example:
cd examples/full-project
flow statusLocation: examples/custom-plugins/
Demonstrates creating and using custom validators:
cd examples/custom-plugins
flow statusSee examples/README.md for detailed documentation of each example.
Transform your checklist from passive checkboxes into an active task runner. When you check an item with an associated action, the command executes automatically.
Configuration:
stages:
P7:
label: "Phase Closing"
checklist:
# Simple string (manual check, as usual)
- "Review code quality"
# Action item (auto-executed on check)
- text: "Run tests"
action: "pytest -v"
# Action with required arguments
- text: "Git commit"
action: 'git add . && git commit -m "${args}"'
require_args: true
# Action with context variables
- text: "Update module status"
action: "${python} -m memory_tool update ${active_module}"
# Action that accepts warnings (exit code 0 or 1)
- text: "Run linter (warnings OK)"
action: "eslint src/"
allowed_exit_codes: [0, 1]Built-in Variables:
Actions can use these built-in variables that are automatically substituted:
| Variable | Description | Example Value |
|---|---|---|
${python} |
Current Python interpreter (venv-aware) | /path/to/.venv/bin/python |
${python_exe} |
Alias for ${python} |
/path/to/.venv/bin/python |
${cwd} |
Current working directory | /path/to/project |
${args} |
CLI --args value (when provided) |
feat: add login |
Context variables from workflow.yaml (e.g., ${active_module}) are also available. Nested variables are supported (e.g., ${test_cmd} containing ${python}).
Note: Actions inherit the full shell environment including
PYTHONPATH,VIRTUAL_ENV, andPATH. This ensures commands run in the same context as the workflow tool itself.
Usage:
# Simple item - just marks as done
flow check 1
# Action item - executes command, then marks as done (if successful)
flow check 2
# ✅ Action executed: pytest -v
# Output: 15 passed in 2.34s
# Checked: Run tests
# Item requiring arguments
flow check 3 --args "feat(auth): add login validation"
# ✅ Action executed: git add . && git commit -m "feat(auth): add login validation"
# Checked: Git commit
# If action fails, item is NOT checked
flow check 2
# ❌ Action failed for item 2: 3 tests failed
# → Use --skip-action to mark as done without running action
# Skip action and mark as done manually
flow check 2 --skip-action
# ⚠️ Action skipped for item 2: pytest -v
# Checked: Run testsBenefits:
| Before (Passive) | After (Active) |
|---|---|
| AI marks item as done | AI must run the actual command |
| No verification | Command must succeed (exit 0) |
| Easy to skip | Enforced execution |
| Manual audit | Automatic audit trail |
The workflow tool supports cross-platform compatibility with two features:
Check file contents without shell commands - works identically on Windows, Mac, and Linux:
checklist:
- text: "Review passed"
file_check:
path: ".workflow/reviews/critic.md"
success_contains: ["APPROVED", "CONDITIONAL PASS"]
fail_contains: ["FAIL"]
fail_if_missing: true
encoding: "utf-8" # Optional, default: utf-8
ralph:
enabled: true
max_retries: 3Options:
| Option | Description |
|---|---|
path |
File path to check (supports variables like ${active_module}) |
success_contains |
Check passes if file contains any of these patterns |
fail_contains |
Check fails if file contains any of these (priority over success_contains) |
fail_if_missing |
Fail if file doesn't exist (default: false) |
encoding |
File encoding (default: utf-8) |
Note: file_check and action are mutually exclusive - use one or the other.
Define different commands for different platforms:
checklist:
- text: "Build project"
action:
unix: "make build"
windows: "msbuild project.sln"
all: "python build.py" # Optional: same for all platformsPriority: all > platform-specific (windows or unix)
Platform detection: Uses sys.platform == 'win32' to detect Windows.
Sync checklists from your existing project documentation (e.g., CONTRIBUTING.md, WORKFLOW.md, or any markdown file). The engine parses markdown checkboxes from headers matching the stage label.
Configuration:
# workflow.yaml
guide_file: "docs/WORKFLOW_GUIDE.md" # Path to your markdown document
stages:
REVIEW:
label: "Code Review" # Matches header in guide_file
checklist: [] # Empty - will sync from guide_fileGuide File Example (docs/WORKFLOW_GUIDE.md):
## Code Review
Before merging, ensure:
- [ ] All tests pass
- [ ] Code follows style guide
- [ ] [USER-APPROVE] Security review completed
- [ ] Documentation updatedHow It Works:
- When entering a stage, the engine looks for a header containing the stage label
- Extracts all markdown checkboxes (
- [ ]or- [x]) below that header - Syncs them as the stage's checklist
Benefits:
- Single source of truth for project workflow documentation
- Non-technical stakeholders can edit the guide file
- Workflow stays in sync with documentation automatically
Automate agent review registration using CLI hooks. When an AI agent completes a review, the hook automatically registers it with the workflow system.
Both Claude Code and Gemini CLI support hooks with similar configuration patterns.
- Copy the hook script:
mkdir -p .claude/hooks
cp examples/hooks/auto-review.sh .claude/hooks/
chmod +x .claude/hooks/auto-review.sh- Configure
.claude/settings.json:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Task",
"hooks": [
{
"type": "command",
"command": ".claude/hooks/auto-review.sh"
}
]
}
]
}
}- Copy the hook script:
mkdir -p .gemini/hooks
cp examples/hooks/auto-review.sh .gemini/hooks/
chmod +x .gemini/hooks/auto-review.sh- Configure
settings.json:
{
"hooks": {
"AfterTool": [
{
"matcher": "spawn_agent|delegate",
"hooks": [
{
"type": "command",
"command": "$GEMINI_PROJECT_DIR/.gemini/hooks/auto-review.sh"
}
]
}
]
}
}| Feature | Claude Code | Gemini CLI |
|---|---|---|
| Event name | PostToolUse |
AfterTool |
| Config file | .claude/settings.json |
settings.json |
| Path variable | (relative path) | $GEMINI_PROJECT_DIR |
| Status | Stable | Experimental |
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐
│ AI CLI │────►│ Hook Event │────►│ flow review │
│ Task/Agent │ │ (PostToolUse/ │ │ --agent X │
│ tool call │ │ AfterTool) │ │ auto-registered│
└─────────────────┘ └──────────────────┘ └─────────────────┘
- AI calls agent delegation tool
- CLI's post-execution hook intercepts the completion
- Hook script extracts agent name and calls
flow review - Agent review is registered in audit log
flow checkfor[AGENT:name]items now passes
If hooks aren't configured, use the --agent flag:
# After agent delegation completes
flow check 1 --agent code-reviewer- Create a validator class:
# my_project/validators/api_validator.py
from workflow.core.validator import BaseValidator
import requests
class APIHealthValidator(BaseValidator):
"""Check if an API endpoint is healthy."""
def validate(self, args, context):
url = args.get('url')
timeout = args.get('timeout', 5)
try:
response = requests.get(url, timeout=timeout)
return response.status_code == 200
except:
return False- Register in workflow.yaml:
plugins:
api_health: "my_project.validators.api_validator.APIHealthValidator"- Use in conditions:
stages:
DEPLOY:
transitions:
- target: "DONE"
conditions:
- rule: api_health
args:
url: "https://api.example.com/health"
timeout: 10
fail_message: "API health check failed"Define common condition sets once:
rulesets:
production_ready:
- rule: all_checked
- rule: shell
args:
cmd: "pytest"
- rule: shell
args:
cmd: "mypy src/"
- rule: fs
args:
path: "CHANGELOG.md"
not_empty: true
stages:
PRE_DEPLOY:
transitions:
- target: "DEPLOY"
conditions:
- use_ruleset: production_readyUse variables for consistency:
variables:
project_name: "my-app"
test_cmd: "pytest tests/ -v"
main_branch: "main"
stages:
TEST:
checklist:
- "Run ${test_cmd}"
transitions:
- target: "MERGE"
conditions:
- rule: shell
args:
cmd: "${test_cmd}"Skip conditions based on context using the when clause:
stages:
IMPLEMENT:
transitions:
- target: "REVIEW"
conditions:
# Only check implementation directory for code modules
- rule: fs
when: '${active_module} not in ["roadmap", "docs"]'
args:
path: "src/${active_module}/"
# Only run tests for code modules
- rule: shell
when: '${active_module} not in ["roadmap", "docs"]'
args:
cmd: "pytest tests/${active_module}/"Supported operators:
==,!=- equality/inequalityin,not in- list membership
When a when condition evaluates to false, the rule is marked as SKIPPED in the audit log.
Automatically load workflow status when AI starts a session. Both Claude Code and Gemini CLI support SessionStart hooks.
Claude Code (.claude/settings.json):
{
"hooks": {
"SessionStart": [
{ "matcher": "startup", "hooks": [{ "type": "command", "command": "flow status 2>/dev/null || true" }] },
{ "matcher": "resume", "hooks": [{ "type": "command", "command": "flow status --oneline 2>/dev/null || true" }] }
]
}
}Gemini CLI (settings.json):
{
"hooks": {
"SessionStart": [
{ "matcher": "startup", "hooks": [{ "type": "command", "command": "flow status 2>/dev/null || true" }] },
{ "matcher": "resume", "hooks": [{ "type": "command", "command": "flow status --oneline 2>/dev/null || true" }] }
]
}
}Matchers: startup (new session), resume (continue session), clear (after /clear)
Result: AI automatically knows the current workflow state at session start.
Show workflow status every time user submits a prompt.
Claude Code - UserPromptSubmit:
{
"hooks": {
"UserPromptSubmit": [
{ "hooks": [{ "type": "command", "command": "flow status --oneline 2>/dev/null || true" }] }
]
}
}Gemini CLI - BeforeModel:
{
"hooks": {
"BeforeModel": [
{ "hooks": [{ "type": "command", "command": "flow status --oneline 2>/dev/null || true" }] }
]
}
}| Hook | Trigger | Use Case |
|---|---|---|
SessionStart |
Once at session start | Initial context |
UserPromptSubmit / BeforeModel |
Every prompt | Real-time tracking |
Automatically check items when CLI commands succeed using tags and shell wrappers.
Step 1: Add tags to checklist items
stages:
DEVELOP:
checklist:
- "[CMD:pytest] Run tests"
- "[CMD:memory-write] Save documentation"
- "[CMD:lint] Run linter"Step 2: Create shell wrappers (in .bashrc or project .envrc)
# pytest wrapper
pytest() {
command pytest "$@"
[ $? -eq 0 ] && flow check --tag "CMD:pytest" 2>/dev/null
}
# Subcommand-aware wrapper
memory_tool() {
command memory_tool "$@"
[ $? -eq 0 ] && case "$1" in
write|save) flow check --tag "CMD:memory-write" ;;
esac
}Step 3: Use normally - checklist auto-updates on success
pytest tests/ # ✅ Auto-checks "[CMD:pytest] Run tests"
memory_tool write x # ✅ Auto-checks "[CMD:memory-write] Save documentation"
memory_tool read x # (no check - read is not mapped)Benefits:
- Works for both AI and human-executed commands
- Subcommand-aware (only specific actions trigger checks)
- No need to know item index numbers
- Explicit tags prevent accidental matches
Execute actions when entering a stage:
stages:
P4:
label: "Implementation"
on_enter:
- action: "shell"
args:
cmd: "git status"
- action: "log"
args:
message: "Starting implementation phase"Instruct your AI assistant to follow the workflow:
## AI Instructions
Before starting any task:
1. Run `flow status` to check current stage
2. Follow the checklist items in order
3. Check off items as you complete them: `flow check N`
4. Don't proceed to next stage until all items are done
5. Use `flow next` to advance when ready
For USER-APPROVE items:
- Ask the human to run `flow check N --token "..."`
- Wait for confirmation before proceedingFor organizations with multiple projects:
organization/
├── workflow-templates/ # Shared templates
│ ├── standard-workflow.yaml
│ └── hotfix-workflow.yaml
├── project-a/
│ └── workflow.yaml # Can extend templates
├── project-b/
│ └── workflow.yaml
| Code | Language | Status |
|---|---|---|
en |
English | Full support |
ko |
Korean (한국어) | Full support |
# Via command line flag
flow --lang ko status
# Via environment variable
export FLOW_LANG=ko
flow status
# Language detection priority:
# 1. --lang flag
# 2. FLOW_LANG environment variable
# 3. System locale
# 4. Default (English)- Create message catalog:
workflow/i18n/messages/{lang}.yaml - Create tutorial content:
workflow/tutorial/content/{lang}/ - Test:
flow --lang {lang} --help
# Error: Configuration file not found: workflow.yaml
# Solution: Create workflow.yaml in project root
# Or specify path: flow --config path/to/workflow.yaml status# Error: Cannot transition: All checklist items must be completed
# Solution: Check remaining items
flow status
# Complete missing items
flow check 3 4
# Try again
flow next# Error: Invalid token for USER-APPROVE
# Solution 1: Check if secret is generated
ls .workflow/secret
# Solution 2: Regenerate secret
flow secret-generate
# Solution 3: Use correct phrase
flow check 2 --token "your-actual-secret"# Error: Failed to load plugin: my_plugin
# Solution: Check plugin path in workflow.yaml
# Ensure the module is importable:
python -c "from my_project.validators import MyValidator"# If state.json is corrupted:
# Option 1: Reset to a known stage
flow set M0
# Option 2: Delete and reinitialize
rm .workflow/state.json
flow status # Creates fresh stateFor detailed debugging:
# Set Python debug
PYTHONDEBUG=1 flow status
# Check state file directly
cat .workflow/state.json | python -m json.tool
# Validate YAML config
python -c "import yaml; yaml.safe_load(open('workflow.yaml'))"- Tutorial:
flow tutorial - Command Help:
flow <command> --help - Documentation:
.workflow/docs/ - Issues: https://github.com/hanyki111/workflow-tool/issues
# Clone repository
git clone https://github.com/hanyki111/workflow-tool.git
cd workflow-tool
# Create virtual environment
python -m venv .venv
source .venv/bin/activate
# Install in development mode
pip install -e ".[dev]"
# Run tests
pytest tests/ -vworkflow-tool/
├── workflow/ # Main package
│ ├── __init__.py
│ ├── __main__.py # Entry point
│ ├── cli.py # CLI commands
│ ├── core/ # Core engine
│ │ ├── controller.py # Main logic (tracks, phases, transitions)
│ │ ├── state.py # State management (tracks, phase_graph)
│ │ ├── scheduler.py # Phase DAG scheduler (Fork/Join)
│ │ ├── schema.py # Data classes
│ │ ├── validator.py # Base validator
│ │ ├── loader.py # Config loading
│ │ └── auth.py # Authentication
│ ├── plugins/ # Built-in validators
│ ├── i18n/ # Internationalization
│ └── tutorial/ # Tutorial system
├── examples/ # Example workflows
├── tests/ # Test suite
└── docs/ # Documentation
- Python 3.10+ type hints
- PEP 8 style guide
- Docstrings for public APIs
- Tests for new features
MIT License - see LICENSE for details.
- Inspired by structured development methodologies
- Built for the AI-assisted development era
- Special thanks to all contributors
Happy Workflow Managing! 🚀