Create example OpenClaw plugin using before_install

[Patrick-Erichsen]

Create an example plugin using the before_install hook on OpenClaw to demonstrate skill scanning capabilities.

Branch: feat/openclaw-plugin

Acceptance criteria:

• Example plugin demonstrates running ClawScan before skill install via OpenClaw's before_install hook.
• Documentation explains how to try the plugin locally.
• The example stays out of the README roadmap until it is ready to ship.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 2, 2026, 1:33 PM ET / 17:33 UTC.

Summary
Keep this issue open for an explicit maintainer security-boundary decision. Current main already provides a documented external OpenClaw install-policy adapter that scans staged skills and plugins before install commit, but it intentionally does not add the requested parallel before_install plugin-hook example; as a collaborator-authored security integration request, it is not eligible for automated closure.

Reproducibility: not applicable. this is a request for a new integration example, not a report of broken existing behavior. Current source and docs already establish a supported pre-install scanning path through the external policy protocol.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should ClawScan standardize solely on the existing external security.installPolicy.exec integration, or should it also endorse and maintain a parallel before_install plugin-hook example?	Keep the external policy adapter only: Treat the documented security.installPolicy.exec configuration as the supported integration and close the request after confirming no separate plugin example is wanted.

Why: Both paths run code in the pre-install security decision boundary, so selecting a second path is a product and security-contract choice rather than a mechanical documentation task.

Next step
A maintainer must choose the canonical pre-install security integration before any implementation work; this collaborator-authored request should not enter an automated fix lane.

Security
Needs attention: A second pre-install hook would extend a privileged security-policy boundary and requires explicit contract and compatibility review before implementation.

Review details

Best possible solution:

Keep security.installPolicy.exec as the canonical pre-install scanning path; only add an example if a maintainer explicitly wants a supported plugin-hook contract and can define its OpenClaw compatibility, privilege boundary, and validation proof.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a request for a new integration example, not a report of broken existing behavior. Current source and docs already establish a supported pre-install scanning path through the external policy protocol.

Is this the best way to solve the issue?

Unclear: the existing external policy adapter already solves the pre-install scanning goal, while a parallel plugin hook needs an explicit maintainer decision before it can be considered the best maintainable path.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A parallel before_install plugin hook could create a competing privileged enforcement path whose scanner, gate, and failure semantics drift from the existing external install-policy protocol.
• The current documentation says the warn decision requires a coordinated OpenClaw protocol-v1 host change and has no compatible release floor yet, so any example must define supported host-version behavior rather than imply universal compatibility.

Codex review notes: model internal, reasoning high; reviewed against e63bacb73e8e.

Label changes

Label changes:

• add clawsweeper:needs-security-review: Current issue advisory state selects this label.
• remove clawsweeper:fix-shape-clear: Current issue advisory state no longer selects this label.

Label justifications:

• P3: This is optional integration/example work with no demonstrated regression in the current supported pre-install scan path.
• impact:security: The request concerns code that decides whether staged skills or plugins may be installed.

Evidence reviewed

Security concerns:

• [medium] Avoid a competing install-policy boundary — docs/openclaw-install-policy.md:3
  The current adapter already owns scanner execution and allow/warn/block responses for staged installs; a parallel hook must not create divergent gate or fail-closed behavior.
  Confidence: 0.94

What I checked:

• Documented supported path: Current documentation states that ClawScan runs as OpenClaw's external security.installPolicy.exec command and explicitly says this does not require a ClawScan plugin, plugin activation, or a new install hook. (docs/openclaw-install-policy.md:3, e63bacb73e8e)
• Pre-commit skill and plugin coverage: The documented protocol receives a staged skill or plugin before its install/update stage is committed, scans its source path, and returns one protocol-v1 decision. (docs/openclaw-install-policy.md:14, e63bacb73e8e)
• Current CLI implementation: The public command dispatches openclaw-install-policy to the dedicated policy runner; help text describes its stdin request and allow/warn/block stdout response. (cmd/clawscan/main.go:55, e63bacb73e8e)
• Protocol regression coverage: The install-policy tests cover decoding OpenClaw skill and plugin payloads, including the plugin target type used by the requested pre-install scanning flow. (internal/installpolicy/policy_test.go:13, e63bacb73e8e)
• Feature provenance and likely owner: git blame attributes the install-policy documentation and policy implementation to the current-main commit e63bacb73e8ede8a166dd0d61267bdb07596972a (feat(policy): add OpenClaw install policy adapter (#35)) by Jesse Merhi. (docs/openclaw-install-policy.md:3, e63bacb73e8e)
• Release position: The adapter commit is on local main and postdates the latest release v0.1.6; git tag --contains produced no release tag containing it, so this capability is current-main-only rather than demonstrated as released. (docs/openclaw-install-policy.md:3, e63bacb73e8e)

Likely related people:

• jesse-merhi: Jesse Merhi authored the current-main install-policy adapter commit and is attributed by blame across the central documentation and policy implementation. (role: introduced current install-policy adapter; confidence: high; commits: e63bacb73e8e; files: docs/openclaw-install-policy.md, cmd/clawscan/main.go, internal/installpolicy/policy.go)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.