Work Item Delivery Loop

Run work execution with strict sequencing and explicit write-back.

Operating Rules

• Always fetch before editing: list -> details -> implement -> write-back.
• Never mark work complete without validation evidence.
• If initiative matching is ambiguous, ask for confirmation.
• A run is incomplete until MCP write-back is done.
• Never modify task descriptions to record progress. Use add-task-comment instead.
• When editing an initiative description, use patch-document with workspaceId, taskId set to the initiative ID, and precise ops; the server resolves or creates the linked content document automatically.
• Prefer replace_text, insert_before, insert_after, and delete_text over rewriting the entire description.
• Use update-initiative only for initiative metadata: title, status, assigneeIds, teamIds, taxonomyLabelIds, and parentInitiativeId.
• If both initiative description and metadata change, do patch-document(taskId=initiativeId, ...) first, then update-initiative(...). If refreshed full details are needed after editing, call get-task-details.
• If a patch fails because the target or anchor is stale or missing, call get-task-details, then retry with corrected ops.
• Always pass "source": "skill" when calling add-task-comment so comments are tagged with their origin.
• Use Changes/Why comments only when real delivery happened (bug fix, completed personal task, completed initiative work).
• For research/planning/triage-only updates, add an Update comment instead.