workflow-conductor

name	workflow-conductor
description	Lightweight conductor for the ADL workflow skills. Use when the operator wants one bounded entrypoint that detects the current issue/workflow state, selects the correct next lifecycle or editor skill, enforces skill/subagent policy, and either stops after routing or dispatches one bounded downstream skill subtask without reimplementing the underlying work.

Workflow Conductor

This skill is a thin orchestrator over the existing ADL operational skills.

Its job is to:

• inspect current workflow state
• choose the next appropriate lifecycle or editor skill
• ensure card-local work is routed to the matching editor skill
• apply explicit skill/subagent execution policy
• record workflow-compliance outcomes
• preserve bound issue worktree identity as first-class routing evidence
• emit a bounded routing artifact
• when explicitly enabled, dispatch one bounded downstream skill subtask and stop at that boundary

This skill must remain lightweight.

It must not replace:

• pr-init
• pr-ready
• pr-run
• pr-finish
• pr-janitor
• pr-closeout
• planning-doc-editor
• stp-editor
• sip-editor
• spp-editor
• srp-editor
• sor-editor

It must stop at the routing/dispatch boundary rather than reimplementing the selected skill's underlying work.

The bundle may include small deterministic helpers for routing evaluation and test fixtures, but those helpers exist to support the stop-boundary contract, not to silently turn the conductor into a second execution engine.

Design Basis

This skill should track the repository's canonical operational skill family and the workflow-policy notes that motivated it.

At the moment, the key repo references are:

• adl/tools/skills/docs/OPERATIONAL_SKILLS_GUIDE.md
• .adl/docs/TBD/ADL_EXECUTION_POLICY_FOR_SKILLS_AND_SUBAGENTS.md
• .adl/docs/TBD/LIGHTWEIGHT_WORKFLOW_CONDUCTOR_SKILL.md

Within this bundle, the operational details live in:

• references/conductor-playbook.md
• references/output-contract.md

If those docs move, prefer the moved tracked canonical copies over stale path references.

Entry Conditions

Use this skill when all of the following are true:

• there is one concrete issue/workflow target
• the operator wants help choosing the next ADL skill
• the operator wants policy-aware routing rather than manual phase selection

Do not use this skill for:

• directly doing the implementation work
• bypassing editor skills
• repo-wide orchestration across many unrelated issues
• silently finishing or closing an issue

Required Inputs

At minimum, gather:

• repo_root
• one concrete target:
  • issue_number
  • task_bundle_path
  • branch
  • worktree_path
  • pr_number
• one explicit routing mode
• one explicit policy block

Useful additional inputs:

• slug
• version
• doctor_result
• source_prompt_path
• stp_path
• sip_path
• sor_path
• spp_path
• srp_path
• current pr_state
• requested stop_boundary

If there is no concrete target, stop and report blocked.

Quick Start

1. Resolve the concrete issue/workflow target.
2. Inspect the current workflow state using the strongest available evidence:
   • doctor JSON
   • task bundle paths
   • branch/worktree state
   • PR state
   • observed subagent assignment state
3. Determine whether the next step is:
   • lifecycle routing
   • card-editor routing
   • planning-doc-editor routing
   • blocked/no-op reporting
4. Apply the declared skill/subagent policy.
5. Select the next skill.
6. If the selected route binds or resumes tracked issue execution, record the issue-bound session-goal requirement in the routing result or handoff note: create the goal after bind/readiness succeeds and before implementation starts; treat complete or blocked as truthful session-terminal states only.
7. Record the workflow-compliance result and write the routing artifact.
8. When explicit dispatch mode is enabled, dispatch one bounded downstream skill subtask.
9. Stop without absorbing the selected skill's logic.

Observability Expectations

When conductor routing depends on doctor/readiness/PR state:

• prefer structured workflow evidence first, but expect current repo-native commands to emit adl_event lines before or alongside the observed machine output on some paths
• do not treat those observability lines as corruption when the command still returns the authoritative structured payload
• for repo-native pr.sh / adl pr JSON readiness surfaces proven by #3789, treat stdout as the authoritative parse-safe JSON channel while adl_event lines may still appear on stderr or an explicit compatibility log
• outside those proven JSON surfaces, do not assume stdout/stderr separation or machine-readable cleanliness unless the relevant issue or proof packet explicitly established it
• when a routing result depends on wait state, queue blocking, or PR inference, preserve the relevant log-policy caveat in the output or handoff notes

Repo-Native Tracker And PR Inference

The conductor helper must not call the GitHub CLI directly for tracker or PR state inference. Its supported repo-native read surfaces are:

• issue/tracker discovery through bash adl/tools/pr.sh issue list --state all --limit 200 --json
• PR state discovery through adl pr validation <pr-number> --json

Those commands may emit human adl_event observability alongside structured payloads. The helper must parse the first JSON object or array from mixed output, record the repo-native surface in workflow_state.evidence_used, and fail closed when those surfaces are missing or malformed. Raw gh is not a supported fallback for this skill.

