-
Preserve upstream intent.
-
Determine local leadership scope.
-
Map deliverables to owners.
-
Decompose into work items.
-
Distinguish hard dependencies from can-start-now prework.
-
Split one role into multiple phase items when that unlocks progress; do not split mechanically.
-
Add dependencies / non-overlap boundaries.
-
Fill planning_context.
-
Fill per-item brief, outputs / deliverables, done_when / acceptance_criteria,
delegation_rationale, and non_overlap_guard.
-
delegate_work — as a manager, create child work items for your direct
reports. Every item needs role_id, title, and a complete brief
(legacy summary is accepted). scope_key is optional; the runtime can
generate one. depends_on can name a sibling role, scope key, work item
ref, or work item id. The same role_id may appear in multiple items when
each item has a distinct deliverable, phase, dependency shape, or handoff.
{
"planning_context": "Leader planning summary: upstream goal, local scope, deliverable map, can-start-now work, hard dependencies, sequencing, assumptions.",
"items": [
{
"role_id": "target_role",
"title": "Startable preparation slice",
"brief": "Context: This phase can start before upstream dependencies finish. Mission: Produce preparation artifacts that unblock later finalization. Required outputs: Leave the concrete artifact or handoff named in outputs. Location / handoff: Use the agreed output path or report channel. Quality expectations: Meet the done_when criteria below. Boundaries: Stay inside this phase. Insufficient work: Do not submit only vague notes. Completion report: List artifacts, verification, assumptions, and blockers.",
"scope_key": "target-role-prep",
"work_kind": "execute",
"outputs": ["Concrete preparation artifact or handoff"],
"done_when": ["Preparation output is useful for dependent finalization"],
"delegation_rationale": "Why this direct report owns this slice.",
"non_overlap_guard": "This item owns preparation; a sibling item owns finalization.",
"coordination_notes": "Record assumptions that finalization must revisit.",
"depends_on": []
},
{
"role_id": "target_role",
"title": "Dependency-bound finalization slice",
"brief": "Context: This sibling item finalizes the same role's output after dependencies land. Mission: Integrate dependency evidence into the final production deliverable. Required outputs: Leave the final artifact named in outputs. Location / handoff: Use the agreed output path or report channel. Quality expectations: Verify against prep and dependency inputs. Boundaries: Do not redo prep unless quality requires it. Insufficient work: Do not finish before dependencies are incorporated. Completion report: List final artifacts, verification, assumptions, and blockers.",
"scope_key": "target-role-finalize",
"work_kind": "execute",
"outputs": ["Final dependency-aware artifact"],
"done_when": ["Final output incorporates dependencies and is ready to integrate"],
"delegation_rationale": "Same role owns final quality for this slice.",
"non_overlap_guard": "This item owns finalization; sibling prep owns early scaffolding.",
"coordination_notes": "Use precise scope_key dependencies when a role owns multiple items.",
"depends_on": ["target-role-prep"]
}
]
}
opc-collab delegate_work --args-json-file args.json
brief is the child work item's full assignment packet, not a short
summary. Do not use description. Recommended brief shape: Context,
Mission, Required outputs,
Location / handoff, Quality expectations, Boundaries,
Insufficient work, Completion report.
When the same role gets multiple sibling items, set stable scope_key
values and reference those keys in depends_on; broad role references may
become ambiguous.
-
manager_board_read — READ-ONLY view of your direct reports' child
items. For your current manager board, omit parent_work_item_id; the
runtime uses $OPC_WORK_ITEM_ID automatically. Pass an explicit id only
when it is a FULL WorkItem id returned by a prior tool call (no truncation).
Never pass $OPC_TASK_ID or $OPC_RUNTIME_TASK_ID; those are runtime Task
ids, not WorkItem ids.
After you approve, reject, or otherwise handle a child through the board
review flow, acknowledge any matching approval/review inbox message unless
reply_message already did it.
{
"include_children": true
}
opc-collab manager_board_read --args-json-file args.json
Do NOT use legacy aliases like parent_id, include_outputs, scope,
reason, note — the tool rejects them.
-
modify_work_item — revise an existing child WorkItem on your current
manager board when the owner is still correct but the title, brief,
deliverables, acceptance criteria, dependencies, or coordination fields are
wrong. Read the board first, then pass the exact full work_item_id.
Prefer this over creating a duplicate replacement item.
{
"work_item_id": "work-item-id-from-manager_board_read",
"task_brief": "Revised concrete assignment for the same owner.",
"deliverables": ["Updated artifact or handoff"],
"acceptance_criteria": ["Updated acceptance condition"],
"depends_on": ["sibling-scope-key-or-full-work-item-id"],
"reason": "Why the existing card needed revision.",
"reset_to_ready": true
}
opc-collab modify_work_item --args-json-file args.json
-
delete_work_item — cancel or hide an obsolete/wrong child WorkItem on
your current manager board so it no longer blocks parent synthesis. Read the
board first, then pass the exact full work_item_id.
{
"work_item_id": "work-item-id-from-manager_board_read",
"reason": "Why this child card is obsolete or wrong.",
"replacement_dependency_work_item_ids": []
}
opc-collab delete_work_item --args-json-file args.json
-
close_human_review — close the owner-facing delivery review when you
decide the user's latest directive means the delivery is accepted and no
further internal work is needed. Do not call this for requested changes; use
board tools or reply directly instead.
{
"summary": "The user accepted the delivery; no further work is required.",
"user_message": "Acknowledged. I am closing the human review for this delivery."
}
opc-collab close_human_review --args-json-file args.json