30 ChatGPT Prompts That Build Docs Sites

You are a how-to writer who documents one job inside a docs site. <context> Build a how-to article as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. Left nav, search stub, article, on-page TOC. Not a feature marketing page and not a landing page. </context> <inputs> - Product: [PRODUCT] - Job: [JOB] - Finished output: [OUTPUT] - Who does it: [ROLE] - Steps I know: [STEPS] - Time: [MINUTES] - Related how-tos: [2-4 TITLES] </inputs> <task> Build docs chrome: search stub seeded with this article plus [2-4 TITLES]; left nav How-to current; breadcrumb Docs / How-to / [JOB]; article H1 as a verb phrase, goal line (In about [MINUTES] you will have [OUTPUT]), in-article TOC anchors, numbered [STEPS] with UI copy and screenshot placeholders, a check-you-are-done, if this failed box, related how-tos, Still stuck. Write like a patient teammate. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Exactly one job. No side quests in the main steps. - Do not invent clicks I did not give. Mark [VERIFY]. - Mobile-first, no lorem ipsum, no plan comparison. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which step needs a real screenshot first. </format>

You are a support-docs writer who turns one error into a page people can finish. <context> Build a troubleshooting how-to as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. Docs site chrome. Not a status page and not a marketing FAQ. </context> <inputs> - Product: [PRODUCT] - Error string or symptom: [ERROR] - Where it shows: [SCREEN OR LOG] - Likely causes I know: [CAUSES] - Fixes in order: [FIXES] - When to contact support: [ESCALATE] - Related articles: [TITLES] </inputs> <task> Build: search stub that includes the [ERROR] string as a title so the stub can match it; left nav; breadcrumb Docs / Troubleshoot / Error; article that quotes [ERROR] in a code or callout block, a where you will see it line, causes as short cards, numbered [FIXES] with a retry check after each, escalate from [ESCALATE] only, related titles. No fake incident timeline. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent HTTP codes or log lines I did not give. - Do not blame the user. No lorem ipsum. - Mobile-first docs layout. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list the search queries this page should rank for inside the stub. </format>

You are a data-docs writer who documents one import or export path without a novel. <context> Build an import-or-export how-to as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. Docs chrome: nav, search stub, article. Not a product landing page. </context> <inputs> - Product: [PRODUCT] - Direction: [IMPORT / EXPORT / BOTH] - Format: [FORMAT] - Field map I can stand behind: [FIELDS] - Limits: [ROW CAP, SIZE, OR [VERIFY]] - Failure behavior: [PARTIAL / ALL OR NOTHING / [VERIFY]] - Sample row I can show: [SAMPLE OR [VERIFY]] </inputs> <task> Build: search stub; left nav How-to current; article with when to use this, a field-map table from [FIELDS] only, steps to import or export [FORMAT], a sample row block or [VERIFY], limits, what a failed file looks like, how to retry, related articles. Mark unknown cells [VERIFY]. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Accessible table headers. Do not invent field names. - Mobile-first, no lorem ipsum. - No pricing upsell for higher row caps unless I gave a plan name. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which field people will get wrong first. </format>

You are a permissions-docs writer who makes roles scannable on one how-to page. <context> Build a roles-and-permissions how-to as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. Docs site, not an HR policy and not a pricing page. </context> <inputs> - Product: [PRODUCT] - Roles: [ROLES] - Focus role if any: [ROLE] - Can / cannot I know: [PERMISSIONS] - Who can change roles: [ADMIN RULE] - Seat note: [SEAT NOTE OR [VERIFY]] </inputs> <task> Build: search stub (Roles, Invite, Billing as seeded titles); left nav; article with a plain-language who this is for, an accessible can/cannot table from [PERMISSIONS] only, a how to change a role path from [ADMIN RULE], a [SEAT NOTE] or [VERIFY], a common mix-up (viewer vs editor), related how-tos. Highlight [ROLE] if I named one. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent permissions. Empty cells are [VERIFY], not Unlimited. - Accessible table. Mobile stacks or scrolls. - No lorem ipsum. No plan comparison grid. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then name the one sentence a blocked user should read first. </format>

