@rudderhq/server 0.5.0 → 0.5.1

package/skills/rudder-create-agent/SKILL.md

@@ -1,185 +0,0 @@
----
-name: rudder-create-agent
-description: Create new agents in Rudder through the `rudder` CLI with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hire request.
----
-
-# Rudder Create Agent Skill
-
-Use this skill when you are asked to hire or create an agent in Rudder.
-
-## Preconditions
-
-You need either:
-
-- board access, or
-- agent permission `canCreateAgents=true` in your org
-
-If you do not have this permission, escalate to your CEO or board.
-
-This workflow is **CLI-first**.
-
-- Use `rudder ... --json` for structured reads and mutations.
-- Use `references/cli-reference.md` as the canonical command catalog for this skill.
-- Treat `references/api-reference.md` as internal/debug/compatibility documentation, not the normal runtime interface.
-- Do not create agent directories, instruction files, or org metadata manually as a fallback.
-- If CLI auth is unavailable in a heartbeat run, stop and report the auth problem instead of mutating the filesystem.
-
-## Workflow
-
-1. Confirm identity and organization context.
-
-```sh
-rudder agent me --json
-```
-
-If this returns `{"error":"Agent authentication required"}`, treat it as a run-auth failure:
-
-- do not ask for `RUDDER_API_KEY` inside the heartbeat
-- do not fall back to manual filesystem creation
-- stop and report that injected agent authentication is missing or invalid for this run
-
-2. Discover available adapter configuration docs for this Rudder instance.
-
-```sh
-rudder agent config index
-```
-
-3. Read adapter-specific docs for the runtime you plan to use.
-
-```sh
-rudder agent config doc codex_local
-rudder agent config doc claude_local
-```
-
-4. Compare existing agents and redacted configurations in your organization.
-
-```sh
-rudder agent list --org-id "$RUDDER_ORG_ID" --json
-rudder agent config list --org-id "$RUDDER_ORG_ID" --json
-rudder agent config get "<agent-id>" --json
-```
-
-5. If the role needs organization skills on day one, inspect or import them before hiring.
-
-```sh
-rudder skill list --org-id "$RUDDER_ORG_ID" --json
-rudder skill get "<skill-id>" --org-id "$RUDDER_ORG_ID" --json
-rudder skill file "<skill-id>" --org-id "$RUDDER_ORG_ID" --path SKILL.md --json
-rudder skill import --org-id "$RUDDER_ORG_ID" --source "<source>" --json
-rudder skill scan-local --org-id "$RUDDER_ORG_ID" --roots "<csv>" --json
-rudder skill scan-projects --org-id "$RUDDER_ORG_ID" --project-ids "<csv>" --workspace-ids "<csv>" --json
-```
-
-6. Draft the hire payload.
-
-Required thinking:
-
-- role / title / optional `name`
-- `name` is optional; if omitted, Rudder assigns a distinct personal name automatically
-- omit `icon` for normal hires; Rudder assigns a DiceBear Notionists avatar automatically
-- only set `icon` when preserving an explicit DiceBear avatar reference or an uploaded `asset:<uuid>` image avatar reference provided by the board/UI
-- reporting line (`reportsTo`)
-- adapter type
-- optional `desiredSkills` from the organization skill library
-- adapter and runtime config aligned to this environment
-- capabilities
-- structured role/persona instructions for the new agent (`promptTemplate` when the CLI payload is the available surface; Rudder materializes this as `SOUL.md`)
-- source issue linkage (`sourceIssueId` or `sourceIssueIds`) when this hire came from an issue
-
-`role` is a fixed Rudder enum, not a free-form job title. Use one of:
-`ceo`, `cto`, `cmo`, `cfo`, `engineer`, `designer`, `pm`, `qa`, `devops`, `researcher`, `general`.
-Put specialization in `title`, `capabilities`, and `promptTemplate`. For example, a Founding Engineer hire should use
-`"role": "engineer"` and `"title": "Founding Engineer"`, not `"role": "founding_engineer"`.
-
-Do not copy Rudder's shared filesystem, memory, language, or safety contract into the hire prompt. Rudder injects that operating contract from runtime code for supported local runtimes. The hire-specific prompt should only define the new agent's role, identity, scope, tone, and durable responsibilities.
-
-Draft `promptTemplate` as a durable SOUL document, not a one-line command. Use these sections when the role is not trivial:
-
-- Opening: one sentence that captures who the agent is
-- Mission: the outcome this agent owns
-- Responsibilities: durable duties and ownership boundaries
-- Boundaries: what the agent should not do or should escalate
-- Decision Principles: role-specific judgment rules
-- Voice: how the agent should communicate
-- Continuity: what should become memory or explicit instruction updates over time
-
-7. Submit the canonical hire request.
-
-```sh
-rudder agent hire --org-id "$RUDDER_ORG_ID" --payload '{
-  "role": "cto",
-  "title": "Chief Technology Officer",
-  "reportsTo": "<ceo-agent-id>",
-  "capabilities": "Owns technical roadmap, architecture, staffing, execution",
-  "desiredSkills": ["vercel-labs/agent-browser/agent-browser"],
-  "agentRuntimeType": "codex_local",
-  "agentRuntimeConfig": {
-    "cwd": "/abs/path/to/repo",
-    "model": "o4-mini",
-    "promptTemplate": "# SOUL.md -- CTO Persona\n\nYou are the CTO.\n\n## Mission\nOwn technical strategy, architecture, engineering execution, and quality bars.\n\n## Responsibilities\n- Set technical direction and execution standards.\n- Review architecture and staffing trade-offs.\n- Keep delivery risks visible and actionable.\n\n## Boundaries\n- Do not approve risky shortcuts without naming the trade-off.\n- Escalate product or budget ambiguity instead of guessing.\n\n## Decision Principles\n- Prefer simple architectures with explicit trade-offs.\n- Treat reliability, developer velocity, and product learning as linked constraints.\n\n## Voice\nDirect, specific, and evidence-led.\n\n## Continuity\nPreserve durable technical standards, repeated failure patterns, and long-running architecture decisions in memory or explicit instructions."
-  },
-  "runtimeConfig": {"heartbeat": {"enabled": true, "intervalSec": 300, "wakeOnDemand": true, "maxConcurrentRuns": 3}},
-  "sourceIssueId": "<issue-id>"
-}' --json
-```
-
-`agent hire` is the canonical surface because it preserves the real server behavior:
-
-- if the organization does not require approval, it creates the agent directly and returns `"approval": null`
-- if the organization requires approval, it creates the agent in `pending_approval` and returns both `agent` and `approval`
-
-Do **not** substitute `rudder approval create --type hire_agent` for this step unless you are doing low-level debugging. That bypasses the canonical direct-create vs pending-approval behavior.
-
-8. Handle governance state.
-
-If the hire response includes `approval`, monitor and discuss on the approval thread:
-
-```sh
-rudder approval get "<approval-id>" --json
-cat > /tmp/rudder-approval-comment.md <<'EOF'
-## CTO hire request submitted
-
-- Approval: [<approval-id>](/<prefix>/messenger/approvals/<approval-id>)
-- Pending agent: [<agent-ref>](/<prefix>/agents/<agent-url-key-or-id>)
-- Source issue: [<issue-ref>](/<prefix>/issues/<issue-identifier-or-id>)
-
-Updated prompt and adapter config per board feedback.
-EOF
-rudder approval comment "<approval-id>" --body-file /tmp/rudder-approval-comment.md --json
-rudder approval resubmit "<approval-id>" --payload '{"title":"Revised title","agentRuntimeConfig":{"cwd":"/abs/path/to/repo","model":"o4-mini"}}' --json
-rudder approval issues "<approval-id>" --json
-```
-
-When the board approves, you may be woken with `RUDDER_APPROVAL_ID`:
-
-```sh
-rudder approval get "$RUDDER_APPROVAL_ID" --json
-rudder approval issues "$RUDDER_APPROVAL_ID" --json
-```
-
-For each linked issue, either:
-
-- close it if the approval resolved the request, or
-- comment in markdown with links to the approval and next actions
-
-## Quality Bar
-
-Before sending a hire request:
-
-- if the role needs skills, make sure they already exist in the org library or import them first using the Rudder org-skills workflow
-- reuse proven config patterns from related agents where possible
-- omit `icon` for normal hires so the server generates the default DiceBear Notionists avatar
-- avoid secrets in plain text unless required by adapter behavior
-- ensure the reporting line is correct and in-org
-- ensure the prompt is role-specific, operationally scoped, and structured enough to become the agent's durable `SOUL.md`
-- include mission, responsibilities, boundaries, decision principles, voice, and continuity when the role has ongoing authority
-- prefer `sourceIssueId` or `sourceIssueIds` in the hire payload instead of manual approval linking
-- if board requests revision, update the payload and resubmit through the approval flow
-- do not report success unless `rudder agent hire` itself succeeded and you can cite the returned `agent.id` or `approval.id`
-- creating local directories or instruction files is not evidence that an agent exists in Rudder
-
-For canonical command syntax and examples, read:
-`references/cli-reference.md`
-
-For low-level route shapes and underlying compatibility endpoints, read:
-`references/api-reference.md`

