nitro_kit 2.0.0.alpha.4 → 2.0.0.alpha.5

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: f4ea3ffdd5e6404639ac11c27f5eb4798b2d29b0103b360404b964c46ffed908
-  data.tar.gz: 5a1141716d12a4e3f30969f9971da1d844d44d057e856bd6ed2d1ea0a99fec2d
+  metadata.gz: 2f703b97ad2c84b8c66a306453dd1070554fe7c45f994a36672639af781856ed
+  data.tar.gz: 9343dd1db39ec96141f560eeebf0edd873d3b68960a36ffdc0abe413b0b66491
 SHA512:
-  metadata.gz: 03b102d89337de8a13f54b0e1e52163897f5d215ea1810d979f3fa4d0985b86e03bd8c9702e9aedccf21d9252e3cdfab23ccf6686cf79caa85f7d383c1af65f0
-  data.tar.gz: f2a33cc6791355080ff7439e714dd2d7c44f4ce706f36817cb7c1c9f42286323bec458c9238e1adb3bbf6807aae57ffedc40b2fd3b49b523027d7b9aa97a0d95
+  metadata.gz: 13e10affc36f849b140ee76f99fb6c7ce4403767d1b2da3a20decb2d15fbcc898bf725b637db7d1f2476c7fd12059e4ffb4449a137309253119de03eb18450a6
+  data.tar.gz: 4889ff8fdd803acfb652511c0938247a5edc0e1ead51687c5ed97966bf2493038def6d2d34b91a1b498310d78c62390ab29cee5fce3763393e9aa01f986263e0

data/CHANGELOG.md

@@ -2,6 +2,21 @@
 
 ## Unreleased
 
+## 2.0.0.alpha.5
+
+### Added
+
+- Add a copyable product bootstrap prompt that tells coding agents to install
+  Nitro Kit before planning an application and to discover optional product
+  patterns when catalog tools are available.
+
+### Changed
+
+- Teach the installed agent guidance and bundled Codex plugin to search an
+  available Nitro Kit catalog by product workflow without making catalog access
+  a requirement, and clarify that Nitro Kit Doctor checks integration health
+  rather than product completeness.
+
 ## 2.0.0.alpha.4
 
 ### Added

data/README.md

@@ -6,7 +6,7 @@
 
 **Audience:** Rails developers evaluating or installing Nitro Kit.
 
