@codemation/agent-skills 0.1.5 → 0.1.6

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # @codemation/agent-skills
 
+## 0.1.6
+
+### Patch Changes
+
+- [#57](https://github.com/MadeRelevant/codemation/pull/57) [`3e882de`](https://github.com/MadeRelevant/codemation/commit/3e882de13103b6001d278b430791c380ee6771e1) Thanks [@cblokland90](https://github.com/cblokland90)! - Align discovered plugin loading with packaged JavaScript entries and keep framework watch mode rebuilding workspace plugin dist outputs.
+
 ## 0.1.5
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codemation/agent-skills",
-  "version": "0.1.5",
+  "version": "0.1.6",
   "description": "Reusable agent skills for Codemation projects and plugin development.",
   "publishConfig": {
     "access": "public"

package/skills/codemation-cli/SKILL.md

@@ -34,6 +34,8 @@ Do not use this skill for workflow graph design, custom node implementation, or
 2. Mention `.codemation/output` only when build artifacts or runtime bootstrap details matter.
 3. When the user is in the monorepo, distinguish framework-author mode from normal consumer mode explicitly.
 4. When Redis-backed execution is involved, mention the shared PostgreSQL requirement instead of assuming local SQLite still fits.
+5. In consumer mode, discovered plugins are loaded from the built JavaScript path declared in `package.json#codemation.plugin`, not from TypeScript source under `node_modules`.
+6. In plugin mode, the CLI TypeScript-loads only the current plugin repo through the generated `.codemation/plugin-dev/codemation.config.ts`.
 
 ## Read next when needed
 

package/skills/codemation-cli/references/command-map.md

@@ -15,6 +15,7 @@ Use `codemation dev` for a standalone Codemation app.
 - The CLI starts the packaged `@codemation/next-host` UI.
 - The CLI owns a stable development gateway.
 - The CLI hot-swaps the in-process API runtime when consumer files change.
+- Discovered plugins are loaded from the built JavaScript entry declared in `package.json#codemation.plugin`.
 
 ### Framework-author mode
 
@@ -22,6 +23,7 @@ Use `codemation dev --watch-framework` when working inside the Codemation monore
 
 - The CLI starts `next dev` for `@codemation/next-host`.
 - The CLI still owns the stable gateway and runtime swapping.
+- Workspace plugin packages keep their `dist/` plugin entry fresh so runtime behavior stays aligned with packaged installs.
 - This mode is for framework package work, not normal consumer usage.
 
 ## Command responsibilities

package/skills/codemation-plugin-development/SKILL.md

@@ -25,15 +25,22 @@ Do not use this skill for ordinary consumer workflow-only changes unless the wor
 2. Keep plugin registration separate from node and credential implementation modules.
 3. Use the sandbox app to exercise the plugin right away.
 4. Keep the package publishable like a normal npm package.
+5. Treat `codemation.plugin.ts` as the plugin repo's source composition root; consumer projects should load the built JavaScript entry declared in `package.json#codemation.plugin`.
 
 ## Common plugin pieces
 
-- `codemation.plugin.ts`: plugin registration and sandbox app
+- `codemation.plugin.ts`: plugin registration and sandbox app source, compiled to the published plugin entry in `dist/`
 - `src/nodes/*`: custom node definitions (`defineNode` → **`execute`**; `defineBatchNode` → batch **`run`**)
 - `src/credentialTypes/*`: custom credential definitions
 - `src/index.ts`: package exports
 - `test/*.test.ts` (optional): Vitest + `WorkflowTestKit` from `@codemation/core/testing` for engine-backed unit tests without starting the full host (`pnpm test`)
 
+## Packaging guardrail
+
+- `package.json#codemation.plugin` should point at runnable JavaScript such as `./dist/codemation.plugin.js`.
+- Do not rely on consumers TypeScript-loading plugin files from `node_modules`.
+- Prefer publishing `dist/**` plus package metadata/docs rather than shipping source-only plugin entry files as runtime dependencies.
+
 ## Unit tests (`WorkflowTestKit`)
 
 Import **`WorkflowTestKit`** from **`@codemation/core/testing`**. Use **`registerDefinedNodes([...])`** for `defineNode` packages, then **`runNode({ node: yourNode.create(...), items })`** or **`run({ workflow, items })`** for fuller graphs. Prefer this for fast node tests; use **`codemation dev:plugin`** when you need the UI and persistence.

package/skills/codemation-plugin-development/references/plugin-structure.md

@@ -19,6 +19,8 @@ Use `codemation.plugin.ts` as the single place that:
 - registers the plugin's nodes
 - defines a small sandbox app through `defineCodemationApp(...)`
 
+That file is the plugin repository's source composition root. Consumers should discover the plugin through `package.json#codemation.plugin`, pointing at built JavaScript in `dist/`.
+
 ## Node guidance
 
 - start with `defineNode(...)` and **`execute(...)`** for simple reusable nodes (per-item pipeline; optional **`inputSchema`** and **`itemValue`** on config fields)
@@ -35,5 +37,7 @@ Use `codemation.plugin.ts` as the single place that:
 ## Publishability
 
 - keep the package build output and plugin entry explicit
+- point `package.json#codemation.plugin` at built JavaScript such as `./dist/codemation.plugin.js`
+- do not rely on consumer runtimes TypeScript-loading plugin files from `node_modules`
 - treat the plugin as a normal npm package
 - installing the package in a Codemation app should be enough for the common auto-discovery flow