Use this terms and conditions generator Skill to prepare terms and a privacy policy grounded in your website's actual behavior. Your assistant reviews features, data collection and marketing claims, then drafts both documents from the business facts and lists unresolved details, giving the team a coherent package to review before publication.
Legal ToS Privacy begins with website code and marketing statements before writing the documents. It identifies the functionality and data practices that need to be described, then produces terms, a privacy draft and questions for missing business information.
The source is oriented toward SaaS products. For a physical-goods store, supply delivery, return and refund rules as well as entity and data-handling details. Use the output as a review package; creating policy routes or implementing missing consent controls is separate work unless explicitly included in the development task.
Legal ToS Privacy suits SaaS teams and stores with custom website features that need their terms and privacy documents to reflect how the product works. It starts with code and marketing claims, then drafts the documents and asks for the missing business decisions. It is most useful when you need a coordinated review package, rather than a generic policy template.
Inspect features, data collection, third-party services and public claims before drafting. The worked example distinguished a checkout preview from real order processing and identified a script loading before consent, showing why the documents must describe implemented behavior accurately.
Use the same account, payment, cancellation and data-handling facts for both documents. Add delivery and returns for physical goods, then review the drafts together so one policy does not promise something that the other document or actual operation contradicts.
Collect missing company details and policy decisions into a clear handoff for the operator and reviewers. Separate unanswered business questions from website changes, so the team knows whether the next step is supplying a fact, approving a rule or implementing a control.
Prepare the following business inputs and software before starting the workflow.
Prepare a compatible coding agent and the complete four-file original Skill directory.
Prepare a sanitized source-code copy and confirmed business/data-processing facts.
Prepare a reviewer for legal decisions, inferred identity and unrelated framework dependencies.
Install the complete Skill package, then start with the merchant inputs listed above.
Copy this request into Codex or Claude Code. The assistant downloads the original repository at the specified commit, installs the complete files and checks required dependencies.
Install legal-tos-privacy in the app I am using and carry out the file installation, not just explain it.
Original repository: https://github.com/galyarderlabs/galyarder-framework.git
Commit: ab209fa59e8a4d8d9c354564097bc123aefd7dbb
Skill folder: skills/legal-tos-privacy
1. Download this exact source into a new directory. Read SKILL.md and its setup references before running any bundled scripts. Do not substitute another author’s package.
2. For Codex, use ~/.agents/skills/legal-tos-privacy; for Claude Code, use ~/.claude/skills/legal-tos-privacy. Install only for my current app. Install the complete Skill folder, including scripts, references, assets and bundled notices. Keep any root license with the installed folder. Check all destination folders first; if any already exist, report differences before replacing them.
3. Compare the source and installed file lists and hashes. Inspect documented runtimes, dependencies and required connections. Configure only the local dependencies needed for this Skill; use an isolated environment when appropriate. Ask me to complete any account login locally, without putting credentials in chat.
4. Report the source commit, actual installation path, file-check results and any remaining runtime setup. Explain how to invoke legal-tos-privacy in this app. Check discovery separately from file copying; start a new session if needed. Do not run production tasks or claim a successful business outcome from installation alone.Starter prompts for the main use cases—copy and use them directly.
Draft SaaS terms to produce a terms draft with account, payment and cancellation clauses. Your code, existing policy and confirmed business facts.
Use legal-tos-privacy from the original Galyarder Labs package. Read all three reference guides. Draft terms covering accounts, billing and cancellation. Use [INPUT] as the source of truth; retain unknown facts as questions and do not publish.[INPUT]Draft a privacy policy to produce a privacy draft matching observed data processing. Your code, existing policy and confirmed business facts.
Use legal-tos-privacy from the original Galyarder Labs package. Read all three reference guides. Map data collection and vendors to a privacy draft. Use [INPUT] as the source of truth; retain unknown facts as questions and do not publish.[INPUT]Find gaps before publication to produce a contradiction report and outstanding business questions. Your code, existing policy and confirmed business facts.
Use legal-tos-privacy from the original Galyarder Labs package. Read all three reference guides. Compare drafts against code, marketing and refund rules. Use [INPUT] as the source of truth; retain unknown facts as questions and do not publish.[INPUT]Cedar & Cart Demo supplied four storefront files and US/Canada sales rules. The checkout was a browser-only preview; the home page loaded a test Google tag before any consent choice.
Case input files: business-inputs.zip
Use the legal-tos-privacy Skill.
Draft English terms of service and a privacy policy for the attached storefront using the merchant facts and completed business questionnaire. Audit the site's actual claims, features and data collection first. Keep delivery, refund and consent terms consistent, provide complete review drafts, and list any remaining business questions and website changes for the merchant to approve. This is a fictional merchant exercise, not a legal opinion.
The attached business materials are:
- inputs/merchant.json
- inputs/simulated-merchant-answers.json
- inputs/storefront/store/checkout.html
- inputs/storefront/store/contact.html
- inputs/storefront/store/index.html
- inputs/storefront/store/styles.css
Deliver a complete result.md report that the operations team can read, plus any finished files needed for this task. Keep supporting calculations and evidence with the deliverables. Write the report in English; use the requested target language for customer-facing copy. The business datasets are fictional examples unless the brief explicitly names a live public website.The primary file produced by this prompt is shown below in its original language.
Completed the requested review drafts against the supplied storefront and completed fictional business questionnaire. The code audit found a static product homepage, a checkout preview with email/address fields and a prevented submit event, a contact page and one stylesheet. There are no accounts, uploads, subscriptions, payment gateway, backend order submission, first-party storage calls or connected carriers. Source hashes and findings are in storefront-audit.json.
The homepage's Google tag loads unconditionally. The questionnaire elects to disable it before public launch; this drafting task has not changed the site. The documents therefore identify the current request and future removal separately, instead of claiming valid consent or completed removal. The demo has no production analytics property or verified Google retention configuration.
Ready for merchant/counsel review; not ready for live merchant publication. All template variables are resolved using the fictional questionnaire. Resolved training details are not verified legal identity, a working address or working contacts. No real purchase, message, refund or vendor connection was made.
| Priority | Owner | Required decision/change | Acceptance evidence |
|---|---|---|---|
| Before any public launch | Engineering | Remove unconditional Google tag and config call under chosen no-analytics launch plan | Clean-browser network capture with zero Google requests across every page |
| Before real collection | Operator / privacy lead | Replace fictional entity, address and contact; identify hosting/mailbox/payment vendors and processing countries | Verified working channels and documented vendor/data inventory |
| Before taking orders | Engineering / operations | Implement reviewed assent, order review, acceptance notice, invoice method and itemized taxes; publish linked policies | Test order through actual chosen payment/fulfillment flow with retained acceptance evidence |
| Before policy approval | Operations | Confirm refund business-day convention, return dispatch/receipt deadlines, cancellation handling, carrier basis and return instructions | Approved policy matrix matching checkout and support procedures |
| Before real collection | Privacy lead | Implement retention/deletion, security and incident responsibilities; determine state/Canadian applicability and transfer needs | Tested request/deletion workflow, provider terms and jurisdiction assessment |
| Before live terms | Counsel / operator | Review product warranties, proposed Texas law/venue, any desired liability cap, mandatory consumer rights and deadline rules | Approved final text; no automatic arbitration/class waiver |
| At launch and changes | Content owner | Replace simulation date/labels only after real approval; link terms/privacy near relevant collection; version notices | Published date/version and consistency check against real code |
The complete questionnaire resolves drafting fields, but it cannot verify a real business or implement a system. These are review and deployment gates, not omitted template blanks.
The FTC merchandise-order rule explains that inability to meet promised shipment timing requires a delay-consent or refund process. The draft preserves that requirement rather than treating carrier estimates as a blanket excuse.
The California Attorney General's CCPA guidance describes consumer rights and covered-business duties. This fictional dataset cannot establish the real operator's applicability or exemption, so the artifact does not copy a potentially outdated threshold from the Skill reference as a current legal conclusion.
Canada's PIPEDA fair information principles inform the review of purpose, collection, retention, safeguards and access. Federal/provincial applicability still needs assessment for an actual business.
The following are the full generated drafts, also included as separate files in the package.
Review draft. Last updated November 2, 2026 (simulation only). Cedar & Cart Training LLC, the address and the domain in this document are fictional training examples. This document is a complete drafting exercise for review by the merchant and qualified counsel, not a legal opinion or permission to launch a store. Do not place real orders, make payments or send parcels using these details.
Cedar & Cart Training LLC is the fictional operator of Cedar & Cart Demo at https://cedar-cart.example. Our training notice address is 100 Example Lane, Demo City, TX 00000, USA, a non-deliverable example. The training contact is [email protected], which does not receive real messages.
The current demonstration shows ceramic mugs, linen towels and a checkout preview. It does not create orders, collect payments, open accounts or provide subscriptions. The purchase provisions below describe the operator's proposed business terms and do not imply that purchasing is currently available. No real contract is formed by using the preview.
The proposed store is for adults aged 18 or older who have legal capacity to contract. Before a real order could be submitted, the operator plans to display these terms with an affirmative acceptance checkbox and an order-review step. That process is not implemented in the supplied preview.
Under the proposed process, an order request or invoice is not acceptance. Acceptance occurs only when the operator sends a separate dispatch-confirmation email. Availability, delivery details, price, taxes and any proposed correction must be clear before the customer commits. An error does not authorize an unapproved higher charge. If the operator cannot fulfill an order, it will explain the situation and provide cancellation and refund rights required by law.
All proposed prices and charges are in USD. In the fictional operating plan, approved requests are manually invoiced; applicable taxes and shipping charges are itemized before acceptance. No card or bank details should be entered into this website. The demonstration has no payment processor and accepts no payments. A real payment method and the related privacy disclosures must be selected and reviewed before taking money.
There are no recurring subscriptions, free trials or automatic renewals. Changes to future prices do not retroactively alter an accepted order without the customer's agreement or another lawful basis.
The proposed fulfillment location is Austin, Texas. Business days mean Monday through Friday excluding US federal holidays. Standard handling is 1–2 business days; preorder handling is 5–7 business days. Carrier transit starts after handoff and is additional to handling. These are estimates rather than guaranteed arrival dates, and no holiday cutoff or daily order cutoff is promised.
| Destination | Proposed service | Transit after handoff | Shipping charge | Address restrictions |
|---|---|---|---|---|
| Contiguous United States | USPS Ground Advantage | 3–5 business days | $5.95 below $75 merchandise subtotal after discounts; free at $75 or more | PO boxes accepted |
| Canada | UPS Standard | 7–12 business days | $18; no free-shipping threshold | No PO boxes |
For Canada, the seller pays the stated import duties and taxes under the supplied DDP plan. Do not add buyer-paid import-duty language. Tracking is to be emailed after carrier handoff. Address-change requests should be made before handoff and are not guaranteed.
If dispatch cannot occur within a legally binding promised time, the operator must provide the required delay notice and cancellation/refund choice. Calling a date an estimate does not remove mandatory duties. A missing shipment should be reported after its estimated window so the operator can investigate with the carrier; the investigation does not waive applicable delivery or refund rights.
Contact support before carrier handoff to cancel. Under the proposed rule, cancellation is accepted while the order has not dispatched; after dispatch, the return process applies, subject to any stronger mandatory rights.
For voluntary returns, request instructions within 30 days after delivery. Items must be unused and in their original packaging. Send an item only after receiving the order-specific return instructions. The address in this training document must never be used for a real parcel. There is no restocking fee.
The customer pays return postage for a change of mind; the seller pays it for a confirmed defect. Original outbound postage is not refunded for a voluntary change-of-mind return, but is refunded for a confirmed defect or where mandatory rights require it. Support reviews the facts before deciding the appropriate remedy.
Report damage within seven days with the order number and photos to help investigation. This reporting request does not remove statutory defect rights or automatically entitle or limit a customer to replacement. After inspection and approval, the planned refund processing time is 5–10 business days to the original payment method. Mandatory refund deadlines take priority; this period must not be used to delay a legally required cancellation refund. Bank posting may be separate from the operator's processing time and is not quantified by this intake.
Use the website for legitimate browsing and, if a reviewed purchase flow is later launched, genuine orders. Do not disrupt the site, introduce malicious code, impersonate someone, or attempt unauthorized access. Site materials remain the property of their respective rights holders; browsing does not transfer copyright or trademarks. You may use the materials for ordinary personal shopping, subject to applicable law. The supplied site has no public uploads, user accounts or user-content licensing feature.
The accompanying Privacy Policy describes what the supplied demonstration currently does and the separate proposed operating plan. Acceptance of purchase terms is not blanket consent to optional analytics or marketing. The current homepage contains an ungated Google test script, which the operator has elected to remove before launch. This drafting exercise does not implement that removal.
Carrier or future payment-provider services may have their own applicable terms, but using a provider does not remove the operator's obligations to the customer. No carrier or payment integration is currently connected in this demonstration.
The demonstration may be interrupted or changed. It does not promise continuous availability or that all display errors will be absent. These website limitations do not exclude product descriptions, statutory product warranties, required remedies or consumer rights that cannot lawfully be restricted.
The merchant has not selected a monetary liability cap or a broad consumer indemnity in the completed intake, so this review draft does not invent either. Liability follows applicable law, including rules that cannot be excluded for injury, fraud, intentional misconduct or other protected claims. Any later limitation must be reviewed for the actual products, jurisdictions and consumers; it cannot erase an existing refund obligation.
The proposed governing law is Texas law, without overriding mandatory consumer protections. Courts in Travis County, Texas are the proposed venue only where mandatory consumer venue rights permit. This exercise adopts no arbitration agreement or class-action waiver. Customers may contact support to discuss an issue, but that invitation does not suspend statutory deadlines or prevent lawful remedies.
Events outside reasonable control may affect fulfillment, but do not eliminate mandatory delay notices, cancellation rights or refunds. The operator may restrict abusive website access; doing so does not cancel valid customer rights or permit keeping payment for unfulfilled obligations.
Material changes are to receive a dated website notice and, where lawful contact information exists, appropriate email notice. Fresh assent is required where applicable; changes do not silently rewrite accepted orders. If a provision is unenforceable, the remaining provisions continue to the extent lawful. This preview sends no notices and implements no assent mechanism.
Training contact: [email protected]. Training notice address: 100 Example Lane, Demo City, TX 00000, USA. Both are fictional and must be replaced with verified working business details before any real use. Merchant approval, operational implementation and qualified legal review remain required before publication as a live store's terms.
Review draft. Last updated November 2, 2026 (simulation only). This is a fictional merchant drafting exercise. Its domain, contact and address are training examples, not working channels. The policy distinguishes the supplied demonstration from proposed operations so that planned controls are not represented as already deployed.
Cedar & Cart Training LLC is the fictional operator of Cedar & Cart Demo, https://cedar-cart.example. The proposed privacy coordinator uses [email protected]. The notice address is 100 Example Lane, Demo City, TX 00000, USA. Neither contact should be used for real requests. Before real collection begins, the operator must provide working contact methods and identify the responsible legal entity.
The checkout preview displays email and delivery-address fields. Its script prevents submission and displays “Demo only. No payment or order created.” The supplied application does not send those values to a backend, create an order, store an account or take payment. Do not enter personal information in this training preview. A visitor's browser may have its own form history; that behavior is outside the application's demonstrated storage.
The homepage currently requests an external Google tag script using the test identifier G-TEST000000, without a consent choice. A request to that service can expose network information such as an IP address and browser request details. The source also queues an analytics configuration call. The test identifier does not establish that a production analytics property receives or retains events. Google-side storage, cookies, retention, processing countries and advertising configuration have not been measured in this exercise. The application itself has no cookie or storage-key calls.
This existing script is a launch blocker. The operator's selected plan is to remove analytics before public launch. This document records that decision; it does not remove the script or certify consent. Until verified removal, the demonstration must not be described as free of third-party requests. No other external host, operational mailbox, payment processor or customer database is identified in the supplied materials.
The following is an approved fictional operating plan, not a statement that these systems currently exist.
| Information | Proposed source and purpose | Proposed recipient categories | Planned retention |
|---|---|---|---|
| Name, email, delivery address and order details | Customer order request; review, fulfillment, receipts and customer support | Authorized staff; selected fulfillment/carrier services when needed | Completed-order and tax records: seven years, subject to applicable duties and documented holds |
| Support messages, order reference and relevant damage photos | Customer correspondence; answer questions and assess return/damage claims | Authorized support staff and the necessary carrier or service provider | 12 months after resolution, unless a documented legal hold applies |
| Invoice/payment status | A future separately reviewed invoice process; reconcile payment and refunds | A provider selected and disclosed before use | Record-specific legal and accounting schedule; no payment-data system currently exists |
| Optional analytics | None in the chosen launch plan | None after verified removal of the test tag | No production analytics retention claimed |
Collect only the information needed for the stated task. Do not request payment credentials by support email or collect unrelated identity documents to answer an ordinary order question. The future payment method, provider, actual fields and retention require a privacy update before collection. USPS and UPS are planned carriers rather than connected services in the current demonstration.
The supplied operator policy prohibits selling personal data or using targeted-advertising sharing. No such application workflow is present. This does not certify Google's downstream configuration or a Global Privacy Control implementation; the test tag is to be removed before launch.
In the proposed operating plan, providers should receive only what is necessary for their service, under appropriate terms reviewed before use. Disclosures required by law or needed for a documented legal claim should be limited and recorded. Any business transfer would require separate assessment and appropriate notice. No unlisted provider relationship, marketing list, social-login service or public profile is implied.
The supplied application sets no first-party cookies or storage keys. The external Google script has not been fully inventoried, so this is not a claim that no third-party identifier can be processed. There is no functioning consent-management interface in this particular input website. Removing the test script is the chosen launch plan; any later optional tracking must first receive a new inventory, legal-basis assessment, notice and choice controls where required.
The demonstration sends no marketing emails. A future marketing program requires its own lawful collection, sender identification and unsubscribe process. Agreement to store terms or contacting support should not be treated as automatic marketing permission.
For the fictional plan, resolved support correspondence is deleted after 12 months and completed-order/tax records after seven years, subject to applicable legal duties. Records under a documented legal hold are restricted to what the hold requires and released when no longer needed. Deleted records are planned to expire from backups within 30 days. None of these server processes has been implemented or tested in the demonstration. The schedule must be checked against the real operator's obligations and systems before it becomes a live promise.
The planned controls are role-based access, administrator MFA, encrypted transport and backups, an incident coordinator and incident logging. Required incident notifications must follow applicable law. These are operating requirements, not verified protections currently deployed by the preview. No system can guarantee absolute security, but this does not remove legal duties to protect information.
The proposed business is US-based and ships to Canada. Google processing locations were not measured. The exercise asserts no international transfer agreement or safeguard. Real hosting, email, carrier and payment providers, their processing locations and any required transfer measures must be assessed and disclosed before use.
The planned process accepts privacy requests through the designated support contact and notice address once replaced with working business channels. Verify requests proportionately, for example through an existing order/email relationship, without requesting unnecessary ID documents. Support authorized agents after appropriate verification. Aim to respond within 30 days or any shorter applicable deadline; use lawful extensions and explanations where permitted. Provide a second-person review for an appeal where applicable. The fictional mailbox does not operate this process.
Depending on the applicable law, rights may include access or knowledge, correction, deletion, portability, objection or opt-out, restriction of certain sensitive-data uses, withdrawal of consent and non-discrimination. Applicable exceptions, verification and response requirements must be assessed rather than assuming every right has identical scope everywhere.
For California, the real operator must assess CCPA applicability and required notices and opt-outs, including legally relevant sale/sharing and preference signals. No real revenue, historical consumer count or processing dataset is supplied, so this draft claims neither an exemption nor full state-law compliance. Other US states may impose different duties.
For Canada, customers may raise concerns with the operator's privacy coordinator or the Office of the Privacy Commissioner of Canada or the relevant provincial authority. The responsible authority and applicable federal/provincial law depend on the actual business. The proposed purposes, collection, retention and access practices require that assessment before launch.
The proposed sales territory does not target the EU or UK. That fact alone is not a legal exemption for a future deployment; assess territorial scope and any additional rights, representatives or transfer requirements before operations expand.
The proposed store is intended for adults aged 18 or older and does not knowingly request children's information. If information about a child is collected inadvertently, the planned coordinator will investigate and delete or otherwise handle it as required by law. No age-verification or parental-consent system is implemented in the demonstration.
The plan is to post a dated notice for material changes and contact affected customers when lawful contact details exist. Obtain fresh consent or assent when required. The preview sends no emails. Review this notice whenever a provider, data field, purpose, retention practice or market changes.
Training privacy contact: [email protected]. Training notice address: 100 Example Lane, Demo City, TX 00000, USA. Both are fictional. Qualified legal review, verified business details and functioning request channels are necessary before real publication.
Merchant business data is synthetic. Website observations, when present, come from the public URLs listed in the report.
Review these limits before using generated files or estimates in your store.
The Skill focuses on SaaS terms and privacy. Retail shipping and returns need your own explicit rules.
The test checked draft fidelity, not the legal suitability of clauses for every jurisdiction.
Unknown entity, address, retention and governing-law choices must be supplied by the business.
Prepare the business facts a terms-and-privacy workflow needs, distinguish document drafting from website implementation and review changes before publication.
Terms describe the rules of using or buying your service: accounts, payment, permitted use, cancellation and responsibilities. A privacy policy describes how personal data is collected and handled. Writing one does not automatically cover the other, although they should agree on shared facts such as the business identity and contact details.
Legal ToS Privacy starts from the product and website evidence so the two drafts can reflect the same operation. Give it the real account, checkout, support and data workflows. Review contradictions explicitly: a site with only a checkout preview should not describe itself as already processing live payments, and a privacy statement should not promise controls absent from the code.
Start with what the store actually collects through checkout, contact forms, accounts, analytics and support. Identify the business contact, purpose of each data flow, relevant service providers, retention decisions and the process for handling requests. The ICO's small-organization guidance is a useful UK reference for why purposes, retention and sharing need clear explanations; the applicable requirements still depend on your markets.
A code scan can identify a form or embedded tag, but it cannot determine an undisclosed retention policy or the legal entity behind the store. Supply those business decisions yourself. The Skill's missing-facts list is useful precisely because it keeps absent information separate from facts found in the website.
Supply how trials end, how billing and renewal work, what cancellation changes, whether refunds or credits apply, and what happens to access and stored data when an account closes. If customers upload content, also describe the intended rights, moderation process and export behavior. The draft should follow the implemented product rather than an idealized roadmap.
The demonstrated case on this page used a fictional physical-goods store, so it is not an end-to-end subscription billing test. Use the Skill's audit-and-question workflow with your own subscription facts, then check the draft against the pricing page, checkout and cancellation screens. Have the responsible reviewer settle contractual choices the code cannot establish.
Use a template to identify topics to discuss, not as proof that its statements fit your business. Another store may use a different payment provider, serve different regions, allow different refunds or retain data for a different purpose. Changing the company name leaves those substantive mismatches intact.
A more useful request is to compare your existing draft with your website and merchant facts, identify unsupported statements and list the decisions still missing. Legal ToS Privacy is designed around that audit and drafting workflow. Keep a reviewer involved in the contractual and jurisdiction-specific choices; a polished document is not evidence that the underlying policies or implementation are correct.
Choose Legal ToS Privacy when the immediate task is to examine code and marketing claims, draft coordinated terms and privacy documents, and collect unresolved business decisions for review. In the completed example, the original audit and drafts were followed by an assisted step that filled 33 variables using explicitly fictional merchant answers.
Choose Compliance Pages when the main task also includes building policy pages, navigation and consent controls inside a website. Completing a terms document does not wire a banner to an analytics script. If you use both, share one merchant fact set and decide which output owns each page, so the second workflow does not silently replace already-reviewed policy choices.
Check the legal entity and contact details, remove every unresolved placeholder, and compare the documents with the actual payment, refund, data and account flows. Keep implementation findings separate: changing a sentence about consent does not fix a script that loads before the visitor chooses. Record the document version and the business decisions used for that draft.
When the product changes, rerun the relevant part of the audit and review the resulting differences. Update the affected claims and have the responsible reviewer decide any notice or acceptance steps required for your situation. The local example completed draft variables and structural checks; publishing it unchanged would still describe a fictional merchant rather than your business.
No reviews yet.