/sop-builder

name: memstack-business-sop-builder
description: "Use this skill when the user says 'create SOP', 'write SOP', 'standard operating procedure', 'document process', 'process documentation', 'runbook', 'playbook', or is creating step-by-step documentation for a repeatable process. Do NOT use for project proposals or scope documents."
version: 1.0.0
license: "Proprietary, MemStack™ Pro by CW Affiliate Investments LLC. See LICENSE.txt"

📋 SOP Builder: Documenting standard operating procedure...

*Generates a structured Standard Operating Procedure with numbered steps, prerequisites, decision points, verification checkpoints, rollback steps, and time estimates.*

Activation

When this skill activates, output:

`📋 SOP Builder, Identifying process and building procedure...`

Then execute the protocol below.

| Context | Status | |---------|--------| | User says "create SOP" or "write SOP" or "document process" | ACTIVE | | User says "runbook" or "playbook" or "process documentation" | ACTIVE | | Creating step-by-step instructions for a repeatable workflow | ACTIVE | | Writing a one-time guide or tutorial | DORMANT | | Discussing process improvement at a high level | DORMANT |

Anti-patterns

| Trap | Reality Check | |------|---------------| | "The steps are obvious" | What's obvious to you is opaque to a new team member at 2 AM. Write every step. | | "Just follow the README" | READMEs explain concepts. SOPs give exact actions in exact order. Different purpose. | | "We'll remember the edge cases" | You won't. Decision points and rollback steps are the whole point of an SOP. | | "This process never changes" | Every process changes. Version numbers and last-updated dates prevent stale docs from causing outages. | | "Anyone can figure out if it worked" | Explicit verification checkpoints ("you should see X") catch failures before they cascade. |

Protocol

Step 1: Identify the Process

If the user hasn't specified the process, ask:

> What process should this SOP document? For example: > - Deploying to production > - Onboarding a new developer > - Handling a customer bug report > - Running a database migration > - Publishing a release > - Setting up a new project

Then gather: 1. **Process name**: clear, specific title 2. **Audience**: who will follow this SOP? (developer, ops, new hire, non-technical) 3. **Trigger**: what event kicks off this process? (PR merged, customer request, scheduled) 4. **Frequency**: how often is this run? (daily, weekly, per release, ad-hoc) 5. **Critical?**: does failure cause downtime, data loss, or revenue impact?

Step 2: Define Prerequisites

List everything needed before starting:

## Prerequisites

### Required Access
| System | Access Level | How to Request |
|--------|-------------|---------------|
| GitHub | Write access to repo | Ask team lead in #dev-access |
| Railway | Deploy permissions | Railway dashboard → Team → Invite |
| Supabase | Database admin | Supabase dashboard → Settings → Team |
| AWS S3 | Read/write to production bucket | IT ticket #aws-access |

### Required Tools
| Tool | Version | Install Command |
|------|---------|----------------|
| Node.js | 20+ | `nvm install 20` |
| Railway CLI | Latest | `npm install -g @railway/cli` |
| Git | 2.40+ | Pre-installed on most systems |

### Required Knowledge
- Familiarity with [relevant concept]
- Completed [training/onboarding step]
- Access to [documentation/wiki link]

### Before You Begin
- [ ] Verify you have all required access (test each login)
- [ ] Pull latest code from main branch
- [ ] Notify team in [channel] that you're starting this process
- [ ] Block [estimated time] on your calendar

**Rules:**

• Every tool, login, and permission is listed: no assumptions
• Include "how to get access" for each system (not just "you need access")
• Include a pre-flight checklist the operator runs before step 1

Step 3: Write Numbered Steps

Each step follows a strict format:

## Procedure

### Step 1: [Action verb] [specific thing]
**Time estimate:** ~5 minutes
**Can fail:** Yes

**Action:**
1. Navigate to [specific location]
2. Run the following command:
   ```bash
   npm run build

3. Wait for the build to complete (typically 1-3 minutes)

**Verification:**

• [ ] Build output shows "Build successful" with zero errors
• [ ] `dist/` directory contains updated files
• [ ] File count is similar to previous build (sanity check)

**If it fails:**

• Build error with dependency issue → Run `npm ci` and retry
• Build error with TypeScript type error → Fix the type error, commit, and restart from Step 1
• Build times out (> 10 minutes) → Check for infinite loops in recent changes

**Step writing rules:**
- Start every step title with an **action verb** (Run, Open, Navigate, Verify, Configure)
- No vague steps ("set up the environment"), every action is copy-pasteable or clickable
- Include the **exact command**, **exact URL**, or **exact menu path**
- Mark whether each step **can fail**: if yes, it needs verification and failure handling
- Time estimates help the operator know if something is taking too long

### Step 4: Add Decision Points

For steps with branching logic, use clear if/then formatting:

```markdown
### Step 4: Check migration status
**Time estimate:** ~2 minutes
**Can fail:** Yes

**Action:**
1. Run: `supabase migration list`
2. Review the output

**Decision point:**

| Situation | Action |
|-----------|--------|
| All migrations show `applied` | Continue to Step 5 |
| One migration shows `pending` | Run `supabase db push` then re-check |
| Migration shows `failed` | Stop. Go to Rollback Procedure below |
| Connection refused error | Verify VPN is connected, retry in 30 seconds |
| Unknown error | Screenshot the error, post in #dev-help, wait for response |

**Do NOT continue to Step 5 until all migrations show `applied`.**

**Decision point rules:**

• Every `can fail: Yes` step gets a decision table
• Cover the 3-5 most