mattrguerra.comHouston area
Matt Guerra
  1. 01AI & Automation
  2. 02Photography
  3. 03Design
  4. 04About
  5. 05Notes
  6. 06Contact
Back to the systems

mattrguerra/meridian-skillsmainPrivate on GitHub, published here in full

SKILL.md

Markdown14.0 KB194 lines

skills/sop-author/SKILL.md

  1. ---
  2. name: sop-author
  3. description: >-
  4. Draft a Standard Operating Procedure (SOP) in Meridian Display Co.'s company .docx format. Use
  5. whenever the user asks to write, draft, build, format, or update an SOP for Meridian: workflow
  6. SOPs, process SOPs, naming-convention SOPs, policy SOPs, or any internal procedure document.
  7. Trigger phrases include 'draft an SOP for X', 'write an SOP', 'we need an SOP for [process]',
  8. 'make me an SOP', 'turn this process into an SOP', 'format this as an SOP', 'build the SOP for
  9. [topic]', or any variant. The skill encodes the required Meridian SOP shape (title bar, 4-column
  10. metadata table, Heading-1 sections including Purpose, Scope & Responsibility, Best Practices,
  11. Quick Reference Card), the Meridian visual style (Arial 11pt body, monospace navy for filenames
  12. and code, bold navy accent subheads), and the filename pattern
  13. SOP_[Title]_[MM-YYYY]_[Initials].docx. Output is always a .docx. Do not produce Meridian SOPs in
  14. markdown or plain text.
  15. ---
  17. # Meridian SOP Author
  19. This skill produces a company-standard SOP for Meridian Display Co. as a .docx file matching the template defined in `assets/template.docx`.
  21. Meridian SOPs live in the Google Shared Drive under `00 - SOPs & How To Guides`. They follow a tight visual standard: a title bar at the top, a four-column metadata table, then Heading-1 sections. Any SOP that doesn't match the standard sticks out in the Drive and signals "not yet ratified." The point of this skill is to make every new SOP indistinguishable in shape from an SOP Ines, Matt, or anyone else has already shipped.
  23. ## When to use
  25. Any time the user asks for an SOP for Meridian Display Co. The trigger is the word "SOP" plus an intent to produce a document. The skill applies whether the SOP is for operations, design, fulfillment, HR, marketing, sales, or any other department. The format is universal across departments; only the content varies.
  27. Do not use this skill for:
  29. - **One-off internal notes or how-tos that aren't being ratified as company procedure.** Those are docs, not SOPs.
  30. - **Customer-facing documents** (quotes, proofs, order confirmations).
  31. - **Vault notes inside Obsidian or other Markdown systems.** This skill emits .docx only.
  33. If the user is unclear whether they want a one-off doc or a formal SOP, ask: "Formal SOP for the Shared Drive, or just an internal note?"
  35. ## The Meridian SOP filename pattern
  37. Every SOP is saved as:
  39. ```
  40. SOP_<Process Title>_<MM-YYYY>_<Author Initials>.docx
  41. ```
  43. - `Process Title` uses Title Case, spaces between words. Some past SOPs join words with hyphens; the company standard documented in Ines's G-Drive SOP allows spaces. Use spaces for readability unless the user specifies otherwise.
  44. - `MM-YYYY` uses a dash between month and year in the *filename* (Windows / macOS / Drive don't allow `/` in filenames). Inside the document body, the date is rendered with a slash: `04/2026`.
  45. - `Author Initials` are the standard two-letter team initials (MG = Matt Guerra, IC = Ines Carvalho, etc.). Ask the user for theirs if not provided.
  47. Examples that match:
  49. ```
  50. SOP_Client Onboarding_07-2025_HO.docx
  51. SOP_Mockup File Naming Convention_04-2026_MG.docx
  52. SOP_G-Drive File Saving and Naming Format_09-2025_IC.docx
  53. ```
  55. Examples that don't match (do not produce these):
  57. ```
  58. SOP.docx (no title, no date, no initials)
  59. sop_client_onboarding.docx (lowercase, no date, no initials)
  60. Client Onboarding SOP.docx (wrong word order, wrong separators)
  61. SOP_Client Onboarding_2025_HO.docx (no month)
  62. ```
  64. Use `_TEMPLATE` before the date for master templates (`SOP_PO Form_TEMPLATE_07-2025_TB.docx`). Use `DRAFT_` as a leading prefix for in-progress versions (`DRAFT_SOP_Client Onboarding_07-2025_HO.docx`).
  66. ## Required shape
  68. Every Meridian SOP, regardless of content, has this structure:
  70. 1. **Title bar (1-cell table at the very top):** one row, two-line content: `SOP | <Process Title>` on line 1, `<Folder context or scope>` on line 2.
  71. 2. **Metadata table (4-column, 2-row):** header row `File Name | Category | Owner | Effective Date`; the data row carries the values.
  72. 3. **`Purpose` (Heading 1):** one or two sentences answering "what does this SOP define and why does it exist."
  73. 4. **`Scope & Responsibility` (Heading 1):** who the SOP applies to and where (folder paths, departments, roles).
  74. 5. **Body sections (Heading 1 each):** the actual procedure. Section names vary by SOP type. Naming-convention SOPs use sections like "Folder Structure", "Naming Convention", "Components", "Examples", "Rules & Best Practices". Workflow SOPs use numbered sections (1. X, 1.1 X.X, 2. Y). Policy SOPs use "Policy", "Procedure", "Responsibilities". Pick what fits the content; never invent unfamiliar section names.
  75. 6. **Quick Reference Card (Heading 1):** a condensed summary at the end. For naming SOPs, this is a code table showing the format + a worked example. For workflow SOPs, this is a numbered list of the high-level steps.
  76. 7. **(Optional) How To Find Past Files / Related Resources (Heading 1):** appears in naming-convention SOPs that document existing file archives.
  78. The metadata table also appears at the *end* of some SOPs (Ines's G-Drive SOP uses a 5-row 2-col footer table with File Name, Category, Owner, Effective Date, Updated Date). Either pattern is acceptable. Default to the 4-col header table at the top; add the footer table only if the SOP is going to be revised on a known cadence and needs an Updated Date field.
  80. ## Required Meridian styling
  82. These are the company's visual standards. The template asset already encodes them; if you build via the helper script (recommended), you get them for free. If you build by hand, match:
  84. - **Body text:** Arial, 11pt, color #000000 (black).
  85. - **Heading 1:** Word's "Heading 1" style. Section titles.
  86. - **Heading 2:** Word's "Heading 2" style. Subsections.
  87. - **Heading 3:** Word's "Heading 3" style. Sub-subsections (Components, Examples, Rules & Best Practices labels).
  88. - **Accent subhead inside a section:** Arial Bold 12pt, color #1F3A5F (Meridian navy). Used for in-section topic labels like "Versioning", "Final Version", "General Formatting Rules".
  89. - **Code, filenames, paths:** Courier New or JetBrains Mono, 10pt. When showing a filename pattern or example, use color #1F3A5F (the same Meridian navy) and bold.
  90. - **Important warnings / red callouts:** Bold red (#FF0000). Reserved for "Do not do X" instructions.
  91. - **Tables:** 3 column for Components (Component | Value | Description) and Examples (Folder | Sub DIR | File Name(s)). 4 column for the header metadata table. 1 column for quick reference / format spec boxes.
  92. - **Page margins:** 1 inch on all sides (the template uses 914400 EMU on top/bottom and either 914400 or 1143000 on left/right; both are seen in the wild).
  94. Do not introduce other colors, other fonts, or other heading levels. Meridian SOPs are visually conservative, and that's the point.
  96. ## Workflow
  98. ### 1. Intake
  100. Gather the metadata before drafting any content. Ask for whatever is missing; do not assume.
  102. - **Process Title** (what is this SOP about, in 3 to 8 words). Used in the filename and the title bar.
  103. - **Category:** one of General, Operations, Design, Fulfillment, Sales, MAS (Marketing/Automation/Sales), HR, Leadership, Finance, Websites. Pick the closest fit. If unclear, ask.
  104. - **Owner:** full name of the person who owns the procedure. Often (but not always) the same as the author.
  105. - **Owner Initials:** two-letter initials (Matt Guerra = MG, Ines Carvalho = IC, Hazel Okafor = HO, etc.). For the filename.
  106. - **Effective Date:** `MM/YYYY` format (use a slash in body content; dash in the filename). Defaults to current month if not specified.
  107. - **Folder Context:** the Shared Drive path the SOP applies to or lives in. Goes on line 2 of the title bar. Example: `00 - SOPs & How To Guides > 02 - Operations`.
  108. - **Body content:** either provided by the user or built up by asking clarifying questions about the procedure. For a workflow SOP, ask for the steps. For a naming-convention SOP, ask for the format pattern, components, examples, and rules. For a policy SOP, ask for the policy statement, scope, procedure, and responsibilities.
  110. Don't draft the body until you have at least the metadata + a clear sketch of the content. SOPs without content rot fast.
  112. ### 2. Pick the SOP type
  114. Three common shapes:
  116. - **Workflow SOP:** describes how to do a multi-step process. Sections: Purpose / Scope & Responsibility / Process (numbered steps, often grouped 1, 1.1, 1.2, 2, 2.1...) / Best Practices / Quick Reference Card. See Ines's G-Drive SOP for the canonical example.
  117. - **Naming convention / formatting SOP:** defines a file or document naming standard. Sections: Purpose / Scope & Responsibility / Folder Structure / Naming Convention (with Components table, Examples table, Rules subsections) / Quick Reference Card / How To Find Past Files. See `SOP_EXAMPLE_04-2026_MG.docx` for the canonical example.
  118. - **Policy SOP:** defines a rule or requirement. Sections: Purpose / Scope & Responsibility / Policy / Procedure / Responsibilities / Quick Reference Card.
  120. If the user's request fits one of these cleanly, use that shape. If it doesn't fit any, ask which is closest and adapt.
  122. ### 3. Build the document
  124. Two paths:
  126. **Path A: use the helper script (default; recommended).**
  128. The skill bundles `scripts/build_sop.py`. It takes a Python dict describing the SOP and produces a styled .docx. Write a small driver that calls `build_sop()` with the content, then run it via bash. The helper handles the title bar, metadata table, all styling, and the filename. See `references/builder-api.md` for the exact dict schema.
  130. **Path B: manually with python-docx.**
  132. If the content requires layout the helper doesn't cover (uncommon), write the docx directly with python-docx. Open `assets/template.docx` as the starting point: its styles (Heading 1/2/3, body) are pre-configured to match the Meridian standard. Modify in place; save out with the correct filename.
  134. In either case, save the output .docx to the user's working directory under the Meridian filename pattern.
  136. ### 4. Verify
  138. Before declaring done, verify the .docx:
  140. - Filename matches `SOP_<Title>_<MM-YYYY>_<Initials>.docx` (or `DRAFT_SOP_...` / `..._TEMPLATE_...` if specified).
  141. - Title bar at the top contains `SOP | <Title>` on line 1.
  142. - Metadata table has all four columns filled.
  143. - Purpose and Scope & Responsibility sections exist as Heading 1.
  144. - Quick Reference Card appears near the end.
  145. - File opens without errors.
  147. If python-docx is available in the environment, a quick validation pass: open the file, walk paragraphs, confirm the styles and required sections. The helper script does this automatically when run with `--validate`.
  149. ### 5. Hand off
  151. Tell the user:
  153. 1. The output path of the .docx.
  154. 2. The Shared Drive folder it should be uploaded to (based on Category + Folder Context).
  155. 3. Whether it's a DRAFT or final. If DRAFT, remind the user to remove the `DRAFT_` prefix after review.
  157. Don't recap the SOP body. The user can open the file.
  159. ## Worked example
  161. **User:** Draft an SOP for the way we hand off completed mockups from design to client success. Process title: Mockup Handoff. Category: Operations. Owner: me, MG. Effective: this month.
  163. **Skill response:**
  165. 1. Quick intake confirmation. Restate the metadata as a one-liner. Ask one question if anything is missing.
  166. 2. Ask for the steps if the user didn't include them: "What does the handoff look like? Who notifies who, what gets attached, and what does CS confirm before going to the client?"
  167. 3. Once the steps are clear, build a Workflow SOP via `scripts/build_sop.py`.
  168. 4. Save to `SOP_Mockup Handoff_05-2026_MG.docx`.
  169. 5. Hand off with the path + a one-line drive-folder suggestion (`00 - SOPs & How To Guides > 02 - Operations`).
  171. ## Bundled resources
  173. - `assets/template.docx`: the canonical SOP_EXAMPLE template. Use as the python-docx base for Path B; the helper script (`scripts/build_sop.py`) also opens it under the hood for style inheritance.
  174. - `scripts/build_sop.py`: the SOP builder. Takes a Python dict and produces the styled .docx. See `references/builder-api.md` for the schema and `references/format-spec.md` for the full styling spec.
  175. - `references/format-spec.md`: full format specification: every section, every style, every table layout, with the exact colors and fonts.
  176. - `references/sop-types.md`: the three SOP shapes (Workflow, Naming Convention, Policy) and which sections each one uses.
  177. - `references/builder-api.md`: the dict schema for `build_sop.py`. Read this when using Path A.
  179. Read `format-spec.md` the first time you use the skill in a session. Read `builder-api.md` whenever you're about to call the helper script. Read `sop-types.md` when picking the SOP type.
  181. ## Edge cases
  183. - **User provides existing content as a draft** (pasted text, an old SOP, notes). Restructure it into the Meridian shape; don't just dump it under random headings. Map their content to Purpose, Scope, Process, Best Practices, etc.
  184. - **User wants to update an existing SOP**, not start fresh. Ask for the current file (or the link/text). Produce a new .docx with the same title but the new month in the filename (e.g., from `_04-2026_MG.docx` to `_05-2026_MG.docx`). Note in the body where things changed.
  185. - **The procedure spans multiple departments**, suggesting more than one Category. Pick the primary department for the Category field; mention the others in the Scope & Responsibility section.
  186. - **Owner Initials conflict with another team member's initials.** Use a three-letter form (MJG vs MEG) and flag for the user to confirm.
  187. - **Effective date is in the past** (the user is documenting a procedure that's been in use). That's fine: set Effective Date to when the procedure actually started, not today. If the user can't recall, default to current month and let them edit.
  189. ## What this skill does NOT do
  191. - **Customer-facing content.** Meridian SOPs are internal-only.
  192. - **Markdown or plain text output.** SOPs are always .docx.
  193. - **Uploading to Drive.** The skill produces a local .docx; the user uploads.
  194. - **Cross-references to other SOPs as hyperlinks.** Meridian SOPs cite each other by filename in the Scope or Quick Reference sections, not as clickable links.