package/skills/rudder-create-agent/references/api-reference.md

@@ -1,179 +0,0 @@
-# Rudder Create Agent API Reference
-
-Internal/debug reference for the bundled `rudder-create-agent` skill.
-
-- Normal runtime execution should follow the CLI-first workflow in `../SKILL.md`.
-- The canonical command catalog lives in `cli-reference.md`.
-- Keep this document for route-level debugging, compatibility work, and payload-shape inspection.
-
-## CLI-to-API Mapping
-
-| CLI command | Primary route |
-| --- | --- |
-| `rudder agent config index` | `GET /llms/agent-configuration.txt` |
-| `rudder agent config doc <agentRuntimeType>` | `GET /llms/agent-configuration/:agentRuntimeType.txt` |
-| `rudder agent config list --org-id <orgId>` | `GET /api/orgs/:orgId/agent-configurations` |
-| `rudder agent config get <agentId>` | `GET /api/agents/:agentId/configuration` |
-| `rudder agent hire --org-id <orgId> --payload <json>` | `POST /api/orgs/:orgId/agent-hires` |
-| `rudder approval get <approvalId>` | `GET /api/approvals/:approvalId` |
-| `rudder approval comment <approvalId> --body-file <path>` | `POST /api/approvals/:approvalId/comments` |
-| `rudder approval resubmit <approvalId> [--payload <json>]` | `POST /api/approvals/:approvalId/resubmit` |
-| `rudder approval issues <approvalId>` | `GET /api/approvals/:approvalId/issues` |
-
-## Reflection Endpoints
-
-- `GET /llms/agent-configuration.txt`
-- `GET /llms/agent-configuration/:agentRuntimeType.txt`
-
-Auth:
-
-- board access, or
-- same-org agent auth with `canCreateAgents=true`
-
-These endpoints return plain text. The CLI wraps them directly.
-
-## Configuration Snapshots
-
-- `GET /api/orgs/:orgId/agent-configurations`
-- `GET /api/agents/:agentId/configuration`
-
-These responses are redacted snapshots for comparison and reuse.
-
-Representative shape:
-
-```json
-{
-  "id": "uuid",
-  "orgId": "uuid",
-  "name": "CTO",
-  "role": "cto",
-  "title": "Chief Technology Officer",
-  "status": "idle",
-  "reportsTo": "uuid-or-null",
-  "agentRuntimeType": "codex_local",
-  "agentRuntimeConfig": {
-    "cwd": "/absolute/path",
-    "model": "o4-mini"
-  },
-  "runtimeConfig": {
-    "heartbeat": {
-      "enabled": true,
-      "intervalSec": 300,
-      "wakeOnDemand": true,
-      "maxConcurrentRuns": 3
-    }
-  },
-  "permissions": {
-    "canCreateAgents": true
-  },
-  "updatedAt": "2026-04-19T12:00:00.000Z"
-}
-```
-
-## `POST /api/orgs/:orgId/agent-hires`
-
-Canonical hire route used by `rudder agent hire`.
-
-Request body:
-
-```json
-{
-  "role": "cto",
-  "title": "Chief Technology Officer",
-  "reportsTo": "uuid-or-null",
-  "capabilities": "Owns architecture and engineering execution",
-  "desiredSkills": ["vercel-labs/agent-browser/agent-browser"],
-  "agentRuntimeType": "codex_local",
-  "agentRuntimeConfig": {
-    "cwd": "/absolute/path",
-    "model": "o4-mini",
-    "promptTemplate": "# SOUL.md -- CTO Persona\n\nYou are the CTO.\n\n## Mission\nOwn technical strategy, architecture, engineering execution, and quality bars.\n\n## Responsibilities\n- Set technical direction and execution standards.\n- Review architecture and staffing trade-offs.\n- Keep delivery risks visible and actionable.\n\n## Boundaries\n- Do not approve risky shortcuts without naming the trade-off.\n- Escalate product or budget ambiguity instead of guessing.\n\n## Decision Principles\n- Prefer simple architectures with explicit trade-offs.\n- Treat reliability, developer velocity, and product learning as linked constraints.\n\n## Voice\nDirect, specific, and evidence-led.\n\n## Continuity\nPreserve durable technical standards, repeated failure patterns, and long-running architecture decisions in memory or explicit instructions."
-  },
-  "runtimeConfig": {
-    "heartbeat": {
-      "enabled": true,
-      "intervalSec": 300,
-      "wakeOnDemand": true,
-      "maxConcurrentRuns": 3
-    }
-  },
-  "budgetMonthlyCents": 0,
-  "sourceIssueId": "uuid-or-null",
-  "sourceIssueIds": ["uuid-1", "uuid-2"]
-}
-```
-
-`role` is validated as a fixed enum: `ceo`, `cto`, `cmo`, `cfo`, `engineer`, `designer`, `pm`, `qa`, `devops`, `researcher`, `general`.
-Use `title`, `capabilities`, and `agentRuntimeConfig.promptTemplate` for narrower job titles. For example, a Founding Engineer should be submitted as `"role": "engineer"` and `"title": "Founding Engineer"`.
-
-Response when approval is required:
-
-```json
-{
-  "agent": {
-    "id": "uuid",
-    "status": "pending_approval"
-  },
-  "approval": {
-    "id": "uuid",
-    "type": "hire_agent",
-    "status": "pending",
-    "payload": {
-      "desiredSkills": ["vercel-labs/agent-browser/agent-browser"]
-    }
-  }
-}
-```
-
-Response when approval is not required:
-
-```json
-{
-  "agent": {
-    "id": "uuid",
-    "status": "idle"
-  },
-  "approval": null
-}
-```
-
-Important notes:
-
-- `name` is optional; if omitted or blank, Rudder assigns a distinct first name automatically
-- `icon` is optional; omit it for normal hires so Rudder generates a DiceBear Notionists avatar automatically
-- only pass `icon` when the board/UI supplied an explicit DiceBear Notionists reference or uploaded `asset:<uuid>` image avatar reference
-- `desiredSkills` accepts organization skill ids, canonical keys, or a unique slug; the server resolves and stores canonical organization skill keys
-- `agentRuntimeConfig.promptTemplate`, when present for local runtimes during hire, is role/persona content that Rudder materializes as managed `SOUL.md`
-- write hire-time `promptTemplate` as a durable SOUL document with mission, responsibilities, boundaries, decision principles, voice, and continuity when the role has ongoing authority
-- do not put Rudder's shared operating contract in `promptTemplate`; supported local runtimes inject that contract from code
-- `sourceIssueId` and `sourceIssueIds` are the canonical way to link the hire back to originating issues
-- this route is preferred over creating `hire_agent` approvals manually because it preserves the organization's approval policy
-
-## Approval Lifecycle
-
-Relevant routes:
-
-- `GET /api/approvals/:approvalId`
-- `POST /api/approvals/:approvalId/comments`
-- `POST /api/approvals/:approvalId/resubmit`
-- `GET /api/approvals/:approvalId/issues`
-
-Statuses:
-
-- `pending`
-- `revision_requested`
-- `approved`
-- `rejected`
-- `cancelled`
-
-For hire approvals:
-
-- approved: linked agent transitions `pending_approval -> idle`
-- rejected: linked agent is terminated
-
-## Safety Notes
-
-- Config read APIs redact obvious secrets.
-- `pending_approval` agents cannot run heartbeats, receive assignments, or create keys.
-- All hire and approval actions are logged in activity for auditability.
-- Use markdown in issue and approval comments and include links to the approval, agent, and source issue.

