Post to LinkedIn using the official API v2. Uses OAuth tokens so only post when explicitly asked or scheduled.
Security Analysis
medium confidenceThe skill's declared requirements and the runtime instructions mostly match the LinkedIn-posting purpose, but there are inconsistent or unexplained items (env var requirements and install metadata) and an install-from-GitHub step that should be audited before trusting it with OAuth credentials.
Name/description (post to LinkedIn via API v2) align with required binary 'linkedin-cli' and the described commands. However, the declared required env vars include LINKEDIN_ACCESS_TOKEN while the SKILL.md's setup flow documents creating LINKEDIN_CLIENT_ID and LINKEDIN_CLIENT_SECRET and using 'linkedin-cli auth' to obtain a token — the ACCESS_TOKEN requirement is not explained in the instructions.
SKILL.md instructions stay within the expected scope (install, create ~/.config/linkedin-cli/.env, run oauth, post/delete). The guidance to 'only post when explicitly asked' is policy text, not an enforced technical restriction — the agent can be invoked autonomously by default, so this is a behavior guideline rather than a safeguard. The skill claims no network calls except to LinkedIn endpoints, which cannot be verified from an instruction-only skill.
Registry metadata says 'No install spec' (instruction-only), but SKILL.md contains an 'openclaw.install' entry that pins an npm install from a GitHub repo: 'npm install -g github:0xmythril/linkedin-cli#v1.0.0'. Installing code from a GitHub repo via npm is common but higher risk than an audited package; the install is pinned (good) but should be audited. The mismatch between 'no install spec' and the embedded install command is an inconsistency that should be clarified.
The skill declares three required env vars (LINKEDIN_CLIENT_ID, LINKEDIN_CLIENT_SECRET, LINKEDIN_ACCESS_TOKEN). Client ID/secret are reasonable for OAuth. Requiring LINKEDIN_ACCESS_TOKEN as a required env var is odd because the SKILL.md documents an interactive 'linkedin-cli auth' flow to obtain the token and stores credentials in ~/.config/linkedin-cli/.env. It's unclear whether an access token is mandatory up front or optional for headless operation. Requesting an access token and client secret gives high-value access — justify why all three are required and whether least-privilege (scoped tokens) is used.
The skill does not request always:true and does not ask to modify other skills or system-wide settings. It uses a per-user config file (~/.config/linkedin-cli/.env) which is proportionate. Note: the agent's ability to autonomously invoke the skill (disable-model-invocation: false) is the platform default; combined with OAuth posting rights this increases impact if the agent were compromised — consider restricting autonomous invocation if you are concerned about accidental posts.
Guidance
Before installing or enabling this skill: 1) Inspect the GitHub repo (https://github.com/0xmythril/linkedin-cli) and review package.json and source for postinstall scripts, network endpoints, and telemetry claims — do not rely solely on the README. 2) Clarify why LINKEDIN_ACCESS_TOKEN is listed as required when the instructions show an interactive auth flow; if a token is needed for cron/headless use, ensure it's scoped and rotated regularly. 3) If you will allow autonomous invocation, consider disabling model invocation for this skill or require explicit confirmation prompts to avoid accidental posts. 4) Only install the pinned release after auditing it; if you cannot audit, avoid installing a globally writable npm package from a personal repo. 5) Store client_secret and tokens with restricted file permissions (chmod 600) as instructed and consider using a secrets manager for long-lived environments.
Latest Release
v0.1.0
Initial release of linkedin-cli-2 - Post to LinkedIn using the official API v2 with OAuth authentication. - Requires explicit user action or scheduling for posting; does not post speculatively. - Provides commands to authenticate, verify authentication, post text updates, share URLs, and delete posts. - Credentials are stored securely in a local config file with restricted permissions. - No telemetry, no postinstall scripts, and minimal dependencies for improved security.
More by @0xmythril
Published by @0xmythril on ClawHub