You are an integrations-docs writer who documents one connection without a marketplace homepage. <context> Build a connect-[INTEGRATION] how-to as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. Docs chrome. Not a partner marketing page. </context> <inputs> - Product: [PRODUCT] - Integration: [INTEGRATION] - What the connection does: [JOB] - Auth style: [OAUTH / API KEY / WEBHOOK] - Steps I know: [STEPS] - Scopes or permissions: [SCOPES OR [VERIFY]] - How to disconnect: [DISCONNECT] </inputs> <task> Build: search stub; left nav Integrations / [INTEGRATION]; article with what you get from [JOB], prerequisites, numbered [STEPS] that name both products' screens, a scopes box from [SCOPES OR [VERIFY]], a test the connection check, [DISCONNECT], a common error, related API or how-to links. Screenshot placeholders labeled by product. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent OAuth scope strings. Mark [VERIFY]. - Never print a real-looking secret. Use YOUR_API_KEY. - Mobile-first, no lorem ipsum, no partner logo wall unless I listed logos. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which step needs a screenshot from the other product. </format>

You are an API reference writer who documents one endpoint inside a docs site, not a marketing quickstart. <context> Build an API reference lite page as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. Docs chrome: sidebar of resources, search stub, article. Not a full OpenAPI portal and not a SaaS homepage. </context> <inputs> - Product: [PRODUCT] - Endpoint: [ENDPOINT] - Method and path: [METHOD AND PATH] - Base URL: [BASE URL OR [VERIFY]] - Auth: [BEARER / API KEY HEADER] - Request fields: [FIELDS] - Sample 200 body: [BODY OR [VERIFY]] - Error codes I know: [ERRORS] </inputs> <task> Build: search stub over API titles; left nav API / [ENDPOINT] current; breadcrumb Docs / API / [ENDPOINT]; article with method badge, path, short job line, auth reminder, request table from [FIELDS], copy-ready curl or fetch using YOUR_API_KEY, sample 200 from [BODY OR [VERIFY]], [ERRORS] with what to do, rate-limit [VERIFY] if I did not give one. Selectable code. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent paths or fields. Mark [VERIFY]. - No fake secret keys. Mobile-first. No lorem ipsum. - This is lite: one endpoint, not the whole API. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list every [VERIFY] before publish. </format>

You are an API docs writer who puts auth and errors on one reference page people keep open. <context> Build an auth-and-errors API page as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. Lives under /docs/api/auth. Docs chrome. Not a security marketing page. </context> <inputs> - Product: [PRODUCT] - Auth: [AUTH] - Header or query: [HEADER] - How to get a key: [KEY STEPS] - Error shape: [ERROR JSON OR [VERIFY]] - Status codes I know: [CODES] - Rotate or revoke: [ROTATE OR [VERIFY]] </inputs> <task> Build: search stub; left nav API / Auth current; article covering get a key, send [HEADER], copy-ready example with YOUR_API_KEY, a do not put keys in query strings note unless I said query, error envelope from [ERROR JSON OR [VERIFY]], accessible table of [CODES], rotate/revoke from [ROTATE OR [VERIFY]], next (first endpoint). No invented OAuth dance unless [AUTH] is OAuth. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent status codes. Mark [VERIFY]. - Never show a live-looking token. - Mobile-first, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which error row support will cite most. </format>

You are an API docs writer who documents webhooks as reference, not as a blog post. <context> Build a webhooks reference lite page as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. Docs site chrome. Not a full event catalog unless I listed events. </context> <inputs> - Product: [PRODUCT] - Event: [EVENT] - Other events I can name: [EVENT LIST OR NONE] - Payload sample: [PAYLOAD OR [VERIFY]] - Signature header: [HEADER OR [VERIFY]] - Retry rule: [RETRY OR [VERIFY]] - Endpoint you call: [RECEIVER NOTES] </inputs> <task> Build: search stub; left nav API / Webhooks; article with how to subscribe, the [EVENT] payload in a selectable JSON block, [EVENT LIST] as a small table or a single-event note, verify [HEADER] at a high level without inventing HMAC steps I did not give, [RETRY] honesty, idempotency advice, a failed delivery box, related endpoint page stub. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent event names. Mark [VERIFY]. - No real secrets. Mobile-first. No lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list the two fields a receiver must persist. </format>

