feat(plugin): add a build-sim-workflow skill to the Sim plugin

Author: waleedlatif1

plugins/sim/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "sim",
   "displayName": "Sim",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "description": "Connect to Sim, the open-source AI workspace, to build, deploy, and manage AI agents: run workflows and work with tables, knowledge bases, files, and logs.",
   "author": {
     "name": "Sim",

plugins/sim/README.md

@@ -11,6 +11,10 @@ claude plugin install sim@sim
 
 Then open `/mcp` in Claude Code and sign in to Sim in the browser. Access follows your Sim account and workspace roles.
 
+## Skills
+
+- `build-sim-workflow`: builds, tests, deploys, runs, and debugs a workflow through the MCP tools. It dry-runs each edit, reads the lint before applying, and checks run traces when something fails. Claude uses it when you ask for a workflow; you can also run `/sim:build-sim-workflow`. See [Build and run workflows with the API](https://docs.sim.ai/api-reference/build-and-run-workflows) for the same steps over HTTP and the CLI.
+
 ## Self-hosted Sim
 
 This plugin connects to Sim Cloud. For a self-hosted deployment, add your own server URL instead, as described in the [MCP docs](https://docs.sim.ai/mcp/overview).

plugins/sim/skills/build-sim-workflow/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: build-sim-workflow
+description: Build, test, deploy, run, and debug a Sim workflow through the Sim MCP tools. Use when the user asks to create or change a Sim workflow, wire blocks or integrations into one, run or deploy it, find out why a run failed, or resume a run waiting for approval.
+---
+
+# Build a Sim workflow
+
+Work through the Sim MCP server's four tools: `search_operations`, `describe_operation`, `call_read_operation`, and `call_write_operation`. Every call names an `operation` and fills `params` (path), `query`, and `body`.
+
+Never write a request from memory. Before the first call to any operation, run `describe_operation` and build the request from the schema it returns. Schemas change; the descriptions also state access rules and edge cases.
+
+If a call returns `403` asking for a personal key or OAuth, tell the user: workspace API keys cannot edit graphs, deploy, or run drafts.
+
+## Loop
+
+1. **Find the workspace.** `listWorkspaces` if the user did not name one. Catalog and create calls need `workspaceId`.
+2. **Discover blocks.** `listBlocks` with `search` (or `capability=trigger` for starters), then `getBlock` for each block you will place. Use its `inputSchema` and `operationInputSchema` field ids as `inputs` keys, its `operations` for the operation id, and its `outputs` for what later blocks can reference as `<blockname.field>`. Do not guess field ids.
+3. **Create or load the workflow.** `createWorkflow` returns the seeded Start block's id. For an existing workflow, read `getWorkflowState` first.
+4. **Declare inputs.** Set the Start block's `inputFormat` (an array of `{ name, type }`) with an `edit` operation. Runs pass `input` keyed by those names; blocks reference them as `<start.name>`.
+5. **Dry-run the edit.** `applyWorkflowOperations` with `query: { dryRun: true }`. Batch related edits; refer to new blocks by the `block_id` you chose. Ignore `previewBlockIds` for later requests.
+6. **Read the result before applying.** Fix and re-dry-run until clean:
+   - `skipped`, `inputValidationErrors`: edits that did not take.
+   - `lint.fieldIssues[].missingRequiredFields`: will fail at run time.
+   - `lint.unresolvedReferences`: bad credentials, resources, tools, or `<block.output>` references.
+   - `lint.orphanBlocks`, `lint.sources`, `lint.emptyOutgoingPorts`, `lint.invalidBranchPorts`: wiring problems.
+   - `lint.manualRunIssue`: the builder's Run button would refuse the workflow.
+   Lint never blocks a write, so it is your job to act on it.
+7. **Apply.** Same body without `dryRun`, with `atomic: true`. Use `mintedBlockIds` for every later reference to new blocks. Do not resubmit `deferred` edges.
+8. **Test the draft.** `executeWorkflow` with `run: { source: "manual" }` and sample `input`. Narrow with `run.entry` (a trigger, `useMockPayload`, or a block plus `sourceRunId`) and `run.stopAfterBlockId`. Check `status`; failures come back as `status: "failed"` with HTTP 200.
+9. **Debug a failure.** The synchronous response's `error.blockId` names the failing block. Otherwise call `getLog` with the `runId` and walk `traceSpans` (and `children`) for the span with `errorMessage`. Fix with an `edit`, dry-run, apply, then rerun from that block with `run.entry: { type: "block", blockId, sourceRunId }`.
+10. **Deploy only when the user asks.** `deployWorkflow`, then poll `getWorkflowDeployment` until `latestDeploymentAttempt.status` is `active` or `failed`. Do not retry a deploy that timed out without checking; each accepted deploy creates a version.
+11. **Run the deployment.** `executeWorkflow` without `run`. For long runs use `async: true` or `waitTimeoutSeconds`, then poll `getWorkflowRun` until `status` is terminal or `paused`. Send an `X-Run-Id` header and reuse it on retry; never retry with a new id.
+12. **Resume approvals.** A `paused` run lists `paused.points`. Show the user each human point's `inputFields`, get their answer, then `resumeWorkflow` with its `contextId` and `input`. Never approve on the user's behalf.
+
+## Rules
+
+- Confirm with the user before deploying, deleting blocks or workflows, or resuming a paused run.
+- Report lint findings you did not fix.
+- Edits change the draft only. Say so when the workflow is deployed and `needsRedeployment` becomes true.
+- Guide: https://docs.sim.ai/api-reference/build-and-run-workflows