@output.ai/cli 0.5.6 → 0.6.0

package/dist/templates/agent_instructions/commands/debug_workflow.md.template

@@ -1,198 +0,0 @@
----
-argument-hint: [problem-description-and-optional-workflow-id]
-description: Debug Output SDK workflow issues
-version: 0.0.1
-model: claude-opus-4-1
----
-
-Your task is to systematically debug an Output SDK workflow issue in a local development environment.
-
-The first argument is a textual description of the problem you're experiencing. If you have a specific workflow ID, include it in your description.
-
-Use the todo tool to track your progress through the debugging process.
-
-# Debugging Process
-
-## Overview
-
-Follow a systematic approach to identify and resolve workflow execution issues: verify infrastructure, gather evidence, analyze traces, and apply targeted fixes.
-
-<pre_flight_check>
-  EXECUTE: @.outputai/instructions/meta/pre_flight.md
-</pre_flight_check>
-
-<process_flow>
-
-<step number="1" name="verify_services">
-
-### Step 1: Verify Services Running
-
-Before debugging, confirm that all required services are operational. The `output-services-check` skill provides comprehensive guidance.
-
-<verification_commands>
-```bash
-# Check Docker containers are running
-docker ps | grep output
-
-# Verify Output services respond
-curl -s http://localhost:3001/health || echo "API not responding"
-
-# Check Temporal UI is accessible
-curl -s http://localhost:8080 > /dev/null && echo "Temporal UI accessible" || echo "Temporal UI not accessible"
-```
-</verification_commands>
-
-<decision_tree>
-  IF docker_not_running:
-    RUN: docker compose up -d
-    WAIT: for services to start (30-60 seconds)
-  IF output_dev_not_running:
-    RUN: npx output dev
-    WAIT: for services to initialize
-  IF all_services_running:
-    PROCEED: to step 2
-</decision_tree>
-
-**Expected State**:
-- Docker containers for `output` are running
-- API server responds at `http://localhost:3001`
-- Temporal UI accessible at `http://localhost:8080`
-
-</step>
-
-<step number="2" name="list_workflow_runs">
-
-### Step 2: List Workflow Runs
-
-Identify the failing workflow execution by listing recent runs. The `output-workflow-runs-list` skill provides detailed filtering guidance.
-
-<list_commands>
-```bash
-# List all recent workflow runs
-npx output workflow runs list
-
-# Filter by specific workflow type (if known)
-npx output workflow runs list <workflowName>
-
-# Get detailed JSON output for analysis
-npx output workflow runs list --format json
-
-# Limit results to most recent
-npx output workflow runs list --limit 10
-```
-</list_commands>
-
-<identification_criteria>
-Look for:
-- Status: FAILED or TERMINATED
-- Recent timestamp matching when the issue occurred
-- Workflow type matching the problem description
-</identification_criteria>
-
-<decision_tree>
-  IF user_provided_workflow_id:
-    USE: provided workflow ID
-    PROCEED: to step 3
-  IF failed_runs_found:
-    SELECT: most recent failed run
-    NOTE: workflow ID from output
-    PROCEED: to step 3
-  IF no_runs_found:
-    CHECK: workflow exists with `npx output workflow list`
-    IF workflow_not_found:
-      REPORT: workflow doesn't exist
-      SUGGEST: verify workflow name and location
-    ELSE:
-      SUGGEST: run the workflow with `npx output workflow run <name>`
-</decision_tree>
-
-</step>
-
-<step number="3" name="debug_workflow" subagent="workflow-debugger">
-
-### Step 3: Debug Specific Workflow
-
-Retrieve and analyze the execution trace for the identified workflow. The `output-workflow-trace` skill provides analysis techniques.
-
-<debug_commands>
-```bash
-# Display execution trace (text format)
-npx output workflow debug <workflowId>
-
-# Display full untruncated trace (JSON format) - recommended for detailed analysis
-npx output workflow debug <workflowId> --format json
-```
-</debug_commands>
-
-**Tip**: Use `--format json` for complete trace data without truncation.
-
-<analysis_checklist>
-1. Identify which step failed
-2. Examine the error message and stack trace
-3. Check input data passed to the failing step
-4. Check output data from preceding steps
-5. Look for patterns matching common error types
-</analysis_checklist>
-
-<temporal_ui_guidance>
-For visual workflow inspection, open the Temporal Web UI at **http://localhost:8080**:
-- Find your workflow execution by ID
-- View the event history timeline
-- Inspect individual step inputs and outputs
-</temporal_ui_guidance>
-
-</step>
-
-<step number="4" name="suggest_fixes" subagent="workflow-quality">
-
-### Step 4: Suggest Fixes
-
-Based on the trace analysis, identify the error pattern and suggest targeted fixes. Claude will invoke the relevant error skill based on symptoms.
-
-<error_matching>
-
-| Symptom | Skill |
-|---------|-------|
-| "incompatible schema" errors, type errors | `output-error-zod-import` |
-| Replay failures, inconsistent results | `output-error-nondeterminism` |
-| Retries not working, errors swallowed | `output-error-try-catch` |
-| Type errors, undefined properties at step boundaries | `output-error-missing-schemas` |
-| Workflow hangs, determinism errors | `output-error-direct-io` |
-| Untraced requests, axios errors | `output-error-http-client` |
-
-</error_matching>
-
-<decision_tree>
-  IF error_matches_known_pattern:
-    INVOKE: relevant error skill for detailed fix
-  ELSE:
-    CONSULT: workflow-quality subagent for additional patterns
-    SUGGEST: Manual trace inspection in Temporal UI
-</decision_tree>
-
-<verification>
-After applying fix:
-```bash
-# Re-run the workflow to verify
-npx output workflow run <workflowName> <input>
-
-# Or start asynchronously and check result
-npx output workflow start <workflowName> <input>
-npx output workflow status <workflowId>
-npx output workflow result <workflowId>
-```
-</verification>
-
-</step>
-
-</process_flow>
-
-<post_flight_check>
-  EXECUTE: @.outputai/instructions/meta/post_flight.md
-</post_flight_check>
-
----- START ----
-
-Problem Description and Optional Workflow ID:
-
-$ARGUMENTS