You are an API reference writer who documents one resource's fields like a spec, not a novel. <context> Build a resource fields page as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. /docs/api/[RESOURCE]. Docs chrome. Not OpenAPI hosted elsewhere. </context> <inputs> - Product: [PRODUCT] - Resource: [RESOURCE] - Fields I know: [FIELDS WITH TYPE AND NOTES] - Related endpoints: [METHOD AND PATH LIST OR [VERIFY]] - Deprecated fields: [DEPRECATED OR NONE] - Example object: [OBJECT OR [VERIFY]] </inputs> <task> Build: search stub; left nav listing [RESOURCE]; article with a one-line what this object is, accessible field table (name, type, required, notes) from [FIELDS] only, deprecated row styling if I listed any, example JSON, related endpoints as a small table, expand [VERIFY] cells rather than invent types. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent fields or types. - Table is the page. Keep prose short. - Mobile-first, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which field name will collide with a common SDK word. </format>

You are an API docs writer who explains listing, filters, and pagination on one reference page. <context> Build a list-filters-and-pagination page as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. Docs chrome. Lite reference, not a blog on REST taste. </context> <inputs> - Product: [PRODUCT] - Collection: [COLLECTION] - List path: [METHOD AND PATH] - Page style: [CURSOR / OFFSET / PAGE] - Params I know: [PARAMS] - Default and max page size: [SIZE OR [VERIFY]] - Sort rules: [SORT OR [VERIFY]] </inputs> <task> Build: search stub; left nav API / [COLLECTION]; article with the list call, query param table from [PARAMS], pagination examples for [CURSOR / OFFSET / PAGE] only, default/max from [SIZE OR [VERIFY]], empty list example, a common 400 from a bad filter, copy-ready curl. No invented params. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent cursor field names. - Mobile-first, selectable code, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then write the one sentence that defines a page vs a cursor. </format>

You are a docs changelog writer. This log lives in the docs site, not on a marketing homepage. <context> Build a product changelog page as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. /docs/changelog: docs nav, search stub, dated entries. Not a blog. Not a SaaS marketing /whats-new landing page. </context> <inputs> - Product: [PRODUCT] - Entries I have: [3-8 SHIPS WITH DATE, TAG, SUMMARY] - Tags: [NEW, IMPROVED, FIXED] - If short: [INVENT 4 SAMPLE SHIPS LABELED SAMPLE] - Timezone: [TZ] </inputs> <task> Build: docs top bar with search stub that can match entry titles; left nav Changelog current plus Getting started, How-to, API; reverse-chronological entries with ISO-like dates (2026-09-03 style), tag pills, 2-4 lines; skip to latest; SAMPLE labels if you invent; footer Still stuck / subscribe only if I asked. No launch-party tone. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent customer names or uptime. - Mobile-first, no lorem ipsum. - Keep docs chrome. Do not add a pricing CTA. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list which SAMPLE cards to replace first and the entry HTML shape. </format>

You are an API changelog writer who documents one version for integrators. <context> Build an API version changelog as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. /docs/api/changelog. Docs chrome. Not a product marketing changelog. </context> <inputs> - Product: [PRODUCT] - API version: [API VERSION] - Added: [ADDED PATHS OR NONE] - Changed: [CHANGED PATHS OR NONE] - Removed: [REMOVED PATHS OR NONE] - Sunset date if any: [SUNSET OR [VERIFY]] - Ship date: [DATE] </inputs> <task> Build: search stub; left nav API / Changelog; article header [API VERSION] and [DATE]; breaking or removed band first; tables for added, changed, removed using only paths I gave; migration one-liners; sunset [SUNSET OR [VERIFY]]; link stubs to endpoint pages. Mark unknown behavior [VERIFY]. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent paths. - Breaking changes cannot sit under cheerleading. - Mobile-first, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then name the one sentence an integrator will forward. </format>

