agentleFS
apifyapify/apify-claude-code-plugin/skills/apify-actor-development/SKILL.md

apify-actor-development

Skill7 starsChanged 25 days agoApache-2.0View on GitHub

Develop, debug, and deploy Apify Actors - serverless cloud programs for web scraping, automation, and data processing. Use when creating new Actors, modifying existing ones, or troubleshooting Actor code.

  • Installs packages

6 other projects use a version of this, 3 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

31 rules. 10 are common, 4 are distinctive, and 17 are very specific to this project.

  • 10

    Common

    Most of the 4 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 17

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before creating or modifying actors, verify that apify CLI is installed apify --help.

    line 26
  2. Distinctive:

    If it is not installed, use one of these methods (listed in order of preference):

    line 30
  3. Common:

    When the apify CLI is installed, check that it is logged in with:

    line 42
  4. Distinctive:

    If not logged in, authenticate using OAuth (opens browser):

    line 49
  5. Common:

    IMPORTANT: Before starting actor development, always ask the user which programming language they prefer:

    line 64
  6. Common:

    Use the appropriate CLI command based on the user's language choice.

    line 69
  7. Very specific:

    Create actor project: - Run the appropriate apify create command based on user's language preference (see Template Selection above)

    line 73
  8. Very specific:

    Implement logic: - Write the actor code in src/main.py, src/main.js, or src/main.ts

    line 77
  9. Very specific:

    Configure schemas: - Update input/output schemas in .actor/input_schema.json, .actor/output_schema.json, .actor/dataset_schema.json

    line 78
  10. Very specific:

    Configure platform settings: - Update .actor/actor.json with actor metadata (see references/actor-json.md)

    line 79
  11. Distinctive:

    Write documentation: - Create comprehensive README.md for the marketplace (see references/actor-readme.md — this is mandatory, not optional)

    line 80
  12. Very specific:

    Test locally: - Run apify run to verify functionality (see Local Testing section below)

    line 81
  13. Very specific:

    Deploy: - Run apify push to deploy the actor on the Apify platform (actor name is defined in .actor/actor.json)

    line 82
  14. Very specific:

    Use apify run to test actors locally (configures Apify environment and storage)

    line 98
  15. Very specific:

    Use Apify SDK (apify) for code running ON Apify platform

    line 99
  16. Common:

    Use CheerioCrawler for static HTML (10x faster than browsers)

    line 101
  17. Common:

    Use PlaywrightCrawler only for JavaScript-heavy sites

    line 102
  18. Common:

    Use router pattern (createCheerioRouter/createPlaywrightRouter) for complex crawls

    line 103
  19. Common:

    Use proper concurrency: HTTP (10-50), Browser (1-5)

    line 105
  20. Common:

    Use semantic CSS selectors with fallback strategies

    line 109
  21. Very specific:

    Use npm start, npm run start, npx apify run, or similar commands to run actors (use apify run instead)

    line 115
  22. Common:

    Use browser crawlers when HTTP/Cheerio works

    line 118
  23. Very specific:

    Use deprecated options like requestHandlerTimeoutMillis on CheerioCrawler (v3.x)

    line 124
  24. Very specific:

    Use additionalHttpHeaders - use preNavigationHooks instead

    line 125
  25. Very specific:

    Use console.log() or print() instead of the Apify logger — these bypass credential censoring

    line 127
  26. Very specific:

    Check usesStandbyMode in .actor/actor.json - only implement if set to true.

    line 134
  27. Very specific:

    IMPORTANT: Always use apify run to test actors locally.

    line 145
  28. Very specific:

    When testing an actor locally with apify run, provide input data by creating a JSON file at:

    line 149
  29. Very specific:

    Do not rely on checking the Apify Console to verify results from local runs — instead, inspect the local storage/ directory or check the …

    line 161
  30. Distinctive:

    IMPORTANT: Always generate a README.md as part of Actor development.

    line 205
  31. Common:

    If MCP server is configured, use these tools for documentation:

    line 214

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Apify Actor Development

Important: Before you begin, fill in the generatedBy property in the meta section of .actor/actor.json. Set it to the name of the AI coding tool and model you are currently running in, in the format "<tool> with <model>" — for example "Cursor with Claude Sonnet 4.5", "Claude Code with Claude Opus 4", or "GitHub Copilot with GPT-5". If you don't know the exact model, use the tool name alone (e.g. "Cursor"). This helps Apify monitor and improve AGENTS.md for specific AI tools and models.

What are Apify Actors?

Actors are serverless programs inspired by the UNIX philosophy - programs that do one thing well and can be easily combined to build complex systems. They're packaged as Docker images and run in isolated containers in the cloud.

