Judging Claw

GitHub/Forgejo + Ollama Cloud + OpenClaw = prioritizing your issues while you sleep.

Judging Claw is a small repository-ledger companion for OpenClaw judge agents. For GitHub-facing packaging, the same shape can be described as an OpenClaw + Ollama judge for repository work. Working nickname: Llama Cloud Judger.

The canonical development home is the Forgejo repository used for dogfooding. The GitHub repository is a private packaging mirror for now, intended to become public once the project has been dogfooded a bit more and the private deployment details are separated cleanly from the reusable tool.

Its job is not to merge code, write implementation plans, or replace Hermes Agency. Its job is to help a configured OpenClaw agent judge and prioritize open work while the operator is not looking: issues, pull requests, stale work-in-progress, and possible handoff candidates. It works with self-hosted Forgejo and private GitHub repositories.

The core product loop:

1. Read open GitHub or Forgejo issues and pull requests.
2. Find targets without a current judgment, or targets whose context changed enough to require a fresh judgment.
3. Ask the configured OpenClaw judge agent to judge priority using the deployment's fit/context contract.
4. Write the result back to the repository ledger as a structured comment.
5. Apply clear labels when the contract allows it.
6. Stay quiet when nothing material changed.

GitHub or Forgejo is the ledger. The OpenClaw agent is the judge. Judging Claw is the toolbelt.

Hard assumptions for this project:

• OpenClaw is the agent runtime.
• Ollama or Ollama Cloud is the model/receipt rail.
• Forgejo or GitHub is the repository ledger.
• OpenRouter and broad model-provider abstraction are intentionally out of scope.

Codex Skill

The canonical Codex skill for ad hoc judge feedback lives in skills/openclaw-judge-feedback/.

The skill is deployment-neutral on purpose. It does not assume a specific judge name, host, repository owner, repository provider, or token source. A Codex environment should provide these local values before use:

• JUDGING_CLAW_SSH_HOST when the runner lives on a remote host;
• JUDGING_CLAW_WORKDIR for the checkout containing python -m judging_claw;
• JUDGING_CLAW_CONFIG for the deployment config;
• a target ref such as owner/repo#issue#123 or owner/repo#pull_request#123.

To install it into Codex, copy or symlink the skill directory into:

${CODEX_HOME:-$HOME/.codex}/skills/openclaw-judge-feedback

The CLI subcommand is currently named ask-iskra for historical compatibility, but public skill copy treats it as "ask the configured OpenClaw judge agent".

Relationship To Existing Systems

Judging Claw sits between the existing repos and product layers:

System	Responsibility
Hermes Agency	Discovery, research, PRD/spec shaping, upstream package generation.
Patchwarden	PR safety, finding resolution, deterministic merge/automerge gates.
Vistula	Flow state, reporting, structured comments, manual-vs-auto delivery telemetry.
OpenClaw judge agent	Product judgment, operator advocacy, priority sensemaking.
Judging Claw	Nightly/backlog judgment loop for issues and PRs, driven by the configured judge agent.

Judging Claw is intentionally separate from Patchwarden and Vistula. It may later be packaged as an OpenClaw skill for structured nightly prioritization.

Current Status

V0 CLI scaffold exists. It is Python stdlib-only and dry-run-first.

Run locally:

python3 -m judging_claw validate --file examples/valid-issue-judgment.json
python3 -m judging_claw apply-judgment --file examples/valid-issue-judgment.json

Forgejo read-only export uses JUDGING_CLAW_FORGEJO_TOKEN or FORGEJO_TOKEN:

python3 -m judging_claw export forgejo \
  --repo owner/repo \
  --out /tmp/judging-claw.export.json

python3 -m judging_claw plan \
  --export /tmp/judging-claw.export.json \
  --out /tmp/judging-claw.plan.json

python3 -m judging_claw render-request \
  --plan /tmp/judging-claw.plan.json \
  --out /tmp/judging-claw.requests.jsonl

GitHub private repositories are supported as a repository ledger with JUDGING_CLAW_GITHUB_TOKEN, GITHUB_TOKEN, GH_TOKEN, or OPENCLAW_GITHUB_PAT:

python3 -m judging_claw export github \
  --repo owner/private-repo \
  --out /tmp/judging-claw.github.export.json

For nightly and ask-iskra, set the repository provider in config:

{
  "forge": {
    "provider": "github",
    "base_url": "https://api.github.com"
  }
}

Write paths are guarded:

• apply-judgment is dry-run by default; Forgejo writes require --yes and --actor.
• bootstrap-labels is dry-run by default; label creation requires --yes.
• nightly can run --dry-run or guarded --yes.
• ask-iskra can ask the configured OpenClaw judge agent for one Forgejo target ad hoc while keeping the same request contract, target binding, validation, and guarded writer as nightly. See docs/ask-iskra.md.
• No command merges, approves, closes, deletes, starts Hermes, or modifies Patchwarden policy.
• VPS dry-runs can use the same Infisical Universal Auth bridge as OpenClaw: secret_bridge reads /home-platform/apps/openclaw for the Forgejo PAT and /home-platform/providers for OLLAMA_CLOUD_API_KEY. The Ollama key is mapped to OLLAMA_API_KEY only inside the receipt writer path and is never written to artifacts.
• The optional judge stage calls openclaw agent --agent main --json and accepts only valid openclaw.judge.v0 JSON. Request packets include an explicit response template and schema skeleton so the judge agent keeps every required field.
• Guarded live nightly writes require --yes plus GO_LIVE_JUDGING_CLAW=1 or live.go_live_judging_claw=true, the configured expected actor, and repo allowlists.
• live.target_allowlist is optional and only narrows live writes to exact target keys such as owner/repo#issue#123. Omit it for normal production backlog/ad hoc runs. Setting it to [] intentionally allows no targets.
• dispatch can create one structured openclaw.dispatch.v0 issue per (source repo, kind, number, action, snapshot).
• hermes can submit hermes_candidate dispatches to POST /v1/briefs only when GO_HERMES_DISPATCH=1 or hermes.go_hermes_dispatch=true and the target is allowlisted.

VPS dry-run shape:

python3 -m judging_claw nightly \
  --config examples/config.vps-dry-run.example.json \
  --dry-run

The production VPS dry-run config example is examples/config.vps-production.example.json. Adapt its repo allowlist, judge actor, and runtime paths before using it outside the original deployment. It writes timestamped artifacts under out_dir_root.

The systemd templates for the VPS live under ops/systemd/. They run the production config as openclaw at 03:00 local VPS time and remain dry-run by default. Do not switch them to live mode until the controlled live writer proof passes.

Use receipt.mode=ollama only after the deterministic dry-run artifact looks right. The deterministic receipt remains the zero-model fallback.

Hermes proof uses examples/config.vps-hermes-proof.example.json after replacing the placeholder target allowlist with the controlled proof issue number. Hermes submit still requires the separate GO_HERMES_DISPATCH=1/config gate and a dispatch issue URL.

Start with:

• docs/context.md
• docs/decisions.md
• docs/ask-iskra.md
• skills/openclaw-judge-feedback/
• docs/implementation-plan.md
• NEXT_THREAD_HANDOFF.md