Build Skill — SOP Production Workflow

How to Use This Skill

Follow this workflow in order for every SOP build. Do not skip steps. Do not jump ahead to building before the gap protocol is complete. The gap protocol exists to protect the quality of the deliverable and the trust of the engagement.

Step 1: Read Reference Data

Before anything else — before reading the source material, before opening the extraction transcript — read the client's reference data file.

The reference data file is the canonical source for:

• Every team member's correct name spelling and title
• Every tool's correct name
• Company name and variations
• Any transcript override notes (e.g., "transcript renders as 'Jennifer' — correct to Jheanifer")

Every proper noun in the SOP must match reference data, regardless of what the transcript, draft, or other source material says. Reference data wins every time.

Step 2: Read the Source Material

Routing Check — Run This First

Is an extraction interview available for this process?

• Yes — interview transcript or detailed session notes exist → proceed. Read the transcript as the primary source.
• No — only a pre-written draft, a brief, or no source material exists → stop here. Do not read source material yet. Go to 06-sop-consultant-methodology.md and conduct the extraction interview first. Return to this step after the transcript is available.

If the advisor confirms that a draft-only build is intentional (e.g., a working draft for client review before full extraction) — document that decision and proceed with the understanding that significant gaps will exist and the output is not production-ready.

Source Material

Read all available source material in this order:

• Extraction interview transcript (primary source — read this first and most carefully)
• Pre-written draft or brief, if any (supplementary — captures principles, not operational detail)
• Session notes or advisor observations
• Prior SOPs for this client (for context on how processes connect — not as a content source)

As you read, note what is explicitly stated vs. what is implied. Only explicitly stated content can be used. Implied content is a gap.

Step 3: Identify Gaps

After reading all source material, work through the Required Inputs table in 01-sop-context.md. For each required input, determine:

• Present: The source material explicitly provides this information
• Gap: The source material does not provide this information

Common gaps when a pre-written draft is the primary source:

• Process owner not designated
• Team roster not specified
• Phase structure not defined
• Step-level What/When/Who not captured
• Step ownership not confirmed per step
• Status tags not defined
• Decision authority not confirmed
• Parking lot items not surfaced

Document every gap. Use the gap report format from 01-sop-context.md.

Step 4: Stop — Present Gap Report to Advisor

Do not proceed to building until every gap is resolved.

Present the gap report to the advisor. For each gap, specify:

• What information is missing
• Which section of the SOP it affects
• What the advisor needs to find out (and from whom)

The advisor decides how each gap gets filled:

• Schedule a targeted extraction session for major gaps (process owner designation, full team roster, step-level detail)
• Send a specific follow-up question to the client for minor gaps
• Make a documented advisor decision where the advisor has sufficient context

Do not suggest answers to fill gaps. Surface them and wait.

When the advisor provides resolutions, record them in the gap report resolution log. Mark each gap RESOLVED before building.

Step 5: Determine SOP Type

After gaps are resolved, confirm which type to build:

When in doubt: if more than one person touches it, it's a Human SOP.

Step 6: Open the Golden Example

Open the correct golden example in a browser:

• Human SOP → 03a-sop-golden-example-human.md (references Month-End Close file)
• Agent SOP → 03b-sop-golden-example-agent.md (references CEO Memo file)

Extract the exact CSS values documented in the golden example file. Do not work from memory. Write them down before building.

Then open the client deployment kit and confirm any client-specific overrides (role badge colors, brand variations). The deployment kit's values override the vault values where specified.

Step 7: Build

Build the SOP using the source material — extraction interview, gap resolutions, reference data — and the styling values from the golden example and deployment kit.

Build Order (Human SOP)

Build sections in this order. Complete each section before starting the next.

1. Header — Document title, subtitle, version badge, client brand name
2. Overview — Description paragraph (Cormorant Garamond, 1.15rem) + meta grid (Process Owner, Scope, Platform, Cadence)
3. Team Roster — Grid of roles with color-coded badges. Every person from the extraction. Responsibilities written for this process specifically.
4. Before the Process Begins — Readiness conditions with .context-bar left borders. Not checkboxes. Not tasks.
5. Process Flow — Hand-built HTML/CSS diagram. No Mermaid. Phases, decision points, path labels, exception paths.
6. Process Guide — Expandable step cards organized by phase. Each card: step number, title, role owner tags, summary, What/When/Who detail, gates/flags if any.
7. Recurring Checkpoints — Cross-phase monitoring item. Navy background with gold left border.
8. Monthly Rhythm & Checkpoints — Dark navy block. Timeline + role checkpoints. All text cream at opacity — no gold, no green.
9. Quick Reference — Status tags, decision authority, key definitions, escalation protocol.
10. Parking Lot — Items from extraction only. "No build assigned." at end of each item.
11. Review Schedule — Owner, last updated, next review, version notes.
12. Footer — Client brand name (line 1) + Document Title · Version · Month Year (line 2). No Advisory OS. No consultant name.

