The full path to docs people can actually navigate — plan the doc set, structure the site, write the guides and the API reference, then ship it as a coherent documentation site.
Documentation fails in a specific way: each page is fine, but the whole is a maze — no clear path from 'getting started' to 'reference', guides that assume what they should explain, an API section nobody can find. A documentation website is a structure problem before a writing one. This project builds one documentation-first: plan the doc set around what readers actually need to do, organize it into an information architecture that makes the next step obvious, write the conceptual guides and the API reference as distinct, deliberate layers, and ship it. It's specifically a documentation site — not a company marketing site, and not an internal knowledge base — so every decision serves a reader trying to accomplish a task with your product. Each stage connects to a NewPrompt workflow you can run on its own; together they turn scattered notes into docs a developer can navigate. You know the product; the project makes sure the docs are organized and complete instead of a pile of pages.
Each stage runs a NewPrompt workflow, with a supporting resource and tool. Work them in order — the output of each stage feeds the next.
See the execution map →Plan the documentation set
Decide what the docs must cover and for whom — the getting-started path, the how-to guides, the reference, the FAQs — driven by the tasks readers actually need to complete, not by what's easy to write.
Structure the docs site
Organize the doc set into an information architecture — sections, hierarchy, and navigation — so a reader always knows where they are and what comes next, instead of getting lost three clicks in.
Write the guides and concepts
Write the conceptual and how-to documentation — the layer that explains how the product works and walks a reader through real tasks — in clear, consistent prose generated from the actual behavior.
Write the API reference
Document the API surface as a distinct reference layer — endpoints, parameters, responses, examples — complete and consistent, because reference docs are where a developer ends up when the guides run out.
Ship the docs site
Cross from built to live — check readiness, plan the deploy and a rollback, and decide what to watch — so the docs ship deliberately and the publishing pipeline is something you can rerun for every update.
A documentation website a reader can navigate — a planned doc set, an information architecture with an obvious path from getting-started to reference, conceptual guides and an API reference written as distinct layers, and the whole thing shipped — instead of a maze of pages that are each fine and collectively unusable.
Intent. This is documentation-first: a planned doc set, search-friendly structure, guides, and an API reference. A company site sells; docs explain.
Yes — writing the API reference is its own stage alongside the conceptual guides, because reference and explanation serve different reader needs.
No — the journey plans content and structure regardless of tooling; you can map it onto whatever docs platform you ship on.
Run the five stages in order, each in your own AI tools. Plan the doc set around reader tasks, structure it into an information architecture, write the conceptual guides, write the API reference as a distinct layer, then ship with a repeatable publish path. NewPrompt supplies the prompts and workflows; you write and verify the docs.
Bring the raw material the docs describe: the product's actual behavior, your API surface — endpoints, parameters, responses — and the real tasks readers need to complete. The planning stage turns that into a doc set, so accurate source knowledge matters more than tooling; you can map the plan onto any docs platform afterward.
Treat the ship stage's publish path as rerunnable. That final stage plans the deploy, a rollback, and what to watch, so publishing becomes a pipeline you rerun for every update rather than a one-time event. When the product changes, revisit the affected guide or API-reference stage and republish. Each republish and its accuracy are yours to check.
Decide what to publish and why before you write a word — set the business goals and audience, map needs to topics, brief the priority pieces, then turn it into a content plan you publish against.
Organize a site so people and crawlers find things — inventory the content, group it into a real hierarchy, design the sitemap and navigation, then document the information architecture for the build.
Turn source material and a target audience into clear docs, help, or knowledge-base content — gather the material, outline the piece, write it section by section, then check it for clarity and gaps.
Generate documentation that matches the code instead of drifting from it — have AI explain what the code really does, write it up as structured docs, then validate the format holds.
Cross the gap between 'tests pass' and 'safe in production' — assess release readiness, plan the deploy and its rollback, and set up the monitoring and launch checks before you ship, not after.
A sequential prompt workflow for content strategy: audience first, then goals, competitor gaps, topic clusters, defensible angles, and a publishing plan with a review loop.
A reference document is only as useful as its addressability. Heavy § labeling turns a nine-section reference into something every answer can point into.
Overview, Key Concepts, How It Works, Usage, Troubleshooting — docs pages with the same shape for every feature, and code in every usage section.
Overview, Authentication, Endpoints, Error Handling, Rate Limits — endpoint docs in an identical structure, with parameter tables and runnable examples forced.
SHIP or DO NOT SHIP: twelve checks on failure modes, observability, rollback, and load — the review that happens before the incident.
Turn website goals, audiences, content types, and conversion paths into a sitemap and information-architecture spec: navigation, a page inventory, hierarchy, URLs, user journeys, and an internal-linking plan.
Break a big goal into a sequential prompt workflow — each step with an objective, prompt, and expected output.
Build prompts that produce documents in a fixed structure — headings, sections, and tables.
Build code explanation prompts — mode, audience, and depth turn into an understanding contract that teaches, not narrates.
Practical project ideas you can build from this base project path — each opens in the Project Advisor.
The full path to knowledge that's findable by people and AI — plan the taxonomy, structure it for search, write the articles, tag the metadata, make it retrievable, then ship it maintainable.
The full path to a business website that holds together — plan the content, structure the site, design the components, write the page copy, then ship it as one coherent whole.
The full path to a backend you can put clients on — define the requirements, design the architecture, API contract, data model, and access control, then build it reviewed, tested, secured, and shipped.