/output-meta-post-flight
Post-flight validation for Output SDK workflow operations. Systematic verification of step completion, convention compliance, quality validation, and deliverable verification.
$ npx -y skills add growthxai/output --skill output-meta-post-flight --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/output-meta-post-flight
Context preview
The summary Claude sees to decide when to auto-load this skill.
Post-flight validation for Output SDK workflow operations. Systematic verification of step completion, convention compliance, quality validation, and deliverable verification.
SKILL.md
output-meta-post-flight.SKILL.mdname: output-meta-post-flight
description: Post-flight validation for Output SDK workflow operations. Systematic verification of step completion, convention compliance, quality validation, and deliverable verification.
allowed-tools: [Read]
Post-Flight Rules for Output SDK Workflows
Execution Verification
After completing all steps in the process_flow, systematically verify:
Step Completion Audit
- [ ] Every numbered step has been read, executed, and delivered according to its instructions
- [ ] All steps that specified a subagent were delegated to the correct subagent
- [ ] If any subagent was not used as specified, document why and report to the user
- [ ] If any step was not executed according to instructions, explain which part was misread or skipped
Output SDK Convention Compliance
Verify the following conventions were followed:
Import Conventions
- [ ] All TypeScript/JavaScript imports use `.js` extension for ES modules
- [ ] No direct axios usage - HttpClient wrapper used throughout
- [ ] Proper import paths for Output SDK packages (@outputai/core, @outputai/llm, etc.)
Workflow Structure
- [ ] Workflow exported in entrypoint.ts: `export * from './path/to/workflow.js';`
- [ ] All external operations wrapped in Temporal activities (steps)
- [ ] Proper error handling with ApplicationFailure patterns
- [ ] Retry policies configured appropriately
Schema Placement
- [ ] All schemas for `Output.object()` defined in `types.ts`, not inline in step functions
- [ ] LLM output schemas use `.describe()` only -- no `.min()/.max()/.length()` on numbers or arrays
- [ ] Prompt files do not contain JSON output format instructions when `Output.object()` is used
LLM Provider & Variables
- [ ] All prompt files use the same provider (no mixing unless explicitly requested)
- [ ] `generateText`/`Agent` variables are `string | number | boolean` only -- no arrays or objects
Code Style (see `output-dev-code-style`)
- [ ] No trailing commas in any generated code
- [ ] No `let` declarations -- all variables use `const`
- [ ] Arrow functions use parens only when needed (multi-param or destructured)
- [ ] Operator linebreaks placed after the operator, not before
- [ ] Space in parens: `fn( x )` not `fn(x)`
Documentation & Testing
- [ ] Comprehensive plan document created with all required sections
- [ ] Testing strategy defined with specific test scenarios
- [ ] Implementation checklist provided for developers
- [ ] All code examples are complete and would compile
Quality Validation
Plan Completeness Check
Ensure the workflow plan includes:
- [ ] **Overview**: Clear purpose and use case definition
- [ ] **Technical Specifications**: Complete input/output schemas with Zod validation
- [ ] **Activity Definitions**: Each activity fully specified with purpose, I/O, and error handling
- [ ] **Prompt Engineering**: LLM prompts designed (if applicable) with template variables
- [ ] **Orchestration Logic**: Step-by-step workflow execution flow
- [ ] **Retry Policies**: Configured for each activity with appropriate timeouts
- [ ] **Testing Requirements**: Comprehensive test scenarios and commands
Implementation Readiness
Confirm the plan is ready for implementation:
- [ ] All schemas defined with exact field types and descriptions
- [ ] Every activity specified with input/output/processing logic
- [ ] External services identified with specific SDK client references
- [ ] Error handling complete for all failure scenarios
- [ ] Testing scenarios documented with expected outcomes
- [ ] Performance requirements clear with measurable criteria
Deliverable Verification
Required Outputs
Verify these deliverables were created or updated:
- [ ] Workflow plan document with full specifications
- [ ] Activity schemas with Zod validation
- [ ] Prompt templates (if LLM integration required)
- [ ] Testing strategy with specific commands
- [ ] Implementation checklist for developers
Next Steps Documentation
Ensure the following guidance is provided:
- [ ] Clear handoff to implementation phase
- [ ] Specific Output SDK CLI commands to execute
- [ ] Dependencies to install (if any)
- [ ] Configuration requirements documented
- [ ] Success criteria clearly defined
Error Reporting
If any issues were encountered: 1. Document the specific issue and step where it occurred 2. Explain any deviations from the planned process 3. Provide recommendations for resolution 4. Note any missing information that prevented completion
Final Validation
Before marking the workflow planning complete:
- [ ] Developer can implement without additional clarification
- [ ] All Output SDK patterns and conventions are followed
- [ ] Testing approach is comprehensive and executable
- [ ] Documentation is clear and complete
- [ ] Plan aligns with project's existing workflow patterns
Read more
name: output-meta-post-flight description: Post-flight validation for Output SDK workflow operations. Systematic verification of step completion, convention compliance, quality validation, and deliverable verification. allowed-tools: [Read]
Post-Flight Rules for Output SDK Workflows
Execution Verification
After completing all steps in the process_flow, systematically verify:
Step Completion Audit
- [ ] Every numbered step has been read, executed, and delivered according to its instructions
- [ ] All steps that specified a subagent were delegated to the correct subagent
- [ ] If any subagent was not used as specified, document why and report to the user
- [ ] If any step was not executed according to instructions, explain which part was misread or skipped
Output SDK Convention Compliance
Verify the following conventions were followed:
Import Conventions
- [ ] All TypeScript/JavaScript imports use `.js` extension for ES modules
- [ ] No direct axios usage - HttpClient wrapper used throughout
- [ ] Proper import paths for Output SDK packages (@outputai/core, @outputai/llm, etc.)
Workflow Structure
- [ ] Workflow exported in entrypoint.ts: `export * from './path/to/workflow.js';`
- [ ] All external operations wrapped in Temporal activities (steps)
- [ ] Proper error handling with ApplicationFailure patterns
- [ ] Retry policies configured appropriately
Schema Placement
- [ ] All schemas for `Output.object()` defined in `types.ts`, not inline in step functions
- [ ] LLM output schemas use `.describe()` only -- no `.min()/.max()/.length()` on numbers or arrays
- [ ] Prompt files do not contain JSON output format instructions when `Output.object()` is used
LLM Provider & Variables
- [ ] All prompt files use the same provider (no mixing unless explicitly requested)
- [ ] `generateText`/`Agent` variables are `string | number | boolean` only -- no arrays or objects
Code Style (see `output-dev-code-style`)
- [ ] No trailing commas in any generated code
- [ ] No `let` declarations -- all variables use `const`
- [ ] Arrow functions use parens only when needed (multi-param or destructured)
- [ ] Operator linebreaks placed after the operator, not before
- [ ] Space in parens: `fn( x )` not `fn(x)`
Documentation & Testing
- [ ] Comprehensive plan document created with all required sections
- [ ] Testing strategy defined with specific test scenarios
- [ ] Implementation checklist provided for developers
- [ ] All code examples are complete and would compile
Quality Validation
Plan Completeness Check
Ensure the workflow plan includes:
- [ ] **Overview**: Clear purpose and use case definition
- [ ] **Technical Specifications**: Complete input/output schemas with Zod validation
- [ ] **Activity Definitions**: Each activity fully specified with purpose, I/O, and error handling
- [ ] **Prompt Engineering**: LLM prompts designed (if applicable) with template variables
- [ ] **Orchestration Logic**: Step-by-step workflow execution flow
- [ ] **Retry Policies**: Configured for each activity with appropriate timeouts
- [ ] **Testing Requirements**: Comprehensive test scenarios and commands
Implementation Readiness
Confirm the plan is ready for implementation:
- [ ] All schemas defined with exact field types and descriptions
- [ ] Every activity specified with input/output/processing logic
- [ ] External services identified with specific SDK client references
- [ ] Error handling complete for all failure scenarios
- [ ] Testing scenarios documented with expected outcomes
- [ ] Performance requirements clear with measurable criteria
Deliverable Verification
Required Outputs
Verify these deliverables were created or updated:
- [ ] Workflow plan document with full specifications
- [ ] Activity schemas with Zod validation
- [ ] Prompt templates (if LLM integration required)
- [ ] Testing strategy with specific commands
- [ ] Implementation checklist for developers
Next Steps Documentation
Ensure the following guidance is provided:
- [ ] Clear handoff to implementation phase
- [ ] Specific Output SDK CLI commands to execute
- [ ] Dependencies to install (if any)
- [ ] Configuration requirements documented
- [ ] Success criteria clearly defined
Error Reporting
If any issues were encountered: 1. Document the specific issue and step where it occurred 2. Explain any deviations from the planned process 3. Provide recommendations for resolution 4. Note any missing information that prevented completion
Final Validation
Before marking the workflow planning complete:
- [ ] Developer can implement without additional clarification
- [ ] All Output SDK patterns and conventions are followed
- [ ] Testing approach is comprehensive and executable
- [ ] Documentation is clear and complete
- [ ] Plan aligns with project's existing workflow patterns
The open-source TypeScript framework for building AI workflows and agents. Designed for Claude Code — describe what you want, Claude builds it, with all the best practices already in place. One framework.
Repo: growthxai/output
Other skills on output.
- /llm-output-schema-constraints
Zod schema constraints that Anthropic rejects or silently ignores when sent as structured-output tool definitions via Output.object(). Use when writing or reviewing Zod schemas passed to Output.object(), or debugging structured-output validation errors.
Open skill - /prompt-file-provider-options
Guide to the providerOptions structure in .prompt files — decision tree for where an option goes, common mistakes, per-provider quick reference, and Anthropic prompt caching. Use when writing or reviewing .prompt file frontmatter (provider, model, providerOptions,
Open skill - /validate
Run lint, build, and tests to validate changes are correct
Open skill - /output-build-workflow
Implement an Output SDK workflow from a plan document. Use when the user asks to build, implement, or code a workflow from an existing plan, or after output-plan-workflow has produced a plan and the user is ready to build.
Open skill - /output-credentials-edit
View and edit encrypted credentials in an Output.ai project. Use when adding secrets, updating API keys, verifying credential values, or retrieving a specific credential.
Open skill - /output-credentials-env-vars
Wire encrypted credentials to environment variables using the credential: convention. Use when setting up LLM provider keys (ANTHROPIC_API_KEY, OPENAI_API_KEY) or any env var that should come from encrypted credentials.
Open skill

