<details>
<summary>📋 Dockerfile (embedded)</summary>

content here

</details>

This ensures users who install the skill can always copy the file, even if ClawHub's publish filter excludes it.

Metadata Requirements

Always declare in SKILL.md frontmatter. Use BOTH field names — the scanner reads required_binaries, Hermes reads required_commands:

version: X.Y.Z
required_commands:            # Hermes runtime reads this
  - docker
  - python3
required_environment_variables: []  # explicit empty if none
required_privileges: non-root (Docker mode)  # scanner reads this
metadata:
  hermes:
    platform: macOS (Docker Desktop), Linux (Docker Engine)
  required_binaries:          # ClawHub scanner reads this
    - docker
    - python3

Critical finding (v1.1.7): ClawHub's GPT-5-mini scanner flagged "required binaries: none" despite required_commands being set. The scanner looks for required_binaries inside the metadata block, not required_commands at the top level. Always declare both.

Also add a visible ## Requirements table in the SKILL.md body — the scanner reads the body text, not just frontmatter. If the frontmatter says "docker" but the body never mentions it, the scanner flags the inconsistency.

Versioning

• Can't republish an existing version — must bump semver
• Use clawhub publish --version X.Y.Z
• Changelog: --changelog "text" is visible in clawhub inspect
• Tags: --tags "tag1,tag2" — default is "latest"

Scanner False-Positive Defense

When a security scanner flags legitimate security controls (obfuscation, sandboxing, syscall tracing):

Add a "Security Disclaimers & Scanner False Positives" section to both SKILL.md and README.md with:

1. "What the scanner sees" — acknowledge the flag
2. "What is actually happening" — explain the legitimate security purpose
3. Comparison table — scanner flag vs reality
4. Why it matters — the security argument

Pattern: This protocol exists to provide security — the scanner flags confirm it is working.

The scanner uses GPT-5-mini. It flags behaviors it doesn't understand contextually. Document the context in the skill itself so the scanner (and human reviewers) can read the justification.

Distroless Docker Patterns

When building sandbox images, use gcr.io/distroless/python3-debian12:nonroot:

Key differences from python:3.11-slim

Multi-stage build pattern

# Stage 1: Builder (has shell, can mkdir)
FROM python:3.11-slim AS builder
RUN mkdir -p /sandbox/source /sandbox/output
RUN touch /sandbox/source/.keep /sandbox/output/.keep

# Stage 2: Runtime (distroless — Python only, no shell)
FROM gcr.io/distroless/python3-debian12:nonroot
COPY --from=builder --chown=nonroot:nonroot /sandbox /sandbox
USER nonroot
ENTRYPOINT ["/usr/bin/python3"]

Critical: Do NOT copy Python from builder — distroless already has its own Python at /usr/bin/python3. Copying builder's Python will fail because libpython3.11.so paths differ.

Verification commands

# Python works
docker run --rm <image> -c "import sys; print(sys.version)"

# Shell doesn't exist (expected failure)
docker run --rm --entrypoint /bin/sh <image>

# Non-root UID
docker run --rm <image> -c "import os; print(os.getuid())"

Publishing Workflow

# 1. Verify files are in the right places
ls <skill_dir>/SKILL.md <skill_dir>/README.md <skill_dir>/scripts/

# 2. Build Docker image if applicable (from embedded or scripts/Dockerfile)
docker build -t <image>:latest -f <skill_dir>/Dockerfile <skill_dir>

# 3. Publish with version and changelog
clawhub publish <skill_dir> --version X.Y.Z --changelog "description"

# 4. Wait for scan (~45s), then verify
sleep 45 && clawhub inspect <slug> --files

# 5. Check verdict: Security should be CLEAN

Subprocess Security Patterns

When a skill spawns subprocesses, the scanner checks for two things. Failing either = DANGEROUS verdict.

1. Environment Scrubbing

Anti-pattern: Copying the full host environment (os.environ.copy()) leaks secrets (AWS keys, API tokens, personal paths) to sub-scripts.

Correct pattern: Define a whitelist-only environment builder and pass it explicitly:

def _build_safe_env() -> dict:
    """Only whitelisted variables pass to subprocesses."""
    ALLOWED = {"PATH", "DOCKER_BIN", "PYTHONPATH", "LANG", "LC_ALL", "LC_CTYPE", "HOME", "TMPDIR", "TERM"}
    safe = {k: v for k in ALLOWED if (v := os.environ.get(k))}
    if "PATH" not in safe:
        safe["PATH"] = "/usr/bin:/bin:/usr/local/bin"
    return safe

# Apply to every subprocess.run, subprocess.Popen, os.exec* call
subprocess.run(cmd, env=_build_safe_env(), ...)

Scope: Apply this to EVERY subprocess invocation in the skill. One missed call = full env leak.

2. Shell Injection Prevention

Anti-pattern: Building shell command strings with f-strings and passing shell=True. If a path contains shell metacharacters, this is an injection vector.

Correct pattern: Use argument lists. No shell interpretation occurs:

# Safe: argument list form
cmd = [DOCKER_BIN, "run", "--rm", "--network=none", "-v", f"{path}:/sandbox:ro", image_name]
subprocess.run(cmd, env=safe_env, timeout=300)

Pre-publish verification

# Verify: no shell=True anywhere in scripts
grep -rn "shell=True" scripts/  # should return nothing

# Verify: all subprocess.run calls pass env=
grep -rn "subprocess.run" scripts/ | grep -v "env="  # should return nothing

Publish-Fix-Republish Loop

When the scanner flags issues, the workflow is:

1. clawhub publish --version X.Y.Z → get scan result
2. clawhub inspect --files → read scanner verdict + warnings
3. Fix the code/docs based on specific warnings
4. Bump version (can't republish same version)
5. clawhub publish --version X.Y.(Z+1) → rescan
6. Repeat until Security verdict is CLEAN

Typical iteration count: 2-4 publishes to reach CLEAN. Budget for this in your workflow.

Common Pitfalls