Build Order (Agent SOP)

1. Header — Document title, subtitle, version badge, client brand name
2. Overview — Description paragraph + 3-column meta grid (Owner, Duration, Output)
3. Owner Line — Single line: Owner: [Role] ([Name])
4. Before You Begin — Readiness conditions with .context-bar left borders
5. Process Flow — Hand-built HTML/CSS. Linear flow with one or two decision points. No phase system.
6. Process Guide — Brief step descriptions. What happens at each step — not expandable cards.
7. Executable Workflow — Dark navy block with copy button. JetBrains Mono. The workflow text is the core deliverable.
8. Recurring Checkpoint — Simple cadence block.
9. Review Schedule — Owner, last updated, next review, version notes (replaces Parking Lot for Agent SOPs).
10. Footer — Same format as Human SOP.

Content Rules

• Write for the person doing the work. Every step should be actionable by the named owner without interpretation.
• Step summaries: one sentence, action-first. "Complete transaction categorization" not "This step covers the transaction categorization process."
• No roadmap language in step cards. SOPs document how things work now, not what's planned.
• If something is pending (a template, a tool, a decision): use a Pending note and reference the build number.
• Questions from executors go to the process owner via the designated tool. State this explicitly in the relevant steps.
• The SOP is a standalone document. Do not reference the project plan, blueprint, or engagement structure.

Process Flow Diagram Rules

• Hand-built HTML/CSS only. No Mermaid. No diagram library.
• Phase boxes: phase color with white text
• Decision points: bordered boxes with black text
• Path labels (YES, NOT READY, RESOLVED, etc.): small caps between connector lines
• NOT READY label: red (#8b4049)
• NOT READY connector lines: amber (#ca8a04) — two different colors on the same path
• Happy path: continuous, no breaks
• Parallel paths: CSS grid, both columns filled
• T-junctions: vertical stem from decision box, horizontal crossbar, vertical drops from crossbar endpoints. Crossbar must align exactly with where the drops begin.
• Connector lines: 2px wide

Step 8: Run Gate 2 QC

After completing the build, run the Gate 2 checklist from 04-sop-quality.md.

Run the checks in order:

1. Encoding (first — any encoding artifact is a blocking failure)
2. Content accuracy
3. Structure
4. Reference data compliance
5. Type-specific checks (Human or Agent)
6. Visual verification (mandatory — open in browser)

Fix every blocking failure before proceeding. After fixing, re-run the full Gate 2 checklist. A fix may introduce a new issue.

Step 9: Deliver for Advisor Review

After Gate 2 passes:

• Save the file to the correct output location per the deployment kit
• Note any warnings from QC (items to address in the next revision)
• Present to advisor for review

The SOP does not go to the client until the advisor reviews and approves.

When the Source Is a Pre-Written Draft

If the primary source is a pre-written draft (a brief, a PDF, a Google Doc) rather than an extraction interview:

1. Read the draft carefully and extract everything that is explicitly stated
2. Work through the Required Inputs table — every item not covered by the draft is a gap
3. Expect significant gaps: process owner, team roster, step-level What/When/Who, phase structure, decision authority are almost never in a draft
4. Present the gap report to the advisor before building
5. Do not start building until extraction fills the gaps

A draft-only build is not complete. It may be useful as a quick reference document or a starting point for the client's internal use, but it is not a production-quality SOP and should not be labeled as one.

When Building a Revision

When new information surfaces (from a session transcript, stakeholder feedback, or implementation observation) that requires updating an existing SOP:

1. Read the current SOP version
2. Identify specifically what changed — step content, ownership, team roster, platform, process structure
3. Update only the changed sections
4. Run Gate 2 QC on the full document after updating
5. Increment the version number
6. Update the Review Schedule version notes with what changed

Do not use a revision as an opportunity to rewrite sections that weren't changed. Update what changed, QC the full document, deliver.