Start With AI#

You are helping me start or improve a Rocket site.

Interview me relentlessly about every important decision until we reach a shared understanding.
Walk down the design tree one decision at a time, resolving dependencies between decisions before
moving on. Ask one question at a time. For each question, include your recommended answer.

First inspect the project. If a question can be answered by exploring the codebase, project docs, or
existing assets, explore instead of asking me. Check package.json, rocket-config.js, docs/pages,
src, public, existing project instructions, and any existing .agents/skills/rocket/SKILL.md.

If this is not already a Rocket project:
- If package.json is missing, create one with npm init -y.
- Install Rocket with npm install @rocket/js when @rocket/js is missing.
- Run npx rocket init to create the minimal Rocket shape.
- Read .agents/skills/rocket/SKILL.md if it exists after initialization and follow it.

If this is already a Rocket project:
- Do not re-scaffold files that already exist.
- Read rocket-config.js before changing Pages.
- Preserve the existing includeGlobs, layouts, Page patterns, and project instructions unless there
  is a clear reason to change them.

Question budget:
- Ask at most 10 substantive questions total.
- Ask fewer questions when the project already gives enough information.
- After 5 substantive questions, or earlier once you can build a coherent first version, ask:
  "I can start building now with these assumptions, or keep asking up to 5 more questions. Which do
  you prefer?"
- If I choose to build, summarize your assumptions and start.
- If I choose to keep going, continue one question at a time until the remaining decisions are
  resolved or the 10-question limit is reached.
- If a decision blocks implementation, say why it blocks before building.

Use this decision order. Skip anything answerable from the codebase:
1. Site purpose and primary audience.
2. Primary visitor action or successful outcome.
3. Required Pages, navigation, and rough content hierarchy.
4. Existing content, assets, code, or source material to reuse.
5. Visual direction, brand constraints, and examples to avoid or emulate.
6. Content tone, language, and localization needs.
7. Whether this is a Standalone Rocket Site or component/library documentation.
8. Request-time behavior, integrations, forms, search, authentication, or other dynamic needs.
9. Deployment target, Site Origin, and whether publishing should happen now or later.
10. Launch readiness: favicon assets, Site Head Metadata, discoverability, and verification.

You have enough to build a coherent first version when you know or can infer:
- the site purpose
- the primary audience
- at least one primary visitor action or outcome
- the initial Page list, even if rough
- whether this is a Standalone Rocket Site or component/library documentation
- the visual direction, or permission to choose one
- whether request-time behavior is needed
- the deployment target well enough to create the right build config or defer deployment safely

Missing favicon assets, final Site Origin, exact production copy, and deployment credentials do not
block the first build. Record them as follow-up items instead.

Build rules:
- Use @rocket/js and Rocket Pages. Do not create a Vite, React, Astro, Next, or other framework app
  for the site unless the existing project already requires separate integration work.
- General Documentation Pages go under docs/pages.
- Component Reference Pages go next to the component they document.
- Every Page owns its public URL through config.path.
- Prefer Markdown Pages for durable content.
- Use JavaScript Pages only for request-time or programmatic rendering.
- Keep the first version static unless the interview identifies real request-time behavior.
- Do not invent extra Pages just to hit a count; create the smallest useful Page set for the visitor
  journey.
- If this is component or Web Component documentation, create at least one Component Reference Page
  with a useful rendered example.
- Add a local layout, styles, data files, public assets, Site Head Metadata, or deployment config
  only when the site decisions call for them.
- Configure Favicon Asset references only for files that actually exist under public/.
- Do not enable sitemap or robots until the final production Site Origin is known and the site is
  ready for public crawlers.
- Do not publish, initialize Git, or commit unless I explicitly ask.

Before building, summarize:
- the decisions you learned from the codebase
- the decisions I answered directly
- the assumptions you are making
- the Pages and files you plan to create or change
- any launch items you are intentionally deferring

After building:
- Run the appropriate Rocket build command, usually npm run build or npm run rocket:build.
- Fix build failures before finishing.
- If you can start a local dev server, tell me the URL.
- Summarize changed files, verification results, and deferred launch items.