---
name: orgx-initiative-ops
description: Use OrgX context and explicit workflow tools to plan, organize, and execute authorized initiative work while preserving human review gates.
---

Use this skill when the user asks to create, plan, inspect, or operate OrgX initiative work. Act within the user's requested scope and inspect current workspace context before writing.

When run as onboarding, start with a read of the connected workspace and show one useful next step grounded in current work. Introduce OrgX as shared team context, quality criteria, evidence, and human review across connected AI clients. Suggest the exact first prompt: ‘OrgX, show my workspace and one useful next step.’ Keep setup read-only; do not create work, launch agents, or request broader permissions. If connection is missing, direct the person to the existing OrgX connection flow.

1. Read `orgx_get_workspace_context`. Use `orgx_search` and `orgx_inspect` to find existing work and avoid duplicates. Read `orgx_get_operator_brief`, `orgx_get_next_actions`, or `orgx_get_initiative_progress` when their current context is useful. An explicit workspace argument is a resource request, not permission to switch session context.
2. For a durable planning draft, use `orgx_start_plan`, `orgx_read_plan`, and `orgx_save_plan`. Saving requires the latest positive `expected_version`; reread on conflict. Start supports optional keyed replay only for an identical active revision-one plan; changed content or replay after editing conflicts. Unkeyed starts can create duplicates, and saves do not replay a stale version. Report a failed edit-history record even when the plan text was saved. `orgx_complete_plan` closes the planning session; it does not launch or complete initiative work.
3. Use `orgx_validate_initiative_plan` before `orgx_create_initiative_hierarchy`. The current atomic hierarchy accepts its published typed plan, including supported assignment, estimates, deliverables, and sibling-scoped dependency references. It rejects unsupported objectives, acceptance/proof fields, and cross-milestone dependencies. Preserve these requirements in the planning draft and report the unsupported fields; never silently discard them to make creation succeed. Creation is private by default, and unverified source evidence keeps the result in draft.
4. For supported individual records use `orgx_create_initiative`, `orgx_create_workstream`, `orgx_create_milestone`, or `orgx_create_task`. Use `orgx_update_work` for its declared content fields. A content edit cannot approve work, select an execution policy, or change lifecycle state.
5. Before dispatch use `orgx_check_execution_readiness` and, when useful, `orgx_estimate_agent_task`. Dispatch through `orgx_start_agent_task`, `orgx_handoff_task`, or `orgx_launch_initiative` only when authorized for that operation and its costs. Creation and launch are separate operations. Use `orgx_pause_work`, `orgx_resume_work`, `orgx_retry_work`, or `orgx_cancel_work` for their named transitions.
6. Poll `orgx_get_operation_status` using the returned operation reference, and use `orgx_get_agent_status` for current agent state. Accepted, queued, or running work is not completed work. Preserve structured blockers, partial effects, and retry guidance in the update to the user.
7. Capture unresolved choices with `orgx_capture_decision`, read `orgx_list_pending_decisions`, and use `orgx_open_decision_review` to open the person's review surface. A review opener does not approve or reject a decision. Human clicks and authenticated human review remain the source of human authority.
8. Attach supported evidence with `orgx_attach_artifact`; in-review registration can trigger evaluation through external model providers and incur costs. Open `orgx_open_artifact_review` or request `orgx_request_independent_artifact_review` as appropriate. `orgx_complete_work_with_proof` currently supports task completion through OrgX's proof gates; parent-work completion remains unsupported on that core path. Report retained proof and blocked or failed completion separately. A producer's assertion of verification cannot replace an independent check or human acceptance.

For a portable account of the work, use the runtime reporting skill. Receipt import records evidence and claims; it does not complete initiative work or settle decisions. Never infer a successful mutation from a rendered widget or an HTTP success code without the operation's authoritative status.