Skip to content
All builds

KeelSOP Builder

What it does for you

A short intake and rough notes become a numbered, linted SOP with roles, decisions, warnings, quality checks, and records, exported as Markdown, HTML, or PDF.

Keel screenshot

Screenshots

Keel screenshot 1

In more detail

Keel turns a short intake and a few rough notes into a properly formatted, numbered standard operating procedure, checks it for weak steps, and exports it as Markdown, HTML, or a PDF. Small businesses know how their work gets done, but it lives in one person's head or a messy note. You type something like "Care Manager visits the home and completes the assessment," and Keel turns it into a clean step with a named role, plus purpose, scope, roles, definitions, quality checks, records, and a revision history.

Honest limits

The sample SOPs are generic examples Claude drafted. They're not legal or regulatory advice and not any state's required form, and the app and every export say so. Storage is browser-only with no accounts. Built and tested, not battle-hardened.

How I built it

This was a Claude Cowork build. I directed "one shot all the Cowork projects," and Cowork took #46 from a single line on my list ("Short intake -> draft SOP (revenue)") and ran with it. In one autonomous pass of about 0.8 hours it specced the app, wrote a DOM-free core (keel.js, about 1,000 lines), wrote the 316-assertion test file, built the page against that core, drafted four sample SOPs (client intake, caregiver onboarding, weekly invoicing, social post approval), and exported each one as Markdown, HTML, and PDF. It also wrote a Cowork skill so the same workflow can run with real connectors, read-only and draft-only by default.

Cowork ran the app under Playwright in both themes and at phone width, looked at the screenshots and the rendered PDFs, and fixed what it found: a table overflowing at 390px, dark pages when printing from the dark theme, and a lone footer spilling onto a fourth PDF page. Going from one line on a list to a finished tool that fast is a big part of why Cowork setup felt so quick to me.

What I learned

  • Turning notes into imperative steps is mostly an inflection problem. We generated every form of about 200 verbs (sends, calling, logging, verified, sent) into one lookup, with base forms winning. That let "visits the home and completes the form" get fixed by conjugating the verb after "and" only when the first verb was third person, so "Update the notes and records" is left alone.
  • The actor detector and the verb list fought each other. "The billing lead sends invoices" failed because "billing" maps to "bill." The fix was to reject a role only when its first word is an exact base verb.
  • color-scheme: dark paints the printed page dark even with the body background cleared, so the print stylesheet has to force light.
  • The optional Claude rewrite gets scored by the same local lint, side by side with the local version. That makes it an honest comparison instead of a trust exercise.

What carried forward

The live preview and the HTML export are the same function (renderDocBody plus one DOC_CSS string), the same "one renderer, no drift" idea behind #41 and #43. #47 was built in this same Cowork pass with the same shape: a pure core, a lint, sample exports, and a not-legal-advice line on every document.

If I took it further

I'd add an SOP library with saved versions, so a revision bumps the version and fills the revision history with a real change note. I'd also have the lint suggest a concrete rewrite for each vague step, and add a DOCX export for reviewers who expect Word.

#046 Built with Claude Cowork September 23, 2026 316 automated checks

Want one like this?