hello-subagent

Subagent orchestration must follow the specifications below. .helloagents/ In this skill, uniformly understand storage paths at the project level: state files use only state_path; session evidence uses the state_path in the directory where the current artifacts/*.jsonis located; if project_store_mode=repo-shared, the plan package,verify.yaml and DESIGN.md are resolved according to the project knowledge/plan directory already injected in the current context.

Before dispatching

First determine whether the task is suitable for a subagent (high independence, clear boundaries, verifiable).

Dispatching specifications

• Each subagent receives: the corresponding task in tasks.md + relevant constraints in the plan package (~plan: requirements.md + plan.md; ~prd: relevant dimension files in prd/ + decisions.md) + verification commands; when UI is involved, additionally attach .helloagents/DESIGN.md(resolved according to the current project storage mode) or relevant fragments thereof
• Fresh context: does not inherit the main session history, avoiding context contamination
• Make clear that this is a partial delegated task: the current output will be returned to the superior agent to continue summarizing, deciding, or restating, rather than being delivered directly to the end user; therefore return only results, evidence, or blockers, do not wrap the HelloAGENTS outer format, and do not write turn-state
• Single responsibility: one subagent does only one thing
• Extract only the context the subagent needs, do not stuff the entire plan package into the subagent

Coordination specifications

• When using subagents, the main agent acts as the controller tracking progress
• The main agent may use the HelloAGENTS outer output format only in the final reply of the current conversation.
• Progress and status reports in team collaboration are all intermediate outputs and must not be wrapped in the HelloAGENTS outer output format.
• Subagents must not call helloagents-turn-state write to write the completed state or waiting state on behalf of the main agent; when runtime state signals are needed, only the main agent writes them
• After a subagent completes, perform a two-stage review:
  1. Requirements compliance review: do the changes comply with the requirements of the plan package and tasks.md? Was anything extra or insufficient done?
  2. Code quality review: run verification commands, review code quality
• Proceed to the next task only after both stages pass
• If a subagent reports BLOCKED: evaluate the blocking reason, retry after providing more context, or escalate to a stronger model, or split the task; do not force a retry in the same way
• When dispatching in parallel, watch out for file conflicts (different subagents must not modify the same file)

Delivery check

• Each subagent has clear task boundaries and acceptance criteria
• Subagent outputs have been reviewed
• All changes have passed verification