Repo and website available
Best path. The agent checks code, docs, routes, public pages, policies, and source maps before creating the package.
Pre-Onboarding Guide
Use the prompt with the right source material, then review the package before Canonica intake.
This guide is for product owners and the AI agents helping them. It explains what to prepare, how to run the prompt, what the agent should inspect, and what must be checked before live support.
Prompt fields
Fill the placeholders before the agent starts.
Use real links where they exist. Use NOT_AVAILABLE when a product does not have that source yet, and the agent must mark the gap instead of inventing it.
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
CANONICA_WORKSPACE_STATUS
OWNER_NOTES
Market patterns
Handle repo-to-doc, FAQ, demo, and website requests safely.
Some teams expect the agent to turn product sources into support docs, FAQs, walkthroughs, or website asset briefs. Canonica keeps those outputs source-backed and review-gated.
Use repo and docs to explain product behavior, not internal implementation details.
For website imports, record included and excluded URLs so unrelated marketing or sister-product pages stay out.
Use OpenAPI or API specs only for public/customer-facing API support.
Use support exports to seed FAQ and coverage gaps only after removing private conversations and identifiers.
Turn recordings and screenshots into capture plans, walkthrough briefs, transcripts, and support-step maps.
Keep demo, FAQ, and website outputs review-ready until the owner approves public use.
Capability limits
The agent can only cover what it can inspect.
Treat the generated package as a source-backed draft. If a source is blocked, private, missing, or unsupported by the AI IDE, the output must show that gap clearly.
The prompt works only with sources the AI IDE can access in that session.
Private repos, login-only apps, restricted websites, recordings, and local files may need owner-granted access or exported copies.
If browsing, file reading, or media inspection is unavailable, the agent must mark that source as pending instead of claiming coverage.
A weaker agent may miss context in a large or unusual codebase, so owner review is mandatory before upload.
No prompt can guarantee perfect output for every product, AI model, IDE, private app, or source shape.
Multi-product repos
Target one product before collecting source truth.
Some clients keep several products in one codebase. In that case, the agent must map the repo first, then prepare Canonica inputs only for the product named in the prompt.
Identify product folders, route groups, packages, domain configs, docs roots, and deployment targets before writing source files.
Match the target using product name, slug, website URL, app URL, and target paths.
Include shared auth, billing, roles, integrations, widget/runtime, and legal pages only when they affect the target product.
Exclude sister-product features, claims, screenshots, support flows, and pricing unless explicitly shared.
Document target paths and exclusions in the generated product-boundary file and source evidence map.
Before running
Give the agent enough source truth.
The prompt works best when the AI IDE can inspect product material, but it can also create a starter package from explicit links, exported docs, or owner notes.
Product name, short slug, product stage, and source mode.
Product website URL and production app URL, or NOT_AVAILABLE.
Repo/docs path, website links, exported docs, or owner notes.
Target product paths and excluded sister products when the repo contains multiple products.
API specs, support exports, demo recordings, or screenshots if they are approved for review.
Help center, pricing, legal, security, and contact links.
Known app pages, user roles, plans, and integrations.
Existing support FAQs, support macros, release notes, or onboarding docs.
Screenshot and marketing approval status.
Run modes
Use the best available source path.
Not every client has the same setup. The guide still works if the repo, website, docs, or production workspace is incomplete.
Multi-product repo
The agent maps all products first, targets only the named product, and excludes sister-product facts.
Website and docs only
Use public pages, help docs, policy pages, and owner notes. Mark repo/code coverage as unavailable.
Docs only
Use local or exported docs. Mark live website and production checks as pending unless links are provided.
Owner notes only
Use product notes, role lists, screenshots, support email, and known policies. Mark unsupported facts as pending.
Early product or private beta
Use README files, screenshots, user flows, release notes, and founder notes. Keep production claims pending.
Owner review
Do not upload the folder blindly.
The AI agent prepares structure. The owner still reviews accuracy, privacy, support boundaries, and production facts before Canonica intake.
Remove secrets, tokens, cookies, API keys, service accounts, and raw logs.
Remove private customer records, private support messages, payment data, and internal IDs.
Check legal, refund, privacy, security, billing, and integration answers for approval.
Check every public website claim against current product behavior.
Confirm the generated support questions match real user language.
Confirm screenshot slots use approved demo data and scrub rules.
For the AI agent
What the agent needs to know before starting.
When the owner gives the AI IDE the Canonica link, the agent should follow the source-first operating contract and avoid unsupported certainty.
Read before writing
Inspect website pages, local docs, route files, policies, screenshots, and support material before producing the final package.
Separate truth from plans
Current production docs/code/public pages outrank archive, roadmap, strategy, and old AI review files.
Mark unavailable sources
If the repo, website, docs, owner approvals, or production account cannot be checked, mark that as pending instead of inventing coverage.
Validate like a package
Check JSON, JSONL, CSVs, manifest paths, source sizes, placeholders, and support coverage before final handoff.
Live support gate
Prepared inputs are not the same as live readiness.
Use the generated package to start Canonica faster. Turn on live support only after the runtime checks and owner approvals are complete.
All required source files are uploaded.
Generated drafts are reviewed and accepted or rejected.
Risky answers are escalation-gated.
Product surfaces are mapped.
Widget key, allowed origins, and blocked routes are configured.
Runtime widget context is seen in Canonica.
Live support test questions pass.
Owner signs off on screenshots and public asset use.
A good agent may say the package is complete for available source coverage. That still does not confirm active feature flags, account entitlements, production host, billing state, widget runtime, or legal approval.