TenetPolicy Document Generator
What it does for you
An intake-to-policy generator for home care agencies with a fixed six-part structure, lint for tokens and absolute wording, placeholder-only references, and a printable manual, clearly labeled a sample and not legal advice.

Screenshots

In more detail
Tenet turns a short intake about a home care agency into draft policies with a consistent structure, numbering, sign-off block, and revision log, ready to print as a small manual. Small agencies need a stack of written policies to get licensed, and most start from a blank page or an old binder with another agency's name still in it. Tenet gets them to a reviewable first draft, and it refuses to invent rule citations.
Honest limits
The topic content is a generic sample Claude drafted from common licensing themes. It's not legal advice and names no state's actual rules. References are [state rule citation to verify] placeholders on purpose, and state-dependent time frames say "within the time frame set by {{state}} rules" instead of guessing. Google Fonts couldn't load in the sandbox, so the screenshots use fallback fonts. In the PDF, a step with a long sub-list moves whole to the next page and leaves some white space. Storage is browser-only.
How I built it
Another Claude Cowork build from my "one shot all the Cowork projects" direction. I gave the spec: the intake fields, 15 topics, a six-part structure, token substitution, a lint for leftover tokens and absolute wording, placeholder-only references, a batch manual mode, a print PDF, and an optional Claude mode. Cowork specced the details, wrote the core (tenet.js) and the 15 sample topics, wrote the 227-assertion test file, built the page, rendered the screenshots and a 13-page sample manual PDF with Playwright, looked at them, and fixed what it saw. One autonomous pass, about 0.7 hours.
The first test run failed exactly one assertion: the lint missed "100%." That became the most useful lesson in the project. Cowork also wrote a skill for running it with Drive and Gmail, drafts only.
What I learned
- A banned-word lint needs word boundaries that depend on the word.
\bnever\bcorrectly skips "nevertheless," but\b100%\bnever matches because there's no boundary after a percent sign. Adding\bonly on ends that are word characters fixed it, and a test keeps "nevertheless" from being flagged. - "Add N months" has to clamp to the end of the month. Jan 31 plus one month is Feb 28, and a leap day plus twelve months lands on Feb 28, which is what a review date should do.
- The no-invented-citations rule lives in two places. The validator rewrites anything that looks like a CFR, U.S.C., or section-sign cite into a placeholder when a topic comes in, and the lint flags it again if it reaches a rendered policy. The validator can clean; the lint can only report.
- Render to a data model first and lint the model. Then one lint covers built-in topics, pasted JSON, and Claude drafts, and a test that renders all 15 topics for all 3 agency types keeps the sample content clean.
What carried forward
This came out of the same Cowork run as #44 and #46 and shares their shape: a pure core imported by the page and verify.mjs, a lint that runs on everything, sample exports, and a Cowork skill with read-only and draft-only defaults. The "same checks for local and AI output" idea is the one #46 uses to score Claude's SOP rewrite.
If I took it further
I'd move the topics into per-state packs with a verified citation field, so a consultant fills in the real rule once and reuses it for every client in that state. I'd also let you edit a rendered step inline and log the change as a revision entry.
#047 Built with Claude Cowork September 23, 2026 227 automated checks