| name | orchestrating-work |
| description | Principles for multi-agent workflow execution. Use when coordinating agents, accepting or rejecting agent work, executing producer-critic cycles, or running any multi-phase orchestrated task. |
Orchestrating Work
Execution principles for multi-agent workflows: input validation, work acceptance, file organisation, and phase transitions. Workflow structure (which phases to run) lives in designing-workflow.
1. Validate Inputs Before Invocation
Agents need complete context to work independently โ every missing input costs a clarification round-trip.
Universal requirements for ALL agents (read agents/<agent-name>.md for agent-specific ones):
- Absolute path to
work/<task-id>/ directory
- Absolute output path for the deliverable
- All dynamic skills provided as file paths or inline content, never just names. Preloaded skills (listed in the agent's
skills frontmatter) are injected automatically.
- All agent-specific required inputs present
- All paths absolute (no
./ or ../)
Before invoking: check universal requirements, read the agent's file for specific ones, then wait for the agent to echo its inputs.
If validation fails: STOP, identify and provide the missing inputs, re-validate before re-invoking. If the agent does not echo inputs: STOP โ silence indicates malformed or truncated instructions; verify and re-invoke.
2. Accept or Reject Work Deliberately
Rejecting work during review costs one iteration cycle; accepting substandard work costs post-deployment rollback and rework.
Universal criteria for all artefacts:
Then apply artefact-type standards from the governing skill:
| Artefact type | Reference skill |
|---|
| Skills (SKILL.md) | writing-skills |
| Research outputs | conducting-research |
| Reviews (critic outputs) | assessing-quality |
| Briefs | creating-briefs |
Base the decision on the checklists, not impressions. On rejection: give the agent clear, actionable guidance on the specific issues plus the path to the previous version, re-invoke, and do NOT advance to the next phase until work is accepted.
3. Organise Files Systematically
Consistent naming lets a workflow be reconstructed from its artefacts alone: artefact_v1 โ review_v1 โ artefact_v2 โ review_v2 is the iteration history.
Task ID: {type}-{subject} (e.g. skill-api-documentation, report-q4-summary) โ lowercase letters, numbers, hyphens; under 64 characters; specific enough to distinguish from similar tasks.
Work directory:
work/<task-id>/
โโโ brief.md
โโโ research_brief.md (optional)
โโโ source_index.md (optional)
โโโ sources/ (optional)
โโโ research_v1.md (optional)
โโโ artefact_v1.md
โโโ artefact_v2.md
โโโ review_v1.md
โโโ review_v2.md
โโโ learning_proposals.md
File naming:
| File type | Format |
|---|
| Artefacts | artefact_v{N}.{ext} |
| Artefact reviews | review_v{N}.md (version matches artefact) |
| Research | research_v{N}.md |
| Research reviews | review_research_v{N}.md |
| Briefs | brief.md / research_brief.md |
| Source index | source_index.md |
| Learning proposals | learning_proposals.md |
Versioning: start at v1; sequential integers, no gaps, no decimals; never overwrite โ create a new version instead. Each artefact version gets a matching review version. New version = new review cycle (after critic feedback or a significant requirement change) โ not for typo fixes or internal refinement before first review.
4. Verify Phase Prerequisites Before Transitions
Advancing without completing prerequisites bakes wrong assumptions into downstream work.
Common sequence: Setup โ Research (optional) โ Production (iterate until approved) โ Learning (optional) โ Finalisation.