Routing Model

Preferred next-skill mapping:

• bootstrap missing -> pr-init
• card-local STP issue -> stp-editor
• card-local SIP issue -> sip-editor
• card-local SPP issue -> spp-editor
• card-local SRP issue -> srp-editor
• card-local SOR issue -> sor-editor
• planning-doc-local issue -> planning-doc-editor
• structurally ready but not bound -> pr-ready
• ready for execution bind -> pr-run
• execution complete, needs publication -> pr-finish
• PR in flight with checks/conflicts/review blockers -> pr-janitor
• PR merged or intentionally closed -> pr-closeout

Prompt-template tooling route:

• new or fully re-rendered prompt card -> active prompt-template values renderer, then validate-structure
• changed prompt-template schema artifact -> validate-schemas, then python3 adl/tools/test_prompt_template_structure_schemas.py
• lifecycle-truth drift in an existing card -> matching card editor skill

Important rule:

• treat partially completed early steps as normal state, not corruption
• the conductor should resume from the next truthful step instead of restarting bootstrap by reflex
• when doctor or worktree evidence reports a bound issue worktree, carry that path into the selected target and downstream handoff instead of treating the primary checkout as the execution surface
• classify unsafe primary-checkout execution, publication from the wrong checkout, and required rebind-to-worktree cases as explicit blockers rather than improvising a root-checkout workflow
• healthy open PRs should normally hand off to human review/waiting state rather than janitor unless there is an actual blocker
• explicit covered by #<n> / satisfied by #<n> style references should block fresh execution when the referenced issue is already closed
• repo-policy residue such as tracked legacy .adl issue records should escalate as a mechanical blocker rather than being mistaken for issue-local implementation work
• linkage-only PR failures should route as a bounded janitor case rather than a generic merge-blocked state
• design-time card-completion blockers from pr doctor should route to the matching card editor before execution or publication continues; generic SIP, incomplete STP, generic/truncated SPP, and legacy/incomplete SRP surfaces are not safe to treat as ready merely because the files exist
• card-status blockers from pr doctor should route to the matching card editor: SIP, STP, and SPP must be ready or approved before execution binding; SRP completion requires review truth; SOR completion requires terminal closeout truth
• planning-document defects such as placeholder residue, missing required planning sections, stale planning status claims, or generated-vs-reviewed truth drift should route to planning-doc-editor; do not send those defects to C-SDLC card editors unless the defect is actually in SIP/STP/SPP/SRP/SOR
• when values-rendered prompt-card support exists for the target, do not route broad card generation to direct Markdown edits; use the renderer/schema path first, then card-editor skills only for issue-local lifecycle truth
• when routing to pr-run or resuming bound execution, include the issue-bound session-goal requirement in the handoff: create the goal after bind/readiness succeeds and before implementation starts
• when routing to pr-run for Rust-heavy validation in a fresh or cold worktree, include the dependency-cache warmup reminder in the handoff: python3 adl/tools/warm_rust_dependency_cache.py --source-target <warm-target> --dest-target <issue-worktree>/adl/target --manifest-path <issue-worktree>/adl/Cargo.toml. The reminder is an acceleration step, not validation proof, and should be skipped when no trusted same-host, same-filesystem, same-checkout-family, and same-toolchain warm target is available.

Policy Model

This skill should enforce policy when supplied, including:

• skills_required
• card_editor_skills_required
• subagent_requirement
• bypass_without_explicit_blocker
• required_skill_by_phase
• required_card_skill_by_type
• observed subagent assignment state

If policy and repo reality conflict:

• prefer truthful blocked output over hidden fallback

Stop Boundary

This skill must stop after:

• selecting the next skill
• recording compliance and routing facts
• writing the bounded routing artifact
• optionally dispatching one bounded downstream skill subtask
• surfacing any blocker that prevents safe routing

It must not:

• perform the selected skill's implementation work itself
• silently invoke unrelated repo-wide cleanup
• create an unrecorded fallback path

Dispatch Boundary

When explicit dispatch mode is enabled, the conductor may:

• call one supported downstream lifecycle skill through the repo-native command it already wraps
• call one editor or special-case skill through an explicit operator-provided command override
• record the selected skill, command source, command shape, and bounded result

It must not:

• inline the downstream skill's behavior into the conductor
• chain multiple downstream skills in one silent rollout
• continue past the first dispatched subtask as if it owned the downstream lifecycle

Output

Return a concise structured result including:

• selected phase
• selected skill
• selected card-editor skill if any
• policy/compliance result
• whether subagent assignment is required
• whether the target should continue, stop, or ask for operator confirmation
• bounded blocker classification for known doctor/PR failure families
• bounded tracker/umbrella satisfaction detection when a child issue wave already appears to cover the acceptance surface
• explicit escalation reason when the conductor should not continue silently
• the artifact path or equivalent routing-proof surface when one is written