feat(cli): harden rocket init

Generate a concise Atlas-backed starter and project-local skills while keeping init quiet in existing Rocket sites. Reuse existing Rocket start/build scripts, skip starter example Pages when a repo already has several Rocket Pages, and keep generated starter data type-clean.

Also harden standalone demo rendering and matching, expose reusable demo component and icon helpers, support direct layout re-exports, add start flags, and document the static JavaScript/request-demo caveats.

Author: daKmoR

.agents/skills/coding-style/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: coding-style
+description: Indexes this repo's coding conventions for file placement, tests, API shape, component authoring, and commit messages. Use when creating or editing source files, adding tests, designing function signatures, creating components, or writing commits in this repo.
+---
+
+# Coding Style
+
+Open only the convention file needed for the current task. If a task spans multiple areas, read each relevant file before editing:
+
+- Source and test files: see [source-and-tests.md](source-and-tests.md)
+- Function signatures and calls: see [apis-and-functions.md](apis-and-functions.md)
+- Components: see [components.md](components.md)
+- Commit messages: see [commits.md](commits.md)
+
+Prefer these conventions over generic language or framework defaults unless nearby code clearly establishes a narrower local pattern.

.agents/skills/coding-style/apis-and-functions.md

@@ -0,0 +1,23 @@
+# APIs and Functions
+
+Keep function signatures easy to read at the call site. Prefer positional parameters only when their meaning is obvious and the argument list stays short.
+
+When a function would take more than two parameters, prefer a single object parameter with named properties:
+
+```js
+foo({ some: 'stuff', safe: true, retries: 2 });
+```
+
+Avoid signatures that require readers to remember positional meaning:
+
+```js
+foo('stuff', true, 2);
+```
+
+Also prefer an object parameter for fewer arguments when a primitive or boolean flag would be ambiguous at the call site:
+
+```js
+foo({ some: 'stuff', safe: true });
+```
+
+Keep existing public APIs stable unless the task explicitly includes changing callers. For private helpers, update the call sites when the object form makes the code clearer.

.agents/skills/coding-style/commits.md

@@ -0,0 +1,29 @@
+# Commit Messages
+
+Use a small Conventional Commits style for the header:
+
+`<type>(<module>): <short message>`
+
+Allowed types: `feat`, `fix`, `docs`, `test`, `refactor`, `chore`, `build`, `ci`.
+
+`<module>` is a short lowercase area such as `api`, `ui`, `docs`, `deploy`, or `tdd`.
+
+Keep the header short, specific, and scannable. Use imperative or present-tense wording, and do not end it with a period.
+
+Examples:
+
+```txt
+feat(auth): add login redirect
+fix(deploy): handle missing env file
+docs(setup): clarify build command
+test(loop): cover retry failure path
+refactor(cli): simplify command parsing
+chore(deps): update lockfile
+ci(release): add publish workflow
+```
+
+Write a generated commit body for non-trivial commits.
+
+The body should be human-readable prose based on the actual diff, not a rigid template. Explain why the change was needed, what changed, and any behavior or test impact worth preserving in history. Do not repeat the header in sentence form.
+
+Prefer one short paragraph for focused commits. Use a few bullets only when the commit spans multiple notable areas. Skip generic boilerplate such as "This commit..." or "Generated by AI".

.agents/skills/coding-style/components.md

@@ -0,0 +1,3 @@
+# Components
+
+When creating components, always prefer `LitElement` unless the existing code in that area clearly uses a different component base.

.agents/skills/coding-style/source-and-tests.md

@@ -0,0 +1,24 @@
+# Source and Test Files
+
+Prefer colocated tests. For `src/foo.js`, put the test in `src/foo.test.js`. For nested modules, keep the test next to the source file it covers.
+
+Name source files after their primary export. Use `camelCase` for functions and plain modules, and `UpperCamelCase` for classes and custom elements:
+
+- `src/mySuperFunction.js`
+- `src/mySuperFunction.test.js`
+- `src/MyElement.js`
+- `src/MyElement.test.js`
+
+For new Node tests, prefer `describe` and `it` from `node:test`:
+
+```js
+import { describe, it } from 'node:test';
+
+describe('Test addressList', () => {
+  it('01: finds default address', async () => {
+    // ...
+  });
+});
+```
+
+Use numbered `it` cases (`01:`, `02:`, etc.) when a module has multiple behavior examples. Keep test names behavior-focused.

.agents/skills/rocket/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: rocket
+description: Use when editing Rocket Pages, config, layouts, component reference Pages, or build behavior in this project.
+---
+
+# Rocket
+
+## Rules
+
+- Read `rocket-config.js` first; Page discovery follows `includeGlobs`.
+- Every Page owns its URL through `config.path`; put general docs in `docs/pages` and component docs next to the component.
+- Prefer Markdown for durable content; use JavaScript Pages for request-time or programmatic output.
+- Prefer interactive examples for component and behavior docs; use `js demo` when readers benefit from trying the UI.
+- Prefer Atlas docs layouts: `atlasDocLayout` for docs, `atlasHeroLayout` for a standalone docs home, with matching `components` exports.
+- Markdown using Rocket custom elements needs a `components` export; use Atlas component maps or `rocketDemoComponents`.
+- Add `menu.iconName` to Atlas docs navigation Pages so the left navigation has icons.
+- Direct layout re-exports are supported when no local wrapper function is needed.
+- Custom layouts rendering `rocket-icon` need `addBootstrapIconLibrary(pageData)` before `document()`.
+- Static JavaScript Pages render once per concrete path; query/header/cookie/live-data output needs `render: 'server'`.
+- Static Request Demos should target concrete non-query URLs.
+- After adding a `js demo`, verify the parent Page and Standalone Demo URL `/page/_demo/demoName/`.
+- Keep `npm run build` passing; record Rocket package issues separately from local workarounds.

