Slash Command

/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-kit
Install
1
Run in your terminal
$
npx claudepluginhub ahmedesa/laravel-api-tool-kit
Details
Namespacelaravel-api-tool-kit/workflows/
Command Content

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 access
  • firebase-investigator.md — born from setting up Firebase across 3 platforms
  • stripe-integration.md — born from integrating Stripe subscriptions with DDD

Step 1 — Extract the Process

Review the current conversation and identify:

  1. What was the goal? (e.g., "Debug why emails aren't sending on staging")
  2. What steps did you take? List them in order
  3. What was non-obvious? Which steps required trial-and-error or knowledge you didn't have?
  4. What would you do differently next time? Optimize the path
  5. 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_ID not 12345)
Stats
Stars525
Forks54
Last CommitMar 20, 2026