@pikku/skills 0.12.22 → 0.12.25

package/skills/pikku-knowledge/SKILL.md

@@ -242,6 +242,20 @@ pikku knowledge index --check   # report stale indexes without writing (CI gate)
 
 `index` rewrites only the block between `<!-- pikku:knowledge-index -->` markers, creating a scaffolded `index.md` for a section that has none. It is idempotent — running it twice changes nothing.
 
+### The milestone plan
+
+A milestone note says what the app must DO. Its **plan** — JSON beside the note, not prose — says what has to exist for it, and is what a finished build is measured against:
+
+```bash
+pikku knowledge plan schema                        # the format, in full
+pikku knowledge plan set <milestone> <file>        # validate and write it
+pikku knowledge plan show <milestone> --for-build  # the ordered work a build follows
+pikku knowledge plan progress <milestone>          # what it still owes, read from .pikku/
+pikku knowledge plan defer <milestone> <item> -r "<why>"
+```
+
+`progress` reconciles the plan against pikku's generated meta — set membership, never anyone's status — and exits non-zero while the first pass is short, or while anything already built contradicts the plan. Unbuilt work in a later pass is reported, not blocked; a function that shipped wide open against a planned permission rule blocks from any pass, because that is a hole rather than a backlog. Writing a plan is its own seat: read `pikku-architect`. Building against one is `pikku-build`.
+
 ## Profiles built on this one
 
 OKF permits frontmatter fields a reader does not know, and the parser ignores them rather than failing. That is the extension point: a tool layered on Pikku can add its own sections and fields on top of everything above without forking the format.

package/skills/pikku-kysely/SKILL.md

@@ -9,9 +9,9 @@ description: >-
   non-trivial kysely query (a join, an aggregate/count/sum, groupBy, subquery, transaction, or
   conditional query), the injected `kysely` service is used in a function body, or code uses
   PikkuKysely, KyselyChannelStore, KyselyWorkflowService, KyselySecretService, or the user asks
-  about SQL setup with Pikku. DO NOT TRIGGER when: user asks about MongoDB (use pikku-mongodb) or
-  Redis (use pikku-redis).
-installGroups: [fabric]
+  about SQL setup with Pikku. DO NOT TRIGGER when: user asks about MongoDB or Redis-backed
+  services (use pikku-service-backends).
+installGroups: [core]
 ---
 
 # Pikku Kysely (SQL Database Services)
