@codemation/agent-skills 0.1.4 → 0.1.6

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # @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
+
+- [#54](https://github.com/MadeRelevant/codemation/pull/54) [`35b78bb`](https://github.com/MadeRelevant/codemation/commit/35b78bb4d8c7ee2998a8b8e51e5ffc3fd901e4c7) Thanks [@cblokland90](https://github.com/cblokland90)! - **Breaking change:** `defineNode(...)` now follows the per-item pipeline: implement **`execute(args, context)`** (optional **`inputSchema`**, **`mapInput`**, and **`TWireJson`** on the generated runnable config). Add **`defineBatchNode(...)`** with **`run(items, context)`** for plugin nodes that still require batch **`run`** semantics.
+
+  Built-in nodes and workflow DSL (`split` / `filter` / `aggregate` on the fluent chain, Switch routing, execution normalization) align with the unified runnable model.
+
+  Align documentation (site guides, repo **`AGENTS.md`**, **`strict-oop-di`** skill, **`packages/core/docs/item-node-execution.md`**) and the **plugin** starter **`AGENTS.md`** with **config** for static wiring (credentials, retry, presentation) vs **inputs** / wire JSON for per-item behavior.
+
 ## 0.1.4
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codemation/agent-skills",
-  "version": "0.1.4",
+  "version": "0.1.6",
   "description": "Reusable agent skills for Codemation projects and plugin development.",
   "publishConfig": {
     "access": "public"
@@ -37,6 +37,7 @@
     "skills"
   ],
   "scripts": {
+    "changeset:verify": "pnpm --workspace-root run changeset:verify",
     "test": "vitest run"
   }
 }

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-custom-node-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: codemation-custom-node-development
-description: Guides Codemation custom node development with `defineNode(...)` (`executeOne` per item), `defineBatchNode(...)` (batch `run`), reusable node modules, credential-aware nodes, and the class-based node fallback for advanced cases. Use when creating or updating custom nodes for apps or plugin packages.
+description: Guides Codemation custom node development with `defineNode(...)` (`execute` per item), `defineBatchNode(...)` (batch `run`), reusable node modules, credential-aware nodes, and the class-based node fallback for advanced cases. Use when creating or updating custom nodes for apps or plugin packages.
 compatibility: Designed for Codemation apps and plugin packages that define reusable nodes.
 ---
 
@@ -15,7 +15,7 @@ Do not use this skill for pure workflow chaining questions unless the node imple
 ## Default approach
 
 1. Start with `defineNode(...)`.
-2. Implement **`executeOne(args, context)`** — one mapped **input** in, one output payload per item (activations are still batch-shaped; the engine iterates items for you).
+2. Implement **`execute(args, context)`** — one mapped **input** in, one output payload per item (activations are still batch-shaped; the engine iterates items for you).
 3. Give the node a stable key and a clear title.
 4. Optionally set **`icon`** on the `defineNode` definition so the workflow canvas shows a proper glyph (same string contract as `NodeConfigBase.icon`).
 5. Use **`defineBatchNode(...)`** with **`run(items, context)`** only when the node must process the **entire batch** at once (legacy batch semantics).
@@ -26,7 +26,7 @@ Do not use this skill for pure workflow chaining questions unless the node imple
 1. Prefer helper-based nodes first.
 2. Keep nodes deterministic and focused.
 3. Request credentials through named slots instead of hard-coded secrets.
-4. Put **static** options (credentials, retry policy, labels) on **config**; put **per-item** behavior in **inputs** / wire JSON and optional **`mapInput`** (consistent with built-in nodes).
+4. Put **static** options (credentials, retry policy, labels) on **config**; put **per-item** behavior in **inputs** / wire JSON and optional **`itemValue`** on config fields (consistent with built-in nodes).
 5. Drop to class-based node APIs only when you need constructor-injected collaborators, decorators, or deeper runtime metadata.
 
 ## Testing with `WorkflowTestKit`

package/skills/codemation-custom-node-development/references/node-patterns.md

