Skip to content

Add SDK code generation guidance to cloudinary-transformations - #24

Open
carlevison wants to merge 2 commits into
mainfrom
feat/transformations-sdk-code
Open

carlevison wants to merge 2 commits into
mainfrom
feat/transformations-sdk-code

Conversation

@carlevison

Copy link
Copy Markdown
Collaborator

Summary

The cloudinary-transformations skill only produced URL strings. This adds a Generating SDK Code section so the skill can give users code for their Cloudinary SDK.

  • Detect the SDK from the project's dependency files. A table maps each Cloudinary package to the code-block tag used on the Transformation Reference pages, covering 17 SDKs. Next.js projects are routed to the cloudinary-next skill, and React projects also point to cloudinary-react. If the SDK is unclear, or the project uses more than one, the skill asks.
  • Build the transformation in URL syntax first, then translate it.
  • Take SDK syntax from the Transformation Reference parameter pages instead of guessing method names from URL parameters. Each parameter page has code examples for every SDK.
  • Pitfalls covered: tag vs. URL methods, older SDK versions, and falling back to a raw transformation string when a parameter has no example.

Also:

  • updated the description and "When to Use" list to mention SDK code
  • added a self-validation checklist item for SDK code
  • bumped the version from 1.0.4 to 1.1.0

Testing

  • scripts/check-discovery.sh, scripts/check-links.sh and scripts/check-versions.sh pass locally.
  • Automated eval coverage for SDK output will follow in a separate PR.

🤖 Generated with Claude Code

carlevison and others added 2 commits September 28, 2026 15:22
Detect the user's Cloudinary SDK from project dependencies and pull
SDK-specific syntax from the Transformation Reference parameter pages
instead of guessing it from URL parameters.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Make references to cloudinary-next and cloudinary-react conditional on
them being installed, and add a rawTransformations fallback for Next.js
projects when cloudinary-next isn't available.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

@sharon-yelenik sharon-yelenik left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. One comment for you to look at.
I also wanted to raise a general question because this seems a bit circuitous to me.
We're asking the LLM to produce the delivery URL, and from that to derive the SDK code, only to return back a valid delivery URL, which is what had in the first place.
Is there intrinsic value for using SDK code that justifies the extra processing and potentially introducing a mistake?

3. Combine the snippets into one expression, following the chaining pattern the snippets show. For example, `@cloudinary/url-gen` chains action methods (`.resize(...).delivery(...)`). The Node.js, Python and Ruby SDKs take an array of transformation objects (`transformation: [{...}, {...}]`), one per URL component.
4. Replace the example public IDs (such as `docs/camera-640.jpg`) and values with the user's.

**Watch out for:**

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a note about import statements? Some SDKs require a separate import for each transformation, shown in the transformation reference. Other SDKs need only one import for all transformations, but for those, the import statement isn't shown in the transformation reference; it's only in the SDK docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants