diff --git a/.claude/README.md b/.claude/README.md
new file mode 100644
index 0000000000..91827fb73e
--- /dev/null
+++ b/.claude/README.md
@@ -0,0 +1,112 @@
+# Claude Code configuration for Apify docs
+
+This directory contains Claude Code configuration for the Apify documentation repository.
+
+## Structure
+
+```text
+.claude/
+├── README.md              # This file - Quick start guide
+├── instructions.md        # Main instructions for Claude Code
+├── rules/                 # Canonical standards (auto-loaded)
+│   ├── writing-style.md   # Language, tone, grammar
+│   ├── content-standards.md  # Formatting, front matter, code
+│   ├── terminology.md     # Apify-specific terms
+│   ├── file-organization.md  # Naming conventions
+│   └── quality-standards.md  # Quality checklist
+└── skills/                # Reusable skills for common tasks
+    ├── doc-write.md       # Documentation writing skill
+    ├── api-doc.md         # API documentation skill
+    ├── tutorial.md        # Tutorial creation skill
+    └── review-docs.md     # Documentation review skill
+```
+
+## How to use
+
+### For Claude Code users
+
+1. **Start a new session**: Claude Code will automatically read `instructions.md`
+2. **Use skills**: Type `/doc-write`, `/api-doc`, `/tutorial`, or `/review-docs` to use specific skills
+3. **Reference standards**: Always refer to `AGENTS.md` in the repo root for core standards
+
+### Available skills
+
+#### /doc-write
+Documentation writing - Create or edit pages following style guide
+
+#### /api-doc
+API documentation - Work with OpenAPI specifications and endpoints
+
+#### /tutorial
+Tutorial creation - Build structured, educational tutorials
+
+#### /review-docs
+Documentation review - Check quality and compliance before submission
+
+## Quick start
+
+### Writing new documentation
+
+```text
+Use /doc-write skill to create a new documentation page about [topic]
+```
+
+### Creating a tutorial
+
+```text
+Use /tutorial skill to create a tutorial on [topic]
+```
+
+### Adding API endpoint
+
+```text
+Use /api-doc skill to document the new [endpoint-name] endpoint
+```
+
+### Reviewing documentation
+
+```text
+Use /review-docs skill to review sources/platform/[file-name].md
+```
+
+## Documentation standards
+
+All documentation standards are in `.claude/rules/` (auto-loaded):
+
+1. **`writing-style.md`** - Language, tone, grammar, headings, word choice
+2. **`content-standards.md`** - Front matter, formatting, code examples, links, images
+3. **`terminology.md`** - Apify-specific capitalization and product names
+4. **`file-organization.md`** - File naming and directory structure
+5. **`quality-standards.md`** - Comprehensive pre-submission checklist
+
+Also reference:
+
+- **`AGENTS.md`** - Vendor-agnostic documentation standards (in repo root)
+- **`CONTRIBUTING.md`** - Setup, workflows, contribution process
+- **`instructions.md`** - Full Claude Code instructions (in this directory)
+
+## Testing
+
+Before submitting:
+
+```bash
+npm run lint:md      # Check markdown
+npm run lint:code    # Check code
+npm start            # Preview changes
+npm test             # Validate API specs
+```
+
+## Best practices
+
+1. **Read `AGENTS.md` first** - Vendor-agnostic documentation standards
+2. **Check `.claude/rules/`** - Auto-loaded standards for writing, formatting, terminology
+3. **Use the appropriate skill** - Designed for specific documentation tasks
+4. **Run linters before committing** - `npm run lint:md` and `npm run lint:code`
+5. **Review before submit** - Use `/review-docs` skill for final checks
+
+## Need help?
+
+- Questions about style: Check `AGENTS.md`
+- Setup issues: See `CONTRIBUTING.md`
+- Skill usage: Read the specific skill file
+- Claude Code general: Visit [Claude Code docs](https://github.com/anthropics/claude-code)
diff --git a/.claude/claude.json b/.claude/claude.json
new file mode 100644
index 0000000000..c4a417efb4
--- /dev/null
+++ b/.claude/claude.json
@@ -0,0 +1,29 @@
+{
+  "skills": [
+    {
+      "name": "doc-write",
+      "description": "Create or edit documentation following Apify style guide",
+      "path": "skills/doc-write.md"
+    },
+    {
+      "name": "api-doc",
+      "description": "Work with OpenAPI specifications and API documentation",
+      "path": "skills/api-doc.md"
+    },
+    {
+      "name": "tutorial",
+      "description": "Create structured tutorials with proper learning progression",
+      "path": "skills/tutorial.md"
+    },
+    {
+      "name": "review-docs",
+      "description": "Review documentation for style guide compliance and quality",
+      "path": "skills/review-docs.md"
+    }
+  ],
+  "instructions": "instructions.md",
+  "context": [
+    "../AGENTS.md",
+    "../CONTRIBUTING.md"
+  ]
+}
diff --git a/.claude/instructions.md b/.claude/instructions.md
new file mode 100644
index 0000000000..a98b59ccae
--- /dev/null
+++ b/.claude/instructions.md
@@ -0,0 +1,231 @@
+# Claude Code instructions for Apify documentation
+
+## Project overview
+
+You are working on the Apify documentation repository, which contains:
+
+- **Platform documentation**: Core platform features and functionality (`/sources/platform/`)
+- **Academy**: Educational content and tutorials (`/sources/academy/`)
+- **API reference**: OpenAPI specifications (`/apify-api/`)
+
+The project uses Docusaurus with MDX, follows Microsoft style guide principles, and has comprehensive style guidelines.
+
+## Primary reference documents
+
+**Always reference these files when working on documentation**:
+
+1. **AGENTS.md** - Primary vendor-agnostic documentation standards (READ THIS FIRST)
+2. **.claude/rules/** - Claude Code-specific standards (AUTO-LOADED)
+   - `writing-style.md` - Language, tone, grammar, and writing guidelines
+   - `content-standards.md` - Formatting, front matter, code examples, links, images
+   - `terminology.md` - Apify-specific capitalization and terminology
+   - `file-organization.md` - File naming and directory structure
+   - `quality-standards.md` - Comprehensive quality checklist
+3. **CONTRIBUTING.md** - Contribution guidelines, setup, and workflows
+4. `.cursor/rules/*.mdc` - Cursor-specific rules (for reference)
+
+## Available skills
+
+Use these skills for specific documentation tasks:
+
+### `/doc-write` - Documentation writing
+
+**When to use**: Creating or editing documentation pages
+**Handles**: Content creation, formatting, style guide compliance
+
+### `/api-doc` - API documentation
+
+**When to use**: Working with OpenAPI specifications
+**Handles**: Creating endpoints, schemas, code samples
+
+### `/tutorial` - Tutorial creation
+
+**When to use**: Creating step-by-step tutorials
+**Handles**: Tutorial structure, learning content, examples
+
+### `/review-docs` - Documentation review
+
+**When to use**: Reviewing documentation before submission
+**Handles**: Style guide compliance, quality checks, consistency
+
+## Documentation standards
+
+All documentation standards are defined in `.claude/rules/` and are auto-loaded by Claude Code:
+
+- **Writing style**: See `writing-style.md` for language, tone, grammar, headings, and word choice
+- **Content formatting**: See `content-standards.md` for front matter, text formatting, admonitions, code examples, links, and images
+- **Terminology**: See `terminology.md` for Apify-specific capitalization and product names
+- **File organization**: See `file-organization.md` for naming conventions and directory structure
+- **Quality assurance**: See `quality-standards.md` for comprehensive pre-submission checklist
+
+**Quick reference**:
+
+- Use sentence case for headings (not Title Case)
+- Bold only for UI elements (not emphasis)
+- All admonitions must have titles
+- Front matter required (title, description 140-160 chars, sidebar_position, slug)
+- Use descriptive link text (never "click here")
+- All code blocks must specify language
+
+## File organization
+
+### Naming conventions
+
+- Use **kebab-case** for file names: `web-scraping-basics.md` (never camelCase or snake_case)
+- Use descriptive names that reflect content
+- Group related files in logical directories
+- **Match slug to file path** for consistency
+
+### Directory structure
+
+```text
+sources/
+├── platform/          # Platform documentation
+│   ├── actors/        # Actor-related content
+│   ├── storage/       # Storage documentation
+│   └── integrations/  # Integration guides
+└── academy/           # Educational content
+    ├── tutorials/     # Step-by-step guides
+    └── webscraping/   # Web scraping courses
+```
+
+## API documentation specifics
+
+See the `/api-doc` skill for comprehensive OpenAPI specification standards, operation ID conventions, and path file naming.
+
+## Development workflow
+
+### Before starting work
+
+1. Read `AGENTS.md` for documentation standards
+2. Review `CONTRIBUTING.md` for specific guidelines
+3. Check existing similar documentation for patterns
+4. Determine which skill to use for the task
+
+### During development
+
+1. Follow the appropriate skill instructions
+2. Reference `AGENTS.md` for style questions
+3. Use proper front matter in all files
+4. Include complete, tested code examples
+5. Add descriptive links and alt text
+
+### Before submitting
+
+1. Run linting checks:
+
+   ```bash
+   npm run lint:md        # Markdownlint - Markdown syntax/formatting
+   npm run lint:code      # ESLint - Code linting
+
+   # Run locally for more detailed output:
+   npx markdownlint "path/to/file.md"  # Markdownlint - Check specific files
+   vale sync                            # Vale - Download styles (first time)
+   vale "path/to/file.md" --minAlertLevel=error  # Vale - Check prose style
+   ```
+
+2. Use `/review-docs` skill to check compliance
+3. Verify all code examples work
+4. Check all links are valid
+5. Ensure front matter is complete
+
+### Testing changes
+
+```bash
+npm install          # Install dependencies
+npm start           # Start development server
+npm test            # Validate OpenAPI specs (if applicable)
+npm run build       # Test production build
+```
+
+## Common patterns
+
+See respective skills for content-type specific patterns:
+
+- **Tutorials**: See `/tutorial` skill for 8-section tutorial structure
+- **Platform documentation**: See `/doc-write` skill for feature documentation patterns
+- **API documentation**: See `/api-doc` skill for endpoint documentation patterns
+
+## Quality checklist
+
+Before considering any documentation complete, see `quality-standards.md` for the comprehensive checklist and use the `/review-docs` skill for final review.
+
+## Best practices
+
+- Start with user's goal/problem
+- Provide context before technical details
+- Use consistent Apify terminology (see `terminology.md`)
+- Structure content logically (basic → advanced)
+- Link to related content
+- Test all code examples before committing
+- Never make assumptions about product features - ask if unsure
+- For code review: check comments and obvious mistakes only
+
+## Content review process
+
+### Before reviewing a PR
+
+- Check that the latest changes were pulled from the feature branch
+
+### Review checklist
+
+When reviewing or creating documentation, verify:
+
+- **Clarity**: Instructions are easy to understand
+- **Consistency**: Uniform terminology (see word list above) and style throughout
+- **Grammar & Spelling**: Correct errors, use American English with Oxford commas
+- **Structure**: Logical flow, no duplicate content, appropriate headings/lists
+- **Links**: Verify all links are functional and relevant, link key terms to their docs
+- **Code snippets**: Developer-provided; check comments and obvious mistakes only (not full code review)
+
+## Getting help
+
+If you're unsure about:
+
+- **Style questions**: Check `AGENTS.md` first
+- **Setup issues**: See `CONTRIBUTING.md`
+- **API documentation**: See `/api-doc` skill
+- **Tutorial structure**: See `/tutorial` skill
+- **Review process**: See `/review-docs` skill
+- **Product features**: Never make assumptions - ask if unsure
+
+## Project-specific context
+
+### Multiple repositories
+
+The full documentation ecosystem includes multiple repos:
+
+- apify-docs (this repo) - Platform, Academy, OpenAPI
+- apify-client-js - JavaScript client docs
+- apify-client-python - Python client docs
+- apify-sdk-js - JavaScript SDK docs
+- apify-sdk-python - Python SDK docs
+- apify-cli - CLI documentation
+
+### Theme
+
+Uses `@apify/docs-theme` package - don't modify theme files directly.
+
+### Deployment
+
+- Automatic deployment on merge to `master`
+- Preview builds available for pull requests
+- Uses nginx for routing between repositories
+
+### Linting tools
+
+- **markdownlint** - Markdown syntax and formatting validation
+- **eslint** - JavaScript/TypeScript code linting
+- **Vale** - Prose style checking (optional, download styles with `vale sync`)
+
+## Remember
+
+The goal is to help users succeed with Apify. Every piece of documentation should:
+
+- Be **clear** and easy to understand
+- Be **accurate** and technically correct
+- Be **actionable** with concrete examples
+- Follow the **style guide** consistently
+- Provide **real value** to users
+
+When in doubt, prioritize clarity and usefulness over strict adherence to rules. But always maintain consistency within the documentation set.
diff --git a/.claude/rules/content-standards.md b/.claude/rules/content-standards.md
new file mode 100644
index 0000000000..a5414dd680
--- /dev/null
+++ b/.claude/rules/content-standards.md
@@ -0,0 +1,392 @@
+---
+description: Standard formatting rules for all Apify documentation
+globs: ["sources/**/*.md", "sources/**/*.mdx"]
+alwaysApply: true
+---
+
+# Content Standards
+
+Canonical formatting standards for all Apify documentation. These rules ensure consistency across platform docs, academy tutorials, and API references.
+
+## Front matter requirements
+
+All documentation files must include YAML front matter with these fields:
+
+```yaml
+---
+title: Page title
+description: A clear description of the page content (140-160 characters)
+sidebar_position: 1.0
+slug: /path/to/page
+---
+```
+
+### Required fields
+
+- **title**: Sentence case, present tense (e.g., "Create your first Actor")
+- **description**: 140-160 characters for SEO, clear and actionable
+- **sidebar_position**: Decimal number for ordering (1.0, 1.1, 2.0, etc.)
+- **slug**: URL path starting with `/` (e.g., `/platform/actors/running`)
+
+### Optional fields
+
+- **sidebar_label**: Shorter version of title for sidebar navigation
+- **toc_min_heading_level**: Minimum heading level in table of contents (default: 2)
+- **toc_max_heading_level**: Maximum heading level in table of contents (default: 3)
+
+### Front matter examples
+
+Documentation page:
+```yaml
+---
+title: Store and manage data
+description: Learn how to store and manage data in Apify datasets, key-value stores, and request queues.
+sidebar_position: 3.0
+slug: /platform/storage
+---
+```
+
+Tutorial:
+```yaml
+---
+title: Build a web scraper
+description: Step-by-step guide to building your first web scraper with Apify and Playwright.
+sidebar_position: 1.0
+slug: /academy/tutorials/web-scraper
+---
+```
+
+## Headings
+
+### Casing
+
+**Sentence case only.** Capitalize only the first word and proper nouns.
+
+| Avoid | Prefer |
+|-------|--------|
+| Store And Manage Data | Store and manage data |
+| Getting Started With Actors | Get started with Actors |
+
+### Form
+
+**No gerunds (-ing forms).** Use noun phrases or imperatives.
+
+| Avoid | Prefer |
+|-------|--------|
+| Finding available tags | Available tags |
+| Getting started with Actors | Get started with Actors |
+| Understanding the API | API overview |
+
+### Hierarchy
+
+Follow proper heading hierarchy: H1 → H2 → H3. Never skip levels.
+
+```markdown
+# Page Title (H1 - only one per page, usually from front matter)
+
+## Main Section (H2)
+
+### Subsection (H3)
+
+#### Detail (H4 - use sparingly)
+```
+
+## Text formatting
+
+### Bold
+
+**Do use bold for:**
+- UI elements (buttons, menus, fields, tabs)
+- Critical warnings or key terms that must stand out
+
+**Don't use bold for:**
+- List introductions or section labels
+- Code block introductions
+- General emphasis (use italics instead)
+- Structural labels when context is clear
+
+| Avoid | Prefer |
+|-------|--------|
+| **Examples:** | Examples: |
+| **In your Dockerfile**, use... | In your `Dockerfile`, use... |
+
+### Italics
+
+Use italics for emphasis and introducing new terms:
+
+| Use case | Example |
+|----------|---------|
+| New term introduction | An *Actor* is a serverless program... |
+| Emphasis | This step is *required* for the Actor to work |
+
+### Code formatting
+
+Use backticks for inline code:
+
+- File names: `Dockerfile`, `package.json`, `.actor/actor.json`
+- Commands: `npm install`, `docker build`
+- Config keys: `actorSpecification`, `dockerfile`
+- Variable names: `API_TOKEN`, `userId`
+- Code values: `true`, `null`, `"string"`
+
+## Admonitions
+
+Use Docusaurus admonitions for important information. **All admonitions MUST have titles.**
+
+### Admonition types
+
+| Type | Use for |
+|------|---------|
+| `:::note` | General callouts and additional context |
+| `:::tip` | Helpful suggestions and best practices |
+| `:::info` | Background information and explanations |
+| `:::caution` | Warnings about potential issues or gotchas |
+| `:::danger` | Critical warnings that could cause data loss or errors |
+
+### Format
+
+```markdown
+:::note Title Here
+Content of the admonition.
+:::
+```
+
+### Examples
+
+```markdown
+:::note Actor versions
+Actors can have multiple versions. Pin to a specific version for production use.
+:::
+
+:::tip Performance optimization
+Use the `maxRequestsPerCrawl` option to limit the number of requests for testing.
+:::
+
+:::caution Breaking changes
+Version 3.0 introduces breaking changes. Review the migration guide before upgrading.
+:::
+
+:::danger Data loss risk
+Deleting a dataset is permanent. All data will be lost and cannot be recovered.
+:::
+```
+
+## Code examples
+
+### Completeness
+
+Code examples should be:
+- **Complete**: Runnable without modifications
+- **Realistic**: Solve real problems, not toy examples
+- **Tested**: Verified to work with current versions
+- **Commented**: Only when logic isn't self-evident
+
+### Syntax highlighting
+
+Always specify the language for syntax highlighting:
+
+````markdown
+```javascript
+import { Actor } from 'apify';
+
+await Actor.init();
+// Your code here
+await Actor.exit();
+```
+````
+
+### Common languages
+
+- `javascript` - JavaScript code
+- `typescript` - TypeScript code
+- `python` - Python code
+- `bash` - Shell commands
+- `json` - JSON data
+- `yaml` - YAML configuration
+- `html` - HTML markup
+- `css` - CSS styles
+
+### Code tabs
+
+Use tabs for multiple language examples:
+
+````markdown
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+<Tabs groupId="language">
+<TabItem value="javascript" label="JavaScript">
+
+```javascript
+const result = await client.actor('apify/web-scraper').call();
+```
+
+</TabItem>
+<TabItem value="python" label="Python">
+
+```python
+result = client.actor('apify/web-scraper').call()
+```
+
+</TabItem>
+</Tabs>
+````
+
+### Version matching
+
+When showing Dockerfile tags and package versions, ensure they match:
+
+```dockerfile
+FROM apify/actor-node-playwright:22
+```
+
+```json
+{
+  "dependencies": {
+    "playwright": "^1.40.0"
+  }
+}
+```
+
+## Links
+
+### Descriptive link text
+
+Use action-oriented, descriptive link text. Avoid generic phrases like "click here" or "this link" - screen readers often read links out of context.
+
+| Avoid | Prefer |
+|-------|--------|
+| `[Click here](url)` to learn more | `[Learn about Actor pricing](url)` |
+| Read more about it `[here](url)` | Read the `[Actor development guide](url)` |
+| See the `[documentation](url)` | `[Read the API documentation](url)` |
+
+### Action verbs for links
+
+Match the verb to the content type:
+
+| Content type | Verbs |
+|--------------|-------|
+| Documentation | Read, View, Check, See |
+| Tutorials | Learn, Build, Follow |
+| Reference | Access, Browse, Explore |
+| Examples | View, Try, Clone |
+
+### Internal vs external links
+
+**Internal links** (within apify-docs):
+- Use relative paths: `[Storage](/platform/storage)`
+- Never include the domain
+
+**External links** (to other sites):
+- Use full URLs: `[Playwright](https://playwright.dev)`
+- Make tool mentions navigable
+
+### Actor references
+
+First mention: Actor name with link, capitalized.
+
+```markdown
+[Website Content Crawler](https://apify.com/apify/website-content-crawler)
+can crawl websites and extract text content.
+```
+
+Subsequent mentions: Just the name, no link needed.
+
+## Images
+
+### Alt text
+
+All images must include meaningful alt text describing the content:
+
+```markdown
+![Apify Console showing the Actor creation dialog](./images/create-actor.png)
+```
+
+### Theme
+
+Screenshots should use:
+- **Light theme** as default
+- **Light background** for diagrams
+- Consistent UI language (English)
+
+### Visual indicators
+
+Use red boxes or arrows to highlight important UI elements:
+- **Red border**: Highlight clickable elements (buttons, fields)
+- **Red arrow**: Point to specific areas
+- **Red circle**: Highlight small elements
+
+### Image format
+
+- **PNG** for screenshots and diagrams
+- **JPG** for photos
+- **SVG** for logos and icons (when available)
+
+### File organization
+
+Store images in an `images/` subdirectory next to the markdown file:
+
+```text
+platform/
+├── actors/
+│   ├── running.md
+│   └── images/
+│       └── run-button.png
+```
+
+## Numbers and formatting
+
+### Thousands and decimals
+
+- Thousands: comma separator ($1,000)
+- Decimals: period ($9.8)
+
+### Money
+
+- Symbol before amount: $49 (not 49$)
+- Include currency: $49 USD for international context
+
+### Dates
+
+- Format: Month Day, Year
+- Example: August 5, 2024
+- Never: 5.8.2024 or 2024-08-05 in prose (ISO format OK in code)
+
+### Time
+
+- Format: 12-hour with space before AM/PM
+- Example: 5 PM, 11:30 AM
+- Uppercase: PM (not pm or p.m.)
+
+## Parallel structure
+
+All items in a list must follow the same grammatical pattern:
+
+**Avoid - mixed patterns:**
+```markdown
+1. Reproducibility - your builds behave the same
+1. Predictability - you know which version
+1. Easier to track down issues
+```
+
+**Prefer - consistent pattern:**
+```markdown
+1. Reproducibility - Your builds behave the same way
+1. Predictability - You know exactly which version you're running
+1. Debugging - Version-specific issues are easier to track down
+```
+
+## List types
+
+- **Numbered lists**: Sequential steps where order matters
+- **Bullet points**: Non-sequential items, features, options
+
+In numbered lists, use `1.` for all items (not sequential numbers):
+
+```markdown
+1. First step
+1. Second step
+1. Third step
+```
+
+This makes reordering easier during editing.
diff --git a/.claude/rules/file-organization.md b/.claude/rules/file-organization.md
new file mode 100644
index 0000000000..55cee71f1f
--- /dev/null
+++ b/.claude/rules/file-organization.md
@@ -0,0 +1,26 @@
+---
+description: File naming conventions and directory structure standards
+globs: ["sources/**/*"]
+alwaysApply: true
+---
+
+# File Organization Rules
+
+## Naming conventions
+
+- Use **kebab-case** for file names: `web-scraping-basics.md`
+- Use **descriptive names** that reflect content
+- Group related files in **logical directories**
+
+## Directory structure
+
+```text
+sources/
+├── platform/          # Platform documentation
+│   ├── actors/        # Actor-related content
+│   ├── storage/       # Storage documentation
+│   └── integrations/  # Integration guides
+└── academy/           # Educational content
+    ├── tutorials/     # Step-by-step guides
+    ├── webscraping/   # Web scraping courses
+```
diff --git a/.claude/rules/quality-standards.md b/.claude/rules/quality-standards.md
new file mode 100644
index 0000000000..bfdf5b554a
--- /dev/null
+++ b/.claude/rules/quality-standards.md
@@ -0,0 +1,122 @@
+---
+description: Content quality checklist and review standards
+globs: ["sources/**/*.md", "sources/**/*.mdx"]
+alwaysApply: true
+---
+
+# Quality Standards
+
+Comprehensive quality checklist for all Apify documentation. Use this before submitting any content for review.
+
+## Complete quality checklist
+
+Before submitting documentation, verify:
+
+### Writing and style
+
+- [ ] Content follows **writing-style.md** (sentence case headings, active voice, no sales language)
+- [ ] Language is US English (analyze, color, not analyse, colour)
+- [ ] Tone is imperative and direct (use "Install the package" not "You should install")
+- [ ] No first person (avoid "I recommend", use "we" for Apify team only)
+- [ ] Content is simple (no sentence over 30 words, gets to the point)
+- [ ] No em dashes (use hyphen with spaces: ` - ` instead of `—`)
+
+### Formatting and structure
+
+- [ ] Front matter follows **content-standards.md** (title, description 140-160 chars, sidebar_position, slug)
+- [ ] Headings use sentence case (not title case) and no gerunds (-ing forms)
+- [ ] Heading hierarchy is correct (H2 → H3 → H4, no skipped levels; H1 comes from front matter title)
+- [ ] Bold used only for UI elements and critical warnings (not for structure or list intros)
+- [ ] Code formatting uses backticks for file names, commands, config keys
+- [ ] All admonitions have titles (required by **content-standards.md**)
+- [ ] Lists use parallel structure (all items follow same grammatical pattern)
+- [ ] Numbered lists use `1.` for all items (not sequential numbers)
+
+### Terminology
+
+- [ ] Apify product names follow **terminology.md** (Apify Actor, Apify Proxy, not actor/proxy)
+- [ ] Platform terms use lowercase with "the" (the Apify platform, not Platform)
+- [ ] Feature terms use lowercase (task, schedule, dataset, not Task/Schedule/Dataset)
+- [ ] Word choice is precise (legacy vs alternative vs deprecated used correctly)
+
+### Code examples
+
+- [ ] Code examples are complete and runnable
+- [ ] Syntax highlighting specified for all code blocks
+- [ ] Code tabs used for multi-language examples
+- [ ] Dockerfile tags match package.json versions
+- [ ] Examples tested and working with current versions
+- [ ] Comments only where logic isn't self-evident
+
+### Links and references
+
+- [ ] Link text is descriptive and action-oriented (no "click here" or "here")
+- [ ] Internal links use relative paths (not full URLs)
+- [ ] External tool mentions are linked to official sites
+- [ ] Actor references include link on first mention
+- [ ] No broken links (verify all URLs)
+
+### Images and media
+
+- [ ] All images include meaningful alt text
+- [ ] Screenshots use light theme
+- [ ] Red indicators used to highlight UI elements
+- [ ] Images stored in `images/` subdirectory
+- [ ] Image format is appropriate (PNG for screenshots, SVG for logos)
+
+### File organization
+
+- [ ] File naming follows **file-organization.md** (kebab-case)
+- [ ] File placed in correct directory (platform/, academy/, api-reference/)
+- [ ] Images in appropriate images/ subdirectory
+
+### Technical validation
+
+- [ ] Markdownlint passes (`npm run lint:md`) - Markdown syntax and formatting
+- [ ] Vale style checks pass (no critical errors) - Prose and style validation
+- [ ] No spelling errors in content
+
+## Content type-specific standards
+
+### For documentation pages
+
+Use the **doc-write** skill for comprehensive guidance on:
+- Content structure (introduction, prerequisites, steps, examples, summary)
+- Documentation type distinction (tutorials vs guides vs reference)
+- Platform-specific or Academy-specific requirements
+
+### For tutorials
+
+Use the **tutorial** skill for comprehensive guidance on:
+- Tutorial structure template (8-section format)
+- Learning objectives and expected outcomes
+- Step-by-step instructions with verification
+- Troubleshooting section
+
+### For API documentation
+
+Use the **api-doc** skill for comprehensive guidance on:
+- OpenAPI specification standards
+- Operation ID conventions
+- Code sample requirements (JavaScript and Python)
+- Schema and path documentation
+
+### For documentation review
+
+Use the **review-docs** skill for comprehensive guidance on:
+- Review process and priority ranking
+- Common issues and how to fix them
+- Output format for review feedback
+
+## Pre-submission checklist
+
+Final verification before creating a pull request:
+
+1. [ ] All items in quality checklist above are verified
+1. [ ] Content reviewed against appropriate skill standards (if applicable)
+1. [ ] Changes tested locally (preview looks correct)
+1. [ ] All linting and validation passes
+1. [ ] No console errors in local preview
+1. [ ] Navigation works correctly (sidebar, breadcrumbs, links)
+1. [ ] Search functionality works for new content
+1. [ ] Cross-references to other pages are accurate
diff --git a/.claude/rules/terminology.md b/.claude/rules/terminology.md
new file mode 100644
index 0000000000..484c0c7b61
--- /dev/null
+++ b/.claude/rules/terminology.md
@@ -0,0 +1,122 @@
+---
+description: Official Apify product and technical terminology
+globs: ["sources/**/*.md", "sources/**/*.mdx", "apify-api/**/*.yaml"]
+alwaysApply: true
+---
+
+# Apify Terminology
+
+Official capitalization and usage rules for Apify-specific terms. Use these exact forms throughout all documentation.
+
+## Product names
+
+Always capitalize these Apify product names:
+
+- **Apify Actor** (never "Apify actor" or "actor")
+- **Apify Proxy** (never "Apify proxy" or "proxy")
+- **Apify Console** (never "Apify console" or "console")
+- **Apify Store** (never "Apify store" or "store")
+- **Apify SDK** (never "Apify sdk")
+- **Apify CLI** (never "Apify cli")
+- **Apify API** (never "Apify api")
+
+## Platform terms
+
+Use lowercase for general platform references (include "the"):
+
+- **the Apify platform** (never "Apify Platform" or "the Platform")
+- **the Apify team** (never "the Apify Team")
+- **the Apify ecosystem** (never "the Apify Ecosystem")
+
+## Feature and concept terms
+
+Use lowercase for platform features and concepts:
+
+- **task** (never "Task")
+- **schedule** (never "Schedule")
+- **run** (never "Run")
+- **build** (never "Build")
+- **dataset** (never "Dataset")
+- **key-value store** (never "Key-Value Store")
+- **request queue** (never "Request Queue")
+- **web scraping** (never "Web Scraping")
+
+## Generic technical terms
+
+Use lowercase for generic technical terms:
+
+- **AI agent** (never "AI Agent")
+- **MCP server** (never "MCP Server")
+- **API endpoint** (never "API Endpoint")
+- **web scraper** (never "Web Scraper")
+- **proxy server** (never "Proxy Server")
+
+## Usage examples
+
+### Correct usage
+
+```markdown
+The Apify Actor runs on the Apify platform and stores data in a dataset.
+You can configure your task to run on a schedule using Apify Proxy.
+```
+
+### Incorrect usage
+
+```markdown
+The Apify actor runs on the Apify Platform and stores data in a Dataset.
+You can configure your Task to run on a Schedule using Apify proxy.
+```
+
+## Word choice guidelines
+
+### Legacy vs alternative vs deprecated
+
+Use precise terms to describe feature status:
+
+| Word | When to use |
+|------|-------------|
+| **legacy** | Old approach still supported for backward compatibility, no announced removal |
+| **alternative** | Valid approach, but not the preferred one |
+| **deprecated** | Feature officially marked for removal in a future version |
+
+### Examples
+
+```markdown
+The legacy Docker Compose approach is still supported.
+You can use the alternative REST API instead of the GraphQL API.
+The `Apify.main()` function is deprecated. Use `Actor.main()` instead.
+```
+
+## Special cases
+
+### Actor names
+
+When referring to specific Actors in the Apify Store:
+
+- First mention: Full name with link, capitalized
+  - Example: `[Website Content Crawler](https://apify.com/apify/website-content-crawler)`
+- Subsequent mentions: Just the name, no link needed
+  - Example: `Website Content Crawler can extract text content.`
+
+### Version numbers
+
+- Use "version" not "ver" or "v" in prose
+- Example: "Node.js version 22" (not "Node.js v22" or "Node.js ver 22")
+- Exception: Tags and code can use abbreviations (`node:22`, `v3.0.0`)
+
+### Acronyms and abbreviations
+
+First use: Spell out with acronym in parentheses
+```markdown
+Application Programming Interface (API)
+```
+
+Subsequent uses: Just the acronym
+```markdown
+The API returns a JSON response.
+```
+
+Common acronyms (no need to spell out):
+- API, SDK, CLI, URL, HTTP, HTTPS, JSON, YAML, HTML, CSS, JS
+- AWS, GCP, Azure
+- npm, pip, Docker
diff --git a/.claude/rules/writing-style.md b/.claude/rules/writing-style.md
new file mode 100644
index 0000000000..28185443bc
--- /dev/null
+++ b/.claude/rules/writing-style.md
@@ -0,0 +1,284 @@
+---
+description: Comprehensive writing style rules for Apify documentation
+globs: ["sources/**/*.md", "sources/**/*.mdx"]
+alwaysApply: true
+---
+
+# Apify Documentation Writing Style
+
+Instructions for AI assistants writing Apify documentation. Based on Apify style guide and technical writer feedback.
+
+## Core Principles
+
+1. **Simple** - Get to the point. No sentence over 30 words. Every sentence delivers information.
+1. **Factual** - Back up claims with evidence. Use numbers, not vague qualifiers.
+1. **Technical** - Write for developers. Don't oversimplify. Link to fill knowledge gaps.
+
+> Write the same way you would explain something to a person sitting next to you.
+
+## Content Types
+
+Match language to content type:
+
+| Content type     | CTA verbs                 | Example                                      |
+| ---------------- | ------------------------- | -------------------------------------------- |
+| Tutorials/guides | Learn, Build, Create      | "Learn how to build a web scraper"           |
+| Reference docs   | Access, Integrate, Use    | "Access the Apify platform programmatically" |
+| Discovery pages  | Explore, Discover, Browse | "Explore available Actors"                   |
+
+Don't use "Learn" for pure reference documentation - it sets tutorial expectations.
+
+## Language & Tone
+
+### US English
+
+Use "analyze" not "analyse", "color" not "colour".
+
+### Imperative tone
+
+Use direct instructions, not soft recommendations:
+
+| Avoid                             | Prefer              |
+| --------------------------------- | ------------------- |
+| We recommend pinning the version  | Pin the version     |
+| You should use the latest SDK     | Use the latest SDK  |
+| It's best to avoid hardcoding     | Avoid hardcoding    |
+
+### No sales language
+
+| Avoid                                      | Prefer                                              |
+| ------------------------------------------ | --------------------------------------------------- |
+| Experience Apify, the ultimate platform!   | Welcome to Apify, the full-stack web scraping platform.  |
+| Our highly efficient system                | Apify's system handles 500K requests per minute     |
+
+### Avoid first person
+
+Use "you" to focus on the reader. Avoid "I", "me", "myself" in docs.
+
+| Avoid                                 | Prefer                           |
+| ------------------------------------- | -------------------------------- |
+| I recommend using version 22          | Use version 22                   |
+| In my experience, this works better   | This approach is more reliable   |
+
+### Active & inclusive voice
+
+Use active voice. Avoid gendered terms. Don't use directional language ("left/right") for UI - it breaks with different layouts.
+
+| Avoid                             | Prefer                           |
+| --------------------------------- | -------------------------------- |
+| The Actor is started by the user  | The user starts the Actor        |
+| He can configure his settings     | You can configure your settings  |
+| Click the button on the left      | Click the **Settings** button    |
+
+## Formatting
+
+### Headings
+
+**Sentence case only.** No title case.
+
+| Avoid                 | Prefer                |
+| --------------------- | --------------------- |
+| Store And Manage Data | Store and manage data |
+
+**No gerunds (-ing forms).** Use noun phrases or imperatives.
+
+| Avoid                         | Prefer                     |
+| ----------------------------- | -------------------------- |
+| Finding available tags        | Available tags             |
+| Getting started with Actors   | Get started with Actors    |
+| Understanding the API         | API overview               |
+
+Rationale: Noun-phrase headings are more scannable and search-friendly (Microsoft style guide).
+
+### Bold
+
+**Do use bold for:**
+
+- UI elements (buttons, menus, fields): Click the **Actors** button
+- Critical warnings or key terms
+
+**Don't use bold for:**
+
+- List introductions
+- Code block introductions
+- Section labels when context is clear
+
+| Avoid                           | Prefer                        |
+| ------------------------------- | ----------------------------- |
+| **Examples:**                   | Examples:                     |
+| **In your Dockerfile**, use...  | In your `Dockerfile`, use...  |
+
+Bold for UI elements helps users scan for clickable items. Bold for structure creates visual noise.
+
+### Italics
+
+Use italics for emphasis and introducing new terms:
+
+| Use case                 | Example                                       |
+| ------------------------ | --------------------------------------------- |
+| New term introduction    | An *Actor* is a serverless program...         |
+| Emphasis                 | This step is *required* for the Actor to work |
+
+### List types
+
+**Numbered lists** - Sequential steps where order matters
+**Bullet points** - Non-sequential items, features, options
+
+In numbered lists, use `1.` for all items (not sequential numbers). Easier to maintain:
+
+```markdown
+1. First step
+1. Second step
+1. Third step
+```
+
+### Parallel structure
+
+All items in a list must follow the same grammatical pattern:
+
+```markdown
+# Avoid - mixed patterns
+1. Reproducibility - your builds behave the same
+1. Predictability - you know which version
+1. Easier to track down issues
+
+# Prefer - consistent pattern
+1. Reproducibility - Your builds behave the same way
+1. Predictability - You know exactly which version you're running
+1. Debugging - Version-specific issues are easier to track down
+```
+
+### Em dashes
+
+**Don't use em dashes (—).** LLMs overuse them. Use hyphen with spaces ( - ) instead.
+
+### Admonitions
+
+Use Docusaurus admonitions for important information:
+
+| Type         | Use for                                     |
+| ------------ | ------------------------------------------- |
+| `:::note`    | General callouts                            |
+| `:::tip`     | Helpful suggestions                         |
+| `:::info`    | Background context                          |
+| `:::caution` | Warnings about gotchas                      |
+| `:::danger`  | Critical warnings that could cause issues   |
+
+**All admonitions require titles.** Use 2-3 words that are scannable and summarize the content.
+
+| Avoid                                   | Prefer                     |
+| --------------------------------------- | -------------------------- |
+| `:::note Note`                          | `:::note Actor versions`   |
+| `:::caution Be careful when deleting`   | `:::caution Data loss`     |
+| `:::tip` (no title)                     | `:::tip Performance`       |
+
+Prefer admonitions over block quotes for highlighted content.
+
+## Grammar
+
+### Articles in definitions
+
+Include "a/an" before nouns in definition lists:
+
+| Avoid                              | Prefer                               |
+| ---------------------------------- | ------------------------------------ |
+| `{version}` - Node.js version only | `{version}` - A Node.js version only |
+
+### Oxford comma
+
+Always use the serial comma:
+
+| Avoid                        | Prefer                           |
+| ---------------------------- | -------------------------------- |
+| pencil, eraser and notebook  | pencil, eraser, and notebook     |
+
+### "the" before products
+
+Use "the" before "Apify platform", "Apify SDK", etc.
+
+| Avoid                | Prefer                    |
+| -------------------- | ------------------------- |
+| I use Apify platform | I use the Apify platform  |
+
+## Terminology
+
+See `terminology.md` for complete Apify-specific terminology and capitalization rules.
+
+## Links
+
+### Action-oriented text
+
+| Avoid                             | Prefer                                  |
+| --------------------------------- | --------------------------------------- |
+| [actor-node-playwright tags](url) | [View actor-node-playwright tags](url)  |
+| See the [documentation](url)      | [Read the documentation](url)           |
+
+### Accessible link text
+
+Use descriptive link text. Avoid generic phrases like "click here" or "this link" - screen readers often read links out of context.
+
+| Avoid                              | Prefer                                    |
+| ---------------------------------- | ----------------------------------------- |
+| `[Click here](url)` to learn more  | `[Learn about Actor pricing](url)`        |
+| Read more about it `[here](url)`   | Read the `[Actor development guide](url)` |
+
+### Make tool mentions navigable
+
+When mentioning tools, languages, or external resources, link them to help readers explore:
+
+| Avoid                               | Prefer                                                      |
+| ----------------------------------- | ----------------------------------------------------------- |
+| You can use Playwright for this     | You can use [Playwright](https://playwright.dev) for this   |
+
+### Trim filler words
+
+| Avoid                          | Prefer                |
+| ------------------------------ | --------------------- |
+| visit the Docker Hub tags page | visit Docker Hub      |
+| check out the official docs    | check the documentation |
+
+### Actor references
+
+First mention: Actor name with link, capitalized.
+
+```markdown
+[Website Content Crawler](https://apify.com/apify/website-content-crawler)
+can crawl websites and extract text content.
+```
+
+## Code Examples
+
+- Use backticks for file names, commands, config keys
+- Prefer complete, runnable examples
+- Add comments only when code isn't self-explanatory
+- Match versions in examples (e.g., Dockerfile tag matches package.json version)
+
+## Numbers & Formatting
+
+- Thousands: comma separator ($1,000)
+- Decimals: period ($9.8)
+- Money: symbol before amount ($49, not 49$)
+- Dates: August 5, 2024 (never 5.8.2024)
+- Time: 5 PM (space before, uppercase)
+
+## Common Mistakes
+
+Patterns to avoid:
+
+- "Happy scraping!" closings
+- Em dashes
+- Title case headings
+- Gerunds in headings
+- Bold for routine structure
+- "Ok" (use "OK" or "okay")
+- Missing "the" before "Apify platform"
+- Sales language ("ultimate", "cutting-edge", "supercharge")
+- Vague claims without numbers
+
+## Reference
+
+This guide covers writing patterns. For structural guidelines (file naming, screenshots, tutorial structure, SEO), see:
+
+- [CONTRIBUTING.md](../../CONTRIBUTING.md) - Contribution workflow and repository standards
+- [AGENTS.md](../../AGENTS.md) - Comprehensive documentation guidelines for AI assistants
+- Full Apify style guide: https://www.notion.so/apify/Apify-style-guide-1b9f39950a2280d49e5be69ce2961a79
diff --git a/.claude/skills/api-doc.md b/.claude/skills/api-doc.md
new file mode 100644
index 0000000000..735991d4d9
--- /dev/null
+++ b/.claude/skills/api-doc.md
@@ -0,0 +1,229 @@
+# API documentation skill
+
+## Purpose
+
+Help create or update OpenAPI specifications and API documentation for Apify API endpoints.
+
+## When to use
+
+- Adding new API endpoints
+- Updating existing endpoint documentation
+- Creating or modifying OpenAPI schemas
+- Adding code samples for API endpoints
+
+## Context files
+
+- `CONTRIBUTING.md` - API documentation section and workflows
+- `AGENTS.md` - API documentation rules
+- `apify-api/openapi/openapi.yaml` - Main OpenAPI spec
+- `.claude/rules/` - Claude Code-specific standards (auto-loaded)
+
+## Standards reference
+
+This skill follows all standards defined in `.claude/rules/`:
+
+- **writing-style.md** - Clear, simple descriptions (US English, active voice)
+- **content-standards.md** - Code examples formatting
+- **terminology.md** - Apify-specific capitalization in descriptions (Apify Actor, the Apify platform)
+- **quality-standards.md** - General quality checklist
+
+**API-specific standards** are documented in this skill file below.
+
+## Instructions
+
+### 1. OpenAPI file structure
+
+```text
+apify-api/openapi/
+├── openapi.yaml              # Main spec file
+├── components/
+│   └── schemas/              # Data model definitions
+└── paths/                    # API endpoint definitions
+```
+
+### 2. Creating schema documentation
+
+**Location**: `apify-api/openapi/components/schemas/`
+
+**Steps**:
+
+1. Create a new YAML file named after your schema
+2. Define the schema structure following OpenAPI 3.0 specification
+3. Include comprehensive descriptions for all properties
+4. Reference schema using `$ref` in other files
+
+**Example**:
+
+```yaml
+type: object
+properties:
+  id:
+    description: The resource ID
+    readOnly: true
+    allOf:
+      - $ref: ./ResourceId.yaml
+  name:
+    type: string
+    description: The resource name
+    example: "my-resource"
+required:
+  - id
+  - name
+```
+
+### 3. Creating path documentation
+
+**Location**: `apify-api/openapi/paths/`
+
+**Naming Convention**: Replace `/` with `@` in the URL path
+
+- `/request-queues` → `request-queues.yaml`
+- `/request-queues/{queueId}` → `request-queues@{queueId}.yaml`
+
+**Example Path File**:
+
+```yaml
+get:
+  tags:
+    - Request Queues
+  summary: Get a Request Queue
+  operationId: requestQueue_get
+  description: |
+    Retrieves a specific request queue by ID.
+
+    Returns detailed information about the queue including
+    its current state, item count, and metadata.
+  parameters:
+    - name: queueId
+      in: path
+      required: true
+      description: The unique identifier of the request queue
+      schema:
+        type: string
+  responses:
+    '200':
+      description: Request queue details
+      content:
+        application/json:
+          schema:
+            $ref: ../components/schemas/RequestQueue.yaml
+    '401':
+      description: Unauthorized
+    '404':
+      description: Queue not found
+  x-code-samples:
+    - lang: JavaScript
+      source:
+        $ref: ../code_samples/JavaScript/request-queues@{queueId}/get.js
+    - lang: Python
+      source:
+        $ref: ../code_samples/Python/request-queues@{queueId}/get.py
+```
+
+### 4. Operation ID conventions
+
+Format: `{objectName}_{httpMethod}`
+
+**Rules**:
+
+- Use camelCase for object names
+- Single object for paths with `{id}`, plural otherwise
+- Underscore separator between object name and action
+- Method name in lowercase at the end
+
+**Examples**:
+
+- `/request-queues` GET → `requestQueues_get`
+- `/request-queues/{queueId}` PUT → `requestQueue_put`
+- `/acts/{actorId}/runs` POST → `act_runs_post`
+
+### 5. Adding code samples
+
+**Location**: `apify-api/openapi/code_samples/{language}/{path}/`
+
+**Steps**:
+
+1. Navigate to the appropriate language folder
+2. Create path-based directory structure
+3. Add code sample file
+4. Reference in path documentation using `x-code-samples`
+
+**Example JavaScript Code Sample**:
+
+```javascript
+// GET /v2/request-queues/{queueId}
+const { ApifyClient } = require('apify-client');
+
+const client = new ApifyClient({
+    token: 'YOUR_API_TOKEN',
+});
+
+const queue = await client.requestQueue('QUEUE_ID').get();
+console.log(queue);
+```
+
+**Example Python Code Sample**:
+
+```python
+# GET /v2/request-queues/{queueId}
+from apify_client import ApifyClient
+
+client = ApifyClient('YOUR_API_TOKEN')
+
+queue = client.request_queue('QUEUE_ID').get()
+print(queue)
+```
+
+### 6. Adding new endpoints to main spec
+
+**File**: `apify-api/openapi/openapi.yaml`
+
+Add path reference:
+
+```yaml
+paths:
+  '/request-queues':
+    $ref: './paths/request-queues/request-queues.yaml'
+  '/request-queues/{queueId}':
+    $ref: './paths/request-queues/request-queues@{queueId}.yaml'
+```
+
+### 7. Testing and validation
+
+After making changes:
+
+```bash
+npm test  # Validates OpenAPI specification
+npm start # Preview changes locally
+```
+
+### 8. Best practices
+
+- **Descriptions**: Write clear, comprehensive descriptions using simple English
+- **Examples**: Include realistic examples in schemas
+- **Error responses**: Document all possible error responses
+- **Authentication**: Document authentication requirements
+- **Consistency**: Follow existing patterns in the codebase
+- **Completeness**: Ensure all parameters and responses are documented
+- **Terminology**: Use correct Apify terminology throughout
+- **Never make assumptions**: About product features - ask if unsure
+
+### 9. API-specific quality checklist
+
+Before submitting, verify these API-specific items:
+
+- [ ] OpenAPI specification validates without errors (`npm test`)
+- [ ] Operation IDs follow naming conventions (`objectName_method` in camelCase)
+- [ ] All parameters have clear descriptions
+- [ ] Response schemas are complete with examples
+- [ ] Code samples included for JavaScript, Python, and cURL
+- [ ] Examples use realistic data (not placeholder values)
+- [ ] Path references added to main `openapi.yaml`
+- [ ] All error responses documented (401, 404, etc.)
+- [ ] Authentication requirements documented
+
+For general quality standards (terminology, language, formatting), see `quality-standards.md`
+
+## Output
+
+Provide the complete OpenAPI specification changes with proper formatting, ready to be tested and committed.
diff --git a/.claude/skills/doc-write.md b/.claude/skills/doc-write.md
new file mode 100644
index 0000000000..eda3da04a4
--- /dev/null
+++ b/.claude/skills/doc-write.md
@@ -0,0 +1,99 @@
+# Documentation writer skill
+
+## Purpose
+
+Help write or edit Apify documentation following the established style guide and best practices.
+
+## When to use
+
+- Creating new documentation pages
+- Editing existing documentation
+- Converting drafts into proper documentation format
+- Updating documentation content
+
+## Context files
+
+- `AGENTS.md` - Primary vendor-agnostic documentation standards
+- `CONTRIBUTING.md` - Contribution guidelines
+- `.claude/rules/` - Claude Code-specific standards (auto-loaded)
+
+## Standards reference
+
+This skill follows all standards defined in `.claude/rules/`:
+
+- **writing-style.md** - Language, tone, grammar, headings, word choice (US English, active voice, sentence case, no gerunds)
+- **content-standards.md** - Front matter, text formatting, admonitions (must have titles), code examples, links, images
+- **terminology.md** - Apify-specific capitalization (Apify Actor, the Apify platform, etc.)
+- **quality-standards.md** - Complete pre-submission quality checklist
+
+**Key reminders**:
+- Sentence case for headings (not Title Case)
+- No gerunds in headings (use "Create" not "Creating")
+- Bold ONLY for UI elements (not for emphasis)
+- All admonitions MUST have titles
+- Front matter required (title, description 140-160 chars, sidebar_position, slug)
+- Match slug to file path
+
+## Documentation structure
+
+### For platform documentation
+
+1. **Introduction** - Clear description of the feature or concept
+2. **When to use** - Explain when this feature is appropriate
+3. **How to configure/use** - Step-by-step instructions with code examples
+4. **Best practices** - Recommendations and tips
+5. **Related features** - Links to related documentation
+
+### For tutorials and guides
+
+1. **Introduction** - What will the user learn? (Include learning objectives)
+2. **Prerequisites** - Required knowledge, setup, accounts
+3. **Step-by-step instructions** - Clear, numbered steps with explanations
+4. **Code examples** - Complete, runnable examples (test before submitting)
+5. **Testing/verification** - How to verify it works
+6. **Summary** - What they accomplished and suggested next steps
+
+### For reference documentation
+
+1. **Overview** - Brief description of the topic
+2. **Parameters/options** - Detailed list with types and descriptions
+3. **Examples** - Practical usage examples
+4. **Related information** - Links to related topics
+
+## Documentation types
+
+### Tutorials
+- **Goal**: Teach users how to accomplish a specific task
+- **Tone**: Instructional, encouraging, step-by-step
+- **Examples**: "Build your first web scraper", "Deploy an Actor to production"
+- **Use**: Complete code examples, screenshots, expected results at each step
+
+### Guides
+- **Goal**: Explain how to use a feature or solve a problem
+- **Tone**: Informative, practical, solution-oriented
+- **Examples**: "Actor configuration", "Working with datasets"
+- **Use**: Focused code snippets, best practices, common patterns
+
+### Reference
+- **Goal**: Document technical specifications and API details
+- **Tone**: Precise, comprehensive, technical
+- **Examples**: "Actor configuration schema", "API endpoints"
+- **Use**: Complete parameter lists, type definitions, return values
+
+## Skill-specific checklist
+
+Before finalizing documentation, verify these doc-write-specific items:
+
+- [ ] Structure matches documentation type (tutorial/guide/reference)
+- [ ] Introduction clearly states what the user will learn
+- [ ] Prerequisites are listed if needed
+- [ ] Code examples are complete and tested
+- [ ] Each step in tutorials has clear instructions
+- [ ] Related documentation is linked
+- [ ] No assumptions made about product features (ask if unsure)
+
+For general quality standards, see `quality-standards.md`
+
+## Output
+
+Provide the complete documentation with proper formatting, ready to be committed to the repository.
diff --git a/.claude/skills/review-docs.md b/.claude/skills/review-docs.md
new file mode 100644
index 0000000000..1e368489d7
--- /dev/null
+++ b/.claude/skills/review-docs.md
@@ -0,0 +1,312 @@
+# Documentation review skill
+
+## Purpose
+
+Review documentation for compliance with Apify style guide, quality standards, and best practices.
+
+## When to use
+
+- Before submitting pull requests
+- During documentation audits
+- When editing existing documentation
+- To ensure consistency across documentation
+
+## Context files
+
+- `AGENTS.md` - Vendor-agnostic documentation standards
+- `CONTRIBUTING.md` - Contribution guidelines and workflows
+- `.claude/rules/` - Claude Code-specific standards (auto-loaded)
+
+## Standards reference
+
+This skill follows all standards defined in `.claude/rules/`:
+
+- **writing-style.md** - Language, tone, grammar (sentence case, no gerunds, active voice)
+- **content-standards.md** - Front matter, formatting, admonitions (must have titles), code examples, links, images
+- **terminology.md** - Apify-specific capitalization (Apify Actor not actor, the Apify platform)
+- **file-organization.md** - File naming and directory structure
+- **quality-standards.md** - Complete quality checklist
+
+**Review-specific process** and common issues are documented in this skill file below.
+
+## Review process
+
+### Before starting review
+
+**CRITICAL**: Check that the latest changes were pulled from the feature branch
+
+## Review checklist
+
+Use this streamlined checklist for reviews. For detailed standards, see `.claude/rules/`:
+
+### Writing quality
+
+- [ ] **Style guide compliance** (see `writing-style.md` + `content-standards.md`)
+  - Headings: Sentence case, no gerunds ("Create" not "Creating")
+  - Bold: ONLY for UI elements (not emphasis)
+  - Language: US English, active voice, inclusive, simple
+  - Terminology: Check `terminology.md` for exact capitalization
+
+- [ ] **Front matter** (see `content-standards.md`)
+  - `title` - Sentence case, simple present tense
+  - `description` - 140-160 chars, value-focused (not feature list)
+  - `slug` - Matches file path
+  - `sidebar_position` - Appropriate numbering
+
+- [ ] **Content structure**
+  - Clear introduction
+  - Proper heading hierarchy (H1 → H2 → H3, no skips)
+  - Logical topic progression
+  - Summary/next steps at end
+  - Related content linked
+
+### Content formatting
+
+- [ ] **Code examples** (see `content-standards.md`)
+  - Complete and runnable
+  - Language tag specified (REQUIRED)
+  - Realistic examples
+  - Code tabs for multiple languages
+  - **Review scope**: Comments and obvious mistakes only (not full code review)
+
+- [ ] **Links** (see `content-standards.md`)
+  - Descriptive text (not "click here")
+  - Internal links use relative paths
+  - External links point to reliable sources
+  - Link text makes sense out of context
+
+- [ ] **Images** (see `content-standards.md`)
+  - Meaningful alt text
+  - Light theme for screenshots
+  - Red indicators for highlighting
+  - Stored in proper directory structure
+
+- [ ] **Admonitions** (see `content-standards.md`)
+  - **MUST have a title** (REQUIRED - no exceptions)
+  - Appropriate type (note/tip/info/caution/danger)
+  - Not overused (max 2-3 per page)
+
+### Technical validation
+
+- [ ] **Technical accuracy**
+  - Code examples tested and working
+  - API endpoints current
+  - Version numbers up to date
+  - No deprecated features recommended
+
+- [ ] **Accessibility**
+  - Proper heading hierarchy
+  - Descriptive link text
+  - Alt text for images
+  - Color not sole indicator
+
+- [ ] **SEO optimization**
+  - Descriptive, unique title
+  - Meta description 140-160 chars
+  - Internal linking to related content
+  - Keywords used naturally
+
+- [ ] **Content-type specific checks**
+  - **Tutorials** (see `tutorial.md` skill): Clear learning objectives, prerequisites listed, sequential numbered steps, summary and next steps
+  - **API docs** (see `api-doc.md` skill): Operation IDs follow conventions, all parameters documented, code samples included (JS, Python, cURL), error responses documented
+  - **Reference pages**: Comprehensive parameter tables, default values specified, type information included
+
+## How to review
+
+### Step 1: Automated checks
+
+```bash
+npm run lint:md        # Markdownlint - Markdown syntax/formatting
+npm run lint:code      # ESLint - Code linting
+vale sync             # Vale - Prose style checking (optional)
+
+```
+
+### Step 2: Manual review
+
+Go through each section of the checklist above, noting any issues.
+
+### Step 3: Provide feedback
+
+**Format your review as**:
+
+```markdown
+## Documentation review: [File name]
+
+### ✅ Strengths
+
+- [What's done well]
+
+### ⚠️ Issues found
+
+#### Style guide
+
+- [ ] Issue 1: [Description]
+
+  - Current: [Example]
+
+  - Suggested: [Better example]
+
+#### Content
+
+- [ ] Issue 2: [Description]
+
+### 📝 Suggestions
+
+- [Optional improvement 1]
+
+- [Optional improvement 2]
+
+### 🎯 Priority issues
+
+1. [Critical issue to fix]
+
+2. [Important issue to fix]
+
+```
+
+## Common issues
+
+### Issue: Title case or gerund headings
+
+```markdown
+# ❌ Bad - Title Case
+## How to create an Actor
+
+# ❌ Bad - Gerund
+## Creating an Actor
+
+# ✅ Good - Sentence case, simple present tense
+## How to create an Actor
+
+# ✅ Good - Simple present tense
+## Create an Actor
+
+```
+
+### Issue: Non-descriptive links
+
+```markdown
+# ❌ Bad
+
+To learn more, click [here](link).
+
+# ✅ Good
+
+Learn more about [Actor input schemas](/actors/development/input-schema).
+
+```
+
+### Issue: Missing front matter description
+
+```markdown
+# ❌ Bad
+
+---
+
+title: "Actors"
+
+---
+
+# ✅ Good
+
+---
+
+title: "Create an Actor"
+description: "Learn how to build and deploy your first Actor with step-by-step instructions covering setup, development, and testing."
+
+---
+
+```
+
+### Issue: Long description or feature-focused
+
+```markdown
+# ❌ Bad - Too long (190 chars) and feature-focused
+
+description: "This comprehensive documentation guide will teach you everything you need to know about creating, configuring, and deploying Actors on the Apify platform from start to finish."
+
+# ❌ Bad - Feature-focused, not value-focused
+
+description: "Documentation for Actor creation, configuration options, and deployment methods."
+
+# ✅ Good - Value-focused (145 chars)
+
+description: "Build and deploy Actors efficiently with this guide covering setup, development, testing, and best practices for production use."
+
+```
+
+### Issue: Bold for emphasis
+
+```markdown
+# ❌ Bad - bold used for emphasis
+
+Click the button and **ensure you verify** the settings.
+
+# ✅ Good - bold only for UI elements
+
+Click the **Save & Run** button and ensure you verify the settings.
+
+```
+
+### Issue: Missing admonition title
+
+```markdown
+# ❌ Bad - no title (REQUIRED)
+
+:::tip
+Use pagination for large datasets.
+:::
+
+# ✅ Good - has title
+
+:::tip Performance best practice
+Use pagination for large datasets.
+:::
+
+```
+
+### Issue: Incorrect Apify terminology
+
+```markdown
+# ❌ Bad
+
+The Apify Console allows you to manage your Apify actors.
+
+# ✅ Good
+
+Apify Console allows you to manage your Apify Actors.
+
+```
+
+## Output format
+
+Provide a structured review using the format above, with:
+
+- Clear identification of issues
+
+- Specific examples from the content
+
+- Concrete suggestions for improvement
+
+- Priority ranking of issues
+
+## Quality standards
+
+A document is ready for publication when:
+
+- All checklist items pass
+
+- Automated linting passes
+
+- Content is technically accurate
+
+- Examples are tested and working
+
+- Style guide is followed consistently
+
+- No broken links
+
+- Proper front matter included
+
+- Accessibility standards met
diff --git a/.claude/skills/tutorial.md b/.claude/skills/tutorial.md
new file mode 100644
index 0000000000..a5b0210a07
--- /dev/null
+++ b/.claude/skills/tutorial.md
@@ -0,0 +1,336 @@
+# Tutorial creator skill
+
+## Purpose
+
+Create comprehensive, structured tutorials for the Apify Academy or Platform documentation.
+
+## When to use
+
+- Creating new tutorials
+- Restructuring existing tutorials
+- Converting informal guides into proper tutorials
+- Building step-by-step learning content
+
+## Context files
+
+- `AGENTS.md` - Documentation standards
+- `CONTRIBUTING.md` - Style guide and contribution workflows
+- `.claude/rules/` - Claude Code-specific standards (auto-loaded)
+
+## Standards reference
+
+This skill follows all standards defined in `.claude/rules/`:
+
+- **writing-style.md** - Language, tone, grammar (US English, active voice, sentence case, simple present tense)
+- **content-standards.md** - Front matter, text formatting, admonitions (must have titles), code examples
+- **terminology.md** - Apify-specific capitalization (Apify Actor, the Apify platform)
+- **quality-standards.md** - General quality checklist
+
+**Tutorial-specific structure** and best practices are documented in this skill file below.
+
+## Tutorial structure
+
+### 1. Front matter
+
+```yaml
+
+---
+
+title: "Action-oriented tutorial title (sentence case, simple present tense)"
+description: "Explain value, not features - what will user achieve (140-160 chars)"
+sidebar_position: 1
+slug: /category/tutorial-name  # Must match file path
+
+---
+
+```
+
+**Important**:
+
+- Use sentence case, NOT Title Case
+
+- Use simple present tense: "Create an Actor" NOT "Creating an Actor"
+
+- Match slug to file path
+
+### 2. Introduction section
+
+**Purpose**: Hook the reader and explain what they'll learn
+
+**Template**:
+
+```markdown
+## [Tutorial title]
+
+**[Brief description of what the user will accomplish]**
+
+---
+
+[Opening paragraph explaining the problem/use case this tutorial addresses]
+
+## What you'll learn
+
+In this tutorial, you'll learn how to:
+
+- [Learning objective 1]
+
+- [Learning objective 2]
+
+- [Learning objective 3]
+
+By the end, you'll be able to [specific outcome].
+
+```
+
+### 3. Prerequisites section
+
+**Purpose**: Set expectations for required knowledge and setup
+
+**Template**:
+
+```markdown
+## Prerequisites
+
+Before starting this tutorial, make sure you have:
+
+- [ ] [Required knowledge/skill 1]
+
+- [ ] [Required tool/account 2]
+
+- [ ] [Required setup 3]
+
+**Time estimate**: [X] minutes
+
+```
+
+### 4. Step-by-step instructions
+
+**Purpose**: Guide users through the process clearly and systematically
+
+**Guidelines**:
+
+- Use numbered lists for sequential steps
+
+- Start each step with an action verb
+
+- Include code examples for each major step
+
+- Add screenshots where helpful
+
+- Explain what each step accomplishes
+
+**Template**:
+
+```markdown
+## Step 1: [Action verb] [what to do]
+
+[Brief explanation of what this step accomplishes]
+
+1. [First sub-step]
+
+2. [Second sub-step]
+
+​```language
+// Code example with comments
+const example = "code";
+​```
+
+**Expected result**: [What should happen after this step]
+
+:::tip
+[Helpful tip related to this step]
+:::
+```
+
+### 5. Code examples section
+
+**Purpose**: Provide complete, working code that users can run
+
+**Guidelines**:
+
+- Include complete, runnable examples
+
+- Use code tabs for multiple languages
+
+- Add comprehensive comments
+
+- Show both input and output
+
+- Explain key parts of the code
+
+**Template**:
+
+```markdown
+## Complete example
+
+Here's the complete code for this tutorial:
+
+<Tabs>
+<TabItem value="js" label="JavaScript">
+
+​```javascript
+// Complete JavaScript example
+// Comments explaining key sections
+const example = "working code";
+​```
+
+</TabItem>
+<TabItem value="py" label="Python">
+
+​```python
+"""Complete Python example with comments explaining key sections"""
+example = "working code"
+​```
+
+</TabItem>
+</Tabs>
+```
+
+### 6. Testing/verification section
+
+**Purpose**: Help users verify their implementation works
+
+**Template**:
+
+```markdown
+## Testing your solution
+
+To verify everything works correctly:
+
+1. [Test step 1]
+
+2. [Test step 2]
+
+**Expected output**:
+
+​```text
+[What the user should see]
+​```
+
+:::note
+If you see [common error], check [solution].
+:::
+```
+
+### 7. Troubleshooting section
+
+**Purpose**: Address common issues users might encounter
+
+**Template**:
+
+```markdown
+## Troubleshooting
+
+### [Common problem 1]
+
+**Symptom**: [What the user sees]
+
+**Solution**: [How to fix it]
+
+### [Common problem 2]
+
+**Symptom**: [What the user sees]
+
+**Solution**: [How to fix it]
+
+```
+
+### 8. Summary/next steps
+
+**Purpose**: Reinforce learning and guide users forward
+
+**Template**:
+
+```markdown
+## Summary
+
+In this tutorial, you learned how to:
+
+- ✅ [Accomplishment 1]
+
+- ✅ [Accomplishment 2]
+
+- ✅ [Accomplishment 3]
+
+## Next steps
+
+Now that you've completed this tutorial, you can:
+
+- [Related tutorial/topic 1] - [Link]
+
+- [Related tutorial/topic 2] - [Link]
+
+- [Advanced topic] - [Link]
+
+## Additional resources
+
+- [Related documentation link 1]
+
+- [Related documentation link 2]
+
+- [External resource link]
+
+```
+
+## Tutorial types
+
+### Platform tutorial
+
+**Focus**: How to use Apify platform features
+**Location**: `/sources/platform/`
+**Style**: Practical, feature-focused
+
+### Academy tutorial
+
+**Focus**: Teaching web scraping or automation concepts
+**Location**: `/sources/academy/tutorials/`
+**Style**: Educational, concept-focused
+
+### Integration tutorial
+
+**Focus**: Connecting Apify with other tools
+**Location**: `/sources/platform/integrations/`
+**Style**: Step-by-step integration guide
+
+## Tutorial best practices
+
+1. **Start Simple**: Begin with basic concepts before advanced topics
+
+2. **Be Specific**: Use concrete examples rather than abstract explanations
+
+3. **Show, Don't Tell**: Include visual aids and code examples
+
+4. **Test Everything**: Ensure all code examples work
+
+5. **Anticipate Questions**: Address common points of confusion
+
+6. **Link Related Content**: Connect to other relevant tutorials
+
+7. **Keep Updated**: Mark tutorials with last-updated dates
+
+8. **User Perspective**: Write from the user's point of view
+
+9. **Never Make Assumptions**: About product features - ask if unsure
+
+10. **Use Simple English**: Prefer "use" over "utilize"
+
+## Tutorial-specific quality checklist
+
+Before publishing, verify these tutorial-specific items:
+
+- [ ] Clear learning objectives stated in introduction
+- [ ] Prerequisites clearly listed with time estimate
+- [ ] All steps are numbered and start with action verbs
+- [ ] Code examples are complete, tested, and runnable
+- [ ] Screenshots included where helpful (light theme, red indicators)
+- [ ] Expected results shown after each major step
+- [ ] Common issues addressed in troubleshooting section
+- [ ] Summary lists what user accomplished
+- [ ] Next steps and related content linked
+- [ ] Tutorial type matches content (platform/academy/integration)
+
+For general quality standards (front matter, formatting, terminology, language), see `quality-standards.md`
+
+## Output
+
+Provide a complete tutorial following the structure above, ready to be added to the documentation.
diff --git a/.cursor/rules/file-organization.mdc b/.cursor/rules/file-organization.mdc
deleted file mode 100644
index 55cee71f1f..0000000000
--- a/.cursor/rules/file-organization.mdc
+++ /dev/null
@@ -1,26 +0,0 @@
----
-description: File naming conventions and directory structure standards
-globs: ["sources/**/*"]
-alwaysApply: true
----
-
-# File Organization Rules
-
-## Naming conventions
-
-- Use **kebab-case** for file names: `web-scraping-basics.md`
-- Use **descriptive names** that reflect content
-- Group related files in **logical directories**
-
-## Directory structure
-
-```text
-sources/
-├── platform/          # Platform documentation
-│   ├── actors/        # Actor-related content
-│   ├── storage/       # Storage documentation
-│   └── integrations/  # Integration guides
-└── academy/           # Educational content
-    ├── tutorials/     # Step-by-step guides
-    ├── webscraping/   # Web scraping courses
-```
diff --git a/.cursor/rules/file-organization.mdc b/.cursor/rules/file-organization.mdc
new file mode 120000
index 0000000000..b434263850
--- /dev/null
+++ b/.cursor/rules/file-organization.mdc
@@ -0,0 +1 @@
+../../.claude/rules/file-organization.md
\ No newline at end of file
diff --git a/.cursor/rules/quality-standards.mdc b/.cursor/rules/quality-standards.mdc
deleted file mode 100644
index dbc3d6c6f1..0000000000
--- a/.cursor/rules/quality-standards.mdc
+++ /dev/null
@@ -1,20 +0,0 @@
----
-description: Content quality checklist and review standards
-globs: ["sources/**/*.md", "sources/**/*.mdx"]
-alwaysApply: true
----
-
-# Quality Standards
-
-## Content quality guidelines
-
-When creating or editing content, ensure:
-
-- [ ] Content follows Microsoft style guide (sentence case headings, proper emphasis)
-- [ ] Front matter includes proper title, description, and metadata
-- [ ] Code examples are complete and include proper syntax highlighting
-- [ ] All links use descriptive text (avoid "click here")
-- [ ] Images include meaningful alt text
-- [ ] Content uses inclusive language and active voice
-- [ ] Headings follow proper hierarchy (H1 → H2 → H3)
-- [ ] Content is clear, concise, and action-oriented
diff --git a/.cursor/rules/quality-standards.mdc b/.cursor/rules/quality-standards.mdc
new file mode 120000
index 0000000000..a7640b2aa0
--- /dev/null
+++ b/.cursor/rules/quality-standards.mdc
@@ -0,0 +1 @@
+../../.claude/rules/quality-standards.md
\ No newline at end of file
diff --git a/.cursor/rules/writing-style.mdc b/.cursor/rules/writing-style.mdc
new file mode 120000
index 0000000000..502fd404ed
--- /dev/null
+++ b/.cursor/rules/writing-style.mdc
@@ -0,0 +1 @@
+../../.claude/rules/writing-style.md
\ No newline at end of file
diff --git a/.github/workflows/vale.yaml b/.github/workflows/vale.yaml
index 8a626e0f0e..89cbc8fffc 100644
--- a/.github/workflows/vale.yaml
+++ b/.github/workflows/vale.yaml
@@ -23,6 +23,8 @@ jobs:
                         apify-api/openapi/paths/README.md
                         apify-api/openapi/components/README.md
                         sources/legal/**/*.{md,mdx}
+                        .claude/rules/**/*.{md,mdx}
+                        .cursor/rules/**/*.{md,mdx}
                     separator: ','
 
             -   uses: errata-ai/vale-action@reviewdog
diff --git a/.markdownlintignore b/.markdownlintignore
index dd87e2d73f..87b70a4bce 100644
--- a/.markdownlintignore
+++ b/.markdownlintignore
@@ -1,2 +1,3 @@
 node_modules
 build
+.claude
diff --git a/.vale.ini b/.vale.ini
index 282c31ca5a..b41626451e 100644
--- a/.vale.ini
+++ b/.vale.ini
@@ -32,3 +32,7 @@ Microsoft.GeneralURL = NO
 
 [{README.md,CONTRIBUTING.md}]
 Apify.H1 = NO
+
+[.claude/**/*.md]
+# Ignore all Vale checks in .claude directory (infrastructure docs)
+BasedOnStyles =