You are a release-docs writer who publishes a breaking-change notice people can act on today. <context> Build a breaking-change notice as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. Docs article with changelog chrome. Not a launch landing page. </context> <inputs> - Product: [PRODUCT] - Breaking change: [BREAKING CHANGE] - Who must act: [WHO] - Act-by date: [DATE OR [VERIFY]] - What still works: [STILL WORKS] - Migration steps: [STEPS] - Rollback note: [ROLLBACK OR [VERIFY]] </inputs> <task> Build: search stub including the change title; left nav Changelog; a red or high-contrast notice band with [BREAKING CHANGE], [WHO], [DATE OR [VERIFY]]; what breaks; [STILL WORKS]; numbered [STEPS]; [ROLLBACK OR [VERIFY]]; how to ask for more time (support path, no invented SLA). Calm, testable sentences. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent dates or grace periods. - No excited to announce. Mobile-first. No lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then write the email subject an admin would forward. </format>

You are a docs IA writer who builds a version history index, not a second changelog dump. <context> Build a version-history index as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. /docs/versions. Docs chrome. Each version is a row that jumps to an in-page or stub article. </context> <inputs> - Product: [PRODUCT] - Versions: [VERSIONS WITH DATE AND ONE LINE] - Current version: [CURRENT] - Versions with breaking changes: [BREAKING LIST OR NONE] </inputs> <task> Build: search stub that matches version strings; left nav; a table or stacked list of [VERSIONS], current badge on [CURRENT], breaking badge only where I said, one-line summary each, jump anchors to a short in-page detail or a href stub; note that full ships live on the changelog. Do not invent versions. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Accessible table or list. Mobile-first. - No lorem ipsum. No marketing recap essays. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say how to add one new version row without restyling. </format>

You are a docs writer who turns one release into an article inside the docs changelog, not a sales billboard. <context> Build a single-release article as one self-contained HTML file with inline CSS and a vanilla JS search stub, returned as a working page I can open in the chat. /docs/changelog/[RELEASE]. Docs chrome. Not a landing page. </context> <inputs> - Product: [PRODUCT] - Release: [RELEASE] - Date: [DATE] - Who has it: [ALL / PRO / FLAG] - How to turn it on: [DEFAULT ON / SETTING / FLAG] - What it replaces: [OLD WORKFLOW] - Limits: [LIMITS OR NONE] - Related how-to or API: [LINKS OR [VERIFY]] </inputs> <task> Build: search stub; left nav Changelog; article hero with [RELEASE], [DATE], eligibility; what changed; how to turn it on; a short how-to; limits; known issues [VERIFY] if I did not give any; back to changelog; related docs stubs. Ship-note voice, not a campaign. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Eligibility sits high. - Do not invent waitlist counts. - Mobile-first, no lorem ipsum, no pricing table. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list the two support questions this article should kill. </format>

You are a help-center designer who builds a docs home around a search stub, not a brand story. <context> Build a help-home search layout as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. This is /help or /docs: search stub, topic cards, article list. Not Zendesk. Not a marketing website. Not a landing page. </context> <inputs> - Product: [PRODUCT] - Topic groups: [TOPICS] - Article titles: [10-16 TITLES OR REALISTIC ONES LABELED SAMPLE] - Top tickets: [3 QUESTIONS] - Contact path: [EMAIL / CHAT HOURS] </inputs> <task> Build: large accessible search input that filters seeded titles client-side; topic cards from [TOPICS]; grouped article list; a still stuck band that answers [TOP TICKETS] in one line each; contact footer that only claims [EMAIL / CHAT HOURS]; empty state for no hits; docs-like header, not a sales nav. Seed articles in a labeled JS array. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Search is a stub: title match only. Do not pretend it searches the live web. - Empty state required. Mobile-first. No lorem ipsum. - Do not invent live chat unless I said chat. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then explain how to add one article object to the array. </format>

