Sop Forge

sop-forge

Point this at something the user did. It writes the SOP, because Littlebird watched them do it.

Purpose

"Document how I built that GoHighLevel workflow last Thursday" returns a numbered procedure with the actual screens, field names, triggers, and settings that were on screen, each step carrying the timestamp the user can open in the Littlebird app to see the original capture. Not a generic tutorial.

The published best practice for a first SOP draft is to observe the actual procedure being performed and write down every step in order [references/research/raw/sop--formats--psu-extension-writing-guide.md, via references/research/distilled-sop-craft.md section 6]. This skill runs that observation against capture instead of standing behind someone with a clipboard.

Littlebird MCP calls used

No routine tools. See routine cadence below.

Trigger

Invoke when the user says any of: write an SOP, document how I did that, turn last Thursday into a procedure, make this repeatable, write it up so I can hand it off, document this process, write the training script for this, turn this into a checklist.

The trigger has a shape: it points at work that was already performed on a specific day in specific applications. A request for a generic tutorial is not this skill.

Routine cadence

None. On-demand only. A routine is an unattended observer that produces one report in one pass, and this skill has a mandatory human redaction gate and an AskUserQuestion confirmation before it writes a file, neither of which a routine can do. The full reasoning and the correct alternative shape are in the routine wiring section below.

Capability gate

This skill requires the Littlebird MCP on a Power or Pro plan. Before doing anything else:

1. List the tools actually available in this session. Use the real tool names you find. Do not assume the names in references/littlebird-mcp-reference.md are still exact. That file is verified as of 2026-08-17 and is a starting point, not a contract.
2. If no Littlebird tools are present, stop. Tell the user this skill needs the Littlebird MCP connected, and that it cannot be run from memory or from a description of what they did.
3. If the plan gate is in doubt, call the subscription status tool to check before promising a reconstruction.

There is no degraded mode. A skill that writes an SOP without capture is writing fiction, and the entire value of this one is that its steps were observed.

Do this first, every time

Read these two, in this order, before you touch retrieval:

1. references/evidence-standards.md - the receipt format, the observed / inferred / external / unknown split, the attribution guardrail, and the confirmation gates.
2. references/littlebird-mcp-reference.md - tool parameters, return shapes, and the known limitations you have to design around.

Then read references/session-reconstruction.md and follow it. The other three guides load at the stage that needs them.

Process

Stage 5 runs before stage 6, so the read-back does not itself display secrets. Stage 5 never gets skipped, not for any output mode, not when the user says the session was harmless.

Retrieval brief

The exact queries. Full parameter shapes and the reasoning are in references/session-reconstruction.md step 3.

Step A. Session boundaries. search_user_context with filters: {"data_source": "summaries"}, date_range fixed to the target date. Queries: ["work session on <artifact or task>", "what was worked on"]. This is the cheapest way to get the shape of the day and it supplies the apps for step B (references/littlebird-mcp-reference.md, retrieval pattern 3).

Step B. App time-window sweep. One call per app, filters: {"app": "<app>", "data_source": "snapshots"}, date_range narrowed to the session window found in step A. Five narrow queries, not one broad one (references/littlebird-mcp-reference.md, retrieval pattern 1):

1. "<app> screen showing configuration settings"
2. "<app> form fields and input values"
3. "<app> navigation menu and page headers"
4. "<app> save publish or confirm action"
5. "<app> error message or validation warning"

Query 5 is not optional. It is how the branches and the dead ends surface, and the branches are half the value of the finished SOP.

Split windows longer than about two hours into sub-windows. A single sweep across a long session exceeds the tool result limit and gets written to a file instead (references/littlebird-mcp-reference.md, "Oversized results").

Step C. Artifact topic sweep. Not app-filtered. date_range widened two days either side of the session, because work gets revisited and a later snapshot of the finished artifact is the best evidence of the final configuration. Queries: ["<artifact name>", "<artifact name> settings and configuration", "<artifact name> steps or actions"].

Step D. Prerequisites sweep. filters: {"data_source": "snapshots"}, window starting 30 minutes before the session. Queries: ["login screen or account selector", "settings integrations or connected accounts", "permissions role or access denied", "browser tabs open before the task"]. Setup happens before the work.

Step E, only if the session was a screen share or a call. Meeting lookup by NAME uses the list-meetings tool with name. Lookup by TOPIC uses the search-meetings tool with query. Using the wrong one is the most common retrieval mistake against this server (references/littlebird-mcp-reference.md, retrieval pattern 6). If the session was narrated, pull the transcript: it carries the spoken reasoning the pixels do not.