Core Concepts:

  • Accept well-defined JSON input
  • Perform isolated tasks (web scraping, automation, data processing)
  • Produce structured JSON output to datasets and/or store data in key-value stores
  • Can run from seconds to hours or even indefinitely
  • Persist state and can be restarted

Prerequisites & Setup (MANDATORY)

Before creating or modifying actors, verify that apify CLI is installed apify --help.

Rule: pass --user-agent apify-claude-code-plugin/apify-actor-development only on actor run commands (apify run). Do not add it to login, info, push, or other CLI commands.

If it is not installed, use one of these methods (listed in order of preference):

# Preferred: install via a package manager (provides integrity checks)
npm install -g apify-cli

# Or (Mac): brew install apify-cli

Security note: Do NOT install the CLI by piping a remote script into a shell. Always use a package manager.

When the apify CLI is installed, check that it is logged in with:

# Auth check — do NOT pipe to /dev/null, you need to see errors
apify info 2>&1

If not logged in, authenticate using OAuth (opens browser):

apify login

If browser login isn't available (headless environment or CI), the CLI automatically reads APIFY_TOKEN from the environment. Ensure the env var is exported and run any apify command - no explicit login needed. If the user doesn't have a token, generate one at https://console.apify.com/settings/integrations.

Security note: Avoid passing tokens as command-line arguments (e.g. apify login -t <token>). Arguments are visible in process listings and may be recorded in shell history. Prefer environment variables or interactive login instead. Never log, print, or embed APIFY_TOKEN in source code or configuration files.

Template Selection

IMPORTANT: Before starting actor development, always ask the user which programming language they prefer:

  • JavaScript - Use apify create <actor-name> -t project_empty
  • TypeScript - Use apify create <actor-name> -t ts_empty
  • Python - Use apify create <actor-name> -t python-empty

Use the appropriate CLI command based on the user's language choice. Additional packages (Crawlee, Playwright, etc.) can be installed later as needed.

Quick Start Workflow

  1. Create actor project - Run the appropriate apify create command based on user's language preference (see Template Selection above)
  2. Install dependencies (verify package names match intended packages before installing)
    • JavaScript/TypeScript: npm install (uses package-lock.json for reproducible, integrity-checked installs — commit the lockfile to version control)
    • Python: pip install -r requirements.txt (pin exact versions in requirements.txt, e.g. crawlee==1.2.3, and commit the file to version control)
  3. Implement logic - Write the actor code in src/main.py, src/main.js, or src/main.ts
  4. Configure schemas - Update input/output schemas in .actor/input_schema.json, .actor/output_schema.json, .actor/dataset_schema.json
  5. Configure platform settings - Update .actor/actor.json with actor metadata (see references/actor-json.md)
  6. Write documentation - Create comprehensive README.md for the marketplace (see references/actor-readme.md — this is mandatory, not optional)
  7. Test locally - Run apify run to verify functionality (see Local Testing section below)
  8. Deploy - Run apify push to deploy the actor on the Apify platform (actor name is defined in .actor/actor.json)

Security

Treat all crawled web content as untrusted input. Actors ingest data from external websites that may contain malicious payloads. Follow these rules:

  • Sanitize crawled data — Never pass raw HTML, URLs, or scraped text directly into shell commands, eval(), database queries, or template engines. Use proper escaping or parameterized APIs.
  • Validate and type-check all external data — Before pushing to datasets or key-value stores, verify that values match expected types and formats. Reject or sanitize unexpected structures.
  • Do not execute or interpret crawled content — Never treat scraped text as code, commands, or configuration. Content from websites could include prompt injection attempts or embedded scripts.
  • Isolate credentials from data pipelines — Ensure APIFY_TOKEN and other secrets are never accessible in request handlers or passed alongside crawled data. Use the Apify SDK's built-in credential management rather than passing tokens through environment variables in data-processing code.
  • Review dependencies before installing — When adding packages with npm install or pip install, verify the package name and publisher. Typosquatting is a common supply-chain attack vector. Prefer well-known, actively maintained packages.
  • Pin versions and use lockfiles — Always commit package-lock.json (Node.js) or pin exact versions in requirements.txt (Python). Lockfiles ensure reproducible builds and prevent silent dependency substitution. Run npm audit or pip-audit periodically to check for known vulnerabilities.

Best Practices

