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.