Skill Publish Vetter

pre-publish privacy scan for ClawHub skills. detects tokens, keys, credentials, .env secrets, personal info, and internal IPs before publishing.

intent

run this skill whenever a user requests to publish, upload, or update a skill to ClawHub or any public registry. the skill scans the target skill's codebase for exposed secrets, credentials, personal data, and internal infrastructure details. publishing to ClawHub makes code world-visible, so any leaked credential becomes a security incident. this scan gates the publish action and requires explicit user confirmation before proceeding.

inputs

• target skill directory (required): filesystem path to the skill being published. if not provided in context, ask the user.
• publish-check.sh script (required): the scan script located at scripts/publish-check.sh relative to this skill's directory. must be executable.
• user confirmation (required): explicit user approval ("yes", "confirm", "ok", "go") before publishing. blocking signal: "cancel", "no", "stop", or timeout.
• clawhub CLI (required): the clawhub command-line tool must be installed and authenticated. requires valid ClawHub API credentials (typically stored in ~/.clawhub/config or CLAWHUB_API_TOKEN env var).
• skill metadata (required for final publish): skill slug, name, version, and changelog. ask the user if not provided.

edge cases and external dependencies:

• network timeout: if clawhub publish hangs beyond 30 seconds, timeout and report failure.
• auth expiry: if ClawHub API returns 401 or 403, the stored credentials are stale. ask user to re-authenticate.
• missing clawhub CLI: if the tool is not found, stop and ask user to install it.
• unreadable directory: if the target skill directory does not exist or is not readable, report and abort.
• empty or missing scan results: if the scan script produces no output, treat as a scan failure and ask user to investigate.

procedure

1. identify the target skill

   • input: user request to publish, or context mentioning a skill directory.
   • if the target skill directory is clear from context, proceed to step 2.
   • else, ask the user: "which skill do you want to publish? provide the directory path or skill name."
   • output: confirmed target skill directory path.

2. validate the target directory exists

   • input: target skill directory path from step 1.
   • check if the directory exists and is readable.
   • if not found or not readable, report "error: directory not found or not accessible" and abort.
   • output: directory validation status (pass/fail).

3. run the privacy scan

   • input: target skill directory path.
   • execute: bash scripts/publish-check.sh <target-skill-directory> from this skill's directory.
   • capture full stdout and stderr.
   • output: complete scan report (unfiltered, unabridged).

4. parse scan results and determine risk level

   • input: full scan report from step 3.
   • classify findings by severity:
     • critical: actual token values, private key content, actual passwords, actual .env values, hardcoded bearer tokens, base64-encoded secrets.
     • warning: personal emails (non-org, non-placeholder), personal filesystem paths, internal IP ranges.
     • info: placeholder fields, metadata, author/repo identity fields marked public intentionally.
   • output: categorized risk assessment.

5. generate confirmation prompt

   • input: risk level, scan report, skill metadata (name, directory, version).
   • construct confirmation message (see template below).
   • output: formatted confirmation prompt ready to display.

6. display report and request confirmation

   • input: formatted confirmation prompt from step 5.
   • output to user the full scan report and confirmation template (see section "output contract").
   • explicitly state: "reply yes/confirm/ok/go to proceed, or cancel/no/stop to abort."
   • output: user response (pending).

7. wait for user response with timeout

   • input: user reply to confirmation prompt.
   • timeout: if no response after 10 minutes, assume user is not ready. abort and report "no confirmation received. publish aborted."
   • output: confirmed or rejected.

8. branch on user response (see "decision points" section)

   • input: user response from step 7.
   • if affirmative ("yes", "confirm", "ok", "go"), proceed to step 9.
   • if negative ("cancel", "no", "stop"), abort and report "publish cancelled by user."
   • else (anything else, unclear, or timeout), abort and report "no valid confirmation. publish aborted."
   • output: decision (proceed or abort).

9. collect missing metadata (if needed)

   • input: user confirmation and existing skill metadata (slug, name, version, changelog).
   • if any field is missing, ask the user: "provide " (e.g., "provide the version number").
   • output: complete metadata (slug, name, version, changelog).

10. execute publish command

    • input: target skill directory, complete metadata (slug, name, version, changelog).
    • execute: clawhub publish <skill-directory> --slug <slug> --name "<name>" --version "<version>" --changelog "<changelog>".
    • capture full stdout and stderr.
    • output: command exit code and output.

