From memstack
Generates structured Standard Operating Procedures (SOPs), runbooks, and playbooks for repeatable processes with prerequisites, numbered steps, decision points, verifications, rollbacks, and time estimates.
npx claudepluginhub cwinvestments/memstack --plugin memstackThis skill uses the workspace's default tool permissions.
*Generates a structured Standard Operating Procedure with numbered steps, prerequisites, decision points, verification checkpoints, rollback steps, and time estimates.*
Generates detailed Standard Operating Procedures (SOPs) from business process descriptions, with clarifying questions and business context integration. Useful for process docs, operational guides, workflows.
Structures Standard Operating Procedures (SOPs) with core sections (Title, Overview, Parameters, Steps), .sop.md naming conventions, and markdown formatting best practices. Use for consistent workflow documentation.
Creates operational runbooks, playbooks, SOPs, and incident response guides for incident procedures, on-call rotations, system maintenance, and escalations.
Share bugs, ideas, or general feedback.
Generates a structured Standard Operating Procedure with numbered steps, prerequisites, decision points, verification checkpoints, rollback steps, and time estimates.
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 |
| 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. |
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:
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:
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
Verification:
dist/ directory contains updated filesIf it fails:
npm ci and retry
**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:
can fail: Yes step gets a decision tableMajor milestones get dedicated verification steps:
### Checkpoint A: Pre-deployment verification
**Time estimate:** ~3 minutes
Before proceeding to deployment, verify ALL of the following:
| Check | How to Verify | Expected Result |
|-------|--------------|-----------------|
| Build passes | `npm run build` exits cleanly | Exit code 0, no errors |
| Tests pass | `npm test` exits cleanly | All tests green |
| Env vars set | Railway dashboard β Variables | All vars from .env.example present |
| Database ready | `supabase status` | Database is running, migrations applied |
| Branch is clean | `git status` | No uncommitted changes |
**All checks must pass.** If any check fails, resolve it before continuing.
Do not skip checks "because it worked last time."
Checkpoint rules:
For any step that modifies state (deployment, data changes, config updates):
## Rollback Procedure
Use this procedure if deployment fails or causes issues in production.
### Rollback Step 1: Revert deployment
**Time estimate:** ~2 minutes
1. Open Railway dashboard β Deployments
2. Find the last successful deployment (green checkmark)
3. Click the three-dot menu β "Rollback to this deploy"
4. Wait for rollback to complete (typically 30-60 seconds)
**Verification:**
- [ ] Railway shows the previous deployment as active
- [ ] Health check endpoint returns 200: `curl https://[app].up.railway.app/health`
- [ ] Users can access the application
### Rollback Step 2: Revert database migration (if applicable)
**Time estimate:** ~5 minutes
1. Run the rollback migration:
```bash
supabase db execute --file supabase/migrations/[number]_rollback.sql
WARNING: Database rollbacks may cause data loss if the forward migration added columns that received data. Assess the risk before proceeding.
**Rollback rules:**
- Every deployment/migration step needs a corresponding rollback
- Rollback steps are just as detailed as forward steps
- Include data loss warnings where applicable
- Always end rollback with team notification
### Step 7: Add Time Estimates
Summarize the total time at the top of the document:
```markdown
## Time Summary
| Phase | Estimated Time |
|-------|---------------|
| Prerequisites check | 5 minutes |
| Steps 1-3 (preparation) | 15 minutes |
| Steps 4-6 (execution) | 20 minutes |
| Steps 7-8 (verification) | 10 minutes |
| **Total (happy path)** | **~50 minutes** |
| **Total (with 1 failure + rollback)** | **~75 minutes** |
**Schedule buffer:** Block 1.5x the happy path time on your calendar.
Time estimate rules:
Output the complete SOP:
# SOP: [Process Name]
| Field | Value |
|-------|-------|
| **Version** | 1.0 |
| **Last updated** | YYYY-MM-DD |
| **Author** | [Name] |
| **Audience** | [Who follows this SOP] |
| **Trigger** | [When to run this process] |
| **Frequency** | [How often] |
| **Estimated time** | [Happy path total] |
| **Critical** | [Yes/No β does failure cause downtime?] |
---
## Table of Contents
1. [Prerequisites](#prerequisites)
2. [Procedure](#procedure)
- Step 1: [title]
- Step 2: [title]
- ...
- Checkpoint A: [title]
- Step N: [title]
3. [Rollback Procedure](#rollback-procedure)
4. [Time Summary](#time-summary)
5. [Change Log](#change-log)
---
[Prerequisites section]
[Procedure section with steps, decision points, checkpoints]
[Rollback Procedure section]
[Time Summary section]
---
## Change Log
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | YYYY-MM-DD | [Name] | Initial version |
Output summary:
π SOP Builder β Complete
Process: [name]
Audience: [who]
Steps: [count] steps, [count] decision points, [count] checkpoints
Rollback: [count] rollback steps
Estimated time: [happy path] / [with failure]
Document: [word count] words
Next steps:
1. Review steps with someone who runs this process
2. Do a dry run following the SOP exactly
3. Store in team wiki/docs and link from relevant README
4. Schedule quarterly review to keep it current