Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

Agent Changelog

v1.2.3

Advanced handling for agent-changelog requests (history, diffs, restores, rollbacks, snapshots) using git and OpenClaw scripts with clear, user-focused summa...

1· 123·0 current·0 all-time

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for noambens/agent-changelog.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "Agent Changelog" (noambens/agent-changelog) from ClawHub.
Skill page: https://clawhub.ai/noambens/agent-changelog
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Required env vars: OPENCLAW_WORKSPACE, OPENCLAW_CONFIG, PROMPTLAYER_API_KEY
Required binaries: git, jq, node
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install agent-changelog

ClawHub CLI

Package manager switcher

npx clawhub@latest install agent-changelog
Security Scan
Capability signals
Requires sensitive credentials
These labels describe what authority the skill may exercise. They are separate from suspicious or malicious moderation verdicts.
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Suspicious
medium confidence
!
Purpose & Capability
The skill's core purpose (workspace changelog via git and OpenClaw hooks) matches the majority of files and scripts. However, the registry/metadata requires PROMPTLAYER_API_KEY and node unconditionally even though PromptLayer integration is optional. Requiring a PromptLayer API key as a mandatory env var is disproportionate to the stated purpose (local changelog + GitHub).
Instruction Scope
SKILL.md and the scripts stay within the stated domain: they read/write the workspace, create hooks, stage commits, present diffs/logs, and optionally sync to external providers. Important behavior to note: pl-init/pl-push/pl-pull will send/receive a full snapshot (zip) of the workspace to/from api.promptlayer.com; setup modifies the global OpenClaw config to enable hooks and register a cron. The skill also writes transient files (.version-context, pending_commits.jsonl) and may stage/commit many files — users should ensure tracked files and .gitignore are correct before enabling sync. The instructions do not attempt to read unrelated system config or arbitrary secrets, but they do use OPENCLAW_CONFIG to read/write OpenClaw settings.
Install Mechanism
No remote download/install of arbitrary code is used; setup.sh copies provided hooks into the user's workspace and updates local OpenClaw config. All code is bundled with the skill (no URL fetches of executables), so install mechanism is low-risk from a supply-chain perspective.
!
Credentials
OPENCLAW_WORKSPACE and OPENCLAW_CONFIG are reasonable. PROMPTLAYER_API_KEY is declared as required in metadata but PromptLayer is optional — that’s disproportionate. If the user enables PromptLayer, the skill will upload a zip snapshot of the workspace to PromptLayer using that API key, which can expose files if .gitignore/tracking is misconfigured. The skill updates openclaw.json to reference the API key (as an env-based secret reference) but does not itself store raw keys in the workspace; still, requiring or supplying the API key enables remote exfiltration of workspace contents.
Persistence & Privilege
The skill modifies OpenClaw config and can register a cron job to run commit.sh automatically (every 10 minutes by default). always is false (good). Hooks run on message events and stage/commit workspace files; this is expected for the feature but does give the skill persistent presence and periodic activity. Combined with optional PromptLayer/GitHub sync, that persistence could lead to repeated remote uploads if configured — review cron and config changes after setup.
What to consider before installing
This skill implements on-disk hooks and a cron job that auto-stages and batches commits of your workspace and can optionally push or upload snapshots to external services (GitHub or PromptLayer). Before installing: 1) Do not set PROMPTLAYER_API_KEY unless you intend to enable PromptLayer sync; the metadata marks it required but the integration is optional. 2) Inspect and tighten .agent-changelog.json so only the files you want are tracked (avoid tracking the entire workspace if you have secrets). 3) If a .gitignore already exists, verify it excludes secrets before setup — setup will leave an existing .gitignore untouched. 4) Review the openclaw.json changes (setup enables hooks and may add a skills entry) and the cron registration; remove the cron if you don't want automatic commits. 5) If you allow PromptLayer, be aware it uploads a zip of your workspace to api.promptlayer.com — only enable that if you trust the service and have removed any sensitive data. Finally, consider testing this in an isolated workspace (not your primary repo) first.
hooks/agent-changelog-commit/handler.ts:14
Shell command execution detected (child_process).
scripts/pl-init.js:47
Shell command execution detected (child_process).
scripts/pl-pull.js:54
Shell command execution detected (child_process).
scripts/pl-push.js:26
Shell command execution detected (child_process).
scripts/pl-init.js:9
Environment variable access combined with network send.
scripts/pl-pull.js:9
Environment variable access combined with network send.
scripts/pl-push.js:9
Environment variable access combined with network send.
!
scripts/pl-init.js:17
File read combined with network send (possible exfiltration).
!
scripts/pl-pull.js:15
File read combined with network send (possible exfiltration).
!
scripts/pl-push.js:16
File read combined with network send (possible exfiltration).
Patterns worth reviewing
These patterns may indicate risky behavior. Check the VirusTotal and OpenClaw results above for context-aware analysis before installing.