Then sort by timestamp. Retrieval is relevance-ordered, not chronological (references/littlebird-mcp-reference.md, known limitations). Sort before writing anything.

Deduplicate before you count anything

Screen capture of one UI state produces many near-identical snapshots. A naive pass produces an SOP with the same step eleven times. OCR of dense UI produces fragments, duplicate lines, and interleaved chrome, and repeated identical lines are one observation (references/littlebird-mcp-reference.md, known limitations).

Build a timestamp-sorted JSON timeline and run:

python3 scripts/dedupe_snapshots.py timeline.json --scan-secrets --json states.json

It groups frames into distinct UI states on three signals (text similarity, time adjacency, app continuity), emits the frame with the most extracted text as each state's representative, and flags states worth checking by hand. --scan-secrets runs a structural credential scan and never prints a matched value.

Read the output. Do not trust it blindly. Two states the script merged can be two real steps on a screen that barely changed. See references/session-reconstruction.md step 5.

Evidence standards

Apply references/evidence-standards.md in full. The four that bite hardest here:

• Every step carries a receipt, in the canonical form [Thursday, August 13, 2026 14:12 EDT | chrome] (rule 1). In this skill the receipt is also a navigation aid: the user opens that timestamp in the Littlebird app to see the original screen. Say so once in the provenance block.
• Observed, inferred, external, unknown are visibly different (rule 2). A step reconstructed from a clear snapshot is observed. A step whose result you concluded from the next screen is inferred and says so. A step you could not resolve is unknown and gets a gap marker.
• Rate what a reader will act on (rule 3). A Low-rated step that deletes, sends, publishes, or charges gets a stop marker telling the reader to verify before executing.
• Attribution guardrail (rule 4). Screen OCR captures what was being viewed. For this skill that lands in one specific place: a screen share shows someone else's computer. The procedure is still valid. The attribution of who performed it is not. State whose screen it was, or state that it is unknown.

Never invent a step

An honest gap marker is worth more than a plausible fabrication, because a fabricated step in an SOP gets followed. The reader is not evaluating the claim, the reader is executing it, usually without the context to notice it is wrong.

Rules, in full in references/gap-handling-and-confirmation.md:

• If states N and N+2 are captured and the action between them is not, the SOP says so. It does not write "click Save" because that is usually what happens there.
• If capture reads "Add Act", the SOP reports it as captured and marks it a gap. It does not silently write "Add Action".
• [GAP: ...] means the reconstruction could not resolve it. [YOUR_API_KEY] means it was resolved and deliberately removed. Never use the same marker for both. A reader who confuses them goes looking for a secret in a screenshot.
• Count the gaps in the provenance block. Three named gaps that the user fills in five minutes beat forty invented steps.

The redaction pass is mandatory

This is the highest-risk skill in the marketplace for accidental secret disclosure. Screen capture of real work routinely contains credentials, API keys, client names, and account identifiers, and an SOP is a document specifically built to be handed to someone who did not previously have access.

references/redaction-pass.md is not optional reading and the pass is not optional execution. Its shape:

1. Pattern sweep for credential-shaped strings, via --scan-secrets.
2. Semantic sweep by reading the values, because a client name is just a normal word and no pattern finds it.
3. Context sweep for what was around the work: tab strips, notification toasts, calendar sidebars, participant lists.
4. Placeholder replacement, not blanket blurring. The governing test is that the step stays followable after the value is removed. [YOUR_STRIPE_SECRET_KEY, from Stripe dashboard, Developers, API keys], never [REDACTED].
5. Rotation flag. Anything matching an authentication pattern was on screen, which is exposure. The deliverable carries a security notice naming the field and the step, never the value.
6. Disclosure with a count. The provenance block states how many values were redacted and in which categories, so the reader can tell a removal from a gap.

Automated redaction is a first pass, not a guarantee. The archive puts state-of-the-art automated redaction at a 79.1% zero-leak rate, which is roughly one document in five still leaking [references/research/distilled-sop-craft.md section 8]. The human confirmation gate is what closes that.

Confirm before you finalize

Read the reconstructed sequence back to the user with AskUserQuestion before rendering. This mirrors the validated method in the cognitive task analysis literature, where the interviewer narrates the reconstructed account back to the participant for correction [references/research/distilled-sop-craft.md section 5].

