orgx-initiative-ops

# OrgX Initiative Ops Use this skill when the task is tied to OrgX execution state rather than just local code. The bundled MCP connection requests the explicit `commander` runtime profile. Use only tools actually exposed in that connection. A missing tool may need connection refresh or a coordinated plugin/server update. Report that tracking limitation and continue independent authorized repo work; never invent an alias or weaken an autonomous run's signed schema policy. ## Workflow 1. Orient when OrgX state is relevant: - Read the relevant workspace or initiative summary before changing OrgX state or relying on its status. Reuse context already read in this session when it is sufficient; local edits do not require a new OrgX read. - For broad status/reporting questions, prefer `get_operator_chronicle` first when available; it is the canonical decision, artifact, PR, goal, gap, and priority readout. - If the hosted OrgX MCP bootstrap advertises `get_operator_chronicle` but the active AI client session has a stale callable tool list, immediately use `orgx_recommend` only when that name is actually callable, with `mode: "morning_brief"`, and report the returned `chronicle.reportingNarrative.briefMarkdown`. Do not wait for the client to reconnect before answering the operator. - If an initiative, workstream, task, blocker, or decision is named, treat OrgX as the source of truth for current status. 2. Reuse existing context before creating new structure: - Query OrgX memory or list the relevant entities first. - Only scaffold new work when no matching initiative structure already exists. 3. Work against the current slice: - Prefer updating the current task or workstream instead of creating parallel duplicate work. - Keep your local implementation aligned with the active OrgX entity state. 4. Report concrete progress: - Use OrgX progress/activity tools for real execution milestones. - Register useful artifacts within the authorized tracking scope. Batch related evidence at a meaningful milestone instead of writing on every file edit. - Missing IDs or unavailable reporting tools do not block implementation, verification, PR updates, or an otherwise authorized merge. Report pending tracking separately from the actual work outcome. 5. Surface decisions explicitly: - Request a decision only when an unresolved choice needs human authority. Resolve routine implementation choices within the user's scope, and honor approval already given instead of requesting it again. - Do not bury blockers in prose. - Only a person settles a decision. `orgx_decide` with `action: "approve"` or `"reject"` never approves or rejects anything: it returns the decision's `review_url` in OrgX. Give the person that link and report only the dependent work as waiting on them. Continue independent work, and never say a decision was approved or rejected unless OrgX shows it settled. 6. Close the loop: - Launching or spawning work starts it; it does not finish it. Report it as started, keep the returned run ID, and check it with `orgx_command_status` (`kind: "run"`, or `kind: "decision"` for a decision) before claiming any outcome. When `next_poll_after_ms` is a number, check again after that many milliseconds; `null` means the state is final. Use `orgx_inspect` for anything without a run, decision or command ID. - When a task is truly done, verify it first. - Then update completion state in OrgX if the current task is known. ## Quality bar - Never assume OrgX entity state from memory alone. - Never mark work complete without verification. - Prefer one verified task completion over broad unverified status claims. - If a write's outcome is unclear, reconcile the returned command or run first. Retry only if that operation documents replay support, with identical input and the same idempotency key; never send it through another tool name. - Use `source_client=codex` whenever the tool supports client attribution.