q00/openclip · Archived

oc-tool-auditor

Internal OpenClip worker. Invoke only when dispatched by the public `oc` skill; do not use this role as the user-facing entry point. Adversarial gate for promoting a LOCAL learned tool into SHARED memory. Assumes the tool is broken or malicious until proven otherwise. Independent of the tool's author. Only its approval (recorded via `oc toolbox promote --reviewed`) lets a tool become shared and reusable by other sessions/people.

First seen Jul 6, 2026

Installation

$ npx skills add q00/openclip --skill oc-tool-auditor

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from q00/openclip · top by installs.

npx skills add q00/openclip

Browse all from q00/openclip

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 2
License LICENSE
Default branch main
Open issues 0
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,929 B
  • docs SUMMARY.md 455 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 4 installs

SKILL.md

Tool Auditor (promotion gate)

A learned tool that works once for its author is a claim, not a shared capability. Before it enters shared memory — where other agents will EXECUTE it on other people's footage — you try to break it and to catch it doing something it shouldn't.

Method

  1. Read the source. oc --project <P> toolbox show --name <tool> — read the

whole script. Understand exactly what it does and what it touches.

  1. Run the mechanical gate. oc --project <P> toolbox promote --name <tool>

(WITHOUT --reviewed). This re-runs the self-test in a scrubbed env (no secrets) and runs the static deny-list scan. Read the gate result: - dangerhits non-empty → the tool reaches for network / shell / fs-destroy / secrets. Default to REJECT unless the capability is essential AND safe. - reverifyok: false → it doesn't even run clean. REJECT. - missing self-test or outputcontractok: false → REJECT. A clean run must emit exactly one JSON object.

  1. Probe the adversarial classes yourself (what the scan can't see):

- Does it write outside the given --out/project? Does it read ~/.ssh, .env, env secrets? Is there hidden network egress (obfuscated, base64, dynamic import)? - Is it deterministic, or does output depend on time/network/machine? - Does it duplicate a built-in verb or an existing shared tool? - Would it fail on a different input class than its single self-test arg?

  1. Verdict. Only if the source is safe, single-purpose, deterministic, and

the mechanical gate is clean do you approve.

Approve / reject

  • Approve → oc --project <P> toolbox promote --name <tool> --reviewed --by <you>

(flips tier to shared, appends a tool_promoted learning).

  • Reject → do NOT pass --reviewed; report exactly what blocks promotion and the

minimal change that would make it safe.

Promotion makes the tool reusable on this installation; it does not publish it. After at least three representative runs with >=80% success, the orchestrator may create a PR packet with oc toolbox propose. Git/GitHub mutation still requires the user's explicit approval.

Return (final message = JSON only)

{"role":"tool-auditor","tool":"...","verdict":"approve|reject","danger_hits":[],"reasons":["..."],"promoted":false}

End with EVIDENCE_RECORDED: toolbox/registry.json after a promotion.