-Nitro Kit is a gem-owned Phlex UI system for Rails. The `2.0.0.alpha.4` prerelease
+Nitro Kit is a gem-owned Phlex UI system for Rails. The `2.0.0.alpha.5` prerelease
 is under active testing and is not stable.
 
 [![RubyGems](https://img.shields.io/gem/v/nitro_kit.svg)](https://rubygems.org/gems/nitro_kit)
@@ -16,7 +16,7 @@ is under active testing and is not stable.
 Pin the prerelease:
 
 ```ruby
-gem "nitro_kit", "2.0.0.alpha.4"
+gem "nitro_kit", "2.0.0.alpha.5"
 ```
 
 ```sh
@@ -42,6 +42,21 @@ Nitro Kit targets maintained evergreen browsers from roughly the previous two
 years, with Mobile Safari as a first-class target. See the
 [browser support policy](docs/browser_support.md) for exact fallback behavior.
 
+## Prompting a coding agent
+
+Add this to a product bootstrap prompt so the agent installs Nitro Kit, uses
+its guidance, and discovers optional product patterns when available:
+
+```text
+Add Nitro Kit 2 to this Rails app and use it for the product's application UI.
+
+Set up Nitro Kit before planning or implementing the product:
+- Add and pin the current Nitro Kit 2 prerelease in the Gemfile, run bundle install, run bin/rails generate nitro_kit:install, and run bin/rails nitro_kit:doctor.
+- Load the generated project-local Nitro Kit skills and installed, version-matched docs.
+- Check whether Nitro Kit catalog or MCP tools are available. If they are, inventory and search them by product workflow, retrieve relevant patterns, and state what you will use, adapt, or defer.
+- If no catalog is available, continue with the bundled docs and component contracts; catalog access is optional.
+```
+
 Maintaining Nitro Kit 1? Its frozen documentation remains at
 [v1.nitrokit.dev](https://v1.nitrokit.dev).
 

data/docs/agent_guide.md

@@ -35,6 +35,28 @@ Read this guide from that directory. The installed
 Before changing a Nitro Kit 1.x application, read the migration guide. Do not
 infer 2.x APIs from memory or old application code.
 
+## Discover optional product patterns
+
+The installed skills, documentation, component contracts, and source are the
+complete required path for using Nitro Kit. A Nitro Kit catalog may also be
+available through MCP or another tool, but catalog access is optional and must
+never block the work.
+
+For greenfield planning or broad product work:
+
+1. Check whether Nitro Kit catalog or MCP tools are available.
+2. When available, inventory the catalog, then search by product workflow rather
+   than component name.
+3. Retrieve the relevant patterns before implementation and record which will be
+   used, adapted, or deferred.
+4. When unavailable, continue with the installed guidance and report no catalog
+   coverage claims.
+
+For a focused component or interaction change, search only when a catalog tool
+is already available and the task could benefit from a higher-level pattern.
+`nitro_kit:doctor` validates installation and runtime contracts; it is not a
+product-completeness audit.
+
 ## Preserve the application's architecture
 
 For a greenfield application, run:

data/docs/component_contracts.md

@@ -4,7 +4,7 @@
 API. This table is also parsed by the gallery; keep every row to four cells and
 escape literal pipe characters.
 
-This is the shipped public catalog for `2.0.0.alpha.4`. It records current Ruby
+This is the shipped public catalog for `2.0.0.alpha.5`. It records current Ruby
 construction, rendered roots, closed vocabularies, compound cardinalities, and
 integration boundaries. For task guidance, start with the
 [agent guide](agent_guide.md) or [Rails integration](rails_integration.md).

data/docs/initialization_prompt.md

@@ -6,20 +6,26 @@
    `2.`.
 2. Choose the project-local Nitro Kit skill matching the task. It will resolve
    and read the installed, version-matched `docs/agent_guide.md`.
-3. Inspect the application before editing. Preserve established view, asset,
+3. For greenfield planning or broad product work, check whether Nitro Kit
+   catalog or MCP tools are available. When available, inventory and search by
+   product workflow, retrieve relevant patterns, and state what will be used,
+   adapted, or deferred. When unavailable, continue with the bundled guidance;
+   catalog access is optional and must never block the work.
+4. Inspect the application before editing. Preserve established view, asset,
    authentication, and testing conventions unless the task changes them.
-4. For a greenfield application, run `bin/rails generate phlex:install` and use
+5. For a greenfield application, run `bin/rails generate phlex:install` and use
    Phlex for the application layout, route views, and reusable UI. In an
    established application, introduce Phlex only at the requested boundary.
    Do not perform an application-wide migration unless it is explicitly
    authorized.
-5. Verify that the application loads Nitro Kit CSS, the appearance bootstrap,
+6. Verify that the application loads Nitro Kit CSS, the appearance bootstrap,
    Turbo, Stimulus, and the normal Stimulus controller loader. Never copy Nitro
    components or `nk--*` controllers into the application.
-6. Verify one application base component includes `NitroKit`, and model-backed
+7. Verify one application base component includes `NitroKit`, and model-backed
    forms select `NitroKit::FormBuilder` explicitly.
-7. Run `bin/rails nitro_kit:doctor`, fix actionable failures, and run the
-   application's relevant tests.
+8. Run `bin/rails nitro_kit:doctor`, fix actionable failures, and run the
+   application's relevant tests. Doctor verifies Nitro Kit integration, not
+   whether the product implements every relevant workflow.
 
 If this is a Nitro Kit 1.x migration, stop and follow
 `docs/migration_1_to_2.md` from the installed gem. Replace a control only when

data/docs/migration_1_to_2.md

@@ -12,7 +12,7 @@ Treat a 1.x migration as a product-flow review, not a helper rename. Nitro Kit
 Add the 2.0 prerelease to the application's Gemfile:
 
 ```ruby
-gem "nitro_kit", "2.0.0.alpha.4"
+gem "nitro_kit", "2.0.0.alpha.5"
 ```
 
 Bundler records the exact released version in `Gemfile.lock`; commit `Gemfile`

data/docs/rails_integration.md

@@ -12,7 +12,7 @@ There are no `nk_form_with` helpers or general ERB component bridge.
 Pin the current prerelease:
 
 ```ruby
-gem "nitro_kit", "2.0.0.alpha.4"
+gem "nitro_kit", "2.0.0.alpha.5"
 ```
 
 Use the released gem and commit `Gemfile` with `Gemfile.lock`. Before upgrading,

data/lib/nitro_kit/installation.rb

@@ -23,6 +23,14 @@ module NitroKit
       Each skill resolves the installed gem with `bundle show nitro_kit` and reads
       its version-matched documentation.
 
+      For greenfield planning or broad product work, check whether Nitro Kit
+      catalog or MCP tools are available. When they are, inventory and search the
+      catalog by product workflow, retrieve the relevant patterns, and state what
+      will be used, adapted, or deferred before implementation. When they are not,
+      continue with the bundled skills, documentation, and component contracts;
+      catalog access is optional and must never block the work. Nitro Kit Doctor
+      verifies integration health, not product completeness.
+
       In a greenfield application, run `bin/rails generate phlex:install` and use
       Phlex for the application layout, route views, and reusable UI. In an
       established application, preserve its existing view architecture and

data/lib/nitro_kit/version.rb

@@ -1,3 +1,3 @@
 module NitroKit
-  VERSION = "2.0.0.alpha.4"
+  VERSION = "2.0.0.alpha.5"
 end

data/plugins/nitro-kit/.codex-plugin/plugin.json

@@ -14,15 +14,15 @@
   "interface": {
     "displayName": "Nitro Kit",
     "shortDescription": "Build Rails UI with Nitro Kit and Hotwire",
-    "longDescription": "Model conventional Rails resources, compose Nitro Kit components, and implement Hotwire interactions from the installed gem version.",
+    "longDescription": "Model conventional Rails resources, compose Nitro Kit components, implement Hotwire interactions from the installed gem version, and use optional catalog guidance when available.",
     "developerName": "Mikkel Malmberg",
     "category": "Developer",
     "capabilities": ["Read", "Write"],
     "websiteURL": "https://nitrokit.dev",
     "defaultPrompt": [
-      "Build this Rails feature on the Nitro Kit Rails path.",
-      "Build this Rails interface with Nitro Kit components.",
-      "Implement this interaction with Nitro Kit and conventional Hotwire."
+      "Build this Rails feature on the Nitro Kit Rails path, using relevant catalog guidance when available.",
+      "Build this Rails interface with Nitro Kit components and any relevant catalog guidance available.",
+      "Implement this interaction with Nitro Kit, conventional Hotwire, and relevant catalog guidance when available."
     ]
   }
 }

data/plugins/nitro-kit/skills/nitro-kit-hotwire/SKILL.md

@@ -25,6 +25,18 @@ Make the server response and stable DOM boundary the interaction API. Add Stimul
 7. Read `NITRO_KIT_ROOT/docs/browser_support.md` for the canonical
    full/reduced/unavailable no-JavaScript classification.
 
+## Discover optional catalog guidance
+
+For a broad product workflow, check whether Nitro Kit catalog or MCP tools are
+available. When they are, inventory and search by workflow, retrieve relevant
+patterns, and state what will be used, adapted, or deferred before
+implementation. When they are not, continue with the installed Hotwire recipes,
+component contracts, and source. Catalog access is optional and must never
+block the work or be implied in the result.
+
+For a focused interaction, use the catalog only when it is already available
+and a higher-level pattern would materially help.
+
 Do not proceed with a remembered Nitro Kit 1.x API. Do not copy or recreate
 the installed gem's `nk--*` controllers under `app/javascript/controllers/nk`.
 

data/plugins/nitro-kit/skills/nitro-kit-hotwire/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Nitro Kit Hotwire"
   short_description: "Build conventional Nitro Kit Hotwire flows"
-  default_prompt: "Use $nitro-kit-hotwire to build this interaction with Nitro Kit and conventional Hotwire."
+  default_prompt: "Use $nitro-kit-hotwire to build this interaction with Nitro Kit, conventional Hotwire, and relevant catalog guidance when available."

data/plugins/nitro-kit/skills/nitro-kit-rails/SKILL.md

@@ -24,6 +24,18 @@ established application outside the requested scope.
 9. Read `NITRO_KIT_ROOT/docs/browser_support.md` before claiming an
    interaction works without JavaScript.
 
+## Discover optional catalog guidance
+
+For greenfield planning or broad product work, check whether Nitro Kit catalog
+or MCP tools are available. When they are, inventory and search by product
+workflow, retrieve the relevant patterns, and state what will be used, adapted,
+or deferred before implementation. When they are not, continue with the
+installed skills, documentation, component contracts, and source. Catalog
+access is optional and must never block the work or be implied in the result.
+
+For a focused Rails change, use the catalog only when it is already available
+and the task could benefit from a higher-level product pattern.
+
 Never use a Nitro Kit 1.x helper, copied component, controller, or Tailwind
 contract as a substitute for the installed API.
 
@@ -70,3 +82,6 @@ Nitro Kit owns component contracts and focused progressive behavior.
 Run focused model and request tests first. Add a system test only where browser
 behavior is part of the contract. Assert status, visibility, authorization,
 and stable DOM boundaries rather than implementation trivia.
+
+Nitro Kit Doctor verifies integration and runtime contracts, not product
+completeness. For broad work, verify the agreed workflow coverage separately.

data/plugins/nitro-kit/skills/nitro-kit-rails/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Nitro Kit Rails"
   short_description: "Build conventional Rails applications with Nitro Kit"
-  default_prompt: "Use $nitro-kit-rails to build this feature on the Nitro Kit Rails path."
+  default_prompt: "Use $nitro-kit-rails to build this feature on the Nitro Kit Rails path, using relevant catalog guidance when available."

data/plugins/nitro-kit/skills/nitro-kit-ui/SKILL.md

@@ -18,14 +18,25 @@ Use the documentation shipped with the application's installed gem as the source
    classifications in `NITRO_KIT_ROOT/docs/browser_support.md`.
 7. Inspect the installed component source when constructor or compound-slot details remain unclear. Never guess a component API from memory.
 
+## Discover optional catalog guidance
+
+For greenfield planning or broad product UI work, check whether Nitro Kit
+catalog or MCP tools are available. When they are, inventory and search by
+product workflow, retrieve the relevant patterns, and state what will be used,
+adapted, or deferred before implementation. When they are not, continue with
+the installed skills, documentation, component contracts, and source. Catalog
+access is optional and must never block the work or be implied in the result.
+
+For a focused component change, use the catalog only when it is already
+available and a higher-level composition would materially help.
+
 For a Nitro Kit 1.x migration, read
 `NITRO_KIT_ROOT/docs/migration_1_to_2.md` before editing. Inventory product
 flows, behavior, application-owned button classes and Rails button helpers,
 joined controls, and the existing semantic color, focus, radius, density, and
 typography tokens first. Capture representative wide and narrow screenshots.
-If the Nitro Kit MCP catalog is available, search it by workflow rather than
-old component name, then select high-level compositions before replacing
-atoms.
+Apply the optional catalog process above, searching by workflow rather than old
+component name and selecting high-level compositions before replacing atoms.
 
 If the gem is not installed, say that the skill requires Nitro Kit and follow the application's requested installation scope. Do not substitute APIs from an older Nitro Kit release.
 
@@ -76,4 +87,8 @@ If the gem is not installed, say that the skill requires Nitro Kit and follow th
 
 Run the smallest relevant application tests. For component rendering, assert semantic elements and owned `data-nk` or slot attributes rather than private implementation helpers. Exercise invalid and empty states when the UI accepts user input or collections.
 
+Nitro Kit Doctor verifies integration and runtime contracts, not product
+completeness. Do not use a green Doctor result as proof that every relevant
+screen, state, or catalog workflow has been implemented.
+
 For a migration, Doctor is an inventory, not visual proof. Run representative form and component rendering with `ActiveModel::Translation.raise_on_missing_translations` enabled when the application uses strict i18n. Compare the same representative flows in a browser at wide and narrow widths, exercise keyboard focus, and inspect computed styles for missing application classes, stacked Button content, broken compound corners, double focus rings, clipping, and theme drift. Re-audit rendered native buttons, Rails button helpers, and application-owned button classes before declaring the conversion complete. Search the whole application for `desperately_need_a_class:` and review every result, aiming for zero. Move layout and visual treatment to application-owned wrappers, remove generic class forwarding, accept incidental Nitro defaults, and keep unmatched product UI application-owned; retain only documented external-integration hooks.

data/plugins/nitro-kit/skills/nitro-kit-ui/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Nitro Kit UI"
   short_description: "Build Rails interfaces with Nitro Kit components"
-  default_prompt: "Use $nitro-kit-ui to build this Rails interface with the installed Nitro Kit components."
+  default_prompt: "Use $nitro-kit-ui to build this Rails interface with the installed Nitro Kit components and any relevant catalog guidance available."

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: nitro_kit
 version: !ruby/object:Gem::Version
-  version: 2.0.0.alpha.4
+  version: 2.0.0.alpha.5
 platform: ruby
 authors:
 - Mikkel Malmberg