Here’s the prompt, ready to paste into your doc-generation platform:You are documenting a healthcare compliance platform made of two apps: a patient-facing portal and an internal care-team portal (doctors, support staff, admins). Write for non-technical readers: clinical/support staff, PMs, sales/GTM, and new hires. Never use code identifiers, file names, class names, or vendor/library names in the body text (e.g. say “automated phone outreach” not “Retell/Telnyx/Twilio”, say “window tint medical exemption form” not “tinted-state-forms”). Translate every internal shorthand into the term staff/patients actually use, and keep a glossary mapping shorthand -> plain name at the end. If you can’t confidently resolve what a piece of code shorthand means, don’t guess — list it as an open question.Ground truth = the current code and routes. Treat any file/doc whose name contains “plan”, “assessment”, “migration”, “investigation”, or “audit” as a historical proposal or post-mortem, NOT a description of what exists today — use it only for background context, never as fact about current behavior.Read these existing internal docs first as a starting point, then verify every claim against the actual code before writing anything:- parkingmd-care-portal/docs/care-portal-kt-guide.md- parkingmd-care-portal/docs/forms-architecture-blueprint.md- parkingmd-care-portal/docs/MULTI_FORM_SYSTEM.md- parkingmd-patient-portal/documentation/service-flow.md- parkingmd-patient-portal/documentation/add-new-service.md- parkingmd-patient-portal/documentation/routing.md- parkingmd-patient-portal/documentation/referral-system.md- parkingmd-patient-portal/documentation/cross-site-auth-cookie.md- parkingmd-patient-portal/documentation/design.mdNever state a behavior you couldn’t confirm in code — flag it as an open question instead of inventing an answer.Cite sources only in a “Where this comes from” list at the end of each chapter (file/module names allowed there only) — never inline in the prose.Write one chapter per topic, each starting with a one-line “Who this is for” and defaulting to an operational voice (what happens, step by step, who’s involved) unless the topic is clearly sales/PM-facing:LIST MUST INCLUDE, BUT NOT LIMITED TO 1. System overview — the two portals, who uses each, how they connect2. Patient onboarding & signup3. Scheduling & appointments4. Form filling (patient side) and form processing (care team side)5. Services catalog — what a “service” is, how services are configured, how they differ by state6. Payments, checkout, coupons, upsells7. Messaging & notifications (email, SMS, voice, in-app) across both portals8. Care team workflows — tasks, follow-ups, review queues9. Referrals10. Reviews & feedback11. Document generation & e-signature (medical cards, prescriptions, permits, etc.)12. Admin, analytics, and multi-brand support13. Printing & fulfillment (physical card/label shipping)14. Glossary (shorthand -> plain-language name) + open questionsDerive the actual service list and state-by-state variations from the code itself (don’t assume from names alone). Output as one document per chapter, plain language, short paragraphs and numbered steps over dense prose.Also saved to documentation_prompt.md in your scratchpad if you want to tweak it before feeding it in.