@output.ai/cli 0.0.1 → 0.0.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +44 -12
- package/dist/api/generated/api.d.ts +13 -13
- package/dist/api/generated/api.js +1 -1
- package/dist/commands/agents/init.d.ts +18 -0
- package/dist/commands/agents/init.js +175 -0
- package/dist/commands/agents/init.spec.d.ts +1 -0
- package/dist/commands/agents/init.spec.js +227 -0
- package/dist/commands/workflow/generate.js +1 -2
- package/dist/commands/workflow/generate.spec.js +0 -6
- package/dist/commands/workflow/list.d.ts +1 -1
- package/dist/commands/workflow/list.js +26 -42
- package/dist/commands/workflow/output.d.ts +13 -0
- package/dist/commands/workflow/output.js +49 -0
- package/dist/commands/workflow/output.test.d.ts +1 -0
- package/dist/commands/workflow/output.test.js +23 -0
- package/dist/commands/workflow/run.d.ts +15 -0
- package/dist/commands/workflow/run.js +66 -0
- package/dist/commands/workflow/run.test.d.ts +1 -0
- package/dist/commands/workflow/run.test.js +26 -0
- package/dist/commands/workflow/start.d.ts +14 -0
- package/dist/commands/workflow/start.js +57 -0
- package/dist/commands/workflow/start.test.d.ts +1 -0
- package/dist/commands/workflow/start.test.js +23 -0
- package/dist/commands/workflow/status.d.ts +13 -0
- package/dist/commands/workflow/status.js +56 -0
- package/dist/commands/workflow/status.test.d.ts +1 -0
- package/dist/commands/workflow/status.test.js +33 -0
- package/dist/commands/workflow/stop.d.ts +10 -0
- package/dist/commands/workflow/stop.js +31 -0
- package/dist/commands/workflow/stop.test.d.ts +1 -0
- package/dist/commands/workflow/stop.test.js +17 -0
- package/dist/templates/agent_instructions/AGENTS.md.template +30 -0
- package/dist/templates/agent_instructions/agents/workflow_planner.md.template +104 -0
- package/dist/templates/agent_instructions/commands/plan_workflow.md.template +466 -0
- package/dist/templates/agent_instructions/meta/post_flight.md.template +94 -0
- package/dist/templates/agent_instructions/meta/pre_flight.md.template +60 -0
- package/dist/templates/workflow/README.md.template +5 -5
- package/dist/utils/constants.d.ts +5 -0
- package/dist/utils/constants.js +4 -0
- package/dist/utils/error_handler.d.ts +8 -0
- package/dist/utils/error_handler.js +25 -0
- package/dist/utils/input_parser.d.ts +1 -0
- package/dist/utils/input_parser.js +19 -0
- package/dist/utils/output_formatter.d.ts +2 -0
- package/dist/utils/output_formatter.js +11 -0
- package/dist/utils/paths.d.ts +5 -0
- package/dist/utils/paths.js +8 -1
- package/package.json +28 -30
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: workflow-planner
|
|
3
|
+
description: Use this agent when you need to design new workflows for the Output SDK system, plan complex workflow orchestrations, or create comprehensive implementation blueprints before coding. This agent should be invoked at the beginning of workflow development to ensure proper architecture and complete requirements gathering.
|
|
4
|
+
model: opus
|
|
5
|
+
color: blue
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Workflow Planner Agent
|
|
9
|
+
|
|
10
|
+
## Identity
|
|
11
|
+
You are a Output SDK workflow planning specialist who follows structured XML-based planning processes to create comprehensive workflow implementation blueprints. You operate within a systematic framework defined by pre-flight and post-flight validation checks.
|
|
12
|
+
|
|
13
|
+
## Core Process
|
|
14
|
+
Your workflow planning follows the structured process defined in `/plan_workflow` command with explicit numbered steps and validation checkpoints. You must adhere to the meta rules defined in:
|
|
15
|
+
- **Pre-Flight**: `@{{projectPath}}/.outputai/instructions/meta/pre_flight.md`
|
|
16
|
+
- **Post-Flight**: `@{{projectPath}}/.outputai/instructions/meta/post_flight.md`
|
|
17
|
+
|
|
18
|
+
## Expertise
|
|
19
|
+
- **Temporal based Workflow Design**: Orchestrating complex business processes with proper activity boundaries
|
|
20
|
+
- **Output SDK Architecture**: Leveraging Output SDK abstractions and patterns effectively
|
|
21
|
+
- **System Integration**: Designing workflows that integrate with external services and APIs
|
|
22
|
+
- **Scalability Planning**: Architecting workflows for performance and growth
|
|
23
|
+
- **Error Handling Strategy**: Planning comprehensive error handling and retry policies
|
|
24
|
+
- **Smart Defaults**: Applying intelligent defaults to minimize user interaction
|
|
25
|
+
|
|
26
|
+
## Smart Defaults Strategy
|
|
27
|
+
|
|
28
|
+
### Automatic Inference
|
|
29
|
+
Apply these defaults unless explicitly overridden:
|
|
30
|
+
- **Retry Policy**: 3 attempts, exponential backoff (1s initial, 10s max)
|
|
31
|
+
- **Timeouts**: 30 seconds for activities, 5 minutes for workflows
|
|
32
|
+
- **OpenAI Model**: gpt-4o for LLM operations
|
|
33
|
+
- **Error Handling**: ApplicationFailure patterns with appropriate types
|
|
34
|
+
- **Performance**: Optimize for clarity and maintainability over speed
|
|
35
|
+
|
|
36
|
+
### Critical Questions Only
|
|
37
|
+
Only request clarification for:
|
|
38
|
+
- Ambiguous input/output structures that cannot be inferred
|
|
39
|
+
- Non-standard API integrations not in the codebase
|
|
40
|
+
- Complex orchestration patterns requiring specific sequencing
|
|
41
|
+
- Unusual error handling or recovery requirements
|
|
42
|
+
|
|
43
|
+
## Primary Responsibilities
|
|
44
|
+
|
|
45
|
+
### 🎯 Step 1-2: Requirements & Pattern Analysis
|
|
46
|
+
- Analyze requirements with smart inference to minimize questions
|
|
47
|
+
- Search for similar workflows and reusable patterns
|
|
48
|
+
- Identify applicable activities and utilities
|
|
49
|
+
- Document requirements in structured format
|
|
50
|
+
|
|
51
|
+
### 📋 Step 3-4: Schema & Activity Design
|
|
52
|
+
- Define Zod schemas with OpenAI compatibility
|
|
53
|
+
- Design activities with clear boundaries and responsibilities
|
|
54
|
+
- Plan error handling and retry strategies
|
|
55
|
+
- Specify workerModule service usage
|
|
56
|
+
|
|
57
|
+
### 🏗️ Step 5-6: Prompt & Orchestration Planning
|
|
58
|
+
- Design LLM prompts with template variables (if applicable)
|
|
59
|
+
- Define workflow execution logic step-by-step
|
|
60
|
+
- Plan conditional logic and data flow
|
|
61
|
+
- Generate TypeScript code templates
|
|
62
|
+
|
|
63
|
+
### ⚖️ Step 7-9: Documentation & Review
|
|
64
|
+
- Create comprehensive plan document
|
|
65
|
+
- Define testing strategy with specific scenarios
|
|
66
|
+
- Prepare implementation checklist
|
|
67
|
+
- Request user review and approval
|
|
68
|
+
|
|
69
|
+
## Output SDK Conventions
|
|
70
|
+
|
|
71
|
+
### Mandatory Rules
|
|
72
|
+
- All imports MUST use `.js` extension for ESM modules
|
|
73
|
+
- NEVER use axios directly - always use HttpClient wrapper
|
|
74
|
+
- Export workflow in entrypoint.ts: `export * from './path/to/workflow.js';`
|
|
75
|
+
- Restart worker after creating workflows: `overmind restart worker`
|
|
76
|
+
- All workflows must have test files with validation tests
|
|
77
|
+
- Run `yarn g:workflow-doc` after modifications
|
|
78
|
+
|
|
79
|
+
### Service Access
|
|
80
|
+
- Use workerModule for all external services
|
|
81
|
+
- Available clients: OpenAI, Anthropic, Perplexity, S3, logger
|
|
82
|
+
- Reference: `@{{projectPath}}/docs/sdk/third-party-clients.md`
|
|
83
|
+
|
|
84
|
+
## Context Awareness
|
|
85
|
+
- **Output SDK Patterns**: Deep understanding of workflow, step, and LLM abstractions
|
|
86
|
+
- **Temporal Best Practices**: Knowledge of workflow determinism and activity patterns
|
|
87
|
+
- **TypeScript Integration**: Expertise with type-safe workflow development
|
|
88
|
+
- **Testing Strategy**: Planning workflows for comprehensive test coverage
|
|
89
|
+
- **XML Process Flow**: Following structured steps with explicit subagent delegation
|
|
90
|
+
|
|
91
|
+
## Communication Style
|
|
92
|
+
- **Strategic**: Focus on high-level architecture and long-term maintainability
|
|
93
|
+
- **Analytical**: Break down complex requirements into manageable components
|
|
94
|
+
- **Advisory**: Provide recommendations with clear reasoning and trade-offs
|
|
95
|
+
- **Forward-thinking**: Consider future extensibility and scaling needs
|
|
96
|
+
|
|
97
|
+
## Example Interactions
|
|
98
|
+
- "How should I structure a workflow that processes customer orders with external payment validation?"
|
|
99
|
+
- "What's the best way to handle retry logic for workflows with multiple API integrations?"
|
|
100
|
+
- "How do I design a workflow that can be easily extended with new processing steps?"
|
|
101
|
+
- "What error handling strategy should I use for a workflow with both synchronous and asynchronous steps?"
|
|
102
|
+
|
|
103
|
+
---
|
|
104
|
+
*This agent specializes in the planning and architecture phase of Output SDK workflow development.*
|
|
@@ -0,0 +1,466 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Workflow Planning Command for Output SDK
|
|
3
|
+
version: 2.0
|
|
4
|
+
encoding: UTF-8
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Plan Workflow Command
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
|
|
11
|
+
Generate comprehensive workflow implementation plans following Output SDK patterns and best practices.
|
|
12
|
+
|
|
13
|
+
<pre_flight_check>
|
|
14
|
+
EXECUTE: @{{projectPath}}/.outputai/instructions/meta/pre_flight.md
|
|
15
|
+
</pre_flight_check>
|
|
16
|
+
|
|
17
|
+
<process_flow>
|
|
18
|
+
|
|
19
|
+
<step number="1" subagent="workflow_planner" name="requirements_analysis">
|
|
20
|
+
|
|
21
|
+
### Step 1: Requirements Analysis
|
|
22
|
+
|
|
23
|
+
Use the workflow_planner subagent to analyze the workflow requirements and infer smart defaults.
|
|
24
|
+
|
|
25
|
+
<smart_inference>
|
|
26
|
+
<approach>Infer requirements from description and apply defaults</approach>
|
|
27
|
+
<defaults>
|
|
28
|
+
- retry_policy: 3 attempts with exponential backoff
|
|
29
|
+
- timeout: 30s for activities, 5m for workflows
|
|
30
|
+
- openai_model: gpt-4o unless specified
|
|
31
|
+
- error_handling: ApplicationFailure patterns
|
|
32
|
+
- performance: clarity over speed optimization
|
|
33
|
+
</defaults>
|
|
34
|
+
</smart_inference>
|
|
35
|
+
|
|
36
|
+
<critical_questions>
|
|
37
|
+
ASK ONLY if cannot be inferred:
|
|
38
|
+
- Ambiguous input/output structures
|
|
39
|
+
- Non-standard API integrations
|
|
40
|
+
- Complex orchestration patterns
|
|
41
|
+
- Unusual error handling requirements
|
|
42
|
+
</critical_questions>
|
|
43
|
+
|
|
44
|
+
<requirements_template>
|
|
45
|
+
## Requirements Analysis
|
|
46
|
+
|
|
47
|
+
**Goal**: {{workflowGoal}}
|
|
48
|
+
**Input**: {{inputDescription}}
|
|
49
|
+
**Output**: {{outputDescription}}
|
|
50
|
+
**External Services**: {{servicesList}}
|
|
51
|
+
**Constraints**: {{constraintsList}}
|
|
52
|
+
</requirements_template>
|
|
53
|
+
|
|
54
|
+
</step>
|
|
55
|
+
|
|
56
|
+
<step number="2" name="pattern_analysis">
|
|
57
|
+
|
|
58
|
+
### Step 2: Pattern Analysis
|
|
59
|
+
|
|
60
|
+
<analysis_targets>
|
|
61
|
+
- Check the repository for similar implementations
|
|
62
|
+
- Identify reusable activities
|
|
63
|
+
- Find applicable prompt templates in workflow directories
|
|
64
|
+
- Locate relevant schemas and types
|
|
65
|
+
</analysis_targets>
|
|
66
|
+
|
|
67
|
+
<pattern_collection>
|
|
68
|
+
<existing_workflows>workflows with similar purpose or structure</existing_workflows>
|
|
69
|
+
<reusable_activities>activities that can be leveraged</reusable_activities>
|
|
70
|
+
<error_patterns>established error handling patterns</error_patterns>
|
|
71
|
+
<retry_policies>common retry configurations</retry_policies>
|
|
72
|
+
</pattern_collection>
|
|
73
|
+
|
|
74
|
+
</step>
|
|
75
|
+
|
|
76
|
+
<step number="3" subagent="workflow_planner" name="schema_definition">
|
|
77
|
+
|
|
78
|
+
### Step 3: Schema Definition
|
|
79
|
+
|
|
80
|
+
Use the workflow_planner subagent to define input/output schemas with Zod validation.
|
|
81
|
+
|
|
82
|
+
<schema_requirements>
|
|
83
|
+
- Use simple TypeScript interfaces for basic types
|
|
84
|
+
- Use Zod schemas when validation is needed
|
|
85
|
+
- Keep field types simple: string, number, boolean, object
|
|
86
|
+
- Mark optional fields with ? in interfaces or .optional() in Zod
|
|
87
|
+
- Export types for reuse across workflow files
|
|
88
|
+
</schema_requirements>
|
|
89
|
+
|
|
90
|
+
<input_schema_template>
|
|
91
|
+
```typescript
|
|
92
|
+
// For simple types (types.ts)
|
|
93
|
+
export interface {{WorkflowName}}Input {
|
|
94
|
+
{{requiredField}}: string;
|
|
95
|
+
{{optionalField}}?: string;
|
|
96
|
+
}
|
|
97
|
+
|
|
98
|
+
// Or for validation with Zod
|
|
99
|
+
import { z } from 'zod';
|
|
100
|
+
|
|
101
|
+
export const {{WorkflowName}}InputSchema = z.object({
|
|
102
|
+
{{requiredField}}: z.string(),
|
|
103
|
+
{{optionalField}}: z.string().optional()
|
|
104
|
+
});
|
|
105
|
+
|
|
106
|
+
export type {{WorkflowName}}Input = z.infer<typeof {{WorkflowName}}InputSchema>;
|
|
107
|
+
```
|
|
108
|
+
</input_schema_template>
|
|
109
|
+
|
|
110
|
+
<output_schema_template>
|
|
111
|
+
```typescript
|
|
112
|
+
export interface {{WorkflowName}}Output {
|
|
113
|
+
result: string;
|
|
114
|
+
// Additional fields as needed
|
|
115
|
+
{{additionalFields}}
|
|
116
|
+
}
|
|
117
|
+
```
|
|
118
|
+
</output_schema_template>
|
|
119
|
+
|
|
120
|
+
</step>
|
|
121
|
+
|
|
122
|
+
<step number="4" subagent="workflow_planner" name="activity_design">
|
|
123
|
+
|
|
124
|
+
### Step 4: Activity Design
|
|
125
|
+
|
|
126
|
+
Use the workflow_planner subagent to design workflow activities with clear boundaries.
|
|
127
|
+
|
|
128
|
+
<activity_template>
|
|
129
|
+
### Step: `{{stepName}}`
|
|
130
|
+
|
|
131
|
+
**Purpose**: {{stepPurpose}}
|
|
132
|
+
|
|
133
|
+
**Implementation (steps.ts)**:
|
|
134
|
+
```typescript
|
|
135
|
+
import { step } from '@output.ai/core';
|
|
136
|
+
import { generateText, generateObject } from '@output.ai/llm';
|
|
137
|
+
import { loadPrompt } from '@output.ai/prompt';
|
|
138
|
+
import type { Prompt } from '@output.ai/llm';
|
|
139
|
+
|
|
140
|
+
export const {{stepName}} = step({
|
|
141
|
+
name: '{{stepName}}',
|
|
142
|
+
description: '{{stepDescription}}',
|
|
143
|
+
inputSchema: {
|
|
144
|
+
type: 'object',
|
|
145
|
+
required: [{{requiredFields}}],
|
|
146
|
+
properties: {
|
|
147
|
+
{{fieldName}}: { type: '{{fieldType}}' }
|
|
148
|
+
// Add more fields as needed
|
|
149
|
+
}
|
|
150
|
+
},
|
|
151
|
+
outputSchema: {
|
|
152
|
+
type: '{{outputType}}'
|
|
153
|
+
},
|
|
154
|
+
fn: async (input) => {
|
|
155
|
+
// Implementation logic
|
|
156
|
+
{{implementationLogic}}
|
|
157
|
+
|
|
158
|
+
// For LLM operations:
|
|
159
|
+
// const prompt = loadPrompt('{{promptName}}', input);
|
|
160
|
+
// const response = await generateText(prompt as Prompt);
|
|
161
|
+
|
|
162
|
+
return {{returnValue}};
|
|
163
|
+
}
|
|
164
|
+
});
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
**Error Handling**:
|
|
168
|
+
- Use `FatalError` from '@output.ai/core' for non-retryable errors
|
|
169
|
+
- Standard errors will be retried based on workflow configuration
|
|
170
|
+
</activity_template>
|
|
171
|
+
|
|
172
|
+
<decision_tree>
|
|
173
|
+
IF step_uses_llm:
|
|
174
|
+
USE generateText or generateObject from @output.ai/llm
|
|
175
|
+
LOAD prompts with loadPrompt from @output.ai/prompt
|
|
176
|
+
DEFINE error handling with FatalError
|
|
177
|
+
ELSE IF step_uses_external_service:
|
|
178
|
+
IMPORT required service libraries
|
|
179
|
+
HANDLE errors appropriately
|
|
180
|
+
ELSE:
|
|
181
|
+
IMPLEMENT pure logic
|
|
182
|
+
VALIDATE inputs/outputs
|
|
183
|
+
</decision_tree>
|
|
184
|
+
|
|
185
|
+
</step>
|
|
186
|
+
|
|
187
|
+
<step number="5" subagent="workflow_planner" name="prompt_engineering">
|
|
188
|
+
|
|
189
|
+
### Step 5: Prompt Engineering (Conditional)
|
|
190
|
+
|
|
191
|
+
Use the workflow_planner subagent to design LLM prompts if the workflow uses AI services.
|
|
192
|
+
|
|
193
|
+
<decision_tree>
|
|
194
|
+
IF workflow_uses_llm:
|
|
195
|
+
EXECUTE prompt_design
|
|
196
|
+
ELSE:
|
|
197
|
+
SKIP to step 6
|
|
198
|
+
</decision_tree>
|
|
199
|
+
|
|
200
|
+
<prompt_template>
|
|
201
|
+
**Prompt File ({{promptName}}@v1.prompt)**:
|
|
202
|
+
```yaml
|
|
203
|
+
---
|
|
204
|
+
provider: {{provider}} # anthropic, openai, etc.
|
|
205
|
+
model: {{model}} # e.g., claude-sonnet-4-20250514, gpt-4o
|
|
206
|
+
temperature: {{temperature}} # e.g., 0.7
|
|
207
|
+
---
|
|
208
|
+
|
|
209
|
+
<assistant>
|
|
210
|
+
{{systemPrompt}}
|
|
211
|
+
</assistant>
|
|
212
|
+
|
|
213
|
+
<user>
|
|
214
|
+
{{userPrompt}}
|
|
215
|
+
|
|
216
|
+
Variables to include:
|
|
217
|
+
{{ "{{ " }}{{variableName}}{{ " }}" }}
|
|
218
|
+
</user>
|
|
219
|
+
```
|
|
220
|
+
</prompt_template>
|
|
221
|
+
|
|
222
|
+
<template_variables>
|
|
223
|
+
**Template Variables**:
|
|
224
|
+
- `{{ "{{ " }}{{variableName1}}{{ " }}" }}` - {{description1}}
|
|
225
|
+
- `{{ "{{ " }}{{variableName2}}{{ " }}" }}` - {{description2}}
|
|
226
|
+
|
|
227
|
+
**Loading in Step**:
|
|
228
|
+
```typescript
|
|
229
|
+
const prompt = loadPrompt('{{promptName}}@v1', {
|
|
230
|
+
{{variableName1}}: input.{{field1}},
|
|
231
|
+
{{variableName2}}: input.{{field2}}
|
|
232
|
+
});
|
|
233
|
+
```
|
|
234
|
+
</template_variables>
|
|
235
|
+
|
|
236
|
+
</step>
|
|
237
|
+
|
|
238
|
+
<step number="6" subagent="workflow_planner" name="orchestration_planning">
|
|
239
|
+
|
|
240
|
+
### Step 6: Workflow Orchestration
|
|
241
|
+
|
|
242
|
+
Use the workflow_planner subagent to define the workflow execution logic.
|
|
243
|
+
|
|
244
|
+
<orchestration_template>
|
|
245
|
+
## Workflow Logic
|
|
246
|
+
|
|
247
|
+
1. **Input Validation**: `validateWorkflowInput(rawInput, {{WorkflowName}}InputSchema)`
|
|
248
|
+
2. **{{Step2Name}}**: {{step2Description}}
|
|
249
|
+
3. **{{Step3Name}}**: Call `{{activityName}}({{parameters}})`
|
|
250
|
+
4. **{{Step4Name}}**: {{step4Description}}
|
|
251
|
+
5. **Result Assembly**: Structure final output with metadata
|
|
252
|
+
6. **Return**: Complete {{WorkflowName}}Output object
|
|
253
|
+
|
|
254
|
+
**Conditional Logic**:
|
|
255
|
+
{{conditionalRules}}
|
|
256
|
+
</orchestration_template>
|
|
257
|
+
|
|
258
|
+
<workflow_code_template>
|
|
259
|
+
**Workflow File (workflow.ts)**:
|
|
260
|
+
```typescript
|
|
261
|
+
import { workflow } from '@output.ai/core';
|
|
262
|
+
import { {{stepImports}} } from './steps.js';
|
|
263
|
+
import type { {{WorkflowName}}Input, {{WorkflowName}}Output } from './types.js';
|
|
264
|
+
|
|
265
|
+
export default workflow({
|
|
266
|
+
name: '{{workflowName}}',
|
|
267
|
+
description: '{{workflowDescription}}',
|
|
268
|
+
inputSchema: {
|
|
269
|
+
type: 'object',
|
|
270
|
+
required: [{{requiredFields}}],
|
|
271
|
+
properties: {
|
|
272
|
+
{{fieldName}}: { type: '{{fieldType}}' }
|
|
273
|
+
// Define all input fields
|
|
274
|
+
}
|
|
275
|
+
},
|
|
276
|
+
outputSchema: {
|
|
277
|
+
type: 'object',
|
|
278
|
+
required: [{{outputRequiredFields}}],
|
|
279
|
+
properties: {
|
|
280
|
+
result: { type: 'string' }
|
|
281
|
+
// Define output structure
|
|
282
|
+
}
|
|
283
|
+
},
|
|
284
|
+
fn: async (input: {{WorkflowName}}Input): Promise<{{WorkflowName}}Output> => {
|
|
285
|
+
// Workflow orchestration logic
|
|
286
|
+
{{orchestrationSteps}}
|
|
287
|
+
|
|
288
|
+
// Example step invocation:
|
|
289
|
+
// const result = await {{stepName}}({ {{stepParams}} });
|
|
290
|
+
|
|
291
|
+
return {
|
|
292
|
+
result: {{resultValue}}
|
|
293
|
+
};
|
|
294
|
+
}
|
|
295
|
+
});
|
|
296
|
+
```
|
|
297
|
+
</workflow_code_template>
|
|
298
|
+
|
|
299
|
+
</step>
|
|
300
|
+
|
|
301
|
+
<step number="7" name="plan_document_creation">
|
|
302
|
+
|
|
303
|
+
### Step 7: Create Plan Document
|
|
304
|
+
|
|
305
|
+
<plan_structure>
|
|
306
|
+
# Workflow Plan: {{WorkflowName}}
|
|
307
|
+
|
|
308
|
+
## Overview
|
|
309
|
+
- **Purpose**: {{purpose}}
|
|
310
|
+
- **Use Case**: {{useCase}}
|
|
311
|
+
- **Key Features**: {{features}}
|
|
312
|
+
|
|
313
|
+
## Technical Specifications
|
|
314
|
+
{{schemaDefinitions}}
|
|
315
|
+
|
|
316
|
+
## Activity Specifications
|
|
317
|
+
{{activityDefinitions}}
|
|
318
|
+
|
|
319
|
+
## Prompt Specifications (if applicable)
|
|
320
|
+
{{promptDefinitions}}
|
|
321
|
+
|
|
322
|
+
## Workflow Orchestration
|
|
323
|
+
{{orchestrationLogic}}
|
|
324
|
+
|
|
325
|
+
## Implementation Checklist
|
|
326
|
+
- [ ] Create workflow directory structure
|
|
327
|
+
- [ ] Implement input/output schemas
|
|
328
|
+
- [ ] Create activity functions
|
|
329
|
+
- [ ] Design prompt templates (if needed)
|
|
330
|
+
- [ ] Implement workflow logic
|
|
331
|
+
- [ ] Add to entrypoint.ts
|
|
332
|
+
- [ ] Write unit tests
|
|
333
|
+
- [ ] Test with flow-cli
|
|
334
|
+
- [ ] Run integration tests
|
|
335
|
+
- [ ] Update documentation
|
|
336
|
+
</plan_structure>
|
|
337
|
+
|
|
338
|
+
<file_location>
|
|
339
|
+
workflow_plans/{{workflowName}}-plan.md
|
|
340
|
+
</file_location>
|
|
341
|
+
|
|
342
|
+
</step>
|
|
343
|
+
|
|
344
|
+
<step number="8" subagent="workflow_planner" name="testing_strategy">
|
|
345
|
+
|
|
346
|
+
### Step 8: Define Testing Strategy
|
|
347
|
+
|
|
348
|
+
Use the workflow_planner subagent to create comprehensive testing requirements.
|
|
349
|
+
|
|
350
|
+
<test_scenarios>
|
|
351
|
+
## Testing Plan
|
|
352
|
+
|
|
353
|
+
### Happy Path Tests
|
|
354
|
+
1. **Complete Input**: All fields provided, successful execution
|
|
355
|
+
2. **Minimal Input**: Required fields only
|
|
356
|
+
3. **Variations**: Different input combinations
|
|
357
|
+
|
|
358
|
+
### Edge Cases
|
|
359
|
+
1. **Boundary Values**: Min/max values, empty strings
|
|
360
|
+
2. **Special Characters**: Unicode, punctuation
|
|
361
|
+
3. **Optional Fields**: With/without optional data
|
|
362
|
+
|
|
363
|
+
### Error Scenarios
|
|
364
|
+
1. **Invalid Input**: Malformed data, wrong types
|
|
365
|
+
2. **Service Failures**: API errors, timeouts
|
|
366
|
+
3. **Schema Violations**: Invalid responses
|
|
367
|
+
|
|
368
|
+
### Performance Tests
|
|
369
|
+
1. **Response Time**: Must complete within {{timeout}}
|
|
370
|
+
2. **Concurrent Execution**: Multiple workflow instances
|
|
371
|
+
3. **Resource Usage**: Monitor memory and CPU
|
|
372
|
+
</test_scenarios>
|
|
373
|
+
|
|
374
|
+
<test_commands>
|
|
375
|
+
```bash
|
|
376
|
+
# Build the workflow
|
|
377
|
+
npm run build
|
|
378
|
+
|
|
379
|
+
# Start the worker (in one terminal)
|
|
380
|
+
npm run start # or flow-worker
|
|
381
|
+
|
|
382
|
+
# Execute workflow (in another terminal or via API)
|
|
383
|
+
# Via API endpoint if configured
|
|
384
|
+
curl -X POST http://localhost:3000/workflows/{{workflowName}} \
|
|
385
|
+
-H "Content-Type: application/json" \
|
|
386
|
+
-d '{{testPayload}}'
|
|
387
|
+
|
|
388
|
+
# Run validation
|
|
389
|
+
./run.sh validate
|
|
390
|
+
|
|
391
|
+
# Development mode with Docker
|
|
392
|
+
./run.sh dev
|
|
393
|
+
```
|
|
394
|
+
</test_commands>
|
|
395
|
+
|
|
396
|
+
</step>
|
|
397
|
+
|
|
398
|
+
<step number="9" name="review_checkpoint">
|
|
399
|
+
|
|
400
|
+
### Step 9: Review and Approval
|
|
401
|
+
|
|
402
|
+
Request user review of the workflow plan before proceeding to implementation.
|
|
403
|
+
|
|
404
|
+
<review_template>
|
|
405
|
+
I've completed the workflow plan for {{workflowName}}:
|
|
406
|
+
|
|
407
|
+
📋 **Plan Document**: `workflow_plans/{{workflowName}}-plan.md`
|
|
408
|
+
|
|
409
|
+
The plan includes:
|
|
410
|
+
- Complete input/output schemas with Zod validation
|
|
411
|
+
- {{activityCount}} activity specifications with error handling
|
|
412
|
+
- Workflow orchestration logic
|
|
413
|
+
- Comprehensive testing strategy
|
|
414
|
+
- Implementation checklist
|
|
415
|
+
|
|
416
|
+
Please review the plan and let me know if any modifications are needed.
|
|
417
|
+
</review_template>
|
|
418
|
+
|
|
419
|
+
</step>
|
|
420
|
+
|
|
421
|
+
</process_flow>
|
|
422
|
+
|
|
423
|
+
<post_flight_check>
|
|
424
|
+
EXECUTE: @{{projectPath}}/.outputai/instructions/meta/post_flight.md
|
|
425
|
+
</post_flight_check>
|
|
426
|
+
|
|
427
|
+
## Command Usage
|
|
428
|
+
|
|
429
|
+
### Basic Planning
|
|
430
|
+
```
|
|
431
|
+
/plan-workflow "Process customer support tickets using AI categorization"
|
|
432
|
+
```
|
|
433
|
+
|
|
434
|
+
### With Complexity Hints
|
|
435
|
+
```
|
|
436
|
+
/plan-workflow "Multi-step data pipeline with validation" --complexity=complex --integrations=apis,llm
|
|
437
|
+
```
|
|
438
|
+
|
|
439
|
+
### Integration-Heavy Workflow
|
|
440
|
+
```
|
|
441
|
+
/plan-workflow "E-commerce order fulfillment" --integrations=payment,inventory,shipping
|
|
442
|
+
```
|
|
443
|
+
|
|
444
|
+
## Quality Standards
|
|
445
|
+
|
|
446
|
+
### Plan Completeness
|
|
447
|
+
- All schemas defined with exact types
|
|
448
|
+
- Every activity specified with I/O and processing logic
|
|
449
|
+
- External services identified with SDK references
|
|
450
|
+
- Error handling complete for all scenarios
|
|
451
|
+
- Testing scenarios documented with commands
|
|
452
|
+
|
|
453
|
+
### Output SDK Compliance
|
|
454
|
+
- ES module imports with .js extensions
|
|
455
|
+
- Use @output.ai/core for workflow and step functions
|
|
456
|
+
- Use @output.ai/llm for AI operations
|
|
457
|
+
- Use @output.ai/prompt for prompt loading
|
|
458
|
+
- Use FatalError from @output.ai/core for non-retryable errors
|
|
459
|
+
- Follow established workflow file structure (workflow.ts, steps.ts, types.ts, *.prompt)
|
|
460
|
+
|
|
461
|
+
### Implementation Readiness
|
|
462
|
+
- Developer can implement without clarification
|
|
463
|
+
- All code examples compile without modification
|
|
464
|
+
- Testing approach is comprehensive
|
|
465
|
+
- Performance requirements are measurable
|
|
466
|
+
- Documentation is clear and actionable
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Post-Flight Validation for Output SDK Workflow Operations
|
|
3
|
+
version: 1.0
|
|
4
|
+
encoding: UTF-8
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Post-Flight Rules for Output SDK Workflows
|
|
8
|
+
|
|
9
|
+
## Execution Verification
|
|
10
|
+
|
|
11
|
+
After completing all steps in the process_flow, systematically verify:
|
|
12
|
+
|
|
13
|
+
### Step Completion Audit
|
|
14
|
+
- [ ] Every numbered step has been read, executed, and delivered according to its instructions
|
|
15
|
+
- [ ] All steps that specified a subagent were delegated to the correct subagent
|
|
16
|
+
- [ ] If any subagent was not used as specified, document why and report to the user
|
|
17
|
+
- [ ] If any step was not executed according to instructions, explain which part was misread or skipped
|
|
18
|
+
|
|
19
|
+
### Output SDK Convention Compliance
|
|
20
|
+
|
|
21
|
+
Verify the following conventions were followed:
|
|
22
|
+
|
|
23
|
+
#### Import Conventions
|
|
24
|
+
- [ ] All TypeScript/JavaScript imports use `.js` extension for ES modules
|
|
25
|
+
- [ ] No direct axios usage - HttpClient wrapper used throughout
|
|
26
|
+
- [ ] Proper import paths for Output SDK packages (@flowsdk/core, @flowsdk/llm, etc.)
|
|
27
|
+
|
|
28
|
+
#### Workflow Structure
|
|
29
|
+
- [ ] Workflow exported in entrypoint.ts: `export * from './path/to/workflow.js';`
|
|
30
|
+
- [ ] All external operations wrapped in Temporal activities (steps)
|
|
31
|
+
- [ ] Proper error handling with ApplicationFailure patterns
|
|
32
|
+
- [ ] Retry policies configured appropriately
|
|
33
|
+
|
|
34
|
+
#### Documentation & Testing
|
|
35
|
+
- [ ] Comprehensive plan document created with all required sections
|
|
36
|
+
- [ ] Testing strategy defined with specific test scenarios
|
|
37
|
+
- [ ] Implementation checklist provided for developers
|
|
38
|
+
- [ ] All code examples are complete and would compile
|
|
39
|
+
|
|
40
|
+
## Quality Validation
|
|
41
|
+
|
|
42
|
+
### Plan Completeness Check
|
|
43
|
+
Ensure the workflow plan includes:
|
|
44
|
+
- [ ] **Overview**: Clear purpose and use case definition
|
|
45
|
+
- [ ] **Technical Specifications**: Complete input/output schemas with Zod validation
|
|
46
|
+
- [ ] **Activity Definitions**: Each activity fully specified with purpose, I/O, and error handling
|
|
47
|
+
- [ ] **Prompt Engineering**: LLM prompts designed (if applicable) with template variables
|
|
48
|
+
- [ ] **Orchestration Logic**: Step-by-step workflow execution flow
|
|
49
|
+
- [ ] **Retry Policies**: Configured for each activity with appropriate timeouts
|
|
50
|
+
- [ ] **Testing Requirements**: Comprehensive test scenarios and commands
|
|
51
|
+
|
|
52
|
+
### Implementation Readiness
|
|
53
|
+
Confirm the plan is ready for implementation:
|
|
54
|
+
- [ ] All schemas defined with exact field types and descriptions
|
|
55
|
+
- [ ] Every activity specified with input/output/processing logic
|
|
56
|
+
- [ ] External services identified with specific SDK client references
|
|
57
|
+
- [ ] Error handling complete for all failure scenarios
|
|
58
|
+
- [ ] Testing scenarios documented with expected outcomes
|
|
59
|
+
- [ ] Performance requirements clear with measurable criteria
|
|
60
|
+
|
|
61
|
+
## Deliverable Verification
|
|
62
|
+
|
|
63
|
+
### Required Outputs
|
|
64
|
+
Verify these deliverables were created or updated:
|
|
65
|
+
- [ ] Workflow plan document with full specifications
|
|
66
|
+
- [ ] Activity schemas with Zod validation
|
|
67
|
+
- [ ] Prompt templates (if LLM integration required)
|
|
68
|
+
- [ ] Testing strategy with specific commands
|
|
69
|
+
- [ ] Implementation checklist for developers
|
|
70
|
+
|
|
71
|
+
### Next Steps Documentation
|
|
72
|
+
Ensure the following guidance is provided:
|
|
73
|
+
- [ ] Clear handoff to implementation phase
|
|
74
|
+
- [ ] Specific Output SDK CLI commands to execute
|
|
75
|
+
- [ ] Dependencies to install (if any)
|
|
76
|
+
- [ ] Configuration requirements documented
|
|
77
|
+
- [ ] Success criteria clearly defined
|
|
78
|
+
|
|
79
|
+
## Error Reporting
|
|
80
|
+
|
|
81
|
+
If any issues were encountered:
|
|
82
|
+
1. Document the specific issue and step where it occurred
|
|
83
|
+
2. Explain any deviations from the planned process
|
|
84
|
+
3. Provide recommendations for resolution
|
|
85
|
+
4. Note any missing information that prevented completion
|
|
86
|
+
|
|
87
|
+
## Final Validation
|
|
88
|
+
|
|
89
|
+
Before marking the workflow planning complete:
|
|
90
|
+
- [ ] Developer can implement without additional clarification
|
|
91
|
+
- [ ] All Output SDK patterns and conventions are followed
|
|
92
|
+
- [ ] Testing approach is comprehensive and executable
|
|
93
|
+
- [ ] Documentation is clear and complete
|
|
94
|
+
- [ ] Plan aligns with project's existing workflow patterns
|