Skill: neurarelay/neura-openclaw-core (version 0.1.0)

--- name: neura-openclaw-core description: Use when an OpenClaw-style or local autonomous computer-use agent needs a single Neura Relay preflight workflow for messages, file changes, browser submits, shell commands, package or publisher changes, workflow state, memory writes, or data exports before execution. --- # Neura Relay Core For OpenClaw-Style Agents Use this skill before a local autonomous agent takes a consequential action. The goal is one governed checkpoint: ```text proposed action -> refs-only Action Card -> Relay Decision Receipt -> runtime-owned execution ``` This is a community example skill pack. It is not an official OpenClaw or ClawHub integration, approval, endorsement, or partnership. ## Current Package Truth - Canonical npm package: `@neurarelay/openclaw-preflight-adapter@0.1.1` - Canonical ClawHub community package: `@neurarelay/openclaw-preflight-adapter@0.1.4` - Historical ClawHub community fallback: `@rpelevin/neura-relay-preflight-adapter@0.1.1` - ClawHub history thread: `openclaw/clawhub#2190` - Execution owner: developer or local runtime, not Neura Prefer the canonical npm package for JavaScript imports. Use the canonical ClawHub community package for OpenClaw installs when ClawHub audits and local policy allow it. The `@rpelevin` package remains a historical fallback only; neither package creates an official OpenClaw or ClawHub approval, listing, endorsement, integration, or partnership claim. ## Workflow 1. Classify the action family: message, file, browser, shell, package/publisher, workflow, memory, or data export. 2. Build a refs-only Action Card. Include action refs, target refs, authority refs, evidence refs, rule refs, risk category, and requested outcome. 3. Reject raw payloads. Do not include message bodies, file contents, form values, raw command strings, package credentials, customer data, secrets, tokens, passwords, or private payloads. 4. Route the card through Relay or the preflight adapter. Use dry-run mode when only shaping the card. 5. Interpret the Decision Receipt before execution: - `proceed`: execute only if authority is Registry-backed or the local policy explicitly accepts the receipt route. - `human_review`: stop and collect a named human review ref. - `revise`: update the Action Card with missing evidence, policy, target, or authority refs. - `stop` or `blocked`: do not execute; record the blocking reason and readiness path. 6. Preserve the trace, transaction ref, receipt id, and developer-owned next step. ## High-Risk Triggers Always require a Decision Receipt before: - sending external messages or public comments - deleting, overwriting, or moving files - submitting browser forms or changing account state - running shell commands, package scripts, deploys, or release operations - publishing packages, changing package metadata, or changing publisher namespace ownership - writing persistent memory - exporting customer, account, browser, or workspace data For package and publisher actions, require source repo, source commit, package identity, owner/publisher ref, artifact digest or pack ref, and no-official-claim boundary refs. ## Output Return: - action family and one-sentence proposed action summary - refs-only Action Card draft or adapter `preflightAction` - missing authority, policy, evidence, artifact, or target refs - Decision Receipt interpretation when a receipt is available - next step for the developer-owned runtime - reminder that no local execution should happen until the receipt path is accepted Read `references/scenario-corpus.md` when the action is package/publisher related, involves customer data, or needs examples for receipt interpretation.

path: references/scenario-corpus.md
content: # Neura Relay OpenClaw Scenario Corpus

Use these scenarios as refs-only patterns for Action Cards and Decision Receipt interpretation. They are examples, not official OpenClaw or ClawHub claims.

## Scenario 1: Package Publish Or Version Release

Action family: `package_publish`

Required refs:

- package identity ref, for example `package_ref:@neurarelay/openclaw-preflight-adapter@0.1.1`
- source repo ref and source commit ref
- pack or artifact digest ref
- publisher authority ref
- changelog or release-intent ref
- no-official-claim boundary ref when the package is OpenClaw-style or ClawHub-facing

Receipt posture:

- `proceed`: publish only if publisher authority, source commit, artifact digest, and release intent are all present.
- `human_review`: use when package namespace, owner, or distribution channel differs from the canonical package.
- `revise`: add missing source, digest, release, or namespace refs.
- `stop`: block when package identity, owner, or artifact digest cannot be verified.

## Scenario 2: Publisher Namespace Or Organization Change

Action family: `publisher_namespace_change`

Required refs:

- desired publisher handle ref
- current account or organization ref
- authority holder ref
- open access request or maintainer-thread ref
- package ownership / namespace mapping ref
- public-claim boundary ref

Receipt posture:

- `proceed`: only for local/account setting changes that are authorized and reversible.
- `human_review`: use when the action changes public ownership, package namespace, or organization membership.
- `revise`: add missing authority holder, maintainer-thread, or namespace mapping refs.
- `stop`: block when the account identity or public ownership consequence is ambiguous.

## Scenario 3: External Message Send

Action family: `outbound_message`

Required refs:

- recipient or channel ref
- user intent ref
- draft ref without raw message body
- communication policy ref
- delegated authority ref

Receipt posture:

- `proceed`: send only after recipient, intent, and authority are clear.
- `human_review`: use for public, partner, legal, customer, or high-reputation messages.
- `revise`: add missing recipient, intent, policy, or approval refs.
- `stop`: block when the message would disclose private material or lacks authority.

## Scenario 4: Browser Submit Or Account Change

Action family: `browser_submit`

Required refs:

- page or form ref
- target account ref
- field-value refs without raw sensitive values
- user intent ref
- policy ref
- authority scope ref

Receipt posture:

- `proceed`: submit only if target account, intent, field refs, and authority are clear.
- `human_review`: use for purchases, account settings, billing, security, or irreversible submits.
- `revise`: add missing page, field, policy, or authority refs.
- `stop`: block when credentials, secrets, or private data would be exposed.

## Scenario 5: Customer Or Workspace Data Export

Action family: `data_export`

Required refs:

- data family ref
- export target ref
- privacy or legal basis ref
- operator intent ref
- retention and deletion posture refs
- authority scope ref

Receipt posture:

- `proceed`: export only when data scope, destination, legal basis, and authority are all clear.
- `human_review`: use for customer data, regulated data, or external destinations.
- `revise`: add missing privacy, target, evidence, or retention refs.
- `stop`: block when raw private data, secrets, or unauthorized customer material would leave the workspace.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal:  | SkillSpector: clean (LOW)