Like a lobster shell, security has layers — review code before you run it.

Runtime requirements

Binsgit, jq, node
EnvOPENCLAW_WORKSPACE, OPENCLAW_CONFIG, PROMPTLAYER_API_KEY
latestvk97bycgg4n78aasn92r80adqw985a86z
123downloads
1stars
6versions
Updated 5d ago
v1.2.3
MIT-0

Agent Changelog

OpenClaw tracks workspace file changes between turns and attributes them to the user who triggered the change. Use this skill to answer history and diff questions and to apply controlled restores or rollbacks.

When To Use

Use this skill when the user asks about:

  • What changed, who changed it, or when it changed
  • Diffs between versions or commits
  • Rolling back or restoring files
  • Taking or inspecting snapshots or status
  • Setting up or verifying auto-versioning
  • Pulling a specific version or label from PromptLayer

Response Framework

  1. Clarify intent and scope.

    • Determine whether the user wants a quick summary or raw output.
    • Pin down file(s), time range, and commit identifiers if needed.
  2. Choose the evidence source.

    • Casual queries: use git to gather a compact view.
    • Explicit /agent-changelog invocations: run the matching script and return stdout verbatim.
  3. Present results clearly.

    • Summarize what changed, who triggered it, and the rough size.
    • Offer the next most likely action (diff, restore, rollback, or log).
  4. Handle destructive actions safely.

    • Always show what will change before a rollback or restore.
    • Prefer restore for single-file fixes; use rollback only when the user wants to revert everything.
    • If the target commit is ambiguous, ask a clarification question.
  5. Guide sync onboarding after setup.

    • After setup, proactively ask: "ok want help with github or promptlayer? (pick one)"
    • If yes, walk them through the chosen provider with no extra setup steps required on their side.
    • Confirm account status, credentials, and configuration for the selected provider.

Output Style

  • For summaries, keep it short and conversational.
  • For script-driven output, do not reformat or summarize; if onboarding guidance is needed, provide it after the raw output.
  • If an argument looks like a typo, confirm before running.

File Content Rules

Never embed attribution metadata inside file content. Do not add inline annotations like (updated by X on date), # changed by Y, status footnotes, or any other authorship/timestamp markers into the files you edit. Attribution belongs exclusively in the git commit message, which is handled automatically by the hooks and commit.sh. Files should contain only their actual content — clean, annotation-free.

Implementation Notes

  • Casual history or diff: use a small git window (last 5-10 commits) and include stat output.
  • Slash commands: use the scripts in setup.sh and scripts/ with the user-provided arguments.
  • Setup: run the setup script, then ask "ok want help with github or promptlayer?" and proceed if they confirm.
  • Restore or rollback: locate the commit via log, then perform the change after showing what will be modified.
  • Semantic summary: before every commit, run a quick diff and generate a sparse one-line summary of what changed and why (e.g. "added rate-limit rule to AGENTS.md, updated memory skill"). Always pass it via --summary and always include it in any history output presented to the user.
  • Log output: log.sh outputs raw structured data — present it conversationally based on what the user asked. Don't dump raw script output. Format each entry using the -prefixed box style (same as status output), one entry per block.