package/skills/rudder-create-agent/references/cli-reference.md

@@ -1,132 +0,0 @@
-# Rudder Create Agent CLI Reference
-
-Canonical CLI contract for the bundled `rudder-create-agent` skill. Prefer these commands over direct `/api` calls.
-
-## Defaults
-
-- All commands support `--json`.
-- `--org-id` defaults to `RUDDER_ORG_ID` when relevant.
-- Mutating commands attach `RUDDER_RUN_ID` automatically when available.
-- `agent config index` and `agent config doc` print plain text by default. With `--json`, they emit that text as a JSON string.
-
-## Core CLI Surface
-
-### Identity and discovery
-
-```sh
-rudder agent me --json
-rudder agent list --org-id "$RUDDER_ORG_ID" --json
-rudder agent get "<agent-id-or-shortname>" --org-id "$RUDDER_ORG_ID" --json
-rudder agent config index
-rudder agent config doc "<agent-runtime-type>"
-rudder agent config list --org-id "$RUDDER_ORG_ID" --json
-rudder agent config get "<agent-id-or-shortname>" --org-id "$RUDDER_ORG_ID" --json
-```
-
-Use these in order:
-
-1. `agent me` to verify auth and org context
-2. `agent config index` to discover installed runtimes
-3. `agent config doc` to read one runtime's required fields and examples
-4. `agent list` plus `agent config list/get` to reuse proven patterns from related agents
-
-### Organization skills
-
-```sh
-rudder skill list --org-id "$RUDDER_ORG_ID" --json
-rudder skill get "<skill-id>" --org-id "$RUDDER_ORG_ID" --json
-rudder skill file "<skill-id>" --org-id "$RUDDER_ORG_ID" --path SKILL.md --json
-rudder skill import --org-id "$RUDDER_ORG_ID" --source "<source>" --json
-rudder skill scan-local --org-id "$RUDDER_ORG_ID" --roots "<csv>" --json
-rudder skill scan-projects --org-id "$RUDDER_ORG_ID" --project-ids "<csv>" --workspace-ids "<csv>" --json
-```
-
-Use these before hiring when the new role needs `desiredSkills`.
-
-`desiredSkills` accepts:
-
-- exact organization skill key
-- exact organization skill id
-- exact slug when it is unique in the organization
-
-### Canonical hire flow
-
-```sh
-rudder agent hire --org-id "$RUDDER_ORG_ID" --payload '{
-  "role": "cto",
-  "title": "Chief Technology Officer",
-  "reportsTo": "<ceo-agent-id>",
-  "capabilities": "Owns technical roadmap, architecture, staffing, execution",
-  "desiredSkills": ["vercel-labs/agent-browser/agent-browser"],
-  "agentRuntimeType": "codex_local",
-  "agentRuntimeConfig": {
-    "cwd": "/abs/path/to/repo",
-    "model": "o4-mini",
-    "promptTemplate": "# SOUL.md -- CTO Persona\n\nYou are the CTO.\n\n## Mission\nOwn technical strategy, architecture, engineering execution, and quality bars.\n\n## Responsibilities\n- Set technical direction and execution standards.\n- Review architecture and staffing trade-offs.\n- Keep delivery risks visible and actionable.\n\n## Boundaries\n- Do not approve risky shortcuts without naming the trade-off.\n- Escalate product or budget ambiguity instead of guessing.\n\n## Decision Principles\n- Prefer simple architectures with explicit trade-offs.\n- Treat reliability, developer velocity, and product learning as linked constraints.\n\n## Voice\nDirect, specific, and evidence-led.\n\n## Continuity\nPreserve durable technical standards, repeated failure patterns, and long-running architecture decisions in memory or explicit instructions."
-  },
-  "runtimeConfig": {"heartbeat": {"enabled": true, "intervalSec": 300, "wakeOnDemand": true, "maxConcurrentRuns": 3}},
-  "sourceIssueId": "<issue-id>"
-}' --json
-```
-
-Canonical semantics:
-
-- this wraps `POST /api/orgs/:orgId/agent-hires`
-- if the organization does not require board approval, the response contains `approval: null` and the agent is created directly
-- if the organization requires board approval, the response contains both `agent` and `approval`, and the new agent stays `pending_approval`
-
-Do not use `rudder approval create --type hire_agent` as a replacement for `agent hire` during normal skill execution. That is a lower-level compatibility surface and does not preserve the canonical direct-create behavior.
-
-`agentRuntimeConfig.promptTemplate`, when used during hire, is for role/persona content. Rudder materializes it as the managed instruction bundle's `SOUL.md`. Write it as a durable SOUL document with mission, responsibilities, boundaries, decision principles, voice, and continuity when the role has ongoing authority. Do not include Rudder's shared operating contract in this field; supported local runtimes inject that contract from code.
-
-### Approval follow-up
-
-```sh
-rudder approval get "<approval-id>" --json
-rudder approval comment "<approval-id>" --body-file "<path>" --json
-rudder approval resubmit "<approval-id>" --payload '{"...":"..."}' --json
-rudder approval issues "<approval-id>" --json
-```
-
-Notes:
-
-- `approval comment` should use markdown and link the approval, pending agent, and source issue when available
-- `approval resubmit` is only for a revision-requested approval; update the payload instead of creating a second hire
-- if the run wakes with `RUDDER_APPROVAL_ID`, treat that approval as the first task
-
-## Payload Notes
-
-The `agent hire` payload accepts the same shape as the hire API, including:
-
-- `name` optional; blank or omitted means Rudder assigns a distinct first name
-- `role`: one of `ceo`, `cto`, `cmo`, `cfo`, `engineer`, `designer`, `pm`, `qa`, `devops`, `researcher`, `general`
-- `title`
-- `icon` optional; omit it for normal hires so Rudder generates a DiceBear Notionists avatar automatically. Only provide an explicit DiceBear reference or uploaded `asset:<uuid>` image avatar reference when the board/UI supplied one.
-- `reportsTo`
-- `capabilities`
-- `desiredSkills`
-- `agentRuntimeType`
-- `agentRuntimeConfig`
-- `runtimeConfig`
-- `budgetMonthlyCents`
-- `metadata`
-- `sourceIssueId`
-- `sourceIssueIds`
-
-`role` is a fixed enum. Do not invent role keys such as `founding_engineer`, `frontend_engineer`, or `reviewer`. Use the closest enum value, then put the specialization in `title`, `capabilities`, and `agentRuntimeConfig.promptTemplate`; for example use `"role": "engineer"` with `"title": "Founding Engineer"`.
-
-Issue linkage rule:
-
-- prefer `sourceIssueId` or `sourceIssueIds` inside the hire payload
-- use `approval issues` to inspect the resulting approval links after the server creates them
-
-## Related Commands
-
-Post-hire adjustments use the normal agent and skill surfaces:
-
-```sh
-rudder agent get "<agent-id-or-shortname>" --org-id "$RUDDER_ORG_ID" --json
-rudder agent skills enable "<agent-id>" "<selection-ref>" --json
-rudder agent skills sync "<agent-id>" --desired-skills "<csv>" --json
-rudder agent local-cli "<agent-id-or-shortname>" --org-id "$RUDDER_ORG_ID" --json
-```