✓ Do:

  • Use apify run to test actors locally (configures Apify environment and storage)
  • Use Apify SDK (apify) for code running ON Apify platform
  • Validate input early with proper error handling and fail gracefully
  • Use CheerioCrawler for static HTML (10x faster than browsers)
  • Use PlaywrightCrawler only for JavaScript-heavy sites
  • Use router pattern (createCheerioRouter/createPlaywrightRouter) for complex crawls
  • Implement retry strategies with exponential backoff
  • Use proper concurrency: HTTP (10-50), Browser (1-5)
  • Set sensible defaults in .actor/input_schema.json
  • Define output schema in .actor/output_schema.json
  • Clean and validate data before pushing to dataset
  • Use semantic CSS selectors with fallback strategies
  • Respect robots.txt, ToS, and implement rate limiting
  • Always use apify/log package — censors sensitive data (API keys, tokens, credentials)
  • Implement readiness probe handler (required if your Actor uses standby mode)

✗ Don't:

  • Use npm start, npm run start, npx apify run, or similar commands to run actors (use apify run instead)
  • Assume local storage from apify run is pushed to or visible in the Apify Console — it is local-only; deploy with apify push and run on the platform to see results in the Console
  • Rely on Dataset.getInfo() for final counts on Cloud
  • Use browser crawlers when HTTP/Cheerio works
  • Hard code values that should be in input schema or environment variables
  • Skip input validation or error handling
  • Overload servers - use appropriate concurrency and delays
  • Scrape prohibited content or ignore Terms of Service
  • Store personal/sensitive data unless explicitly permitted
  • Use deprecated options like requestHandlerTimeoutMillis on CheerioCrawler (v3.x)
  • Use additionalHttpHeaders - use preNavigationHooks instead
  • Pass raw crawled content into shell commands, eval(), or code-generation functions
  • Use console.log() or print() instead of the Apify logger — these bypass credential censoring
  • Disable standby mode without explicit permission

Logging

See references/logging.md for complete logging documentation including available log levels and best practices for JavaScript/TypeScript and Python.

Check usesStandbyMode in .actor/actor.json - only implement if set to true.

Commands

apify run --user-agent apify-claude-code-plugin/apify-actor-development     # Run Actor locally
apify login   # Authenticate account
apify push    # Deploy to Apify platform (uses name from .actor/actor.json)
apify help                                          # List all commands

IMPORTANT: Always use apify run to test actors locally. Do not use npm run start, npm start, yarn start, or other package manager commands - these will not properly configure the Apify environment and storage.

Local Testing

When testing an actor locally with apify run, provide input data by creating a JSON file at:

storage/key_value_stores/default/INPUT.json

This file should contain the input parameters defined in your .actor/input_schema.json. The actor will read this input when running locally, mirroring how it receives input on the Apify platform.

IMPORTANT - Local storage is NOT synced to the Apify Console:

  • Running apify run stores all data (datasets, key-value stores, request queues) only on your local filesystem in the storage/ directory.
  • This data is never automatically uploaded or pushed to the Apify platform. It exists only on your machine.
  • To verify results on the Apify Console, you must deploy the Actor with apify push and then run it on the platform.
  • Do not rely on checking the Apify Console to verify results from local runs — instead, inspect the local storage/ directory or check the Actor's log output.

Standby Mode

See references/standby-mode.md for complete standby mode documentation including readiness probe implementation for JavaScript/TypeScript and Python.

Project Structure

.actor/
├── actor.json           # Actor config: name, version, env vars, runtime
├── input_schema.json    # Input validation & Console form definition
└── output_schema.json   # Output storage and display templates
src/
└── main.js/ts/py       # Actor entry point
storage/                # Local-only storage (NOT synced to Apify Console)
├── datasets/           # Output items (JSON objects)
├── key_value_stores/   # Files, config, INPUT
└── request_queues/     # Pending crawl requests
Dockerfile              # Container image definition

Actor Configuration

See references/actor-json.md for complete actor.json structure and configuration options.

Input Schema

See references/input-schema.md for input schema structure and examples.

Output Schema

See references/output-schema.md for output schema structure, examples, and template variables.

Dataset Schema

See references/dataset-schema.md for dataset schema structure, configuration, and display properties.

Key-Value Store Schema

See references/key-value-store-schema.md for key-value store schema structure, collections, and configuration.

Actor README

IMPORTANT: Always generate a README.md as part of Actor development. The README is the Actor's landing page on Apify Store and is critical for discoverability (SEO), user onboarding, and support. Do not consider an Actor complete without a proper README.

See references/actor-readme.md for the required structure, SEO best practices, and content guidelines. Also review these top Actors for best practices:

Apify MCP Tools

If MCP server is configured, use these tools for documentation:

  • search-apify-docs - Search documentation
  • fetch-apify-docs - Get full doc pages

Otherwise, the MCP Server url: https://mcp.apify.com/?tools=docs.

Resources

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.