/create-workflow
Use this when you discover a repeatable process during a session — an investigation type, a setup procedure, a debugging pattern — that should be captured as a reusable workflow.
From laravel-api-tool-kitnpx claudepluginhub ahmedesa/laravel-api-tool-kitlaravel-api-tool-kit/workflows/Workflow: Create a New Workflow
Use this when you discover a repeatable process during a session — an investigation type, a setup procedure, a debugging pattern — that should be captured as a reusable workflow.
Trigger phrases: "create workflow", "make a workflow for this", "save this as a workflow", "this should be a workflow", /create-workflow
Also trigger proactively — if you just finished an investigation or multi-step process and realize someone will hit this again, suggest creating a workflow.
When to Create a Workflow
A workflow is worth creating when:
- You just completed a multi-step process that took real effort to figure out
- The steps would be the same next time (not a one-off)
- Someone (including future-you) would otherwise have to rediscover these steps
- The knowledge doesn't fit in a rule file (it's procedural, not declarative)
Examples from real projects:
server-investigator.md— born from debugging a staging server with no root accessfirebase-investigator.md— born from setting up Firebase across 3 platformsstripe-integration.md— born from integrating Stripe subscriptions with DDD
Step 1 — Extract the Process
Review the current conversation and identify:
- What was the goal? (e.g., "Debug why emails aren't sending on staging")
- What steps did you take? List them in order
- What was non-obvious? Which steps required trial-and-error or knowledge you didn't have?
- What would you do differently next time? Optimize the path
- What tools/commands were needed? (artisan, SQL, curl, ssh, etc.)
Step 2 — Structure the Workflow
Use this template:
# Workflow: [Name] ([Short Context])
[One sentence: when to use this workflow.]
**Trigger phrases**: "[keyword1]", "[keyword2]", `/[command-name]`
---
## Prerequisites
- [What must be true before starting]
- [Required access, tools, or packages]
---
## Architecture / Context
[Brief description of HOW the system works, so the reader understands
WHY the steps are in this order. Include:]
- Key files / tables / services involved
- Common configurations
- Constraints (no root access, specific PHP version, etc.)
---
## Investigation / Execution Steps
### Step 1: [First thing to check/do]
[Why this step first]
\`\`\`bash
[Command or query]
\`\`\`
[What to look for in the output]
### Step 2: [Next step]
...
---
## Common Scenarios & Fixes
### Scenario A: [Problem Title]
**Symptom**: [What you see]
**Cause**: [Why it happens]
**Fix**:
\`\`\`bash
[Command or code to fix]
\`\`\`
### Scenario B: [Problem Title]
...
---
## Anti-Patterns / Usage Rules
- NEVER [common mistake that wastes time]
- ALWAYS [thing that saves time]
- If [condition] → [do this instead]
Step 3 — Include Battle-Tested Commands
If the workflow involves commands, include the EXACT commands that worked — not generic examples. Include:
- Artisan commands with real flags
- SQL queries with placeholder variables (
STORE_ID,USER_ID) - Curl commands with correct headers
- SSH/server commands with correct paths
- Tinker one-liners
These are the most valuable part. A workflow without commands is just documentation.
Step 4 — Add Common Scenarios
The best workflows have a "Scenarios & Fixes" section that covers:
- The 3-5 most common variations of this problem
- Symptoms → Cause → Fix for each
- Specific error messages and what they mean
This turns an investigation workflow into a lookup table — next time you see the symptom, you skip straight to the fix.
Step 5 — Place the File
Save to workflows/[descriptive-name].md:
- Investigation workflows:
workflows/[feature]-investigator.md - Setup procedures:
workflows/[feature]-setup.md - Integration guides:
workflows/[service]-integration.md - Operational runbooks:
workflows/[operation]-runbook.md
Then update the main skill entry point (SKILL.md or instructions.md) → "Available Workflows" section.
Step 6 — Report
Tell the user:
Created workflows/queue-debugger.md:
→ 5 investigation steps (check failed_jobs → check Horizon → check listener → ...)
→ 3 common scenarios (Redis down, listener exception, job serialization)
→ 8 diagnostic commands
Updated SKILL.md → Added to Available Workflows list
Quality Checklist
Before saving, verify:
- Trigger phrases are natural (what would someone actually type?)
- Architecture section explains enough context to follow the steps
- Steps are in the order you'd actually do them (optimized, not chronological)
- Commands are copy-pasteable (real flags, correct paths)
- Common scenarios have symptom → cause → fix (not just "check X")
- Anti-patterns section prevents the time-wasting mistakes you made
- Placeholder variables used instead of real IDs (
ORDER_IDnot12345)