Command Reference (Compact)

Use this only for explicit /agent-changelog invocations, and return stdout verbatim.

  • setup -> bash {baseDir}/setup.sh
  • setup follow-up -> Sync onboarding guidance (GitHub or PromptLayer)
  • status -> bash {baseDir}/scripts/status.sh
  • log -> bash {baseDir}/scripts/log.sh [count]
  • diff -> bash {baseDir}/scripts/diff.sh [commit] [commit2]
  • rollback -> bash {baseDir}/scripts/rollback.sh <commit> ["reason"]
  • restore -> bash {baseDir}/scripts/restore.sh <file> <commit> ["reason"]
  • commit (user-requested) -> bash {baseDir}/scripts/commit.sh --manual ["message"] [--summary "one-line semantic summary"]
  • commit (cron-triggered) -> bash {baseDir}/scripts/commit.sh [--summary "one-line semantic summary"]
  • pull from promptlayer -> node {baseDir}/scripts/pl-pull.js
  • pull from promptlayer version <n> -> node {baseDir}/scripts/pl-pull.js --version <n>
  • pull from promptlayer label <label> -> node {baseDir}/scripts/pl-pull.js --label <label>
  • pull from promptlayer version <n> reason <text> -> node {baseDir}/scripts/pl-pull.js --version <n> --reason "<text>"

Auto-Versioning Overview

Two hooks capture and commit changes between turns and attribute them to the active user. Defaults can be overridden via .agent-changelog.json.

Tracked by default: . (entire workspace). Secrets and runtime files are excluded via the .gitignore that setup creates — note that if a .gitignore already exists in the workspace, setup leaves it untouched, so ensure it covers secrets before enabling tracking.

To track a specific subset instead, edit <workspace>/.agent-changelog.json with a tracked array (this fully replaces the default):

{ "tracked": ["<file-or-folder>", "<file-or-folder>"] }

GitHub Onboarding (Setup Add-on)

Use this flow after setup to help users connect the workspace to GitHub. The user will need to authenticate (SSH key or HTTPS credential) — walk them through it step by step:

  1. Account and intent. Confirm they have a GitHub account and want this repo linked.
  2. Git identity. Ensure user.name and user.email are set for commits.
  3. Auth method. Offer SSH or HTTPS; proceed with their preference.
  4. Remote and verify. Ensure an origin remote exists and verify access.
  5. Enable sync. Set github.enabled = true in <workspace>/.agent-changelog.json to activate auto-push on each batch commit.
  6. Next action. Create or select the GitHub repo, then push or fetch as needed.

PromptLayer Onboarding (Setup Add-on)

Use this flow after setup to help users connect the workspace to PromptLayer. Keep it conversational like the GitHub flow and ensure they pick PromptLayer (not both).

  1. Intent. Confirm they want PromptLayer sync for this workspace.
  2. API key. Ask for the API key and set it as PROMPTLAYER_API_KEY in their environment (e.g. shell profile or OpenClaw env config). The scripts read it from the environment; do not write the raw key value into any config file.
  3. Collection choice. Ask whether to connect to an existing collection or create a new one.
  4. Dependency check. PromptLayer pulls require unzip (macOS/Linux) or PowerShell Expand-Archive (Windows).
  5. Config. Collection metadata (collectionId, skillName, provider) is stored in .agent-changelog.json in the workspace — the scripts handle this automatically. The only openclaw.json entry written is the SecretRef: skills.entries.agent-changelog.apiKey = { source: "env", provider: "default", id: "PROMPTLAYER_API_KEY" }.
  6. Connect.
    • Existing: run node {baseDir}/scripts/pl-pull.js --connect <name-or-id>
    • New: run node {baseDir}/scripts/pl-init.js after setting promptlayer.skillName
  7. Confirm. Verify the collection ID and explain that future batch commits sync to PromptLayer.

Comments

Loading comments...