ThoughtProof
v1.0.0Epistemic verification for AI agent outputs. Use ThoughtProof to verify AI reasoning, detect blind spots, and build consensus across multiple model families....
⭐ 0· 231·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
high confidencePurpose & Capability
The skill's stated purpose (multi-model epistemic verification) aligns with its instructions and the thin CLI wrapper. However, the registry metadata claims no required binaries, env vars, or config paths, while SKILL.md and scripts clearly require the external 'pot-cli' binary and provider API keys. This is an inconsistency between declared metadata and actual purpose/capability needs.
Instruction Scope
SKILL.md keeps scope to verification: normalize → generate → critique → synthesize and stores 'Epistemic Blocks' locally as JSON. The runtime instructions and the wrapper script only delegate to pot-cli and reference a local config (~/.potrc.json). There is no instruction to read unrelated system files or to transmit data to ThoughtProof servers (the README claims BYOK). Still, the docs reference Phase 3 IPFS and an external URL in the wrapper help; confirm those are optional and implemented only by pot-cli before trusting external storage.
Install Mechanism
The skill is instruction-only with a thin shell wrapper (tp.sh). It instructs users to install pot-cli via npm ('npm install -g pot-cli') but the skill manifest contains no install spec. This is not immediately dangerous, but it means installation pulls code from the npm ecosystem (pot-cli) which should be audited — the skill itself does not include or embed third-party binaries.
Credentials
ThoughtProof expects provider API keys (Anthropic, OpenAI, xAI, Moonshot) and a local config file (~/.potrc.json) to supply them, yet the registry metadata lists no required env vars or config paths. Requesting multiple unrelated provider keys is expected for 'model diversity', but the omission in the manifest prevents automated gating and misleads users about credential exposure. Users should be cautious about where and how keys are stored and whether pot-cli transmits them off-host.
Persistence & Privilege
The skill does not request always:true or other elevated persistence. It is user-invocable and not forced into all agent runs. The skill stores blocks locally (per SKILL.md) and the wrapper does not modify other skills or global agent configs.
What to consider before installing
This skill appears to be what it says (a wrapper that delegates to pot-cli to run multi-model verification), but the registry metadata omits critical requirements. Before installing or providing API keys:
- Verify the pot-cli package: inspect its npm page and source repository (who maintains it, recent commits, issues). Do not blindly 'npm install -g' without review.
- Audit pot-cli behavior: check where it stores keys (~/.potrc.json), whether it encrypts them, and whether it ever posts data to external endpoints (IPFS, remote servers). Run pot-cli in a sandbox or with network logging if unsure.
- Use least-privilege keys: create limited-scope or rate-limited provider keys, or keys tied to billing limits. Consider dedicated accounts for verification tasks.
- Inspect ~/.potrc.json permissions and consider using OS-level secrets managers rather than plaintext files.
- Ask the registry maintainer (or the publisher) to correct the manifest so required binaries and config paths are declared. If you cannot confirm pot-cli's trustworthiness, do not install the skill or do so in an isolated environment.
If you want, I can summarize the exact lines to look for in pot-cli's source (network calls, telemetry, config handling) or help draft questions to ask the package maintainer.Like a lobster shell, security has layers — review code before you run it.
latestvk97atpvybfxy6cxr6525hxyjzh82b6fd
License
MIT-0
Free to use, modify, and redistribute. No attribution required.