Conductor Workflow Create

Ensure .conductor/ exists: Check whether the required subdirectories are present:

ls <target_dir>/.conductor/agents/ <target_dir>/.conductor/workflows/ 2>/dev/null || echo "MISSING"

If either directory is missing, invoke /conductor-workflow-init <target_dir> (silently, no confirmation prompt needed) to create the full directory structure before continuing.

1. Read the canonical DSL reference

Read docs/workflow/engine.md for the full grammar, all constructs, and design rationale. This is the authoritative source — use it throughout this session.

1. Gather intent

Ask the user:

• What should this workflow do? (plain-English description)
• What does it operate on? (worktree for branch-level work, repo for repo-level work, or both)
• What should the workflow be named? (suggest a hyphenated slug from their description if they don't provide one)
• Are there any required inputs the workflow needs from the user at run time? (e.g., ticket_id, pr_url)

If the user already provided this information as arguments to the skill, skip to step 2.

2. Introspect existing repo state

Run these commands to understand what's available:

ls <target_dir>/.conductor/agents/

ls <target_dir>/.conductor/workflows/

ls <target_dir>/.conductor/prompts/ 2>/dev/null || echo "(no prompts directory)"

Note the exact filenames (without .md/.wf extension) — these are the identifiers you can use in call statements. Do not suggest call targets that don't exist without noting they need to be created.

3. Draft the workflow structure

Design the .wf file using the correct DSL constructs. Key rules:

Structure:

workflow <name> {
  meta {
    description = "..."
    trigger     = "manual"
    targets     = ["worktree"]   # or ["repo"] or ["worktree", "repo"]
  }

  inputs {
    my_input required
    optional_input default = "value"
  }

  # steps go here
}

Choosing constructs:

• Sequential agent call: call <agent-name>
• Conditional: if <step>.<marker> { ... } or unless <step>.<marker> { ... }
• Loop (check before first run): while <step>.<marker> { max_iterations = N ... }
• Loop (always run at least once): do { ... } while <step>.<marker>
• Parallel agents: parallel { call a; call b; call c }
• Human gate: gate human_review { prompt = "..." timeout = "48h" on_timeout = fail }
• Automated gate: gate pr_checks { timeout = "2h" on_timeout = fail }
• Always run (cleanup/notify): always { call notify-result }
• Compose another workflow: call workflow <name>

Loop options (required/optional):

• max_iterations = N — required on while and do {} while
• stuck_after = N — optional, must be < max_iterations
• on_max_iter = fail — optional, defaults to fail

Context threading:

• {{prior_context}} — context string from the immediately preceding step
• {{prior_contexts}} — JSON array of all prior step contexts
• {{gate_feedback}} — feedback text from a human_review gate

Prompt snippets (reusable .md files from .conductor/prompts/):

call review { with = ["review-diff-scope"] }
parallel { with = ["review-diff-scope"]; call review-security }

Workflow composition:

call workflow lint-fix
call workflow test-coverage { inputs { pr_url = "{{pr_url}}" } }

Avoid creating a cycle — check existing .wf files to ensure the workflow you're creating doesn't reference a workflow that would transitively reference it back.

4. Identify missing agents

Compare the call statements in your draft against the existing agents listed in step 2. For any agent that doesn't exist yet, note that you will need to create a stub .md file at .conductor/agents/<name>.md.

Stub format:

---