Nota Sign
Send files for e-signature with Nota Sign. Use for requests to send an envelope, initiate signing, send a signing link, configure Nota Sign credentials, or s...
MIT-0 · Free to use, modify, and redistribute. No attribution required.
⭐ 0 · 11 · 0 current installs · 0 all-time installs
MIT-0
Security Scan
OpenClaw
Benign
high confidencePurpose & Capability
Name/description (send files for e-signature with Nota Sign) match the included code and SKILL.md. The script validates files, constructs signatures, obtains tokens, uploads files, and calls Nota Sign endpoints. Required credentials are the Nota Sign appId/appKey/userCode/region, which are appropriate for this integration and are stored in local config files (./notasign-config.json or ~/.notasign/config.json).
Instruction Scope
Instructions are narrowly scoped to reading local files or URLs, collecting signer info, storing Nota Sign credentials in a local config, and invoking the TypeScript script. It explicitly instructs not to echo secrets. Note: the runtime uses shell-invoked npx commands with JSON and file path arguments — if the agent or caller interpolates untrusted values into those command-line arguments, there is a risk of argument/command injection or accidental leakage. Also the script will transmit file contents and credentials to external Nota Sign API endpoints as expected for its purpose.
Install Mechanism
No persistent install spec; the skill is instruction-plus-script. The SKILL.md uses npx/tsx and includes a fallback that temporarily downloads node@20 and tsx from npm when local Node.js is older than 18. That is coherent for running a TypeScript script but does require network access to npm for the fallback and pulls runtime packages for the single run.
Credentials
No unrelated environment variables or registry-declared secrets are requested. The only secrets are Nota Sign credentials (appKey is a Base64 PKCS#8 private key) which the skill legitimately needs to sign requests and obtain access tokens. Those are stored in local config files rather than environment variables.
Persistence & Privilege
The skill does not request always:true, does not modify other skills, and only writes its own config at ./notasign-config.json or ~/.notasign/config.json. Autonomous invocation is allowed (platform default) but not excessive for this integration.
Assessment
This skill appears coherent for sending documents via Nota Sign, but consider the following before installing: 1) The script will store sensitive credentials (private key, appId, userCode) in a local config file — protect ~/.notasign/config.json (chmod 600) and avoid storing unrelated secrets there. 2) The fallback runtime temporarily downloads Node/tsx from npm when needed; that requires network access and fetches packages at runtime. 3) When the agent constructs npx command lines with user-supplied file paths or JSON signer strings, ensure inputs are sanitized to avoid shell/argument injection. 4) Confirm you trust the Nota Sign endpoints listed in the code (openapi-*.notasign.* / openapi-*.uat.notasign.*) before uploading sensitive documents. If you want higher assurance, run the provided script locally in a controlled environment first and inspect the full script output and network calls.scripts/send_envelope.ts:457
Environment variable access combined with network send.
scripts/send_envelope.ts:226
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.
Current versionv1.0.1
Download ziplatest
License
MIT-0
Free to use, modify, and redistribute. No attribution required.
SKILL.md
Nota Sign
Use this skill when the user wants to send a supported file for signature through Nota Sign.
Supported tasks
- Send a supported local file, uploaded attachment, or URL for signature
- Collect one or more signer names and emails
- Initialize Nota Sign credentials on first use
- Update or replace existing credentials when the user explicitly asks
- Send in
PRODorUATenvironment
Inputs
Collect only the missing fields.
Required to send:
- file path, uploaded attachment path, or URL
- at least one signer with
userNameanduserEmail
Supported file formats:
doc,docx,pdf,xls,xlsx,bmp,png,jpg,jpeg
Size limit:
- local files and uploaded attachments must be
<= 100MB
Optional:
subjectDefault to the file name when the user does not provide one.
Required only when config is missing or the user asks to reconfigure:
appIdappKeyas Base64 PKCS#8 RSA private keyuserCodeserverRegioninCN | AP1 | AP2 | EU1environmentinPROD | UATDefault toPROD.
Important:
PRODandUATrequire separate credential sets- do not assume a
PRODappId,appKey,userCode, orserverRegioncan be reused inUAT - do not assume a
UATappId,appKey,userCode, orserverRegioncan be reused inPROD - if the user switches environments, treat it as a full reconfiguration and collect the full target-environment credential set
Workflow
- Check whether
./notasign-config.jsonexists; if not, check~/.notasign/config.json. - If config is missing, ask only for the missing credential fields and write the config file.
- If the user wants to switch between
PRODandUAT, do not only flipenvironment. Collect the full target-environment values forappId,appKey,userCode, andserverRegion, then rewrite the config. - Validate the file input before sending:
- local path must exist, or
- uploaded attachment must resolve to a real local file path, or
- remote input must start with
http://orhttps://
- Validate the file type against the supported list:
doc,docx,pdf,xls,xlsx,bmp,png,jpg,jpeg. - Reject local files and uploaded attachments larger than
100MB. - If the user uploaded a supported file in chat, treat it as a valid file input when the client exposes a real attachment path. If no real path or URL is available, ask the user for the original file path or a URL instead of guessing.
- Normalize signer input into JSON:
[{"userName":"Alice","userEmail":"alice@example.com"}]
- Check the local Node.js major version before execution.
- If
nodeexists and the major version is18+, run:
npx tsx scripts/send_envelope.ts --file "PATH_OR_URL" --signers '[{"userName":"Alice","userEmail":"alice@example.com"}]' --subject "Optional subject"
- If local Node.js is missing or below
18, temporarily downloadnode@20andtsxfor this run only:
npx -y -p node@20 -p tsx -c 'tsx scripts/send_envelope.ts --file "PATH_OR_URL" --signers '"'"'[{"userName":"Alice","userEmail":"alice@example.com"}]'"'"' --subject "Optional subject"'
- Use the same fallback pattern for
init:
npx -y -p node@20 -p tsx -c 'tsx scripts/send_envelope.ts init'
- On success, return the envelope ID and basic send summary.
- On failure, surface the exact validation or API error and state the next required action.
Config File
The shared config normally lives at ~/.notasign/config.json. The script also supports a local override at ./notasign-config.json.
Write the config in this shape:
{
"appId": "your_app_id",
"appKey": "base64_pkcs8_private_key",
"userCode": "your_user_code",
"serverRegion": "AP1",
"environment": "PROD"
}
Notes:
environmentis optional and defaults toPROD- the config stores one environment's credential set at a time
- switching from
PRODtoUAT, or fromUATtoPROD, requires replacingappId,appKey,userCode, andserverRegionwith the target environment's values - do not switch environments by editing only the
environmentfield - do not echo secrets back to the user after writing the config
- do not overwrite an existing config unless the user asks to change credentials
- if the temporary runtime fallback is needed, it requires network access to npm
Response Style
- Ask concise follow-up questions only for missing information.
- Prefer one grouped question instead of several small questions.
- Do not ask for
subjectif the file name is good enough. - Do not invent emails, file paths, or credential values.
- Keep credentials and private keys out of normal responses.
- Prefer the direct
scripts/send_envelope.tscommand with a runtime check instead of inventing wrappers or extra helper files. - For user-uploaded files, prefer the attachment's real local path when available. If the attachment exists only as visual context and no path is available, ask for the original file path or URL.
- Reject unsupported file types and local or attachment files above
100MBbefore trying to send.
Examples
This skill should trigger for requests like:
English:
- "Send this file for signature with Nota Sign"
- "Send the file I just uploaded to Daniel with Nota Sign"
- "Use Nota Sign UAT to send this document to two signers"
Chinese:
- "用 Nota Sign 发个信封给 Daniel,附件是 contract.pdf"
- "把我刚上传的文件用 Nota Sign 发给 Daniel"
- "帮我发起电子签署"
Files
3 totalSelect a file
Select a file to preview.
Comments
Loading comments…
