| name | dev-workflow |
| description | Master orchestrator for the AI-driven development workflow. Use when starting a new User Story / Issue implementation. Coordinates the Planner, Developer, Reviewer, and Tester agents through all 7 phases with human approval gates. Supports multiple work item providers (ADO, Jira, GitLab, GitHub, Zoho, local-markdown) and git providers (ADO, GitLab, GitHub, gh-cli, glab-cli) via provider adapters. Supports multi-repo stories with parallel developer agents across repos while maintaining sequential execution within each repo.
|
| allowed-tools | Read, Write, Edit, Bash, Grep, Glob, Agent, mcp__azure-devops__*, mcp__jira__*, mcp__gitlab__*, mcp__github__*, mcp__zoho__* |
| argument-hint | [command] <Work-Item-ID> [project-name] [team-name] |
AI-Driven Development Workflow
Provider Resolution
Before executing any command, read .claude/context/provider-config.md to determine
the active work item and git providers. All MCP tool calls throughout the workflow are
resolved through the provider adapters in skills/providers/<provider>/.
Usage
/dev-workflow <Work-Item-ID> [project-name] [team-name] # Full pipeline
/dev-workflow <command> <Work-Item-ID> [project-name] [team-name] # Specific phase
Examples:
/dev-workflow 123456 MyProject backend (ADO)/dev-workflow PROJ-123 PROJ backend (Jira)/dev-workflow 42 mygroup/myproject backend (GitLab)/dev-workflow plan 123456 (specific phase)
Argument Parsing
Parse $ARGUMENTS:
- First token: If it looks like a work item ID (numeric, or matches Jira key pattern
like
PROJ-123), treat as Story/Issue ID and run the full pipeline.
If it matches a command name, use that command (direct phase mode).
- Story/Issue ID (required): The Work Item ID (format depends on provider).
- Project name (optional): Defaults from
provider-config.md.
- Team name (optional): Defaults from
provider-config.md if configured, otherwise must be provided.
Pass all three values to downstream commands and agents.
Commands
| Command | File | Phase | Description |
|---|
preflight | commands/preflight.md | Pre | Branch creation and setup |
requirements | commands/requirements.md | 1 | Requirements Ingestion |
plan | commands/plan.md | 2 | Planning & Approval |
develop | commands/develop.md | 3 | Development Loop |
approve-impl | commands/approve-impl.md | 4 | Human Approval of Implementation |
test | commands/test.md | 5 | Test Implementation |
create-pr | commands/create-pr.md | 6 | PR Creation |
review-response | commands/review-response.md | 7 | PR Review Response |
If the first token doesn't match a command name and isn't numeric, show this usage table and stop.
Orchestrator Rules
Before executing any command, read context/orchestrator-rules.md. These rules apply to
ALL phases and cannot be overridden by individual commands.
Full Pipeline Mode
When no command is specified (first argument is the Story ID), execute all commands in sequence:
preflight → 2. requirements → 3. plan → 4. develop → 5. approve-impl → 6. test → 7. create-pr
After create-pr completes, review-response is not run automatically — it is triggered
on demand (via direct phase mode) once PR review comments arrive from human reviewers.
Read each command file as you reach that phase. Do not pre-load all command files — load
one at a time to conserve context.
After each command completes, proceed to the next automatically (unless a human gate blocks).
Direct Phase Mode
When a command is specified, read its command file and execute it. Each command file states
its own prerequisites — verify them before proceeding.
This mode is useful for:
- Resuming a workflow after a session interruption
- Re-running a specific phase (e.g., re-running tests after manual fixes)
- Debugging a single phase in isolation
