Task Workflow

This is a system rule (task-workflow.md) baked into the container image. It defines a five-phase workflow that every agent follows when processing tasks. The workflow is enforced by the rule only -- there is no code pipeline, no phase state in SQLite, and no automated phase transitions. Compliance depends on model instruction-following.

For how system rules fit into the rule cascade, see Rules-Architecture#System Rules. For tool selection guidance within the Act phase, see Tool-Guidelines.

---

Lifecycle Phases

Every task passes through five phases. Do not skip phases. Do not jump to Act before completing Discover and Plan.

Phase 1: DISCOVER

Understand before acting. Gather the context you need to do the job well.

• What exactly is being asked? Restate the task in your own words.
• What is the current state? Use list_teams, get_status, list_triggers, or read relevant files.
• What constraints exist? Check your rules, scope, and available tools.
• Is anything ambiguous? If the task is unclear, ask for clarification (interactive context) or query your parent (delegated context).
• Are there existing skills for this task? If creating a new skill or trigger, search the skill repository (search_skill_repository) for existing patterns. Use matches ≥60% as starting points rather than generating from scratch. See Skill-Repository.

Phase 2: PLAN + EXPECTATION

Define "done" before starting. Set acceptance criteria so you can verify later.

• What steps will you take, in what order?
• What does success look like? Define concrete, checkable acceptance criteria.
• Are there risks or failure modes? Identify them now, not after the fact.
• For structural changes, present the plan and wait for confirmation (see Tool-Guidelines#Structural Change Guidance).

Phase 3: ACT

Execute the plan step by step. Use Tool-Guidelines#Task Routing Decision Framework to decide which tool to use at each step.

• One step at a time. Do not batch untested changes.
• If a step fails, investigate the root cause before retrying.
• If the plan needs to change mid-execution, return to Phase 2 and revise.

Phase 4: VERIFY

Check your work against the acceptance criteria from Phase 2.

• Did you meet every acceptance criterion? Check each one explicitly.
• Are there side effects or regressions? Verify nothing was broken.
• Is the result complete, or are there open items? Surface them now.

Phase 5: DONE

Summarize what was accomplished and close out the task.

• What was done? Brief summary of actions taken.
• What is the result? Deliverables, outcomes, or status changes.
• Are there open items? Anything that needs follow-up, handoff, or monitoring.

---

Context Adaptation

The workflow applies in all contexts, but how you gather information differs.

Context	How You Discover	How You Clarify	How You Report
Interactive (user conversation)	Ask the user directly, read files, check status	Ask the user for clarification	Reply to the user in the conversation
Delegated (task from parent)	Read the task description, check status, read files	Call query_team on parent or escalate if blocked	Result returned via task queue notification to parent
Triggered (cron/webhook/event)	Use the trigger's task template as starting context	No interactive clarification available -- use best judgment or escalate	Result logged; notification routed per task type defaults

Main team task consumption. The main team processes tasks from its own queue like any other team. This includes escalations from child teams and user-initiated tasks. The main agent has no learning or reflection triggers — those run at subagent level within child teams (ADR-40). Stall detection runs as engine-level infrastructure, not through the task pipeline (see Architecture-Decisions#ADR-38). See Conversation-Threading.

---

Extra Diligence for Structural Changes

Some operations are harder to undo and affect other agents or the org tree. Apply extra thoroughness in the Discover and Plan phases for these:

Operation	Extra Diligence
spawn_team	Verify no duplicate exists. Confirm scope does not overlap with existing children. Present plan to user.
shutdown_team	Verify the team has no pending tasks. Check for active triggers. Confirm with user, especially if cascade: true.
create_trigger / update_trigger	Verify trigger name is unique for the team. Use test_trigger before enable_trigger. Present plan to user.
Org-rule changes	Understand the cascade impact -- org-rules affect all descendants. Verify no conflicts with higher-level rules. Present plan to user.

For the full structural change protocol, see Tool-Guidelines#Structural Change Guidance.

---

Design Notes

• System rule only. This workflow is a markdown rule loaded at the highest cascade priority. There is no code that tracks phases, no SQLite state, no enforcement API. See ADR-25 for the rationale.
• No code pipeline. If model compliance proves insufficient, code enforcement can be added later without changing the rule itself.
• Inspired by Ralph Loop. The Discover-Plan-Act-Verify-Done structure draws from Claude Code's Ralph Loop plugin, adapted for a multi-agent delegation context where agents may need to clarify with parents or users rather than always having direct access to the full picture.
• Customizable per team. Teams can refine or extend the workflow via team-rules (e.g., adding a "Review" phase for code-producing teams) as long as the team-rule does not contradict this system rule. See Rules-Architecture#Rule Validation for conflict resolution.