flows.ts•6.96 kB
export const prompt = `
Turn this into a tool called \`create_flow\`, it will just return the text and type
# Flow Documentation Generation Prompt
You are an expert at creating business flow documentation using EventCatalog's flow schema. Your task is to generate a complete markdown file for a business flow based on the user's description.
You will use other tools like \`get_resources\` or \`get_resource\` to work out what services, messages, and owners are available for the flow.
## Instructions:
Given a business process description (e.g., \`payment for users\`, \`user registration\`, \`order fulfillment\`), generate a complete flow documentation file following this exact structure:
### Required Format:
\`\`\`markdown
---
id: [CamelCaseFlowName]
name: [Human readable flow name]
version: 1.0.0
summary: [Brief description of what this business flow accomplishes]
owners:
- [owner-id]
steps:
[Array of step objects - see schema below]
---
### Flow of [feature name]
<NodeGraph />
\`\`\`
### Schema Rules:
1. **Each step must have:**
- \`id\`: Unique identifier (string or number)
- \`title\`: Human-readable step name
- Navigation: Either \`next_step\` (single) or \`next_steps\` (array) but not both
2. **Each step could have:**
- One of these properties:
- \`message\`: For events/commands/queries (with id and version)
- \`service\`: For service interactions (with id and version)
- \`flow\`: For nested flows (with id)
- \`actor\`: For human/system actors (with name)
- \`custom\`: For custom steps (with title, summary, etc.)
3. **Navigation can be:**
- Simple: Just an id string/number
- With label: \`{ id: "step_id", label: "Description of transition" }\`
4. **Message references require:**
- \`id\`: The message identifier
- \`version\`: The message version (e.g., "0.0.1", "1.0.0")
## JSON Schema for the flow
\`\`\`json
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"steps": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": {
"anyOf": [{ "type": "string" }, { "type": "number" }]
},
"title": { "type": "string" },
"summary": { "type": "string" },
"message": { "type": "string" },
"service": { "type": "string" },
"flow": { "type": "string" },
"actor": {
"type": "object",
"properties": {
"name": { "type": "string" }
},
"required": ["name"],
"additionalProperties": false
},
"custom": {
"type": "object",
"properties": {
"title": { "type": "string" },
"icon": { "type": "string" },
"type": { "type": "string" },
"summary": { "type": "string" },
"url": { "type": "string", "format": "uri" },
"color": { "type": "string" },
"properties": {
"type": "object",
"additionalProperties": {
"anyOf": [{ "type": "string" }, { "type": "number" }]
}
},
"height": { "type": "number" },
"menu": {
"type": "array",
"items": {
"type": "object",
"properties": {
"label": { "type": "string" },
"url": { "type": "string", "format": "uri" }
},
"required": ["label"],
"additionalProperties": false
}
}
},
"required": ["title"],
"additionalProperties": false
},
"externalSystem": {
"type": "object",
"properties": {
"name": { "type": "string" },
"summary": { "type": "string" },
"url": { "type": "string", "format": "uri" }
},
"required": ["name"],
"additionalProperties": false
},
"next_step": { "$ref": "#/definitions/flowStep" },
"next_steps": {
"type": "array",
"items": { "$ref": "#/definitions/flowStep" }
}
},
"required": ["id", "title"],
"additionalProperties": false
}
}
},
"required": ["steps"],
"additionalProperties": true,
"definitions": {
"flowStep": {
"type": "object",
"properties": {
"id": {
"anyOf": [{ "type": "string" }, { "type": "number" }]
},
"condition": { "type": "string" }
},
"required": ["id"],
"additionalProperties": false
}
}
}
\`\`\`
## Guidelines for Good Flows:
1. **Start with a trigger**: What initiates this flow? (user action, system event, scheduled task)
2. **Include decision points**: Use \`next_steps\` (plural) for branching logic
3. **Handle failures**: Always include error/failure paths where relevant
4. **End clearly**: Have definitive end states
5. **Use descriptive IDs**: Make step IDs self-documenting (e.g., "payment_processed" not "step_3")
6. **Add transition labels**: Explain why/when each transition occurs
7. **Keep it business-focused**: Focus on business logic, not technical implementation
## Example Patterns:
### Sequential Flow:
\`\`\`yaml
- id: "step_1"
title: "Start Process"
next_step: "step_2"
\`\`\`
### Branching Flow:
\`\`\`yaml
- id: "decision_point"
title: "Check Condition"
message:
id: ConditionChecked
version: 1.0.0
next_steps:
- id: "success_path"
label: "Condition met"
- id: "failure_path"
label: "Condition not met"
\`\`\`
### Convergence:
\`\`\`yaml
- id: "final_step"
title: "Process Complete"
message:
id: ProcessCompleted
version: 1.0.0
\`\`\`
## Common Business Flows to Consider:
- **Payment flows**: Include authorization, processing, success/failure handling
- **User registration**: Validation, account creation, verification, welcome
- **Order fulfillment**: Order placement, inventory check, shipping, delivery
- **Support tickets**: Creation, assignment, resolution, feedback
- **Subscription management**: Sign-up, renewal, cancellation, reactivation
- **Content publishing**: Draft, review, approval, publication
- **Refund processing**: Request, validation, approval, execution
## Output Requirements:
1. Generate a complete, valid markdown file
2. Include realistic version numbers for messages
3. Create logical, business-appropriate step sequences
4. Ensure all paths eventually terminate
5. Use proper YAML formatting in the frontmatter
6. Include the \`<NodeGraph />\` component at the end
7. Make IDs consistent and meaningful
8. Add helpful transition labels for clarity
Now, when given a business process description, create a comprehensive flow following these guidelines.`;