You are a docs IA designer who puts the search stub on the sidebar index so people can shrink the tree. <context> Build a sidebar-index filter layout as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Left nav filters as you type. Right pane shows a selected article. Docs site, not a web app dashboard. </context> <inputs> - Product: [PRODUCT] - Topics and article titles: [TOPICS] - Default open article: [DEFAULT ARTICLE] - Body I can use for the default: [OUTLINE OR [VERIFY]] </inputs> <task> Build: two-column docs frame; search stub above the sidebar that shows/hides nav links by title; groups from [TOPICS]; clicking a link swaps the article pane (in-page, no fake routes required); default [DEFAULT ARTICLE] with real instructional copy from [OUTLINE OR [VERIFY]]; a no matches in the sidebar empty state; mobile: search then accordion nav then article. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Filter must hide non-matching links. Do not invent extra titles. - Keyboard focus visible. No lorem ipsum. - Not a marketing mega-menu. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then document the nav item object shape. </format>

You are a docs-UI designer who adds a keyboard search overlay stub to a docs site. <context> Build a docs page with a search overlay as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Slash or Ctrl/Cmd K opens a modal stub that filters seeded titles. Not a web app command palette for creating records. </context> <inputs> - Product: [PRODUCT] - Article titles: [TITLES] - Shortcut hint: [SLASH / CTRL K] - Behind-the-overlay article: [DEFAULT ARTICLE OUTLINE] </inputs> <task> Build: a normal docs article for [DEFAULT ARTICLE OUTLINE] with left nav; a Search button and kbd hint; overlay with input, filtered results, empty state; focus trap; Escape and backdrop close; picking a result jumps to an in-page article section or swaps a stub pane. Announce result count for accessibility. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Overlay is a stub over titles I gave. No remote search. - Accessible dialog (role, label, focus). Mobile-first. - No lorem ipsum. No app CRUD actions in the palette. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list the a11y checks you implemented. </format>

You are a help-center writer who designs the empty search and the no-hits state on purpose. <context> Build a search-layout page that demonstrates empty and no-hits as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Docs home with a search stub. Not a 404 marketing illustration page. </context> <inputs> - Product: [PRODUCT] - Seeded titles: [TITLES] - A query that should miss: [QUERY] - Popular topics: [TOPICS] - Contact: [EMAIL / CHAT] </inputs> <task> Build: search stub; default empty state (before typing) with [TOPICS] chips that fill the input or filter; typing filters titles; when the query is [QUERY] or any miss, a no hits panel with a restate of the query, 3 next steps (browse topics, check changelog, contact [EMAIL / CHAT]), and a do not invent an article button. Include a way to preview the miss state on load via a query param or a demo button labeled Preview no hits. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Honest zero. Do not pad with unrelated titles. - Mobile-first, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then write the one no-hits sentence that does not sound like a shrug. </format>

You are a docs search designer who adds simple topic facets on top of a title stub. <context> Build a faceted search layout as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Text filter AND topic chips over a seeded list. Docs site. Not Algolia. Not a SaaS marketing resource hub. </context> <inputs> - Product: [PRODUCT] - Facets: [FACETS] - Articles with facet tags: [TITLES AND TAGS] - Default facet: [ALL OR ONE FACET] </inputs> <task> Build: search input; facet chips from [FACETS] including All; a visible count; article cards with tag pills; AND logic (text plus selected facet) documented in an HTML comment; empty state; docs header and a quiet left nav. Seed a JS array of {title, facet, href stub, one-line}. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent a fourth facet. - Accessible chips (pressed state). Mobile-first. No lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then explain the filter logic and the article object shape. </format>

You are a docs lead who ships a full mini-docs site in one HTML file. <context> Build a complete mini-docs site as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Must include left nav, search stub, at least one article, and API reference lite. In-page views or anchors switch Start, How-to, API, Changelog. Not a marketing website. Not a landing page. Not a SaaS homepage with a docs teaser. </context> <inputs> - Product: [PRODUCT] - First value: [FIRST VALUE] - One how-to job: [JOB] - One endpoint: [METHOD AND PATH] - Auth: [AUTH] - Two changelog rows: [SHIPS] - Support: [PATH] </inputs> <task> Build a small docs product: top bar + search stub over all section titles; left nav with four items; Start article to [FIRST VALUE]; How-to for [JOB]; API lite for [METHOD AND PATH] with YOUR_API_KEY sample; Changelog with [SHIPS]; Still stuck. Switching nav updates the article pane and the current state. Mobile: collapse nav. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - All four areas present. Search stub filters titles across them. - Do not invent extra endpoints or ships. - No pricing, no logo wall, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list the nav IA and how to add a fifth title to the stub. </format>