package/skills/rudder-create-plugin/SKILL.md

@@ -1,103 +0,0 @@
----
-name: rudder-create-plugin
-description: Create new Rudder plugins with the current alpha SDK/runtime. Use when scaffolding a plugin package, adding a new example plugin, or updating plugin authoring docs. Covers the supported worker/UI surface, route conventions, scaffold flow, and verification steps.
-  Create new Rudder plugins with the current alpha SDK/runtime. Use when
-  scaffolding a plugin package, adding a new example plugin, or updating plugin
-  authoring docs. Covers the supported worker/UI surface, route conventions,
-  scaffold flow, and verification steps.
-allowed-tools: 
-disable: true
----
-
-# Create a Rudder Plugin
-
-Use this skill when the task is to create, scaffold, or document a Rudder plugin.
-
-## 1. Ground rules
-
-Read these first when needed:
-
-1. `doc/engineering/PLUGIN_AUTHORING_GUIDE.md`
-2. `packages/plugins/sdk/README.md`
-3. `doc/engineering/PLUGIN_RUNTIME_CONTRACT.md` only for future-looking context
-
-Current runtime assumptions:
-
-- plugin workers are trusted code
-- plugin UI is trusted same-origin host code
-- worker APIs are capability-gated
-- plugin UI is not sandboxed by manifest capabilities
-- no host-provided shared plugin UI component kit yet
-- `ctx.assets` is not supported in the current runtime
-
-## 2. Preferred workflow
-
-Use the scaffold package instead of hand-writing the boilerplate:
-
-```bash
-pnpm --filter @rudderhq/create-rudder-plugin build
-node packages/plugins/create-rudder-plugin/dist/index.js <npm-package-name> --output <target-dir>
-```
-
-For a plugin that lives outside the Rudder repo, pass `--sdk-path` and let the scaffold snapshot the local SDK/shared packages into `.rudder-sdk/`:
-
-```bash
-pnpm --filter @rudderhq/create-rudder-plugin build
-node packages/plugins/create-rudder-plugin/dist/index.js @acme/plugin-name \
-  --output /absolute/path/to/plugin-repos \
-  --sdk-path /absolute/path/to/rudder/packages/plugins/sdk
-```
-
-Recommended target inside this repo:
-
-- `packages/plugins/examples/` for example plugins
-- another `packages/plugins/<name>/` folder if it is becoming a real package
-
-## 3. After scaffolding
-
-Check and adjust:
-
-- `src/manifest.ts`
-- `src/worker.ts`
-- `src/ui/index.tsx`
-- `tests/plugin.spec.ts`
-- `package.json`
-
-Make sure the plugin:
-
-- declares only supported capabilities
-- does not use `ctx.assets`
-- does not import host UI component stubs
-- keeps UI self-contained
-- uses `routePath` only on `page` slots
-- is installed into Rudder from an absolute local path during development
-
-## 4. If the plugin should appear in the app
-
-For bundled example/discoverable behavior, update the relevant host wiring:
-
-- bundled example list in `server/src/routes/plugins.ts`
-- any docs that list in-repo examples
-
-Only do this if the user wants the plugin surfaced as a bundled example.
-
-## 5. Verification
-
-Always run:
-
-```bash
-pnpm --filter <plugin-package> typecheck
-pnpm --filter <plugin-package> test
-pnpm --filter <plugin-package> build
-```
-
-If you changed SDK/host/plugin runtime code too, also run broader repo checks as appropriate.
-
-## 6. Documentation expectations
-
-When authoring or updating plugin docs:
-
-- distinguish current implementation from future spec ideas
-- be explicit about the trusted-code model
-- do not promise host UI components or asset APIs
-- prefer npm-package deployment guidance over repo-local workflows for production