package/dist/templates/agent_instructions/commands/plan_workflow.md.template

@@ -1,261 +0,0 @@
----
-argument-hint: [workflow-description-and-additional-instructions]
-description: Workflow Planning Command for Output SDK
-version: 0.0.1
-model: claude-opus-4-1
----
-
-Your task is to generate a comprehensive Output.ai workflow implementation plan in markdown format.
-
-The plan will be displayed to the user who can then decide what to do with it.
-
-Please respond with only the final version of the plan.
-
-Use the todo tool to track your progress through the plan creation process.
-
-# Plan Creation Rules
-
-## Overview
-
-Generate detailed specifications for implementation of a new workflow.
-
-<pre_flight_check>
-  EXECUTE: @.outputai/instructions/meta/pre_flight.md
-</pre_flight_check>
-
-<process_flow>
-
-<step number="1" name="context_gathering" subagent="workflow-context-fetcher">
-
-### Step 1: Context Gathering
-
-Take the time to gather all the context you need to create a comprehensive plan.
-1. Read any given files or links
-2. Find any related workflows in the project
-3. Read the projects documentation files
-
-</step>
-
-<step number="2" name="requirements_clarification">
-
-### Step 2: Requirements Clarification
-
-Clarify scope boundaries and technical considerations by asking numbered questions as needed to ensure clear requirements before proceeding.
-
-<clarification_areas>
-  <scope>
-    - in_scope: what is included
-    - out_of_scope: what is excluded (optional)
-  </scope>
-  <technical>
-    - functionality specifics
-    - UI/UX requirements
-    - integration points
-  </technical>
-</clarification_areas>
-
-<decision_tree>
-  IF clarification_needed:
-    ASK numbered_questions
-    WAIT for_user_response
-  ELSE:
-    PROCEED schema_definition
-</decision_tree>
-</step>
-
-<step number="3" name="workflow_design" subagent="workflow-quality">
-
-### Step 3: Workflow Design
-
-Design the workflow with clear single purpose steps and sound orchestration logic.
-
-<thought_process>
-
-  1. Define the workflow name and description
-  2. What is a valid output schema for the workflow?
-  3. What is a valid input schema for the workflow?
-  4. What needs to happen to transform the input into the output?
-  5. What are the atomic steps that need to happen to transform the input into the output?
-  6. How do these steps relate to each other?
-  7. Are any of these steps conditional?
-  8. Are any of these steps already defined in the project?
-  9. How could these steps fail, and how should we handle them? (retry, backoff, etc.)
-
-</thought_process>
-
-<workflow_template>
-```typescript
-import { workflow, z } from '@output.ai/core';
-import { sumValues } from './steps.js';
-
-const inputSchema = z.object( {
-  values: z.array( z.number() )
-} );
-
-const outputSchema = z.object( {
-  result: z.number()
-} );
-
-export default workflow( {
-  name: 'simple',
-  description: 'A simple workflow',
-  inputSchema,
-  outputSchema,
-  fn: async input => {
-    const result = await sumValues( input.values );
-    return { result };
-  }
-} );
-```
-</workflow_template>
-
-<step number="4" name="step_design" subagent="workflow-quality">
-### Step 4: Step Design
-
-Design the steps with clear boundaries.
-
-<step_template>
-```typescript
-import { step, z } from '@output.ai/core';
-
-export const sumValues = step( {
-  name: 'sumValues',
-  description: 'Sum all values',
-  inputSchema: z.array( z.number() ),
-  outputSchema: z.number(),
-  fn: async numbers => numbers.reduce( ( v, n ) => v + n, 0 )
-} );
-```
-</step_template>
-
-</step>
-
-<step number="5" name="prompt_engineering" subagent="workflow-prompt-writer">
-
-### Step 5: Prompt Engineering
-
-If any of the steps use an LLM, design the prompts for the steps.
-
-<decision_tree>
-  IF step_uses_llm:
-    USE prompt_step_template
-  ELSE:
-    SKIP to step 6
-</decision_tree>
-
-<prompt_step_template>
-```typescript
-import { step, z } from '@output.ai/core';
-import { generateText } from '@output.ai/llm';
-
-export const aiSdkPrompt = step( {
-  name: 'aiSdkPrompt',
-  description: 'Generates a prompt',
-  inputSchema: z.object( {
-    topic: z.string()
-  } ),
-  outputSchema: z.string(),
-  fn: async ( { topic } ) => {
-    const response = await generateText( {
-      prompt: 'prompt@v1',
-      variables: { topic }
-    } );
-    return response;
-  }
-} );
-
-export const finalStep = step( {
-  name: 'finalStep',
-  outputSchema: z.boolean(),
-  fn: async () => true
-} );
-
-```
-</prompt_step_template>
-
-<prompt_template>
-```
----
-provider: anthropic
-model: claude-sonnet-4-20250514
-temperature: 0.7
----
-
-<assistant>
-You are a concise assistant.
-</assistant>
-
-<user>
-Explain about "{{ topic }}"
-</user>
-
-```
-
-</prompt_template>
-
-</step>
-
-<step number="6" name="testing_strategy">
-
-### Step 6: Testing Strategy
-
-Design the testing strategy for the workflow.
-<thought_process>
-  1. What unit tests do we need to write?
-  2. How can I run the workflow?
-  3. What cases do we need to validate?
-</thought_process>
-
-</step>
-
-<step number="7" name="generate_plan">
-### Step 7: Generate Plan
-
-Generate the complete plan in markdown format.
-
-Note that every implementation should start with running the cli command `npx output workflow generate --skeleton` to create the workflow directory structure.
-
-<file_template>
-  <header>
-    # Workflow Requirements Document
-
-    > Workflow: [WORKFLOW_NAME]
-    > Created: [CURRENT_DATE]
-  </header>
-  <required_sections>
-    - Overview
-    - Spec Scope
-    - Out of Scope
-    - Workflow Design
-    - Step Design
-    - Testing Strategy
-    - Implementation Phases
-  </required_sections>
-</file_template>
-
-</step>
-
-<step_number="8" name="post_flight_check">
-
-
-### Step 8: Post-Flight Check
-
-Verify the plan is complete and ready for implementation.
-
-<post_flight_check>
-  EXECUTE: @.outputai/instructions/meta/post_flight.md
-</post_flight_check>
-
-</step>
-
-</process_flow>
-
-<post_flight_check>
-  EXECUTE: @.outputai/instructions/meta/post_flight.md
-</post_flight_check>
-
----- START ----
-
-Workflow Description and Additional Instructions:
-
-$ARGUMENTS

