terms-policy-generator

name

terms-policy-generator

description

Generate first-draft Terms of Service, Privacy Policy, and Cookies Policy from a project spec (industry, jurisdiction, data collected, payment processor, sub-processors). Use when launching a SaaS product, landing page with sign-ups, or any service that collects user data and needs the three legal documents before going live. Outputs to `legal/<project>/<doc>.md`. NOT a substitute for a lawyer — produces a starting draft that requires counsel review before publication.

Terms / Privacy / Cookies generator

Founder-grade drafting for the three documents every public web service eventually needs. Saves you from staring at a blank terms-of-service.md for an afternoon. The output is a draft that covers the standard clauses for the configured jurisdiction; a lawyer still has to sign off before you publish.

The disclaimer up front

This skill produces drafts, not legal advice. Walter-OS does not practice law. The output requires:

1. Counsel review before publication. Cost: typically 1-3 hours of a SaaS-experienced lawyer per document. Worth every dollar.
2. Update on regulatory change. Privacy laws shift faster than most projects audit them. Re-review at every material change to data collected, sub-processors, or jurisdiction reach.
3. No reliance for compliance. The output is a starting point. It is not a defense in a regulatory action.

The skill includes a legal/<project>/DISCLAIMER.md template that makes this explicit for any future operator who finds the generated files and assumes they are publication-ready.

Inputs — project spec YAML

The skill reads legal/<project>/spec.yml (or a path the operator passes). Required fields:

project:
  name: ExampleApp
  company_legal_name: Example Labs Inc.
  domain: example.com
  contact_email: [e-mail]

jurisdiction:
  primary: US-Delaware              # the company's primary jurisdiction
  also_active_in:                   # any country/state where you have users
    - EU
    - UK
    - California
    - Brazil

industry:
  category: saas                    # saas / marketplace / mobile-app / consumer / fintech / health
  age_minimum: 13                   # 13 / 16 / 18 — lowest user age allowed
  b2b_or_b2c: b2c

data_collected:
  account_data:                     # PII fields you collect during signup
    - email
    - hashed_password
    - display_name
  usage_data:                       # what you log about user behavior
    - page_views
    - feature_clicks
  payment_data:
    collects_directly: false        # if true, you handle card numbers (PCI-DSS scope)
    processor: stripe               # if false, the third party that does
  health_data: false                # HIPAA territory
  financial_data: false             # GLBA / financial-services territory
  cookies:
    essential: true
    analytics: true
    marketing: false                # if true, also need ad-tracking section

sub_processors:                     # third parties that touch user data
  - name: Stripe
    purpose: payment processing
    data_shared: [email, billing_address]
    location: US
  - name: Postmark
    purpose: transactional email
    data_shared: [email, display_name]
    location: US
  - name: PostHog
    purpose: product analytics
    data_shared: [hashed_user_id, page_views, feature_clicks]
    location: EU

retention:
  account_data: until-deletion-requested
  usage_logs: 90-days
  payment_data: 7-years              # tax law in most US jurisdictions

deletion:
  user_initiated: true               # GDPR Article 17 requires this
  self_service: true                 # operator surfaces a delete-account button
  retention_after_request: 30-days   # before purge from backups

Outputs

The skill writes to legal/<project>/:

legal/<project>/
├── spec.yml                    (the input — kept for re-generation traceability)
├── DISCLAIMER.md               (operator-facing reminder this is a draft)
├── terms-of-service.md         (TOS draft)
├── privacy-policy.md           (privacy draft)
└── cookies-policy.md           (cookies draft — only if cookies.* set)

Each generated document includes:

• A header block stating Generated by walter-os terms-policy-generator on YYYY-MM-DD. NOT LEGAL ADVICE. Counsel review required before publication.
• A ## Last reviewed by counsel placeholder for the lawyer to fill in.
• A table of contents (standard structure for each document type).
• Inline [REVIEW] markers wherever the generator made an assumption that should be sanity-checked by counsel (e.g., default 30-day refund window, default arbitration venue, default governing law).

Section coverage per document

terms-of-service.md (TOS)

The structural template covers:

1. Acceptance & binding effect
2. Eligibility (age minimum, business-only if b2b)
3. Account registration & security (responsibility for credentials)
4. Acceptable use & prohibited conduct
5. Subscription, pricing, billing (only if payment processor configured)
6. Refunds (default 30-day window — [REVIEW])
7. Termination by user
8. Termination by service (cause + non-cause)
9. Intellectual property (service IP + user content licensing)
10. Disclaimer of warranties
11. Limitation of liability (capped at fees-paid-in-last-12-months — [REVIEW])
12. Indemnification
13. Governing law & dispute resolution (arbitration default — [REVIEW])
14. Modifications to the terms
15. Contact

privacy-policy.md

Adapts to jurisdiction. If EU/UK in also_active_in, GDPR sections fire. If California, CCPA sections fire. If Brazil, LGPD sections.

Sections:

