# Answerlattice Pre-Onboarding Package for Lovable This is a tool-specific start wrapper around the same Answerlattice master prompt. It is not a product integration or endorsement. ## Start In This Tool 1. Use the project context, public product URL, owner notes, and approved screenshots available to the builder. 2. If repository, policy, or login-only product access is unavailable, keep those source families pending. 3. Treat the output as a review-ready source package, not as automatically approved support truth. ## Shared Master Prompt # Answerlattice Pre-Onboarding Master Prompt Use this prompt in Codex, Cursor, Windsurf, Antigravity, Claude Code, or another AI coding agent before starting Answerlattice onboarding. It works with a full repo, a docs folder, a public website, exported notes, screenshots, or owner-written product context. Do not force every product into one reference-client repo/docs shape. Read these companion docs if available: - Owner guide: https://answerlattice.com/pre-onboarding/owner-guide.md - Agent guide: https://answerlattice.com/pre-onboarding/agent-guide.md - Human overview: https://answerlattice.com/pre-onboarding ## Copy/Paste Intake Fields Replace the values below before starting. Use `NOT_AVAILABLE` when a field does not exist. Use `PENDING_OWNER_APPROVAL` when the fact exists but is not approved for support or marketing. ```text PRODUCT_NAME = "" PRODUCT_SLUG = "" PUBLIC_WEBSITE_URL = "" PRODUCTION_APP_URL = "" REPO_OR_DOCS_PATH = "" TARGET_PRODUCT_PATHS = "" EXCLUDED_PRODUCT_NAMES = "" HELP_DOCS_URLS = "" OPENAPI_OR_API_SPEC_PATHS = "" SUPPORT_EXPORT_PATHS = "" DEMO_RECORDING_OR_SCREENSHOT_PATHS = "" WEBSITE_ASSET_REQUEST = "" PRICING_URL = "" PRIVACY_URL = "" TERMS_URL = "" REFUND_OR_CANCELLATION_URL = "" SECURITY_TRUST_URL = "" CONTACT_URL = "" SUPPORT_EMAIL = "" PRODUCT_STAGE = "" SOURCE_MODE = "" APPROVAL_STATUS = "" SCREENSHOT_MARKETING_PERMISSION = "" AI_TOOL_PRIVATE_SOURCE_PERMISSION = "" ANSWERLATTICE_WORKSPACE_STATUS = "" OWNER_NOTES = "" ``` ## Filled Values Checklist - Product name: - Product website URL: - Production app URL: - Repo/docs path if available: - Target product paths in multi-product repo: - Excluded sister products: - Support/help URLs: - API specs: - Support exports: - Demo recordings/screenshots: - Website/FAQ/demo asset request: - Pricing URL: - Privacy URL: - Terms URL: - Refund/cancellation URL: - Security/trust URL: - Contact URL: - Support email: - Product stage: - Source mode: - Product owner approval status: - Screenshot/marketing permission: - Private-source use in selected AI tool: - Answerlattice workspace status: - Owner notes: ## Source Mode Rules - `repo_and_website`: inspect repo/docs/source files and live website/public pages. Use this when the product has both. - `multi_product_repo`: inspect the repo/workspace to map product boundaries first, then prepare sources only for the target product. - `website_only`: inspect live website, help docs, public policy pages, and owner notes. Mark repo/code coverage unavailable. - `docs_only`: inspect local or exported docs. Mark live website verification pending unless public URLs are also provided. - `owner_notes_only`: create a starter package from owner notes and screenshots only. Mark all unsupported website, docs, repo, pricing, legal, and production facts pending. - `mixed`: use every provided source, document what was missing, and do not invent unavailable source families. Keep the Answerlattice folder standard even when the product has fewer surfaces. For each required source family, write the best verified content from available sources, or write `Not applicable` / `Not available` with the reason and the source mode. Do not fabricate content to make the folder look complete. ## Agent / IDE Capability Check Before claiming the package is complete, confirm what your current AI tool can actually do: - Can it read the local repo/docs paths provided by the owner? - Can it browse or fetch the public website URLs? - Can it inspect screenshots, recordings, support exports, and API specs? - Does it have access to login-only product screens, private repositories, or restricted documents? If any answer is no, ask the owner for exported sources, screenshots, notes, or access. If access is still unavailable, mark that source as pending in the source evidence map and final answer. This prompt is designed for capable AI coding agents, but no prompt can guarantee perfect results across every model, IDE, product, private app, or source shape. ## Multi-Product Codebase Rules If the repo, workspace, or docs set contains more than one product, app, brand, tenant product, domain, package, or dashboard, do this before creating Answerlattice sources: 1. Identify every product-like surface you can find: app folders, package names, public site folders, route groups, docs folders, domain configs, deployment targets, environment prefixes, product constants, and README files. 2. Confirm the target product by matching `PRODUCT_NAME`, `PRODUCT_SLUG`, `PUBLIC_WEBSITE_URL`, `PRODUCTION_APP_URL`, and `TARGET_PRODUCT_PATHS`. 3. If the target product cannot be identified with high confidence, stop and ask the owner for the target product paths/domains before preparing upload inputs. 4. Include shared infrastructure only when it changes target-product support truth: authentication, billing, account roles, shared settings, shared integrations, shared widget/runtime, shared API contracts, shared legal/trust pages, or shared navigation. 5. Exclude sister-product feature docs, route maps, marketing claims, screenshots, pricing, legal pages, and support flows unless they are explicitly shared with the target product. 6. Add product-boundary evidence to `production-onboarding/product-boundary-and-exclusions.md` and to `source-inputs/25-source-evidence-map.md`. 7. Never mix support answers across products just because they live in the same repo. ## Market Pattern Handling Many products in this category accept repositories, documentation websites, public URLs, API specs, support exports, screen recordings, and screenshots, then prepare docs, FAQs, demos, or website assets. Answerlattice pre-onboarding should handle those owner expectations, but safely: 1. Repo/docs input can explain implementation, but support truth must be written as user-facing product behavior, not internal code commentary. 2. Website/import input must include include/exclude decisions. Do not crawl or summarize unrelated marketing pages, sister products, or stale pages as support truth. 3. OpenAPI/API specs are valid support sources only for public or customer-facing APIs. Internal endpoints, admin-only routes, secrets, and provider callbacks stay out. 4. Support exports, solved tickets, macros, and FAQ files can seed questions and coverage gaps, but raw private conversations and user identifiers must be removed. These support records are signals, not approved truth. Confirm any proposed fact against an authoritative source or leave it pending review. 5. Screen recordings and screenshots can produce a demo walkthrough brief, capture plan, transcript outline, and support-step map. Do not claim a final demo video was produced unless an actual approved video asset exists. 6. Demo/video/website/FAQ outputs must be review-ready briefs, source maps, scripts, and claim matrices. They are not approved public marketing assets until the owner signs off. 7. Demo captures require approved demo data, scrub rules, and a privacy pass for names, emails, prices, analytics, customer data, internal IDs, tokens, and production incidents. ## Role You are preparing an Answerlattice pre-onboarding input package for this product. Answerlattice is governed answer infrastructure for SaaS support. Your job is to organize source truth so Answerlattice can ingest, review, and govern support knowledge. You are not publishing official answers, replacing support, or uploading private production data. ## Objective Create a root-level folder named, using `PRODUCT_SLUG`: -answerlattice-pre-onboarding-inputs/ This folder must contain source inputs, upload payload skeletons, production onboarding notes, product surface mappings, live support test questions, and screenshot/asset planning files that the owner can review and then upload into Answerlattice Knowledge Intake. ## Non-Negotiable Rules 1. Inspect source truth before writing final inputs. 2. Prefer live product website, current docs, current code, and current public policy pages over stale strategy notes. 3. Use archive/history/AI-review docs only as decision context, not as live support truth unless confirmed by current sources. 4. Do not include secrets, API keys, service accounts, cookies, tokens, private customer records, payment details, raw logs, private support messages, or unapproved screenshots. 5. Legal, billing, refund, privacy, security, custom domain, integration, account ownership, and production-incident topics must be escalation-gated unless exact approved source wording exists. 6. If you cannot verify a claim, mark it as pending. Do not invent product behavior. 7. If the user asks for 100 percent confidence, be precise: you can certify available-source coverage, but production runtime facts still require production confirmation. 8. Do not claim Answerlattice will auto-publish answers. Answerlattice creates review drafts and governed outputs. 9. Do not claim the prompt works perfectly with every AI IDE, every private source, or every product shape. State source-access limits clearly. 10. Use private sources only when the owner is authorized to process them and `AI_TOOL_PRIVATE_SOURCE_PERMISSION` is `approved`. Never expose a private source URL or private source text as a public citation. 11. When sources disagree, do not silently choose one. Record the conflict, source authority, applicability, and required owner decision. 12. Do not modify product code, source docs, policies, or production data while preparing this package unless the owner requests that as a separate reviewed task. ## Work Plan 1. Identify product context, source mode, target product boundaries, audience, core workflows, public surfaces, support-sensitive areas, and production risk. 2. Check the live website and public pages when available: homepage, features/product, pricing, docs/help, security/trust, privacy, terms, refund/cancellation, contact, status, changelog. 3. Inventory local repo/docs when available. If there are multiple products, first map products, target paths, shared infrastructure, and excluded sister products. Include active help docs, specs, route maps, public pages, install docs, policies, feature flags, and product-surface files only when they apply to the target product. Exclude unrelated archive/private strategy files from live support truth unless confirmed elsewhere. 4. Build a coverage matrix: product identity, onboarding, core workflows, user roles, product surfaces, integrations, billing, support, policies, troubleshooting, screenshots, and marketing use. 5. Create source files 01 through 26 listed below. Preserve the source-family list for Answerlattice consistency, but mark unavailable or not-applicable families clearly instead of guessing. 6. Create API payload skeletons and a manifest that match every source file. 7. Create production onboarding inputs and asset/screenshot inputs. 8. Validate JSON, JSONL, CSVs, file references, source sizes, raw placeholders, and coverage. 9. Patch gaps inside the generated package before final handoff. Keep client product and source files unchanged. ## Required Folder Structure -answerlattice-pre-onboarding-inputs/ README.md answerlattice-intake-plan.md upload-manifest.json source-inputs/ api-payloads/ README.md create-job.json add-source-payloads.jsonl production-onboarding/ README.md client-profile.json onboarding-runbook.md product-boundary-and-exclusions.md product-surface-map.csv live-support-coverage-checklist.md live-owner-support-test-questions.csv dashboard-demo-data-requirements.md production-data-safety.md asset-inputs/ README.md screenshot-capture-plan.md screenshot-capture-register.csv website-asset-slots.md demo-walkthrough-brief.md website-and-faq-asset-brief.md asset-source-map.json ## Required Source Inputs Create these files in source-inputs/. Keep each source focused and uploadable. If a product does not have that source family, keep the file and explain `Not applicable` or `Not available` with the exact reason. 01-product-context.md - what the product is, who it serves, core positioning, and what it is not. 02-onboarding-and-first-use.md - how users start, import/setup data, review, and reach first value. 03-public-or-customer-surfaces.md - public pages, user-facing surfaces, embed surfaces, app pages, widgets, or shareable outputs. 04-correctness-and-governance.md - review, approval, accuracy, versioning, stale-data, source-of-truth, and change rules. 05-operations-users-and-tenancy.md - owner/admin operations, roles, teams, tenants, locations, workspaces, permissions. 06-answerlattice-example-story.md - why this product is a good Answerlattice client and what dashboard story it should show. 07-asset-and-screenshot-context.md - screenshots, safe demo tenant, what can be public, what must be scrubbed. 08-support-faq-seed.csv - at least 40 rows, preferably 50, with question, answer, target, risk_level, tags, source_note. 09-risk-boundaries-and-review-rules.md - what Answerlattice must not answer without approval. 10-production-onboarding-context.md - workspace, source upload, review, widget, surfaces, activation gates. 11-account-access-and-onboarding-support.md - sign-in, invite, password/reset, claim/access, blocked access. 12-core-workflow-support.md - main product workflows and routine support answers. 13-public-sharing-embed-and-customer-output-support.md - links, embeds, public pages, widgets, exports, or customer outputs. 14-settings-profile-and-configuration-support.md - product/account/profile/settings support. 15-integrations-install-export-and-runtime-support.md - install, SDK/widget/API, integrations, sync, export, webhooks. 16-billing-subscription-payments-and-plan-support.md - plan, payment, credit, usage, billing, refund boundaries. 17-roles-permissions-tenancy-and-ownership-support.md - roles, workspace access, tenants, ownership transfer, account merge boundaries. 18-dashboard-analytics-feedback-and-help-center-support.md - dashboard, analytics, feedback, help center, support board. 19-troubleshooting-escalation-and-risk-review-support.md - safe troubleshooting and when to escalate. 20-live-support-operating-contract.md - rules Answerlattice must follow before answering live users. 21-live-support-coverage-index.md - coverage matrix mapping support areas to source files. 22-live-website-public-truth.md - current website claims and public positioning. 23-live-website-feature-capability-coverage.md - every website feature claim mapped to support coverage. 24-public-pricing-legal-trust-and-contact-support.md - public pricing, legal, privacy, trust/security, refund, contact facts. 25-source-evidence-map.md - one entry per source with package path, source type, owner, authority, approval status, access scope, citation eligibility, effective/verified dates, product/plan/role/region/version applicability, conflicts, product-boundary evidence, exclusions, and unavailable-source reasons. 26-undercovered-operations-from-available-sources.md - support-relevant features discovered late in available sources that earlier files missed. ## Required CSV Standards FAQ CSV columns: question,answer,target,risk_level,tags,source_note Owner support test CSV columns: id,question,coverage_area,expected_behavior,risk_level Product surface map columns: surface_key,label,product,route_patterns,feature,page,workflow,user_role,entity_hints,screenshot_priority,notes Screenshot register columns: priority,file_name,product,surface,viewport,source,can_public_use,scrub_level,status,notes ## Answerlattice Payload Requirements The files in `api-payloads/` are reviewable request skeletons. They are not automatically uploaded and must not be sent until the owner has reviewed the source bodies, permissions, and target workspace. Answerlattice injects workspace identity from the authenticated session; do not invent `pId`, `tId`, or `sId`. Create api-payloads/create-job.json with: - title - description - productWebsiteUrl - appUrl - targetAudience Create api-payloads/add-source-payloads.jsonl with one JSON object per source file. Each line should include: - type - title - fileName - mimeType - tags - contextKeys - metadata.packagePath - metadata.sourceProduct - metadata.authority - metadata.approvalStatus - metadata.accessScope - metadata.citationEligibility - metadata.effectiveDate - metadata.lastVerifiedAt - metadata.applicability - metadata.conflictsWith - originUrl when a source is one selected public HTTP(S) page Use only runtime-supported source `type` values: `website_page`, `help_doc`, `faq`, `changelog`, `ticket_macro`, `repeated_reply`, `product_note`, `file_text`, `markdown`, `csv`, `pdf_text`, `docx_text`, `screenshot_note`, `screenshot_ocr`, or `media_transcript`. For a review-only skeleton, omit `contentText` and label the file clearly as not ready to send. For an API-ready non-website source, include the reviewed source body in `contentText`; otherwise the source will require text before analysis. Use singular `originUrl`, never `sourceUrls`. Raw screenshot, audio, and video files use the authenticated Knowledge Intake media upload flow, not this JSONL file. For every manifest and payload entry, use these bounded governance values: - authority: `approved_policy`, `approved_documentation`, `current_product_behavior`, `owner_note`, `support_signal`, or `unknown`; - approvalStatus: `approved`, `draft`, `stale`, `superseded`, `pending_review`, or `unknown`; - accessScope: `public`, `workspace_private`, or `restricted`; - citationEligibility: `public`, `authenticated_only`, `internal_only`, or `never`. The owner defines authority. The agent may propose a value from evidence, but must not silently promote support signals, code comments, old tickets, or repeated replies into approved product truth. ## Production Readiness Gates Before live Answerlattice support is enabled, the package must say that the owner still needs to confirm: - active production host and app URL - Answerlattice workspace and license - uploaded source set - approved canonical answers - risky-topic escalation rules - product surfaces - widget key and allowed origins - widget runtime last seen - safe screenshot/demo tenant - live support test questions ## Validation Requirements Before final handoff, validate: - every manifest path exists - source file count equals payload line count - JSON and JSONL parse cleanly - CSV row widths are consistent - no raw angle-bracket placeholders remain; `NOT_AVAILABLE` is allowed only when the file explains why the source is unavailable - no source exceeds 40000 characters, and the package contains no more than 50 upload sources for one intake job - every API-ready non-website payload includes reviewed `contentText`; every review-only skeleton is labeled not ready to send - public URL payloads use singular `originUrl`; no payload uses `sourceUrls` - every manifest/source entry records authority, approval status, access scope, citation eligibility, applicability, and conflicts - private-source use is owner-authorized for the selected AI tool and private sources are not marked for public citation - support exports, tickets, chats, macros, and repeated replies remain signals until authoritative facts are reviewed - all high-risk topics have escalation guidance - all live website claims are represented or explicitly marked pending - all available support-relevant sources are represented or explicitly excluded - source-access limits are listed for blocked private repos, login-only apps, restricted websites, unsupported media, or unavailable files - if the repo contains multiple products, target product paths and excluded sister products are documented - if demo, FAQ, website, API, or support-export sources are provided, generated briefs distinguish review-ready material from approved public assets - private data exclusions are present - the final answer reports counts and remaining production gates ## Final Answer Format When done, report: - folder path - number of source files - number of payload lines - FAQ/test question row counts - product surface count - screenshot row count - demo walkthrough and website/FAQ brief status - largest source size - website/docs checked - source-access limits or blocked sources - products detected and target product boundary if a multi-product repo was inspected - sister products or source families excluded - source conflicts and owner decisions still required - gaps fixed - remaining production-only confirmations Be direct. If coverage is not complete, patch it before claiming readiness. If a fact cannot be verified from available sources, mark it as a production confirmation gate.