11. report result to user

    • input: exit code and output from step 10.
    • if exit code 0: report "✓ skill published successfully to ClawHub."
    • if exit code non-zero: report "✗ publish failed. error: ."
    • output: final status message.

decision points

before step 3 (scan execution)

• if target skill directory is missing or unclear: ask user to provide it. do not guess or assume.
• if directory does not exist: abort with "directory not found" error.

after step 4 (risk assessment)

• if risk level is critical (actual tokens, private keys, real passwords):
  • go to step 5 and prompt user.
  • in the confirmation prompt, flag "critical findings detected. recommend fixing before publishing."
  • if user replies "publish anyway despite risks", re-confirm once more (step 5-6 again) before proceeding to step 9.
  • if user says "no" or "cancel", abort and do not publish.
• if risk level is warning (personal emails, internal IPs, personal paths):
  • go to step 5 and prompt user.
  • in the confirmation prompt, note "warnings found. recommend reviewing."
  • user may proceed, but encourage fixing first.
• if risk level is info only (metadata, placeholders):
  • proceed to step 6 with standard confirmation (no extra escalation).

during step 7 (confirmation wait)

• if no response within 10 minutes: abort and report timeout.
• if user response is unclear or malformed (e.g., "maybe", "i think so"): ask for clarification. do not guess.

during step 8 (branch on response)

• affirmative keywords: "yes", "confirm", "ok", "go", "proceed", "yep", "absolutely", "let's do it".
• negative keywords: "cancel", "no", "stop", "abort", "don't", "nope", "hold on".
• if response matches neither: ask for clarification. do not auto-proceed.

during step 10 (publish execution)

• if clawhub CLI is not found: abort with "clawhub command not found. install the ClawHub CLI first."
• if authentication fails (401/403): report "ClawHub authentication failed. re-authenticate and try again." ask user to run clawhub login.
• if network timeout (>30s): abort and report "publish timed out. check network and try again."
• if directory is unreadable during publish: report error and abort.

after step 11 (final result)

• if publish succeeded: task complete. offer next steps (e.g., "view on ClawHub at ").
• if publish failed: provide the full error message. ask user to debug or retry.

output contract

scan report (step 3 output)

• format: plain text or structured log.
• content: full unfiltered output from publish-check.sh.
• must include all detected issues (tokens, keys, emails, paths, IPs) with line numbers and file paths.
• example:

  SCAN REPORT: skill-example
  
  CRITICAL:
  - File: src/config.js, Line 42
    Found token pattern: sk-abc123xyz... (OpenAI API key)
  
  WARNING:
  - File: README.md, Line 15
    Found personal email: john@gmail.com
  
  INFO:
  - File: package.json
    Metadata field: "author": "john-doe" (non-sensitive)
  
  RESULT: ISSUES FOUND (2 critical, 1 warning)
  

confirmation prompt (step 6 output)

• format: markdown or plain text block displayed to user.
• template:

  📋 Publish Confirmation
  
  Skill: <skill-name>
  Path: <skill-directory>
  Version: <version>
  Scan Result: <PASS / ISSUES FOUND>
  
  [Full scan report here]
  
  ⚠️ Risk Level: <CRITICAL / WARNING / INFO / CLEAN>
  
  Reply "yes" or "confirm" to proceed with publishing, or "cancel" to abort.
  

final publish result (step 11 output)

• format: plain text status message.
• success case: "✓ skill published successfully to ClawHub as v."
• failure case: "✗ publish failed. error: . please fix and retry."

outcome signal

the skill has worked when:

1. scan completes without crashing: the publish-check.sh script runs to completion and produces a report.
2. user sees full report: the unfiltered scan report is displayed in chat, showing all detected issues (if any) with file paths and line numbers.
3. user is prompted for confirmation: the confirmation prompt appears, clearly stating the risk level and asking for explicit approval.
4. user response is processed correctly: affirmative responses trigger publish; negative responses abort without publishing.
5. publish command executes: after confirmation, clawhub publish is run with correct metadata.
6. result is reported: user sees final status (success or failure) with details.

success indicators:

• user confirms and sees "✓ skill published successfully to ClawHub."
• if issues were found, user is informed of them and can choose to fix or proceed.
• no skill is ever published without explicit user confirmation.
• no credentials, tokens, or secrets are leaked to ClawHub.

original skill by weidongkl. enhanced for Implexa standards with explicit decision points, edge case handling, and detailed output contracts.