package/dist/templates/agent_instructions/meta/post_flight.md.template

@@ -1,94 +0,0 @@
----
-description: Post-Flight Validation for Output SDK Workflow Operations
-version: 1.0
-encoding: UTF-8
----
-
-# 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 (@flowsdk/core, @flowsdk/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
-
-#### 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

package/dist/templates/agent_instructions/meta/pre_flight.md.template

@@ -1,60 +0,0 @@
----
-description: Pre-Flight Checks for Output SDK Workflow Operations
-version: 1.0
-encoding: UTF-8
----
-
-# 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 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 @output.ai/http wrapper
-- **LLM Client**: NEVER use a direct llm call - always use @output.ai/llm wrapper
-- **Worker Restarts**: Remember to restart worker after creating workflows: `overmind restart worker`
-- **Documentation**: Run `yarn g:workflow-doc` after modifications
-
-## 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)
-- **OpenAI Models**: Use `gpt-4o` unless specified otherwise
-- **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:
-  - `{{workflowName}}` - The workflow being planned
-  - `{{projectPath}}` - Root project directory path
-  - `{{requirements}}` - User-provided requirements
-  - `{{currentDate}}` - Current date in YYYY-MM-DD format
-  - `{{sdkVersion}}` - Current Output SDK version
-
-## Quality Gates
-
-Before proceeding past pre-flight:
-1. Confirm all required context is available
-2. Verify understanding of the workflow's purpose
-3. Check for existing similar workflows to use as patterns
-4. Ensure Output SDK conventions are understood
-5. Validate that necessary subagents are available