preflight
Webiny-only. Run all checks required before packages are ready for publish: deps, build, lint, format, tests.
Best use case
preflight is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Webiny-only. Run all checks required before packages are ready for publish: deps, build, lint, format, tests.
Teams using preflight should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/preflight/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How preflight Compares
| Feature / Agent | preflight | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Webiny-only. Run all checks required before packages are ready for publish: deps, build, lint, format, tests.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
AI Agents for Coding
Browse AI agent skills for coding, debugging, testing, refactoring, code review, and developer workflows across Claude, Cursor, and Codex.
AI Agents for Marketing
Discover AI agents for marketing workflows, from SEO and content production to campaign research, outreach, and analytics.
AI Agents for Startups
Explore AI agent skills for startup validation, product research, growth experiments, documentation, and fast execution with small teams.
SKILL.md Source
# Preflight
Webiny-only skill. Run all checks required before packages are ready for publish.
## Important
- Run steps in order.
- If any step fails, diagnose and fix the issue, then restart from step 1.
- Never run tests in parallel. Run each package sequentially.
- Before running tests for each package, count active test cases and shard at 32 tests per shard.
- To count active tests: `rg "^\s*(it|test|it\.each|test\.each)\s*\(" packages/<name>/__tests__ -t ts --count-matches | awk -F: '{s+=$2} END {print s}'`
- Calculate shards: `shards = ceil(count / 32)`. If shards is 1, no `--shard` flag needed.
- Suppress noisy output: redirect stdout to `/dev/null` or pipe through `tail` as needed.
## Steps
### 1. Install dependencies
```bash
yarn > /dev/null 2>&1
```
### 2. Sync dependency versions
```bash
yarn webiny sync-dependencies
```
Verify `packages/cli/files/duplicates.json` is an empty array (`[]`). If it contains entries, there are duplicate dependency versions that must be resolved before continuing.
### 3. Regenerate tsconfig files
```bash
node scripts/generateTsConfigsInPackages.js
```
### 4. Check package node_modules
```bash
node scripts/checkPackageNodeModules.js
```
### 5. Verify package.json dependencies match source imports
```bash
yarn adio
```
Must output "All dependencies in order!" to pass.
### 6. Format code
```bash
yarn prettier:fix > /dev/null 2>&1
```
This auto-fixes formatting issues. No manual intervention needed.
### 7. Lint
```bash
yarn eslint
```
This only checks — it does not auto-fix. If eslint reports errors, fix them manually, then restart from step 1.
### 8. Full clean build
```bash
yarn build --no-cache 2>&1 | tail -10
```
### 9. Check dist paths
```bash
node scripts/checkDistPaths.js
```
Verifies no `src/` paths remain in built output.
### 10. Run DDB tests
Run `yarn test` for each package below, sequentially. Count active tests first and shard at 32.
**Packages that need `yarn test`:**
- `api`
- `api-aco`
- `api-audit-logs`
- `api-core`
- `api-file-manager`
- `api-file-manager-aco`
- `api-headless-cms`
- `api-headless-cms-aco`
- `api-headless-cms-bulk-actions`
- `api-headless-cms-ddb`
- `api-headless-cms-import-export`
- `api-headless-cms-scheduler`
- `api-headless-cms-tasks`
- `api-headless-cms-workflows`
- `api-mailer`
- `api-record-locking`
- `api-scheduler`
- `api-sync-system`
- `api-website-builder`
- `api-website-builder-scheduler`
- `api-websockets`
- `api-workflows`
- `app-admin`
- `cognito`
- `db-dynamodb`
- `form`
- `handler`
- `handler-aws`
- `handler-graphql`
- `lexical-converter`
- `plugins`
- `react-composition`
- `react-properties`
- `react-rich-text-lexical-renderer`
- `tasks`
- `utils`
```bash
# 1. Count active tests
count=$(rg "^\s*(it|test|it\.each|test\.each)\s*\(" packages/<name>/__tests__ -t ts --count-matches | awk -F: '{s+=$2} END {print s}')
shards=$(( (count + 31) / 32 ))
# 2a. If shards <= 1, run without sharding
yarn test packages/<name> 2>&1 | grep "Test Files"
# 2b. If shards > 1, run each shard sequentially
yarn test packages/<name> --shard=1/$shards 2>&1 | grep "Test Files"
yarn test packages/<name> --shard=2/$shards 2>&1 | grep "Test Files"
# ... etc
```
### 11. Run OpenSearch tests
Run `yarn test:os` for each package below, sequentially. Count active tests first and shard at 32.
**Packages that need BOTH `yarn test` (step 10) AND `yarn test:os`:**
- `api-aco`
- `api-audit-logs`
- `api-file-manager`
- `api-file-manager-aco`
- `api-headless-cms`
- `api-headless-cms-aco`
- `api-headless-cms-bulk-actions`
- `api-headless-cms-import-export`
- `api-mailer`
- `api-scheduler`
- `api-workflows`
- `tasks`
**Packages that need ONLY `yarn test:os` (not in step 10):**
- `api-dynamodb-to-elasticsearch`
- `api-elasticsearch-tasks`
- `api-headless-cms-ddb-es`
- `api-headless-cms-es-tasks`
- `api-opensearch`
```bash
yarn test:os packages/<name> 2>&1 | grep "Test Files"
```
### 12. Check for uncommitted changes
```bash
git status
```
Report any unexpected uncommitted changes from the steps above.
## Keeping the package lists up to date
If the lists seem stale, re-derive them:
```bash
# All testable packages (have vitest.config.ts)
find packages -maxdepth 2 -name "vitest.config.ts" | sed 's|packages/||;s|/vitest.config.ts||' | sort
# Packages with ddb-os support
grep -rl "ddb-os" --include="ci.config.json" packages/ | sed 's|packages/||;s|/ci.config.json||' | sort
# Check if a package has standalone ddb tests too
grep -o '"ddb"' packages/<name>/ci.config.json
```Related Skills
webiny-v5-to-v6-migration
Migration patterns for converting v5 Webiny code to v6 architecture. Use this skill when migrating existing v5 plugins to v6 features, converting context plugins to DI services, adapting v5 event subscriptions to v6 EventHandlers, or understanding how v5 patterns translate to v6. Targeted at AI agents performing migrations.
webiny-api-permissions
Schema-based permission system for API features. Use this skill when implementing authorization in use cases, defining permission schemas with createPermissionSchema, creating injectable permissions via createPermissionsAbstraction/createPermissionsFeature, checking read/write/delete/publish permissions, handling own-record scoping, or testing permission scenarios. Covers the full pattern from schema definition to use case integration to test matrices.
webiny-admin-permissions
Admin-side permission UI registration and DI-backed permission checking. Use this skill when adding permission controls to the admin UI — schema-based auto-generated forms, injectable permissions via createPermissionsAbstraction/ createPermissionsFeature, typed hooks (createUsePermissions), the HasPermission component (createHasPermission), and the Security.Permissions component props. Covers both simple apps and complex multi-entity permission schemas.
webiny-sdk
Using @webiny/sdk to read and write CMS data from external applications. Use this skill when the developer is building a Next.js, Vue, Node.js, or any external app that needs to fetch or write content to Webiny, set up the SDK, use the Result pattern, list/get/create/update/publish entries, filter and sort queries, use TypeScript generics for type safety, work with the File Manager, or create API keys programmatically. Covers read vs preview mode, the `values` wrapper requirement, correct method names, and the `fields` required parameter.
webiny-project-structure
Webiny project layout, webiny.config.tsx anatomy, and extension registration. Use this skill when the developer asks about folder structure, where custom code goes, how to register extensions, what webiny.config.tsx does, or how the project is organized. Also use when they need to understand the relationship between extensions/, webiny.config.tsx, and the different extension types (Api, Admin, Infra, CLI).
webiny-local-development
Deploying, developing locally, managing environments, and debugging Webiny projects. Use this skill when the developer asks about deployment commands (deploy, destroy, info), local development with watch mode (API or Admin), the Local Lambda Development system, environment management (long-lived vs short-lived, production vs dev modes), build parameters, state files, debugging API/Admin/Infrastructure errors, or the redeploy-after-watch requirement.
webiny-infrastructure-extensions
Modifying AWS infrastructure using Pulumi handlers and declarative Infra components. Use this skill when the developer wants to customize AWS infrastructure, add Pulumi handlers, configure OpenSearch, VPC, resource tags, regions, custom domains, blue-green deployments, environment-conditional config, or manage production vs development infrastructure modes. Covers CorePulumi.Interface, all <Infra.*> declarative components, and <Infra.Env.Is>.
webiny-infra-catalog
Infrastructure — 33 abstractions. Infrastructure extensions.
webiny-extensions-catalog
extensions — 5 abstractions.
webiny-cli-command-catalog
cli/command — 1 abstractions.
webiny-cli-catalog
cli — 2 abstractions.
webiny-api-tenant-manager-catalog
API — Tenant Manager — 2 abstractions. Tenant management event handlers and use cases.