The user knows which steps were incidental. Recognition is easier than recall: shown a sequence, they will immediately tell you that step 4 was them checking something unrelated and step 9 only happened because of a stale cache.

Confirm the session boundary, the steps you classified as incidental or abandoned, the Low-confidence readings, the fragmentary labels, the traps, and the output mode. Do not confirm every High-confidence step individually, which is just asking the user to write the SOP themselves. Full question set in references/gap-handling-and-confirmation.md part 2.

Output

One markdown file, written to the working directory, named by mode:

<slug> is a kebab-case name for the procedure, taken from the artifact or outcome, not from the tool. build-tag-triggered-nurture-workflow, not gohighlevel-stuff.

Every mode contains, in this order: title, provenance block with counts, security notice if credentials were found, values you will need, gaps to fill, prerequisites, the procedure, decision points, traps where they earned a place, how you know it worked, and the validation and review block with owner, version, and next review date. Structures and worked examples in references/sop-formats.md.

Format selection follows the published matrix: 10 steps or fewer with few decisions goes step-by-step, longer goes hierarchical, many decisions goes flowchart, and consistency between two different people doing the task pushes toward hierarchical regardless of length [references/research/distilled-sop-craft.md section 1].

Delete the working timeline and the raw retrieval once the deliverable is written. Raw capture never ships (references/evidence-standards.md rule 7).

Empty retrieval

A failed or empty retrieval ends the run. Never fabricate to fill a gap (references/evidence-standards.md rule 9). A skill that reports "I found nothing for this window" is doing its job correctly.

Guardrail

This skill carries two risks that no other skill in the marketplace carries in this combination, and both come from the same fact: an SOP is written to be handed to someone who did not previously have access, and it is executed rather than evaluated.

Risk one: the deliverable discloses what was on screen. Screen capture of real work routinely contains API keys, session tokens, passwords in plain fields, client names, account identifiers, invoice numbers, and whatever sat in the tab strip, the notification toasts, and the calendar sidebar around the work. A client-facing procedure that names a different client is a breach of one relationship and an embarrassment in the other. The redaction pass is the control, it runs at stage 5 before the read-back so the confirmation itself does not display secrets, and it never gets skipped, not for any output mode and not when the user says the session was harmless. Automated redaction is a first pass and not a guarantee: the archive puts state-of-the-art automated redaction at a 79.1% zero-leak rate, roughly one document in five still leaking [references/research/distilled-sop-craft.md section 8]. The human gate is what closes it. Anything matching an authentication pattern was on screen, which is exposure, so it also raises a rotation flag naming the field and the step and never the value. Full procedure in references/redaction-pass.md.

Risk two: a fabricated step gets followed literally. The reader of an SOP is not weighing the claim, they are executing it, usually without the context to notice that step 7 is wrong. A plausible invention is therefore worse than an honest hole, which is why an unresolved action becomes a [GAP: ...] marker rather than the step that usually goes there, why a fragmentary OCR label like "Add Act" is reported as captured and marked a gap rather than silently completed, and why the gap count appears in the provenance block. A Low-rated step that deletes, sends, publishes, or charges carries a stop marker telling the reader to verify before executing [references/evidence-standards.md rule 3].

The two markers are never interchangeable. [GAP: ...] means the reconstruction could not resolve it. [YOUR_API_KEY] means it was resolved and deliberately removed. A reader who confuses them goes looking for a secret in a screenshot.

Routine wiring

None. This skill is on-demand only.

Stated explicitly rather than left as an omission, because the reason is a real constraint. A routine is an unattended observer that produces one report in one pass. This skill runs multi-sweep retrieval, a mandatory human redaction gate, and an AskUserQuestion confirmation before it produces a file deliverable. Routines cannot do approvals and cannot write file deliverables (references/littlebird-mcp-reference.md, "Do not ask a routine to do work it cannot finish unattended in one pass").

If the user wants recurring documentation coverage, the correct shape is the Routines-observe, Cowork-acts pattern: a separate routine watches for undocumented recurring work and writes a report naming it, then the user opens Cowork and runs sop-forge against the session the routine flagged. That routine is not part of this skill and is not created by it.

Related skills

Ship Gate removed, research-only skill, produces no committable code.

Reference map

Three of this skill's design decisions are not evidenced by the research archive and are labelled as design decisions rather than researched practice: frame deduplication, the happy-path-versus-flailing split, and the premise that documentation cost is what stops small operators from delegating. See references/research/distilled-sop-craft.md section 11.