| name | output-meta-pre-flight |
| description | Pre-flight validation checks for Output SDK workflow operations. Ensures conventions are followed, requirements are gathered, and quality gates are passed before workflow execution. |
| allowed-tools | ["Read"] |
Pre-Flight Rules for Output SDK Workflows
Execution Requirements
- CRITICAL: For any step that specifies a subagent in the
subagent="" XML attribute, you MUST use the specified subagent to perform the instructions for that step
- Process all XML blocks sequentially and completely
- Execute every numbered step in the process_flow EXACTLY as specified
Output SDK Knowledge Check
Ensure you have a deep understanding of the Output SDK and its capabilities. If not, use Claude Skill: output-meta-project-context and read it carefully.
Output SDK Conventions Check
Before proceeding with any workflow operation, verify:
- ES Modules: All imports MUST use
.js extension for ESM modules
- HTTP Client: NEVER use axios directly - always use @outputai/http wrapper
- HTTP Bodies: Consume non-HEAD response bodies with
.json()/.text() or cancel unused bodies with
response.body?.cancel()
- LLM Client: NEVER use a direct llm call - always use @outputai/llm wrapper
- Worker Restarts:
npx output dev auto-restarts the worker on file changes; if the worker runs detached, restart it manually with docker restart <project>-worker-1
Requirements Gathering Strategy
Smart Defaults Application
When information is not explicitly provided, apply these defaults:
- Retry Policies: 3 attempts with exponential backoff (1s initial, 10s max)
- Model selection: Run
output-dev-model-selection to pick the current default for the chosen provider. Don't pin a specific model ID here — the listing changes faster than the docs.
- Error Handling: ApplicationFailure patterns with appropriate error types
- Performance: Optimize for clarity and maintainability over raw speed
- Timeouts: 30 seconds for activities, 5 minutes for workflows
Critical Information Requirements
Only stop to ask for clarification on:
- Ambiguous input/output structures that cannot be inferred from context
- Specific API keys or services not commonly used in the project
- Non-standard error handling or recovery requirements
- Complex orchestration patterns requiring specific sequencing
- External dependencies not already in the project
Template Processing Rules
- Use exact templates as provided in each step
- Replace all template variables with actual values:
{workflow_name} - The workflow being planned{project_root} - Root project directory path{requirements} - User-provided requirements{current_date} - Current date in YYYY-MM-DD format{sdk_version} - Current Output SDK version
Quality Gates
Before proceeding past pre-flight:
- Confirm all required context is available
- Verify understanding of the workflow's purpose
- Check for existing similar workflows to use as patterns
- Ensure Output SDK conventions are understood
- Validate that necessary subagents are available
Plan Creation Rules
- All complex tasks should be tracked in a workflow plan file
- These files should be created at .outputai/plans directory.
- If
.outputai/plans directory does not exist, create it.
- Ensure the plan folder is named with the date, then the workflow name, then the task name. e.g. 2025_12_16_simple_sum_workflow_creation_plan/PLAN.md
- Track the implementation progress of any plan in a TASK file in the plan folder. e.g. 2025_12_16_simple_sum_workflow_creation_plan/TASK.md
- Use markdown todo list to track the progress of the plan. e.g
