Is skills/signal-lab-apify-tools safe?

Workflow Step 2 instructs the agent to read the live Apify Actor input schema before every execution. The Edge Cases section further instructs the agent to 'follow the live schema and update assumptions accordingly' if it differs from the skill's documentation. This creates a runtime dependency on external content: if Apify's Actor metadata were modified to include adversarial instructions, the agent would be directed to follow them in preference to the audited skill text. The trust boundary is effectively Apify's infrastructure, not this skill file.

The References section lists first-livid-omega.vercel.app/llms.txt and describes it as an 'AI-agent discovery index.' The llms.txt convention is commonly used to provide machine-readable instructions specifically to LLM agents. The content of this file is dynamic and was not reviewed during this audit; it is fetched at agent runtime, not at install time. An agent that fetches this URL could receive behavioral instructions beyond what is documented in the skill.

All API guide references point to first-livid-omega.vercel.app, a Vercel-hosted subdomain not associated with a major auditable organization. If this domain's DNS or content were later changed, agents following the skill's guidance to consult these guides could be exposed to injected instructions. The skill was audited at install time, but the referenced URLs could serve different content at any subsequent agent execution.

The skill's primary purpose is to route user-supplied inputs — URLs, search queries, product identifiers, YouTube video links, job posting URLs — through Apify's hosted Actor infrastructure. While this is user-authorized and explicitly disclosed, all submitted data leaves the local environment and is processed by Apify's systems. Apify's data retention, logging, and access policies are outside the scope of this audit.

The Website to Markdown Actor accepts any user-supplied URL with no technical URL-scope enforcement in the skill itself. If an agent operating in an environment with visibility into intranet hostnames or internal service URLs constructed Actor inputs from that context, internal content could be transmitted to Apify's infrastructure. The skill's own text restricts use to 'public websites' but this boundary is enforced behaviorally by the agent, not technically by the skill.

Installation produced exactly one file: SKILL.md. No executable code, no package.json, no npm lifecycle scripts (preinstall, postinstall), no git hooks, no gitattributes filters with executable commands, no git submodules, and no symlinks were found in the skill subpath. The audit framework's install script performed a sparse checkout and file copy with no hook execution from the skill.

The only external network connections observed during the install window were to GitHub (140.82.121.3:443) for the sparse repository clone and to pre-existing Ubuntu system infrastructure (185.125.190.48:443, 185.125.188.58:443) for the check-new-release background service. No connections were made to Apify, first-livid-omega.vercel.app, or any unexpected third-party host during installation. The connection diff shows no new listening ports or persistent connections after install.

inotify events captured reads of .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and gcloud application_default_credentials.json. Cross-referencing with auditd timestamps shows these accesses occurred at audit epoch 1789074572.283 (pre-clone baseline, before the git clone which starts at 1789074577.793) and 1789074583.865 (post-install verification scan). Both timestamps correspond to the audit framework's own canary integrity verification passes. The skill performed no file access beyond SKILL.md. All canary files are intact and unmodified.