@@ -8,7 +8,7 @@ Use `defineNode(...)` when:
 - the node belongs to one app or plugin package
 - helper-based credential slots are enough
 
-## Standard helper shape (`executeOne`)
+## Standard helper shape (`execute`)
 
 ```ts
 export const uppercaseNode = defineNode({
@@ -18,7 +18,7 @@ export const uppercaseNode = defineNode({
   input: {
     field: "string",
   },
-  executeOne({ input }, { config }) {
+  execute({ input }, { config }) {
     return {
       ...input,
       [config.field]: String(input[config.field as keyof typeof input] ?? "").toUpperCase(),
@@ -31,7 +31,7 @@ Optional **`icon`** is forwarded to the generated node config for the canvas (Lu
 
 ## Batch helper shape (`defineBatchNode`)
 
-When the node must see **all items in one call**, use **`defineBatchNode`** and **`run(items, { config, credentials, execution })`** returning **`Items`** per port (same as class-based **`Node.execute`**).
+When the node must see **all items in one call**, use **`defineBatchNode`** and **`run(items, { config, credentials, execution })`** returning outputs for the batch (same contract as other batch-shaped nodes such as **Aggregate**).
 
 ## When a custom node pays off
 
@@ -52,6 +52,6 @@ Reach for class-based node APIs when:
 
 ## Runtime reminder
 
-- **`defineNode`** runs **`executeOne` once per item** (with optional **`mapInput`** / **`inputSchema`** before enqueue)
+- **`defineNode`** runs **`execute` once per item** (with optional **`inputSchema`** and **`itemValue`** on config fields before **`execute`**)
 - **`defineBatchNode`** runs **`run`** once per activation batch
 - keep nodes deterministic and testable; prefer real code paths or in-memory collaborators over heavy mocking

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
-- `src/nodes/*`: custom node definitions (`defineNode` → **`executeOne`**; `defineBatchNode` → batch **`run`**)
+- `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,9 +19,11 @@ 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 **`executeOne(...)`** for simple reusable nodes (per-item pipeline; optional **`mapInput`** / **`inputSchema`**)
+- start with `defineNode(...)` and **`execute(...)`** for simple reusable nodes (per-item pipeline; optional **`inputSchema`** and **`itemValue`** on config fields)
 - use `defineBatchNode(...)` only when the node must process the **whole activation batch** in one **`run(items, ...)`**
 - keep runtime logic close to the node definition
 - move to class-based node APIs when you need constructor-injected collaborators or deeper runtime metadata
@@ -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

package/skills/codemation-workflow-dsl/SKILL.md

@@ -17,14 +17,14 @@ Do not use this skill for CLI-only troubleshooting or deep host architecture que
 1. A workflow definition describes how items move from a trigger through downstream steps.
 2. The fluent authoring chain is the normal starting point for Codemation apps.
 3. Finish fluent workflow definitions with `.build()`.
-4. Activations are **batch-shaped** (`Items`); many steps use **per-item** execution (`executeOne`, including helper **`defineNode`**) with optional **`mapInput`** / **`inputSchema`**. Batch reshape steps (split/filter/aggregate, **`defineBatchNode`**) work on the whole batch.
+4. Activations are **batch-shaped** (`Items`); many steps use **per-item** execution (`execute`, including helper **`defineNode`**) with optional **`inputSchema`** and **`itemValue`** on config fields. Batch reshape steps (split/filter/aggregate, **`defineBatchNode`**) work on the whole batch.
 
 ## Authoring rules
 
 1. Prefer the fluent `workflow(...)` chain for app-local workflow files.
 2. Keep workflow files focused on orchestration and named steps.
 3. Use custom nodes when a callback grows into reusable product logic.
-4. Distinguish **batch activations** from **per-item node bodies**: custom nodes from **`defineNode`** implement **`executeOne`** per item unless you chose **`defineBatchNode`** for batch **`run`**.
+4. Distinguish **batch activations** from **per-item node bodies**: custom nodes from **`defineNode`** implement **`execute`** per item unless you chose **`defineBatchNode`** for batch **`run`**.
 
 ## Typical flow