package/skills/skill-optimizer/CHANGELOG.md

@@ -1,29 +0,0 @@
-# Changelog
-
-## v4.3 framing evidence hardening
-
-- Added sequencing guidance for requests that ask to optimize a skill after another live task: complete and verify the primary task first, then optimize from evidence.
-- Added explicit treatment of strong user corrections as high-signal evidence, especially framing corrections and wrong-abstraction-level failures.
-- Added framing checks for user outcome vs UI surface, scenario spine vs fixture rows, source of truth vs derivative signal, and product intent vs local convenience.
-- Relaxed the final response contract for larger workflows so the primary task result can be reported before concise skill changes.
-
-## v4.2 open-source package
-
-- Added package mode and open-source project structure guidance.
-- Added explicit adapter file lookup under `references/adapters/`.
-- Added packaging expectations for README, examples, evals, changelog, and distributable skill zip.
-- Preserved the generic analysis framework: core optimizer plus modular domain adapters.
-
-## v4.1 adapter hardening
-
-- Added explicit domain adapter use rule: source of truth, required inputs, review owner, authority gates, privacy, output template, validation cases, and must-not behaviors.
-- Added benchmark reporting split for trigger accuracy, patch-quality coverage, and downstream transfer.
-- Added warning that synthetic verifier scores are regression signals, not official leaderboard results.
-
-## v4.0 generic
-
-- Reframed Skill Optimizer from a software-focused hardening checklist into a domain-general analysis framework.
-- Added universal optimization lens covering purpose, triggers, inputs, workflow, tools, outputs, quality, safety, failure, and maintainability.
-- Moved domain-specific checks into modular adapter patterns.
-- Added trigger optimization guidance and benchmark mode.
-- Preserved strict patch safety around high-impact actions.