1. What we collect (mapped from data_collected.*)
2. Why we collect it (purpose specification — required under GDPR Art. 5, CCPA, LGPD)
3. Legal basis (GDPR Art. 6 — operator picks per-data-category)
4. Sub-processors table (mapped from sub_processors)
5. International transfers (if any sub-processor is outside the primary jurisdiction)
6. Cookies (linked to cookies-policy.md if generated)
7. Retention (mapped from retention)
8. User rights (GDPR Art. 15-22 / CCPA / LGPD — adapted per also_active_in)
9. Deletion process (mapped from deletion)
10. Children (if age_minimum >= 13, references COPPA for US)
11. Security
12. Changes to this policy
13. Data Protection Officer / contact

cookies-policy.md (only if cookies enabled)

1. What cookies we use (table per category)
2. Why (purpose per cookie)
3. How to control (browser settings + service-level toggle if marketing cookies are enabled)
4. Sub-processor cookies (if analytics/marketing processors set)
5. Cookie consent banner reference (links to the operator's implementation — Walter-OS does not generate the banner UI; use the landing-page-fast skill's cookie-consent recipe)

What the skill DOES NOT generate

• A cookie-consent banner UI. Use landing-page-fast skill.
• A data processing agreement (DPA) with sub-processors. Each sub-processor typically provides their own DPA.
• A data protection impact assessment (DPIA). Required under GDPR for high-risk processing. Out of scope.
• Country-specific addenda beyond US/EU/UK/California/Brazil. For Argentina, Mexico, India, Australia, etc., flag a follow-up.
• An incident response / breach notification policy. That belongs in docs/operational/incident-response.md, not a public terms doc.

Decision matrix — which jurisdictions need which sections

User location	TOS additions	Privacy additions
US (any state)	governing law per jurisdiction.primary	minimal — CCPA only fires for California users
California	nothing extra in TOS	full CCPA section (Do Not Sell, Right to Know, Right to Delete, Right to Opt-Out)
EU / UK	nothing extra in TOS	full GDPR section (legal basis, DPO contact if required, international transfers, supervisory authority right)
Brazil	nothing extra in TOS	full LGPD section (mirrors GDPR with local terms)
Other	the skill flags a [REVIEW] marker pointing at counsel to research local requirements

Operator workflow

1. First time: walter-os new project <name> (the project-induction skill) scaffolds legal/<project>/ and asks the legal-spec questions inline.
2. Subsequent: edit legal/<project>/spec.yml directly. Re-run the generator (overwrites the three documents; the YAML is the single source of truth).
3. Counsel review: the lawyer fills in the ## Last reviewed by counsel block and resolves every [REVIEW] marker. Operator commits the reviewed file. The next regeneration warns if the reviewed file would be overwritten — only proceed if the spec change is non-substantive.
4. Publication: the operator deploys the three documents to <domain>/terms, <domain>/privacy, <domain>/cookies. The landing-page-fast skill includes templates for these paths.

Anti-patterns

1. Skipping the disclaimer header. Removing the "Generated by walter-os, NOT LEGAL ADVICE" line so the doc looks publication- ready is dangerous. The header is required.
2. Publishing without counsel review. Even a perfect draft includes operator-specific assumptions (refund window, governing law, retention period) that need a lawyer to sanity-check against your actual business.
3. Treating [REVIEW] markers as optional. Every marker is the generator saying "I picked a default that may not match your situation." Resolving them is mandatory.
4. Forgetting spec.yml is the source of truth. Editing the generated terms-of-service.md directly means the next regeneration overwrites your edits. Push changes back into spec.yml.

Hard rules

• Always emit the disclaimer header. No exceptions.
• Always emit [REVIEW] markers where defaults were applied.
• Never claim regulatory compliance. The output never says "this policy is GDPR-compliant"; it says "this policy includes sections intended to satisfy GDPR Articles 13/14".
• Never include real operator data in the spec template. The template uses generic placeholders (Example Labs Inc., example.com); operators supply their own values per project.
• Always write to legal/<project>/, never to the project root or docs/. The legal-document directory is a known location for the oss-readiness audit and for human reviewers.

Integration with other Walter-OS skills

• project-induction (Phase R skill, #10's sibling) — asks the legal-spec questions when scaffolding a new project and triggers this generator on completion.
• landing-page-fast — links to /terms, /privacy, /cookies in the footer of the generated landing page.
• oss-readiness — verifies legal/<project>/ exists with the three documents before approving an OSS public-release.
• regulatory-research-international — for jurisdictions outside US/EU/UK/California/Brazil, the operator runs this skill first to gather local-law context before re-running the generator.

References

• Walter-OS execution plan Phase 4.1.3.
• GDPR Articles 13, 14, 15-22 (data subject rights).
• CCPA / CPRA (California).
• LGPD (Brazil).
• COPPA (US, for age_minimum < 13).
• skills/landing-page-fast/SKILL.md — the consumer that links to the generated docs.
• skills/oss-readiness/SKILL.md — the gate that checks for these files before a public release.