.changeset/sparkly-pots-tickle.md

@@ -0,0 +1,5 @@
+---
+'@rocket/js': patch
+---
+
+Harden rocket init for Atlas docs starters and existing Rocket sites, add demo/icon helpers, start flags, and standalone demo build validation.

AGENTS.md

@@ -1,60 +1,7 @@
-## Agent skills
-
 ### Issue tracker
 
 Issues are tracked as local markdown files under `.scratch/<feature-slug>/`. See `docs/agents/issue-tracker.md`.
 
-### Triage labels
-
-Use the default mattpocock/skills triage label vocabulary. See `docs/agents/triage-labels.md`.
-
 ### Domain docs
 
 This repo uses a single-context domain documentation layout. See `docs/agents/domain.md`.
-
-### Source and test files
-
-Prefer colocated tests. For `src/foo.js`, put the test in `src/foo.test.js`. For nested modules, keep the test next to the source file it covers.
-
-Name source files after their primary export. Use `camelCase` for functions and plain modules, and `UpperCamelCase` for classes and custom elements:
-
-- `src/mySuperFunction.js`
-- `src/mySuperFunction.test.js`
-- `src/MyElement.js`
-- `src/MyElement.test.js`
-
-For new Node tests, prefer `describe` and `it` from `node:test`:
-
-```js
-import { describe, it } from 'node:test';
-
-describe('Test addressList', () => {
-  it('01: finds default address', async () => {
-    // ...
-  });
-});
-```
-
-Use numbered `it` cases (`01:`, `02:`, etc.) when a module has multiple behavior examples. Keep test names behavior-focused.
-
-### Commit messages
-
-Use a small Conventional Commits style:
-
-`<type>(<module>): <short message>`
-
-Allowed types: `feat`, `fix`, `docs`, `test`, `refactor`, `chore`, `build`, `ci`.
-
-`<module>` is a short lowercase area such as `api`, `ui`, `docs`, `deploy`, or `tdd`. Keep the message short, use imperative or present-tense wording, and do not end it with a period.
-
-Examples:
-
-```txt
-feat(auth): add login redirect
-fix(deploy): handle missing env file
-docs(setup): clarify build command
-test(loop): cover retry failure path
-refactor(cli): simplify command parsing
-chore(deps): update lockfile
-ci(release): add publish workflow
-```

CONTEXT.md

@@ -482,7 +482,7 @@ _Avoid_: Rewrite, alias, Page
 - **Zero-install Agent Onboarding** creates an **Agent Starter Site** by default.
 - An **Agent Starter Site** uses static Pages unless the **Site Author** asks for request-time behavior.
 - A **Rocket Initializer** may create an **Agent Starter Site** in an empty project or add Rocket documentation Pages to an existing codebase.
-- A **Rocket Initializer** creates the smallest durable Rocket site shape; project-specific expansion belongs to a **Coding Agent**.
+- A **Rocket Initializer** creates a compact Atlas-backed **Agent Starter Site** with shared layout data, starter documentation Pages, demo examples, and a **Rocket Agent Skill**; project-specific expansion belongs to a **Coding Agent**.
 - A **Rocket Initializer** creates a **Rocket Agent Skill** by default.
 - A **Rocket Initializer** creates **General Documentation Pages** in the project's documentation area for both **Standalone Rocket Sites** and documentation added to an existing codebase.
 - **Component Reference Pages** may live near the component they document.

README.md

@@ -76,8 +76,9 @@ npm install @rocket/js
 npx rocket init
 ```
 
-`rocket init` creates `rocket-config.js`, `docs/pages/index.rocket.md`, and a removable
-project-local Rocket Agent Skill. It also adds npm scripts when the names are available:
+`rocket init` creates a compact Atlas docs starter, including `rocket-config.js`,
+`docs/pages/sharedData.js`, starter Markdown Pages, a static JSON Page for a Request Demo, and a
+removable project-local Rocket Agent Skill. It also adds npm scripts when the names are available:
 
 ```json
 {
@@ -102,7 +103,7 @@ export default {
 };
 ```
 
-The generated `docs/pages/index.rocket.md` gives you a first Page:
+The generated `docs/pages/index.rocket.md` gives you an Atlas hero home Page:
 
 ````md
 ```js server
@@ -112,14 +113,22 @@ export const config = {
     title: 'Rocket Site',
     description: 'Documentation built with Rocket.',
   },
+  menu: {
+    iconName: 'house',
+    order: 0,
+  },
 };
 
-export { layout } from '@rocket/js/layout.js';
+import { atlasHeroLayout, atlasHeroComponents } from '@rocket/js/layouts/atlasHero.js';
+import { heroData } from './sharedData.js';
+
+export const components = atlasHeroComponents;
+export const layout = pageData => atlasHeroLayout(pageData, heroData);
 ```
 
 # Rocket Site
 
-This Page is rendered by Rocket.
+This starter is rendered with Rocket's Atlas hero layout.
 ````
 
 Then run: