OrgX

View saved version →

---
name: orgx-deviation-reporting
description: Record a skill deviation with OrgX so it feeds tomorrow's Daily Brief. Use whenever an OrgX skill fires locally on a file edit, commit, PR, chat turn, or task output.
tools:
  - mcp__orgx__*
---

# OrgX — skill deviation reporting

Every time an OrgX skill catches a deviation during your work, record it
with OrgX so the evidence shows up in tomorrow's Daily Brief and drives
the confidence trajectory for that skill.

## When to record

You should record a deviation when:

- A rule from an OrgX skill triggered on code or content you touched.
- You accepted or rejected a skill's suggestion (pass `outcome: confirmed`
  or `outcome: rejected`).
- A skill surfaced a pattern in output you produced.

Do **not** record the same deviation more than once per 10-minute window —
the server dedupes on `dedupe_key` automatically; duplicate POSTs waste
tokens.

## How to record

Direct HTTP POST through the OpenClaw bridge or via `orgx.post_skill_deviation`
MCP tool:

```
POST /api/v1/skills/{skill_id}/deviations
Authorization: Bearer <OrgX API key>
Content-Type: application/json

{
  "evidence_kind":      "file_edit" | "commit" | "pr" | "chat_turn" | "task_output",
  "evidence_ref":       "<repo>#<pr>" | "<path>:<line>" | "<commit_sha>",
  "summary":            "<one-line description>",
  "application_source": "plugin_codex",
  "confidence":         0.0..1.0,
  "outcome":            "pending" | "confirmed" | "rejected" | "ignored",
  "trigger_context":    { "file_path": "...", "rule_matched": "..." },
  "dedupe_key":         "<sha1(skill_id | evidence_kind | evidence_ref | floor(epoch/600))>",
  "captured_at":        "2026-04-17T10:00:00Z"
}
```

### Computing `dedupe_key`

```ts
import { createHash } from "node:crypto";

const bucket = Math.floor(Date.now() / 1000 / 600);
const material = [skillId, evidenceKind, evidenceRef, String(bucket)].join("|");
const dedupe_key = createHash("sha1").update(material).digest("hex");
```

10-minute bucketing handles save-happy editors without losing legitimate
re-fires beyond that window.

## What happens next

Your deviation lands in `skill_deviations`. The nightly rollup feeds it
into the Daily Brief proof strip's "Deviations caught" tile + updates
the skill's confidence sparkline. Agents whose loadout doesn't include
the skill may get a cross-pollination proposal surfaced.

## Links

- Full contract: https://github.com/hopeatina/orgx/blob/main/orgx/docs/api-contracts/daily-brief-schema.md#04
- SDK reference implementation (Node): https://github.com/useorgx/openclaw-plugin/blob/main/src/deviations-sdk.ts
- Daily Brief surface: https://useorgx.com/today

View saved version →

---
name: orgx-initiative-ops
description: Use when Codex is working on a repo or task that is scoped to an OrgX initiative, workstream, milestone, task, blocker, or decision and needs to use OrgX MCP as the source of truth.
---

# OrgX Initiative Ops

Use this skill when the task is tied to OrgX execution state rather than just local code.

## Workflow

1. Orient before editing:
- Call the OrgX workspace or initiative summary tools first.
- 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` or `_orgx_recommend` with `mode: "morning_brief"` and report
  the returned `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 artifacts when code, docs, plans, screenshots, or reports are produced.

5. Surface decisions explicitly:
- If work is blocked on judgment, request a decision with clear options and impact.
- Do not bury blockers in prose.

6. Close the loop:
- 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.
- Use `source_client=codex` whenever the tool supports client attribution.

View saved version →

---
name: orgx-runtime-reporting
description: Use when a Codex execution should report progress, artifacts, blockers, or completion state back to OrgX during a live task.
---

# OrgX Runtime Reporting

Use this skill when Codex should keep OrgX updated during execution.

## Reporting contract

There are two reporting paths:

- **Active path:** call OrgX MCP tools during the work when you know the
  initiative, task, decision, blocker, or artifact context.
- **Chronicle readout:** for operator reporting, call
  `get_operator_chronicle` first when available and present
  `reportingNarrative.briefMarkdown` before drilling into individual entities.
- **Stale-client fallback:** if bootstrap or docs advertise
  `get_operator_chronicle` but the current AI client session has not refreshed
  its callable tool list, immediately call `orgx_recommend` or
  `_orgx_recommend` with `mode: "morning_brief"` and present the returned
  `reportingNarrative.briefMarkdown`. Do not ask the user to reconnect before
  giving the report.
- **Passive backstop:** Codex runtime hooks installed by `orgx-wizard hooks
  install` record compact session events and run summary-only local Work Graph
  reconciliation on `Stop`.

Do not treat hook presence as a substitute for intentional OrgX writes. Hooks
answer whether OrgX was used and can write a local report automatically; MCP
calls, or an explicitly opted-in successful Work Graph post, make the work
durable in OrgX while the session is still fresh.

## Workflow

1. Resolve available IDs from args, env, or the current OrgX context:
- `ORGX_INITIATIVE_ID`
- `ORGX_WORKSTREAM_ID`
- `ORGX_TASK_ID`
- `ORGX_RUN_ID`
- `ORGX_CORRELATION_ID`

2. For reporting questions, retrieve the operator chronicle:
- Use `get_operator_chronicle` with `period: "30d"` for broad clarity when it
  is callable in the current client.
- Use `period: "day"` or `period: "week"` when the user asks for yesterday or
  this week.
- If `get_operator_chronicle` is not callable in the current client, use the
  existing `orgx_recommend` / `_orgx_recommend` fallback with
  `mode: "morning_brief"` and the broadest supported period. Treat the direct
  tool as preferred, but do not block on client schema refresh.
- Lead with `reportingNarrative.briefMarkdown`, then call out gaps and the
  next action.

3. Emit activity at meaningful milestones:
- `intent`
- `execution`
- `handoff`
- `blocked`
- `completed`

4. Register proof of work:
- When you produce a file, diff, document, screenshot, or report, register it as an artifact with a concrete summary.

5. Handle blockers structurally:
- If judgment is required, request a decision with explicit options.
- If context is missing, report the exact missing dependency.

6. Close execution cleanly:
- When the task is complete and verified, emit completion activity and update entity state if the task ID is available.

7. If no OrgX IDs are available:
- Continue the work, but make the final response easy for the hook reconciler to
  classify: name decisions, artifacts, blockers, next actions, and verification.
- Do not claim OrgX was updated unless an MCP tool or API call actually
  succeeded.

8. Preserve Work Graph continuity:
- When a Work Graph report is generated, include its `work_graph_fingerprint`
  and `signup_hydration.hydration_key` in summaries or artifacts that are safe
  to store.
- Automatic Stop-hook reconciliation writes the latest local report to
  `~/.config/useorgx/wizard/hooks/reports/latest-work-graph-report.json`.
- Stop-hook posting requires `ORGX_HOOK_RECONCILE_POST=true` or
  `ORGX_WIZARD_HOOK_RECONCILE_POST=true` plus `ORGX_API_KEY`.
- Treat the fingerprint as the durable claim key that lets OrgX hydrate
  pre-signup audit value into a user's future workspace.
- Never derive the fingerprint from secrets or raw transcripts that would need
  to leave the local machine.

## Quality bar

- Never post empty status updates.
- Messages must be evidence-based and specific.
- Include OrgX IDs whenever available.
- Use `source_client=codex`.
- Preserve secrets: never emit tokens, cookies, API keys, or storage state into
  activity, retro, hook summaries, or final reports.