FFmpeg Master Pro Skill Falsely Reported

[aqbjqtd]

FFmpeg Master Pro Skill Falsely Reported

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Keep open. This is a ClawHub issue, and the repository policy for this cleanup pass keeps issues open. Substantively, the public ClawHub API still reports the hosted FFmpeg Master Pro latest version as suspicious, while current main only provides generic visibility, owner rescan, and staff manual override tooling; the source checkout cannot prove this specific hosted artifact is safe to clear.

Required change / next step:

Not a safe automated fix-PR candidate because clearing a production suspicious-skill flag requires staff-only hosted artifact, scan output, and audit history rather than a repository-only code change.

Security review:

Security review needs attention: This issue asks to clear a live suspicious-skill flag, so staff artifact and scan-log review is needed before any production moderation state is changed.

Review details

Best possible solution:

Staff should inspect the latest hosted FFmpeg Master Pro artifact, private scan output, and audit history, then either request or confirm a fresh rescan or apply an audited clean manual override only if version 2.3.1 is confirmed safe; any repeatable scanner false positive should be handled separately with a narrow calibration test and code change.

Security concerns:

• [medium] Review hosted artifact before clearing the flag
  The live public API still reports the latest hosted version as suspicious with an LLM reason code and no public evidence. Clearing that flag without staff-only scan logs, audit history, and artifact inspection could expose users to unsafe skill content.
  Confidence: 0.9
• [medium] Avoid broad scanner changes from a sparse appeal
  The report does not include the artifact contents, scanner transcript, or false-positive explanation. A global scanner relaxation based only on this issue could suppress legitimate warnings for other hosted skills.
  Confidence: 0.84

What I checked:

• Issue and discussion context: The supplied GitHub context shows this issue is open, author association NONE, no protected labels, and a sparse body claiming the FFmpeg Master Pro skill was falsely reported. Two prior ClawSweeper comments also kept it open for moderation follow-up, and the timeline links Fastlane skill reported as suspicious #658 as a similar open suspicious-skill appeal rather than a merged fix or canonical replacement. (7bef2a0b65d4)
• Live skill API still flags the hosted skill: The public skill detail API returned owner handle aqbjqtd, latest version 2.3.1, moderation.isSuspicious true, verdict suspicious, reasonCodes [suspicious.llm_suspicious], engineVersion v2.4.2, and updatedAt 2026-04-29T06:48:32Z.
• Live moderation endpoint has no public clearance evidence: The public moderation endpoint returned the same suspicious LLM verdict with empty public evidence and legacyReason null, so public data does not establish a false positive.
• No bundled artifact in the repository: Search found no ffmpeg-master-pro, FFmpeg Master Pro, Ffmpeg Master Pro, or aqbjqtd content in the source tree, confirming this is hosted production data rather than a source-bundled skill artifact that can be reviewed or patched from main. (7bef2a0b65d4)
• Public detail API exposes moderation state: The v1 skill detail route maps moderationInfo into the public moderation response, including isSuspicious, verdict, reasonCodes, summary, engineVersion, and updatedAt. (convex/httpApiV1/skillsV1.ts:645, 7bef2a0b65d4)
• Moderation API access contract: The v1 moderation route allows public details for flagged visible skills and owner/staff details for hidden skills, with evidence sanitization based on owner or staff access. (convex/httpApiV1/skillsV1.ts:662, 7bef2a0b65d4)

Likely related people:

• Patrick Erichsen: Current blame and recent commits tie this person to the public moderation API, owner rescan surfaces, staff manual override mutation, and rescan-guidance workflow relevant to hosted suspicious-skill follow-up. (role: recent maintainer; confidence: high; commits: ecf09b868a98, ef2846b2e4c7, e6c3d6ff28b1; files: convex/httpApiV1/skillsV1.ts, convex/skills.ts, convex/model/rescans/policy.ts)
• Deepak Jain: Recent history shows work on moderation-engine calibration and false-positive handling adjacent to suspicious-skill appeals, especially VirusTotal Code Insight calibration. (role: adjacent moderation maintainer; confidence: medium; commits: d855d09ab070; files: convex/lib/moderationEngine.ts, convex/lib/moderationEngine.test.ts, convex/skills.ts)
• Peter Steinberger: Recent commits adjusted scanner state handling and documented VirusTotal Code Insight calibration, which is adjacent to hosted moderation false-positive triage even though this appeal currently reports an LLM suspicious code. (role: adjacent scanner maintainer; confidence: medium; commits: 232e429dee6f, 370173379786, b8ba595d06e0; files: convex/skills.ts, convex/vt.ts, convex/vt.test.ts)

Remaining risk / open question:

• The hosted skill state can change outside the repository, so staff should recheck production before acting.
• Public source and public API responses do not expose private scan logs, reviewer notes, or full artifact audit history needed to decide whether version 2.3.1 is a false positive.
• A broad scanner change based only on this sparse appeal could weaken legitimate suspicious-skill warnings for other hosted content.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 7bef2a0b65d4.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Keep open. This is an unresolved ClawHub hosted-skill moderation appeal; the repository policy for this cleanup pass keeps open issues open, and the live public API still reports the skill as suspicious. Current main provides visibility, rescan, and audited staff override mechanisms, but source review cannot adjudicate whether this specific hosted artifact is safe to clear.

Required change / next step:

This requires staff moderation/security review of live hosted scan and audit data; there is no safe automated repository patch that can clear one production skill flag.

Review details

Best possible solution:

Staff should inspect the latest hosted FFmpeg Master Pro artifact and private scan/audit history, then request a rescan or apply an audited clean manual override only if version 2.3.1 is confirmed safe.

Acceptance criteria:

• curl -fsSL https://clawhub.ai/api/v1/skills/ffmpeg-master-pro
• curl -fsSL https://clawhub.ai/api/v1/skills/ffmpeg-master-pro/moderation
• Review staff-only scan results, audit logs, and artifact contents for latest version 2.3.1 before requesting a rescan or applying a clean override.

What I checked:

• Issue status: GitHub API shows this issue is still open, author association is NONE, and it has no protected labels.
• Live skill API state: The public skill API currently returns owner handle aqbjqtd, latest version 2.3.1, moderation.isSuspicious true, verdict suspicious, reasonCodes [suspicious.llm_suspicious], and engineVersion v2.4.2.
• Live moderation endpoint state: The public moderation endpoint returns the same suspicious LLM verdict and an empty public evidence array, so the hosted flag remains visible and unresolved from public data.
• Public API exposes moderation snapshot: The v1 skill detail response maps result.moderationInfo into moderation.isSuspicious, verdict, reasonCodes, summary, engineVersion, and updatedAt. (convex/httpApiV1/skillsV1.ts:645, 7bef2a0b65d4)
• Moderation endpoint access contract: The v1 moderation route allows public details only for flagged visible skills, while owner or staff callers can see hidden-skill details and unredacted evidence. (convex/httpApiV1/skillsV1.ts:662, 7bef2a0b65d4)
• HTTP API docs: The docs describe GET /api/v1/skills/{slug}/moderation, including public access for already-flagged visible skills and owner/staff access for hidden skills and evidence. (docs/http-api.md:180, 7bef2a0b65d4)

Likely related people:

• Patrick-Erichsen: Current blame and commit history tie Patrick Erichsen to the public moderation API and owner/admin rescan surfaces used for hosted suspicious-skill follow-up. (role: recent maintainer; confidence: high; commits: ecf09b868a98, ef2846b2e4c7, 2e5ffdc56593; files: convex/httpApiV1/skillsV1.ts, convex/skills.ts, docs/http-api.md)
• deepujain: Recent public commit history shows Deepak Jain working on moderation-engine calibration and false-positive suppression behavior adjacent to suspicious-skill appeals. (role: adjacent moderation maintainer; confidence: medium; commits: d855d09ab070, 932155cb8ff5, f20dd624a526; files: convex/lib/moderationEngine.ts, convex/lib/moderationEngine.test.ts, convex/skills.ts)
• ngutman: Public commit history shows Nimrod Gutman introduced and hardened the staff manual override audit tooling that would be used if staff clear this hosted flag. (role: manual override feature history; confidence: medium; commits: 4049a3b58a0e, e93f9411f39b, e689a33a09aa; files: convex/lib/manualOverrides.ts, convex/skills.ts, src/routes/management.tsx)

Remaining risk / open question:

• The hosted skill state can change outside the repository, so staff should recheck production before acting.
• A public source checkout and public API response do not expose private scan logs, reviewer notes, or artifact audit history needed to decide whether version 2.3.1 is a false positive.
• Changing scanner behavior globally for one sparse appeal would be security-sensitive and needs maintainer moderation judgment.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 7bef2a0b65d4.

[openclaw-barnacle]

Thanks for the report. Please use the "Rescan" button on the skill/plugin page while signed in as the owner.

You can also request a fresh scan from the CLI:

• Skill: clawhub skill rescan <slug>
• Plugin/package: clawhub package rescan <name>

If the content or metadata changed, publish the fixed version first, then request the rescan for the latest release. I'm closing this issue after posting this guidance. If you're still having trouble after rescanning, please reopen this issue with the ClawHub URL, version, and latest scan result.