A translation of what shipped in the latest wk and recipe-lint releases (both cut August 1, 2026), and in Developer Skills (from June 28–August 1).
Each packaged repo auto-generates release notes from merged PR titles. This post maps changes back to what developers will actually notice.
wk v1.0.3
Release Notes (GitHub)
Compare: v1.0.2...v1.0.3
wk lint prints readable output by default now.
(#95) wk gained support for plugin-owned output renderers. A plugin can declare its own formatter for human-readable text. Paired with the matching change in recipe-lint below, this fixes an issue with wk lint‘s default (non- --json) output, which previously printed the raw internal result as literal Go map syntax (map[level:warn message:...]). This is the highest-traffic command in the toolkit, so it’s the biggest default-experience fix in this release.
Recipe mutation failures no longer fail silently.
(#92) The platform API returns HTTP 200 with success:false in the body for certain refusals, and wk was discarding that body. Concretely, this meant: deleting a running recipe would report success, delete your local .recipe.json, and leave the server recipe running untouched, creating a silent local/server divergence. wk recipes start on a recipe with activation errors would just poll blindly for the full 2-minute timeout with no indication why. Both behaviors are now fixed: refusals now surface as typed errors with exit code 2, local files are preserved on a refused delete, and start reports the actual activation error immediately instead of timing out.
wk recipes jobs get stops hiding why a job failed.
(#93, corrected in #96) The --json output only declared four fields per job step, so input, output, error, and the full HTTP error body were silently dropped by Go’s JSON decoder. You’d see a failed step with no indication of why. Both are now surfaced, including the downstream HTTP response (status, body, headers).
Setup got clearer: CLI-to-API permission scopes are now documented.
(#94, closing labs#1) This one addresses a real first-five-minutes blocker: a developer hit a confusing 401: Unauthorized on wk auth login with no way to know which API client permission level was actually required. The README now lists the baseline scopes wk needs, and known-limitations.md documents the complete mapping from CLI functionality to the underlying API permission groups, so a permissions error is now something you can look up instead of guess at.
New wk folders update — rename and move, plus wk folders list --projects.
(#93, closing #91 and #97) wk folders update <id> takes --name and --parent independently or together, so this is both a rename command and the first way to move a folder without a copy/delete round-trip:
wk folders update 123 --name "New name"
wk folders update 123 --parent 456
wk folders update 123 --name "New name" --parent 456
It routes to PUT /folders/{id} or PUT /projects/{id} depending on whether the target is a plain folder or a top-level project (projects are always top-level and can’t be reparented — the command errors if you try). wk folders list --projects lists projects directly via GET /projects instead of inferring them from a flagged folder list. Together this closes out CLI coverage of the Projects & folders permission group — previously both renaming and moving required the UI.
Also in this release: a couple of Windows-only test fixes with no user-facing behavior change (#99).
recipe-lint v1.1.0
Release Notes (GitHub)
Compare: v1.0.0...v1.1.0
Lint output is human-readable by default now.
(#27, closing #26) The other half of the wk renderer change above: recipe-lint now implements the plugin-owned renderer contract, so you get actual formatted diagnostics. This is the default output of the most-run command, so it’s the top-priority fix in this release.
Trigger-level filters now get datapill lint coverage.
(#28) The trigger’s “only continue if…” condition (code.filter) was invisible to the linter in every sense: not parsed, not walkable by custom rules, and its lhs values got none of the existing datapill checks that an if-block’s conditions already get for free. A malformed filter condition (e.g. a stray formula-mode string) used to pass wk lint with zero diagnostics. Now filter.{field} is a resolvable path for custom rules, and filter conditions get the same datapill validation as if-blocks.
RETURN_RESPONSE_SCHEMA_CONSISTENT‘s own suggested fix was wrong.
(#25) Following this rule’s previous suggested fix verbatim produced a recipe that linted clean but the platform refused to activate, as Workato requires every non-optional declared response field to be populated within its own block. The old text didn’t say so. The suggested-fix text now names the "optional": true requirements explicitly.
recipe-skills
Currently, no releases/tags exist for this repo. It’s distributed as a rolling main branch. The changes below are everything merged since 2026-06-28 (recipe-lint‘s prior tag, used as the cutoff).
Skills are now discoverable by any agent, not just Claude Code, and installable without cloning the repo at all.
(#6, closing #5; extended by #17) First, a root AGENTS.md was added so any AGENTS.md-aware agent (i.e. Codex, Cursor, Devon) routes a request to the right connector skill; previously that auto-discovery only worked in Claude Code. Then #17 went further: the skills library now packages as an installable plugin in each agent’s own marketplace (Claude Code, Codex, Cursor), so you install once and get recipe skills in any project. No cloning the repo, no relying on AGENTS.md discovery at all.
Recipe-skills docs now flag a control_type gotcha neither the importer nor wk lint is positioned to catch.
(#10) control_type was documented as required on trigger-level schema fields, but not on result_schema_json, py_eval input/output schemas, or declare_variable/declare_list fields, even though the Workato UI needs it there too, to give its datapill mapping picker something to attach to. It’s a UI-rendering requirement, not a structural one, so a recipe missing it imports fine and lints clean (including --profile strict). There was never a validation rule this could have violated. The docs now call it out explicitly, with new validation-checklist items in python-snippets.md and variables-and-lists.md.
A cluster of doc-accuracy fixes, mostly small: corrected if/else equality operand and return_result empty-string scope (#11); nested array-of-primitive fields documented as stringified rather than iterated (#13); three install/lint workflow bugs fixed in cli-guidance.md (#7); new Scheduler trigger documentation (#14); invalid condition operands fixed so the api-endpoint template actually activates (#15). One to highlight specifically: #16 documents the optional: true requirement for unified return_response schemas in the api-endpoint skill — the docs-side companion to the exact same non-optional-field gap that recipe-lint‘s RETURN_RESPONSE_SCHEMA_CONSISTENT fix (above) addresses on the lint side.
New Contributors This Cycle
Four people showed up in these repos for the first time this cycle 🎉:
- hoswork — first-time contributions landed across three repos:
wk(#92, thesuccess:falserefusal fix),recipe-lint(#25, theRETURN_RESPONSE_SCHEMA_CONSISTENTfix), andrecipe-skills(#15 and #16, the api-endpoint condition and schema fixes). - Abhishek Bhattacherjee — first PR into
wk(#96), correcting theerror_descriptor/error_partsfield names against the real API response, also ensured update would support move/reparent. - jco-cw-de — four merged PRs into
recipe-skillsin one showing (#7, #10, #11, #13), all doc-accuracy fixes caught by using the skills in recipe building. - mikel-flyr — added the Scheduler trigger documentation to
recipe-skills(#14).
Thank you to all of our new contributors. We look forward to seeing more contributions from the community, based on your builds.
(Also merging their first PRs into these repos this cycle: Chris Miller and Bill Prin, both of whom have joined the Labs core maintainer team. Welcome!)
How to Upgrade
Homebrew (recommended for Mac). One quirk to know: brew upgrade wk / brew upgrade recipe-lint on their own won’t reliably pick up the new version — a known Homebrew behavior with custom taps, not something on our end. Use the fully tap-qualified name instead:
brew upgrade workato-devs/tap/wk
brew upgrade workato-devs/tap/recipe-lint
wk plugins install recipe-lint
Scoop (recommended for Windows):
scoop update wk
scoop update recipe-lint
wk plugins install recipe-lint
Why re-run wk plugins install? That command copies the plugin into ~/.wk/plugins/ (rather than wk constantly attempting to guess at the installation location of plugins while executing commands). If you upgraded via Homebrew/Scoop, you’ve updated the binary on $PATH but not what wk invokes until you re-run install. Note: this step is only for recipe-lint.
Currently, the Developer Skills bundled in recipe-skills aren’t pinned to a version. If you installed via your agent’s plugin marketplace (Claude Code, Codex, Cursor) they will automatically use the latest version. If you cloned the repo directly, you will need to run git pull.
If you installed wk or recipe-lint by manually downloading a release tarball, that path still works. You need to repeat the download for the new versions, and re-run wk plugins install recipe-lint as well.