@@ -216,15 +216,15 @@ Each database variant exports these services with a prefix (`Pg`, `MySQL`, `SQLi
 A handful more live only on the base package — there is no `Pg`/`MySQL`/`SQLite`
 variant to reach for, you import them from `@pikku/kysely` whatever the engine:
 
-| Service                      | Purpose                                      |
-| ---------------------------- | -------------------------------------------- |
-| `KyselySessionStore`         | Persisted user sessions                      |
-| `KyselyScopeService`         | Scope and role storage                       |
-| `KyselyWebhookService`       | Webhook registrations and deliveries         |
-| `KyselyCredentialService`    | Encrypted third-party credentials            |
-| `KyselyAgentRunStateService` | AI run state (also implemented by AIStorage) |
-| `KyselyWorkflowMirror`       | Mirrors workflow runs into queryable tables  |
-| `KyselyAuditService`         | Durable audit sink (see `pikku-audit`)       |
+| Service                      | Purpose                                                             |
+| ---------------------------- | ------------------------------------------------------------------- |
+| `KyselySessionStore`         | Persisted user sessions                                             |
+| `KyselyScopeService`         | Scope and role storage                                              |
+| `KyselyWebhookService`       | Outgoing webhook deliveries + attempt history (see `pikku-webhook`) |
+| `KyselyCredentialService`    | Encrypted third-party credentials                                   |
+| `KyselyAgentRunStateService` | AI run state (also implemented by AIStorage)                        |
+| `KyselyWorkflowMirror`       | Mirrors workflow runs into queryable tables                         |
+| `KyselyAuditService`         | Durable audit sink (see `pikku-services`)                           |
 
 All services take a `Kysely<KyselyPikkuDB>` instance in their constructor and have an `init()` method that creates tables if needed.
 
@@ -257,7 +257,7 @@ const newVersion = await secrets.rotateKEK()
 
 `getSecret` hands back a `SecretValue<T>`, not the bare value — it serializes as
 `[secret]` until something reveals it, which is what stops a secret drifting into
-a log line or an audit row. See `pikku-config` for the reveal rules.
+a log line or an audit row. See `pikku-services` for the reveal rules.
 
 ## Usage Patterns
 

package/skills/pikku-meta/SKILL.md

@@ -1,139 +1,67 @@
 ---
 name: pikku-meta
 description: >-
-  Read and change a Pikku project's declarations without grepping or hand-editing — functions
-  (with their transport, middleware and permissions), schemas, workflows, wires, tags, middleware
-  and permission definitions, plus `pikku meta apply` to set config on them. TRIGGER when: user
-  asks "what functions exist?", "show me the project structure", "list routes/middleware/
-  permissions", needs a function's input/output shape, or wants to add a permission, retag a
-  function, or change a declaration's config. DO NOT TRIGGER when: user is writing a NEW function
-  or wiring (use the specific wiring skill) or asking about Pikku concepts (use pikku-concepts).
+  Use to inspect or evolve a project you did not just write — `pikku meta` and `pikku info` for
+  what the project declares (functions, schemas, wires, workflows, middleware, permissions) and
+  `pikku meta apply` to change it, `pikku versions` / `pikku semver` for contract hashes,
+  breaking-change detection and the semver a release should get, and `pikku audit` / `pikku
+  update` for dependency advisories and moving Pikku forward. TRIGGER when: user asks what
+  functions or routes exist, wants a function's input/output shape, wants to retag a function or
+  set config on a declaration, asks about API versioning, breaking changes, what semver a release
+  deserves, dependency vulnerabilities, the console Security screen, or upgrading Pikku. DO NOT
+  TRIGGER when: user is writing a new function or wiring (use the wiring skill) or asking about
+  Pikku concepts (use pikku-concepts).
 installGroups: [core]
 allowed-tools: Bash(yarn pikku meta *), Bash(yarn pikku info *)
-argument-hint: '[context|functions|schemas|workflows|middleware|permissions|wires|apply]'
+argument-hint: '[context|functions|schemas|workflows|middleware|permissions|wires|apply|versions|semver|audit|update]'
 ---
 
 # Pikku Project Metadata
 
-`pikku meta` is the machine-readable view of the project and the write path to it.
-`pikku info` is the same ground as human-readable tables. Prefer `meta` when you are
-going to act on the output; prefer `info` when a person is going to read it.
-
-## Agent Operating Procedure
-
-Use this skill as an execution checklist, not reference material.
-
-1. Discover before editing. Run the relevant `pikku meta ... --json` command and inspect only the focused output you need.
-2. Identify the source files that own the behavior. Do not start by reading generated output, `.pikku`, `node_modules`, vendored packages, or broad build artifacts.
-3. Change a declaration's config with `pikku meta apply`, not by hand-editing the file.
-4. Make the smallest source change that satisfies the task. Keep generated files generated, and avoid hand-editing SDKs, schema output, or typegen.
-5. Validate with the narrowest relevant command first, then run `pikku-verify` or `pikku all` when functions, wirings, schemas, or generated clients may have changed.
-6. If validation fails, fix the source cause and rerun validation. Do not paper over generated errors by editing generated files.
-
-## Reading
-
-| Command                         | What it answers                                                                                                                  |
-| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
-| `pikku meta context`            | Everything a planner needs in one call — functions, wires, middleware, permissions, workflows, capabilities, layout. Start here. |
-| `pikku meta functions get <id>` | One function's input/output schema names, source file, tags, expose/readonly                                                     |
-| `pikku meta schemas get <name>` | One generated JSON schema                                                                                                        |
-| `pikku meta workflows get <id>` | One workflow's steps                                                                                                             |
-| `pikku meta permissions list`   | What permissions exist and where they are defined                                                                                |
-| `pikku meta middleware list`    | What middleware exists                                                                                                           |
-| `pikku meta wires list`         | Wires by transport (http, channel, scheduler, queue, trigger)                                                                    |
-| `pikku meta clients`            | Exposed RPCs/workflows/channels with their type names — what a frontend can call                                                 |
-
-`list` is the default for each group, so `pikku meta functions` and `pikku meta functions list`
-are the same call.
-
-A function's input/output shape comes from here. Do not infer it by reading the
-function body, and do not cast a call site to make it compile — the schema is the type.
-
-## Changing
-
-`pikku meta apply` applies a batch of edits to your own source. Pass JSON as a file
-or on stdin:
-
-```bash
-pikku meta apply ops.json
-```
-
-```json
-{
-  "operations": [
-    {
-      "kind": "functionConfig",
-      "sourceFile": "src/functions/todos.functions.ts",
-      "exportedName": "listTodos",
-      "changes": { "title": "List Todos", "tags": ["todos", "read"] }
-    },
-
-    {
-      "kind": "functionConfig",
-      "sourceFile": "src/functions/todos.functions.ts",
-      "exportedName": "listTodos",
-      "changes": {
-        "permissions": {
-          "functionLevel": {
-            "name": "isTodoOwner",
-            "from": "../permissions.js"
-          }
-        }
-      }
-    }
-  ]
-}
-```
-
-Three kinds: `functionConfig`, `agentConfig`, `functionBody`. Every operation names
-a `sourceFile` and the `exportedName` declared in it.
-
-`functionConfig` changes: `title`, `description`, `summary`, `tags`, `errors`,
-`expose`, `remote`, `mcp`, `readonly`, `approvalRequired`, `permissions`.
-`agentConfig` changes: `name`, `description`, `instructions`, `role`, `personality`,
-`goal`, `model`, `maxSteps`, `temperature`, `toolChoice`, `tools`, `tags`.
-
-`null` removes a property. Edits are spliced into the original text, so formatting,
-comments and JSDoc survive.
-
-`permissions` and `tools` are written as identifiers rather than literals, so each
-one carries the module it comes from (`{"name": "isTodoOwner", "from": "../permissions.js"}`)
-and the missing import is added for you — widening an existing import from that
-module rather than adding a second one.
-
-### Why batch
-
-The whole batch either lands or it does not: every operation is resolved before
-anything is written, so a failure leaves every file untouched and names the
-operation that caused it. Batching is also what makes one codegen pass correct —
-**run `pikku all` once after the batch**, not once per property. The response tells
-you whether it is needed:
-
-```json
-{
-  "schemaVersion": "meta-apply.v1",
-  "applied": 2,
-  "files": ["src/functions/todos.functions.ts"],
-  "generatedMetaIsStale": true
-}
-```
-
-## Human-readable tables (`pikku info`)
-
-Four subcommands only — `functions`, `tags`, `middleware`, `permissions`. Routes,
-channels, schedulers and queues are not subcommands; they are the _transport_ column
-of `info functions --verbose`.
-
-```bash
-yarn pikku info functions --verbose --silent
-yarn pikku info tags --silent
-yarn pikku info middleware --verbose --silent
-yarn pikku info permissions --verbose --silent
-```
-
-`--silent` suppresses the banner and inspector diagnostics. It works, but it is not
-declared as an option, so every run also prints `Warning: Unknown option: --silent
-(ignored)` — the warning is wrong. Ignore that one line.
-
-`--limit N` caps rows (default 50); the footer says how many were withheld.
-On `tags`, `--verbose` swaps counts for names; elsewhere it adds columns.
+The project already knows what it declares. Ask it rather than grepping for it,
+and change it through the write path rather than by hand.
+
+## Pick the reference
+
+| You are… | Read |
+| --- | --- |
+| Asking what exists, or setting config on a declaration | `references/meta.md` |
+| Versioning a contract, or deciding a release's semver | `references/versioning.md` |
+| Chasing a dependency advisory, or upgrading Pikku | `references/audit.md` |
+
+## Start with `pikku meta context`
+
+It answers in one call what a planner needs — functions, wires, middleware,
+permissions, workflows, capabilities, layout. Reach for `pikku meta` when you
+are going to act on the output and `pikku info` when a person will read it;
+they are the same ground in two shapes.
+
+## Direction decides whether a change is breaking
+
+An input is contravariant (the caller writes it) and an output is covariant (the
+caller reads it), so the same edit is not the same event on both. Adding a
+required field breaks an input and is compatible on an output; making a field
+optional is the reverse. `pikku semver` reads the generated JSON Schemas with
+that asymmetry built in, so let it decide rather than eyeballing a diff.
+
+## What NOT to do
+
+- **Do not infer a function's input or output by reading its body**, and do not
+  cast a call site to make it compile. The schema is the type; `pikku meta
+  functions get <id>` has it.
+- **Do not expect an unversioned function to be promoted for you.** Without an
+  explicit `version: 2` it is version 1 of its contract, collides with the
+  pinned `@v1`, and `pikku versions check` reports the published contract as
+  modified.
+- **Do not reach for `override` by default.** The contract key already drops a
+  matching `V<n>` suffix from the export name, so `getBookV1` keys under
+  `getBook`. `override` is for an export that cannot follow that convention.
+- **Do not shell out to the package manager from a function.** The audit is a
+  generated artifact — read `.pikku/audit.json` through
+  `metaService.readFile('audit.json')`.
+- **Do not redeclare the audit report's shape.** `SecurityAuditReport` and its
+  companions come from `@pikku/core`; the CLI writes it, the addon reads it, the
+  UI renders it.
+- **Do not treat a failed audit run as a clean one.** `bun audit` exits non-zero
+  when it *finds* advisories and still writes its payload, so non-zero with
+  output is data; non-zero with no output throws on purpose.

package/skills/{pikku-deps/SKILL.md → pikku-meta/references/audit.md}

@@ -1,19 +1,3 @@
----
-name: pikku-deps
-description: >-
-  Use for the Pikku dependency security audit: the `pikku audit` CLI command, the
-  `.pikku/audit.json` artifact, the `SecurityAuditReport` type in @pikku/core, and the console
-  Security screen (getSecurityAudit / runSecurityAudit / updateDependency + SecurityAuditView).
-  Also covers `pikku update`, which moves the @pikku/* dependency set forward and reports the
-  peers those versions need.
-  TRIGGER when: user asks about `pikku audit` or `pikku update`, dependency
-  vulnerabilities/advisories, outdated dependencies, upgrading Pikku itself, peer dependency
-  conflicts, the Security screen/page in the console, updating a vulnerable dependency, or
-  reading/rendering audit.json. DO NOT TRIGGER when: user asks about authentication/sessions/JWT
-  (use pikku-security), permissions (use pikku-permissions), or secrets/env vars (use
-  pikku-config).
----
-
 # Pikku Dependency Audit
 
 ## Agent Operating Procedure
@@ -98,7 +82,7 @@ lockfiles, because that field states intent before a lockfile exists and a
 project can carry a stale one from another tool. Guessing wrong is not a soft
 failure: the spawn dies with `Executable not found in $PATH`.
 Like every console RPC these require an **authenticated session** (the console
-is admin-only), so the host must have Better Auth wired — see `pikku-better-auth`.
+is admin-only), so the host must have Better Auth wired — see `pikku-auth`.
 
 - `getSecurityAudit` — reads `.pikku/audit.json`, returns the report (or `null`).
 - `runSecurityAudit` — runs `pikku audit --outdated` server-side (regenerates the

package/skills/pikku-meta/references/meta.md

@@ -0,0 +1,114 @@
+# Pikku Project Metadata
+
+`pikku meta` is the machine-readable view of the project and the write path to it.
+`pikku info` is the same ground as human-readable tables. Prefer `meta` when you are
+going to act on the output; prefer `info` when a person is going to read it.
+
+
+## Reading
+
+| Command                         | What it answers                                                                                                                  |
+| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| `pikku meta context`            | Everything a planner needs in one call — functions, wires, middleware, permissions, workflows, capabilities, layout. Start here. |
+| `pikku meta functions get <id>` | One function's input/output schema names, source file, tags, expose/readonly                                                     |
+| `pikku meta schemas get <name>` | One generated JSON schema                                                                                                        |
+| `pikku meta workflows get <id>` | One workflow's steps                                                                                                             |
+| `pikku meta permissions list`   | What permissions exist and where they are defined                                                                                |
+| `pikku meta middleware list`    | What middleware exists                                                                                                           |
+| `pikku meta wires list`         | Wires by transport (http, channel, scheduler, queue, trigger)                                                                    |
+| `pikku meta clients`            | Exposed RPCs/workflows/channels with their type names — what a frontend can call                                                 |
+
+`list` is the default for each group, so `pikku meta functions` and `pikku meta functions list`
+are the same call.
+
+A function's input/output shape comes from here. Do not infer it by reading the
+function body, and do not cast a call site to make it compile — the schema is the type.
+
+## Changing
+
+`pikku meta apply` applies a batch of edits to your own source. Pass JSON as a file
+or on stdin:
+
+```bash
+pikku meta apply ops.json
+```
+
+```json
+{
+  "operations": [
+    {
+      "kind": "functionConfig",
+      "sourceFile": "src/functions/todos.functions.ts",
+      "exportedName": "listTodos",
+      "changes": { "title": "List Todos", "tags": ["todos", "read"] }
+    },
+
+    {
+      "kind": "functionConfig",
+      "sourceFile": "src/functions/todos.functions.ts",
+      "exportedName": "listTodos",
+      "changes": {
+        "permissions": {
+          "functionLevel": {
+            "name": "isTodoOwner",
+            "from": "../permissions.js"
+          }
+        }
+      }
+    }
+  ]
+}
+```
+
+Three kinds: `functionConfig`, `agentConfig`, `functionBody`. Every operation names
+a `sourceFile` and the `exportedName` declared in it.
+
+`functionConfig` changes: `title`, `description`, `summary`, `tags`, `errors`,
+`expose`, `remote`, `mcp`, `readonly`, `approvalRequired`, `permissions`.
+`agentConfig` changes: `name`, `description`, `instructions`, `role`, `personality`,
+`goal`, `model`, `maxSteps`, `temperature`, `toolChoice`, `tools`, `tags`.
+
+`null` removes a property. Edits are spliced into the original text, so formatting,
+comments and JSDoc survive.
+
+`permissions` and `tools` are written as identifiers rather than literals, so each
+one carries the module it comes from (`{"name": "isTodoOwner", "from": "../permissions.js"}`)
+and the missing import is added for you — widening an existing import from that
+module rather than adding a second one.
+
+### Why batch
+
+The whole batch either lands or it does not: every operation is resolved before
+anything is written, so a failure leaves every file untouched and names the
+operation that caused it. Batching is also what makes one codegen pass correct —
+**run `pikku all` once after the batch**, not once per property. The response tells
+you whether it is needed:
+
+```json
+{
+  "schemaVersion": "meta-apply.v1",
+  "applied": 2,
+  "files": ["src/functions/todos.functions.ts"],
+  "generatedMetaIsStale": true
+}
+```
+
+## Human-readable tables (`pikku info`)
+
+Four subcommands only — `functions`, `tags`, `middleware`, `permissions`. Routes,
+channels, schedulers and queues are not subcommands; they are the _transport_ column
+of `info functions --verbose`.
+
+```bash
+yarn pikku info functions --verbose --silent
+yarn pikku info tags --silent
+yarn pikku info middleware --verbose --silent
+yarn pikku info permissions --verbose --silent
+```
+
+`--silent` suppresses the banner and inspector diagnostics. It works, but it is not
+declared as an option, so every run also prints `Warning: Unknown option: --silent
+(ignored)` — the warning is wrong. Ignore that one line.
+
+`--limit N` caps rows (default 50); the footer says how many were withheld.
+On `tags`, `--verbose` swaps counts for names; elsewhere it adds columns.

package/skills/{pikku-versioning/SKILL.md → pikku-meta/references/versioning.md}

@@ -1,31 +1,5 @@
----
-name: pikku-versioning
-description: >-
-  Use when versioning Pikku function contracts, detecting breaking changes, or managing API
-  backward compatibility. Covers the version property, versions.pikku.json manifest, contract
-  hashing, and CI integration. Also covers `pikku semver`, which derives a release's semver by
-  diffing this build's surface against a deployed one and writes .pikku/changes.gen.json.
-  TRIGGER when: code uses version: on a pikkuFunc, user asks about
-  API versioning, breaking changes, contract hashes, backward compatibility, what semver a
-  release should get, comparing against production/staging, or "pikku versions" / "pikku semver"
-  CLI commands. DO NOT TRIGGER when: user asks about secrets/variables/OAuth2 (use pikku-config)
-  or general function definitions (use pikku-concepts), or about updating dependency versions
-  (use pikku-deps).
----
-
 # Pikku Function Versioning
 
-## Agent Operating Procedure
-
-Use this skill as an execution checklist, not reference material.
-
-1. Discover before editing. Run the relevant `pikku meta ... --json` command and inspect only the focused output you need.
-2. Identify the source files that own the behavior. Do not start by reading generated output, `.pikku`, `node_modules`, vendored packages, or broad build artifacts.
-3. Make the smallest source change that satisfies the task. Keep generated files generated, and avoid hand-editing SDKs, schema output, or typegen.
-4. Validate with the narrowest relevant command first, then run `pikku-verify` or `pikku all` when functions, wirings, schemas, or generated clients may have changed.
-5. If validation fails, fix the source cause and rerun validation. Do not paper over generated errors by editing generated files.
-
-Track and protect function contracts across releases. Pikku hashes each function's input/output schema into a manifest so you can detect breaking changes before they ship.
 
 ## Before You Start
 

package/skills/pikku-middleware/SKILL.md

@@ -6,8 +6,8 @@ description: >-
   understanding middleware execution order and priority. TRIGGER when: user wants middleware on
   some or all routes, machine-to-machine auth, tag-scoped cross-cutting concerns, global
   interceptors, or middleware priority/order questions. DO NOT TRIGGER when: user asks about
-  permissions/authorization checks (use pikku-permissions), auth strategies like
-  authBearer/authCookie (use pikku-security), or deployment.
+  permissions, sessions or auth strategies like authBearer/authCookie (use
+  pikku-auth), or deployment.
 installGroups: [core]
 ---
 
@@ -223,7 +223,7 @@ export const reportSomething = pikkuFunc({
 })
 ```
 
-An unresolved token leaves the session unset and the function throws `MissingSessionError` — 401, for free. Declare the scope tree once with `defineScope` (see `pikku-permissions`).
+An unresolved token leaves the session unset and the function throws `MissingSessionError` — 401, for free. Declare the scope tree once with `defineScope` (see `pikku-auth`).
 
 ### It MUST be `addHTTPMiddleware`, never `addTagMiddleware`
 
@@ -255,13 +255,13 @@ Unlike tag middleware over `/rpc`, this works: `runScheduledTask` builds its wir
 
 ### The one sessionless exception: bootstrap
 
-An endpoint that runs BEFORE the caller has an identity — registering a new host with a shared bootstrap key, a login, a device-code request — has no session to set. That one stays `pikkuSessionlessFunc` and declares its gate in `permissions` (see `pikku-permissions`).
+An endpoint that runs BEFORE the caller has an identity — registering a new host with a shared bootstrap key, a login, a device-code request — has no session to set. That one stays `pikkuSessionlessFunc` and declares its gate in `permissions` (see `pikku-auth`).
 
 ## Service-to-Service Bearer Auth (gate-only pattern)
 
 Use this when the callee needs to know only THAT the caller is trusted, not WHICH caller it is. If it needs to know which, use the session pattern above.
 
-A server that exposes RPCs only to a trusted caller (e.g. an API calling a machine-agent). Auth lives in a tag middleware — NOT in the function body. Authorization/permission checks belong in the `permissions` field (see `pikku-permissions`), never inside `func`.
+A server that exposes RPCs only to a trusted caller (e.g. an API calling a machine-agent). Auth lives in a tag middleware — NOT in the function body. Authorization/permission checks belong in the `permissions` field (see `pikku-auth`), never inside `func`.
 
 **On the server (the service being called):** tag the function, register a `pikkuMiddleware` that reads the `Authorization` header on that tag.
 

package/skills/pikku-n8n-import/SKILL.md

@@ -3,7 +3,6 @@ name: pikku-n8n-import
 description: 'Use to import an n8n workflow JSON export into a runnable Pikku workflow. Triggers when the user says "import this n8n workflow", "convert this n8n export to pikku", points at an n8n `.json` export or a directory of them, or picks up after `pikku import n8n` left throwing stub functions (`STUB — generated from n8n …`, `— implement me`) or a `<workflow>.integrations.json` manifest. Owns the whole flow: run the importer, triage what it could not map, fill each stub, report any missing `@pikku/addon-*` integrations, and verify the result compiles and runs with no surviving stubs. DO NOT TRIGGER for hand-written addon wiring unrelated to an n8n import (use pikku-addon), or for authoring workflows from scratch (use pikku-workflow).'
 metadata:
   version: 1.0.0
-installGroups: [fabric]
 ---
 
 # n8n → Pikku Import