UltragoalSAFE
Teams-first Multi-agent orchestration for Claude Code
Overview
Teams-first Multi-agent orchestration for Claude Code
23b879c5f631OBSERVED · 2026-09-30Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| claude-code | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
name: ultragoal
description: Durable multi-goal workflow that persists plan/ledger artifacts under .omc/ultragoal and prints Claude /goal handoff text for the active session
argument-hint: "<brief or subcommand>"
level: 3
---
<Purpose>
Ultragoal breaks a brief into an ordered set of goals, records start/checkpoint/blocker/failure events in a durable append-only ledger, and tells the active Claude agent how to drive the Claude Code `/goal` slash command alongside the plan. It does not — and cannot — mutate Claude `/goal` state from the shell; it persists durable repo state and prints a model-facing handoff that the active agent must act on in-session.
</Purpose>
<Use_When>
- The user wants a durable, repo-native way to track an ultragoal across multiple Claude sessions or worktrees
- The work is large enough to warrant multiple ordered "stories" with attempt counts and per-story evidence
- The user wants the final completion gated behind ai-slop-cleaner + verification + $code-review
- The user wants the active Claude `/goal` directive coordinated with the ledger so that a session restart does not lose progress
</Use_When>
<Do_Not_Use_When>
- The task is a single small change — use direct delegation or `ralph` instead
- The user wants the assistant to literally invoke `/goal` itself from the shell — that is not possible; `omc ultragoal` only writes artifacts and prints handoff text
- The user wants a planning-only artifact with no execution loop — use `plan` instead
</Do_Not_Use_When>
<Why_This_Exists>
Claude Code `/goal` is a session-scoped Stop hook: it blocks the session from stopping until a condition holds, and auto-clears on success. That is a great single-session execution primitive, but it loses state across sessions and does not by itself enforce a final review gate. `omc ultragoal` adds a durable plan, ledger, and gating layer so a long multi-step initiative can survive session restarts, fresh worktrees, and review iterations while still leveraging Claude `/goal` to keep the active agent focused.
</Why_This_Exists>
<How_To_Use>
1. Create a plan from a brief:
```
omc ultragoal create-goals --brief-file plan.md
```
Or with explicit stories:
```
omc ultragoal create-goals --brief "ship the migration" \
--goal "Schema::Add new columns" \
--goal "Backfill::Backfill rows in batches" \
--goal "Cutover::Drop old columns and switch reads"
```
The default mode is `aggregate` (one Claude `/goal` covers the run).
Pass `--claude-goal-mode per-story` if you want each story to have its own `/goal`.
**Multi-repo workspaces / parallel sessions:** when several Claude sessions
in the same workspace need to run `/ultragoal` concurrently, pass either
`--plan-id <stable-id>` or `--auto-plan-id` so the plan is written to
`.omc/ultragoal/plans/{planId}/` instead of the shared single-plan path.
Without that flag, two sessions creating goals would clobber each other.
`--auto-plan-id` derives `{epochMs}-{slug}` from the brief title. Then thread
the same `--plan-id <id>` through every subsequent subcommand in that session.
Use `omc ultragoal list-plans` to enumerate available planIds when needed.
2. Start (or resume) the next story:
```
omc ultragoal complete-goals [<goal-id>]
```
With no goal id, this preserves the default behavior of resuming the active story or starting the first pending story. With a goal id, OMC targets exactly that named eligible story (a pending story may be started out of order); it never falls through to another story. An active different story, unknown id, completed or review-blocked story, or failed story without `--retry-failed` is rejected without state mutation. An in-progress named story is resumed without changing its attempt. This prints a model-facing handoff. The active Claude agent must read it and:
- Set the native Claude `/goal` for this session — in standalone Claude Code neither the
shell nor the agent can do it, so ask the user to type `/goal <aggregate objective>` and
wait. `--claude-goal-json` (below) reconciles the ledger only and does not satisfy the
PreToolUse `/goal` guard, which blocks tool calls until it observes an active `/goal`.
- Work the story.
- When the story is complete (and for the final story, after the full quality gate), share back a snapshot of the active `/goal` state and call `checkpoint`.
3. Checkpoint a story:
```
omc ultragoal checkpoint --goal-id G001-... --status complete \
--evidence "tests/files/PR evidence" \
--claude-goal-json '{"goal":{"objective":"...","status":"active"}}'
```
For the final story, also pass `--quality-gate-json` containing
`aiSlopCleaner`, `verification`, and `codeReview` evidence (all clean).
4. If the final review is not clean, do NOT mark complete. Record blockers:
```
omc ultragoal record-review-blockers --goal-id G00X-... \
--title "Resolve final code-review blockers" \
--objective "Fix the listed review findings and rerun final gates" \
--evidence "<the review findings>" \
--claude-goal-json '{"goal":{"objective":"...","status":"active"}}'
```
This appends a new blocker story and keeps the Claude `/goal` active.
5. Inspect state at any time:
```
omc ultragoal status
```
</How_To_Use>
<Important_Limitations>
- The shell cannot invoke or mutate Claude Code `/goal` state. `omc ultragoal` only persists durable artifacts and prints instructions that the active Claude agent reads and acts on in-session.
- Snapshots passed via `--claude-goal-json` are model-supplied proof of the active `/goal` state; OMC validates them for textual consistency with the plan's expected objective and ledger event, but it cannot independently observe Claude `/goal` state. They do not satisfy the PreToolUse `/goal` guard, which requires an actual active `/goal` — a host-injected snapshot or the native `/goal` the user set in-session.
- If the Claude `/goal`Trust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
23b879c5f631full audit observations/trust-audit/skill/yeachan-heo__ultragoal.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-09-30 | 23b879c5f631 | SAFE | B | 89 | first audit |
Questions
What does the Ultragoal skill do?
Teams-first Multi-agent orchestration for Claude Code
Is Ultragoal safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Ultragoal access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does Ultragoal work with?
Its documentation mentions claude-code. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (23b879c5f631), read on 2026-09-30. The repository is watched, and a new audit runs when it changes — this is the first audit.