Reckit
ReviewAudited by ClawScan on May 10, 2026.
Overview
This looks like a real code-verification skill, but it can run many local scripts and worker agents and may save or commit sensitive audit data unless supervised.
Install only if you are comfortable with a code-verification tool that runs local scripts and worker agents. Use it on a disposable branch or sandbox first, require approval before repository writes or CI-file generation, and review/redact .wreckit artifacts before committing or sharing them.
Findings (7)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
You may be relying on bundled scripts without an independently verifiable source or dependency manifest.
The skill includes many runnable helper scripts but provides no external provenance or install/dependency contract. This is not malicious by itself, but users should inspect the packaged scripts before running them.
Source: unknown; Homepage: none; No install spec — this is an instruction-only skill; 25 code file(s)
Review the scripts in a disposable branch or sandbox before using the skill on important repositories.
Running the skill can execute tests, benchmarks, package tools, and project code on your machine.
The skill instructs the agent to run bundled shell helpers for type checks, mutation tests, dynamic analysis, benchmarks, and audits. This is central to the verification purpose, but it means local project code and tooling may execute.
Deterministic helpers — run these, don't rewrite them
Use it only on codebases you trust or inside a sandbox/container, especially for untrusted repositories.
An audit run could create CI configuration files that later run in your repository if committed.
The CI integration gate can write a new GitHub Actions workflow. That is a repository mutation, and it is especially concerning because SKILL.md describes AUDIT mode as 'Verify and report only' while CI Integration is enabled for AUDIT.
If not found: generates a starter `.github/workflows/wreckit-audit.yml`
Require explicit confirmation before creating or committing CI files, especially during audit-only tasks.
Sensitive examples or production-like outputs could be saved into the repository workspace.
Behavior capture can persist API inputs, outputs, and CLI results into local files. These may include secrets, customer data, proprietary behavior, or other sensitive project context.
Record all inputs → outputs from existing codebase (API calls, function returns, CLI outputs) ... Save as golden fixtures in `.wreckit/golden/`
Use sanitized fixtures, review .wreckit/golden before sharing, and add exclusions or redaction rules for secrets and PII.
Private audit findings or golden fixtures could be accidentally committed and shared.
The proof-bundle instructions tell the agent to commit generated audit and behavior artifacts. If those files contain sensitive findings or captured behavior, the data can propagate to shared repos, CI, teammates, or public mirrors.
Commit to repo: `.wreckit/` ... `behavior-capture.md` ... `security-review.md` ... `dashboard.json`
Do not commit .wreckit artifacts until you have reviewed and redacted them; consider keeping .wreckit in .gitignore by default.
A website opened in your browser might be able to read local wreckit dashboard status while the dashboard server is running.
The local dashboard server aggregates project status data and allows any browser origin to read it via CORS if the server is running. It binds to 127.0.0.1, which limits exposure, but the open CORS policy broadens who can read local dashboard data from the browser.
aggregates .wreckit/dashboard.json from all watched project paths ... res.setHeader('Access-Control-Allow-Origin', '*');Run the dashboard only when needed, limit watched project paths, and restrict CORS to the local dashboard origin.
Several workers may read, test, and potentially modify the same project during a verification run.
The skill intentionally uses multiple spawned worker agents. This is disclosed and purpose-aligned for parallel verification, but it increases the amount of autonomous activity touching the codebase.
Uses sessions_spawn for parallel verification swarms. Requires maxSpawnDepth >= 2 ... maxChildrenPerAgent: 8
Use a clean branch, review worker outputs, and avoid enabling broad spawning for sensitive repositories unless you trust the workflow.