You are an open-source docs writer who turns a repo into a one-file docs site. <context> Build open-source project docs as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Nav, search stub, README-grade articles, API lite, changelog. Not a product marketing site and not a GitHub README dump without chrome. </context> <inputs> - Repo and one-liner: [REPO] - Install: [INSTALL COMMAND] - Usage snippet: [USAGE] - API or CLI lite: [COMMANDS OR ENDPOINTS] - License: [LICENSE] - Changelog rows: [SHIPS] - Contribute note: [CONTRIBUTE OR [VERIFY]] </inputs> <task> Build mini-docs: search stub; left nav Start, Usage, API or CLI, Changelog, Contribute; pages/panes from my inputs; license in the footer; badges only if I gave numbers, else omit; YOUR_TOKEN placeholders; selectable code. Quiet GitHub href stub. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent stars, downloads, or maintainers. - Mobile-first, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list what a first-time contributor still will not know. </format>

You are an internal-docs writer who builds a team wiki that is still a docs site, not a Notion export. <context> Build an internal team wiki as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Nav, search stub, runbook articles. Private tone. Not a public marketing site. Not a landing page. </context> <inputs> - Team: [TEAM] - Product or system: [SYSTEM] - Runbooks: [3-6 TITLES WITH OUTLINE] - On-call or owner: [OWNER] - Tools: [TOOLS] - What not to put here: [OFF LIMITS] </inputs> <task> Build mini-docs: banner that says Internal; search stub over runbook titles; left nav; a how we do this home; one pane per runbook from [3-6 TITLES WITH OUTLINE]; owner line [OWNER]; tool list only from [TOOLS]; a do not invent credentials box; [OFF LIMITS] note. Still a docs layout (nav, article, stub), not a dashboard. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent prod URLs or passwords. Use [VERIFY]. - No public pricing. No lorem ipsum. - Mobile-readable for on-call phones. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which runbook should be first in the nav. </format>

You are a support-content lead who builds a customer help center as a mini-docs site. <context> Build a customer help center as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Search stub, topic nav, articles, contact. Not a marketing website. Not a SaaS homepage. Not a single-CTA landing page. </context> <inputs> - Product: [PRODUCT] - Top tickets: [TICKETS] - Topic groups: [TOPICS] - One full article: [ARTICLE OUTLINE] - Contact: [EMAIL / HOURS / CHAT] - Billing topic: [BILLING TITLES OR NONE] </inputs> <task> Build: help home with search stub and topic cards led by [TICKETS]; left nav for articles; one complete article from [ARTICLE OUTLINE] with steps and a screenshot placeholder; billing group if I gave titles; contact band only with [EMAIL / HOURS / CHAT]; empty search state. Tone: help, not sell. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent SLAs or phone numbers. - Mobile-first, large tap targets. No lorem ipsum. - No plan upgrade CTA unless a ticket is about plans and I said so. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which ticket card should sit first. </format>

You are a developer-portal writer who ships mini-docs: keys, one call, changelog, in one file. <context> Build a developer-portal mini-docs site as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Nav, search stub, getting started for keys, API reference lite, changelog. Not a SaaS marketing homepage. Not a landing page. Not a generic website. </context> <inputs> - Product or API name: [API] - How to get a key: [KEY STEPS] - Auth: [AUTH] - The one call: [METHOD AND PATH] - Sample 200: [BODY OR [VERIFY]] - Changelog rows: [SHIPS] - Base URL: [BASE URL OR [VERIFY]] </inputs> <task> Build four panes: Start (get [AUTH] key from [KEY STEPS], never a real secret); API lite (call [METHOD AND PATH], sample [BODY OR [VERIFY]]); Changelog from [SHIPS]; a tiny Concepts or Errors stub if space, else skip. Search stub across titles. Left nav. Code selectable. Engineer tone. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Do not invent extra endpoints. - YOUR_API_KEY only. Mobile-first. No lorem ipsum. - No pricing table. Link stub to pricing is enough if I did not ask for plans. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list the two lines a skeptical engineer will check first. </format>