camox 0.42.0 → 0.44.0

package/skills/camoxify/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: camoxify
+description: Turn an existing website, screenshot, or design into an editable Camox site. Use when recreating a reference in an existing Camox project, composing its design into blocks, layouts, fields, and repeaters.
+---
+
+# Camoxify
+
+Work in the existing Camox project; project creation and authentication are onboarding prerequisites. Match the reference while making the result reusable and easy to edit.
+
+## Inspect and decompose
+
+Inspect the source URL with available browsing tools, or use the supplied screenshot/design. If the URL is inaccessible, ask for screenshots. Check multiple pages and viewport sizes when available; don't infer a whole site's structure from one crop.
+
+For URL references, use a browser when available to explore interactive states: navigation dropdowns, hover menus, tooltips, modals, accordions, carousels, and mobile navigation. Reproduce observed behavior, not just the initial appearance. Avoid submitting forms or triggering destructive actions.
+
+Before coding, map the reference to:
+
+- **Layout:** the consistent shell across pages, such as navigation and footer. Editable shell content still lives in blocks, placed by the layout.
+- **Page blocks:** independently useful sections such as a hero, feature grid, testimonials, or pricing. Reuse existing definitions where they fit. Avoid both a monolithic page block and separate blocks for every heading or card.
+- **Fields and repeaters:** editable content within each section, grouped by meaning rather than visual position.
+
+Read [Block Definitions](../camox/references/block-definitions.md) and, when creating or changing a shell, [Layout Definitions](../camox/references/layout-definitions.md).
+
+## Use the existing styling stack
+
+Strongly prefer the project's existing shadcn components and Tailwind utilities for all styling. Inspect and reuse existing components, theme tokens, and styling conventions before building new ones. Compose or extend them to match the reference.
+
+If the reference uses another styling system, recreate its appearance and behavior with the project's existing shadcn components and Tailwind utilities; do not copy or introduce the reference's styling dependencies.
+
+Do not install other styling libraries or rely on raw CSS, custom stylesheets, or inline styles. Express layout, spacing, typography, colors, responsive behavior, and interactive states through Tailwind and the existing shadcn components.
+
+## Keep definitions generic
+
+Block names, schemas, rendering, and **default content** must work on other pages. Use `feature-grid`, not `acme-homepage-features`. Defaults are neutral examples, not the reference's copy, links, assets, or item data.
+
+Apply reference-specific content **only to instances through the CLI**, never by changing definition defaults or hardcoding it in JSX.
+
+## Model repetition, not a fixed screenshot
+
+Use `Type.Repeater` for every repeated content structure: lists, rows, columns, tables, carousels, navigation items, and cards. Never use `field1`, `field2`, etc., or hardcoded content arrays. Nest repeaters for structures such as footer columns containing links or table rows containing cells.
+
+Choose bounds from real constraints, not the number of items visible in the reference. Many sibling fields are a code smell: look for repeated groups or separate sections. Model enough flexibility to add, remove, reorder, and rewrite content without code changes; don't expose every CSS value as a field.
+
+## Use settings for constrained choices
+
+Before adding a `content` field, ask whether the editor is writing free-form content or choosing from known options. For configuration choices such as alignment, theme, size, or variant, use `settings` with `Type.Enum`. For on/off choices such as showing a background or enabling autoplay, use `settings` with `Type.Boolean`.
+
+Do not model these choices as `content` fields using `Type.String`, even if rendering code could interpret strings such as `"left"`, `"dark"`, or `"true"`. Editors should choose a valid option or toggle a setting, not type a magic string. Reserve `content`'s `Type.String` for genuinely free-form text, such as headings and descriptions. Enum defaults must match an option key.
+
+## Keep formatted text in one field
+
+Use inline formatting and `textStyle`, including highlights, instead of fields such as `headingStart`, `coloredWord`, and `headingEnd`. Editors should be able to move the emphasis by editing content alone. Read [Field styling](../camox/references/field-styling.md).
+
+```ts
+// Avoid: headingStart + coloredWord + headingEnd
+// Instance content:
+{
+  title: "Build <highlight>something great</highlight>";
+}
+```
+
+## Populate and verify
+
+Follow the [Camox CLI workflow](../camox/SKILL.md#content-and-cli) to assign layouts, place blocks, and populate content, including shared navigation/footer content. Don't publish unless asked.
+
+Compare the rendered site with the reference at desktop and mobile sizes. Verify that fields remain editable and that longer text and different repeater counts still work. Fix the reusable implementation, not just the one captured arrangement.

package/skills/camox/references/cli-blocks.md

@@ -1,78 +0,0 @@
-# Managing Blocks with the Camox CLI
-
-Read [cli-common.md](cli-common.md) first. Replace `{{CAMOX_CMD}}` as described there and verify commands with `--help`.
-
-Use these commands for Block instances and their Content. To change which fields or rendering a Block type provides, use the Block Definition reference instead.
-
-## Inspect before changing
-
-Look up the Page before creating or moving Blocks so you have its `id`, current Blocks, and any sibling ids. Describe the Block type before constructing Content:
-
-```sh
-{{CAMOX_CMD}} pages get --path /
-{{CAMOX_CMD}} blocks describe --type hero
-```
-
-## Create and position a Block
-
-```sh
-{{CAMOX_CMD}} blocks create --page-id 25 --type hero --content '{...}'
-{{CAMOX_CMD}} blocks create --page-id 25 --type hero --content '{...}' --position first
-{{CAMOX_CMD}} blocks create --page-id 25 --type hero --content '{...}' --before-id 174
-{{CAMOX_CMD}} blocks create --page-id 25 --type hero --content '{...}' --after-id 174
-```
-
-`blocks create` and `blocks move` accept the same positioning flags. Pass at most one:
-
-| Flag                      | Meaning                                         |
-| ------------------------- | ----------------------------------------------- |
-| `--position first`        | Put the Block first.                            |
-| `--position last`         | Put the Block last; this is the create default. |
-| `--after-id <ID>`         | Put it immediately after a sibling Block.       |
-| `--before-id <ID>`        | Put it immediately before a sibling Block.      |
-| `--after-position <KEY>`  | Insert after a known fractional-index key.      |
-| `--before-position <KEY>` | Insert before a known fractional-index key.     |
-
-Prefer `--position`, `--after-id`, and `--before-id`. A move requires one positioning flag.
-
-## Edit Block Content
-
-Content patches merge ordinary fields, so send only fields that should change:
-
-```sh
-{{CAMOX_CMD}} pages get --path /pricing
-{{CAMOX_CMD}} blocks edit --id 314 --content '{"headline": "New headline"}'
-```
-
-## Edit repeatable Content safely
-
-A repeatable field's array is replacement-shaped: omitting an existing item deletes it and cascades to its file references, settings, and nested items. Fetch the Block, preserve every existing item with `_itemId`, and add changes only to the intended entries:
-
-```sh
-{{CAMOX_CMD}} blocks get --id 99
-
-{{CAMOX_CMD}} blocks edit --id 99 --content '{
-  "items": [
-    {"_itemId": 401},
-    {"_itemId": 402, "answer": "Updated answer."},
-    {"_itemId": 403}
-  ]
-}'
-```
-
-The response's `repeatableItems` contains each item's `id`, `fieldName`, `parentItemId`, and Content. Use the same `_itemId` pattern recursively for nested repeatables. Fetch multiple Blocks together when useful:
-
-```sh
-{{CAMOX_CMD}} blocks get-many --id 99 --id 100 --id 101
-```
-
-`blocks get-many` returns the same bundle shape as `blocks get`, in requested-id order.
-
-## Draft and live reads
-
-```sh
-{{CAMOX_CMD}} blocks get --id 314        # draft
-{{CAMOX_CMD}} blocks get --id 314 --live # published snapshot
-```
-
-Publish or discard at the Page level; read [cli-pages.md](cli-pages.md) when the task includes review or publication.

package/skills/camox/references/cli-pages.md

@@ -1,53 +0,0 @@
-# Managing Pages with the Camox CLI
-
-Read [cli-common.md](cli-common.md) first. Replace `{{CAMOX_CMD}}` as described there and verify commands with `--help`.
-
-Use these commands for Page paths and metadata, Layout assignments, draft review, and publishing. Use [cli-blocks.md](cli-blocks.md) when changing the ordered Blocks or Content on a Page.
-
-## Create a Page with an existing Layout
-
-```sh
-{{CAMOX_CMD}} layouts list
-{{CAMOX_CMD}} pages create --path-segment about --layout-id 39
-```
-
-Use `--parent-page-id <ID>` to nest the Page under another Page. Assigning an existing Layout is a CLI content operation; creating or changing a Layout Definition is a code operation covered by the Layout Definition reference.
-
-## Review draft and live state
-
-```sh
-{{CAMOX_CMD}} pages get --path /pricing        # draft
-{{CAMOX_CMD}} pages get --path /pricing --live # published snapshot
-```
-
-Live reads fail when the Page or Block has never been published. `--live` is not a write target and does not publish anything.
-
-## Publish after approval
-
-```sh
-{{CAMOX_CMD}} pages publish --path /pricing
-```
-
-`pages publish` accepts exactly one of `--id` or `--path`. It publishes the Page's current draft and, by default, its Layout. Publishing the Layout is a no-op when it has no pending changes. Use `--no-layout` only when the user explicitly does not want pending Layout changes published with the Page:
-
-```sh
-{{CAMOX_CMD}} pages publish --path /pricing --no-layout
-```
-
-Do not publish merely because a draft edit succeeded. Summarize the draft and wait for the user to ask or approve publication.
-
-## Unpublish or discard drafts
-
-Remove a Page from live without deleting its draft:
-
-```sh
-{{CAMOX_CMD}} pages unpublish --path /pricing
-```
-
-Reset a draft to its current live snapshot without changing live:
-
-```sh
-{{CAMOX_CMD}} pages discard-changes --path /pricing
-```
-
-Both commands accept exactly one of `--id` or `--path`. Discarding fails if the Page has never been published.