CtrlK
BlogDocsLog inGet started
Tessl Logo

putio/sdk-dev

Develop or review put.io SDK repositories, API clients, and client libraries across TypeScript, Swift, Kotlin, and similar packages. Use when adding or changing namespaces, tightening request or error types, aligning SDK behavior with backend and app usage, updating SDK verification flows, or checking how an SDK repo should be documented and released.

97

Quality

97%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

language-notes.mdreferences/

SDK Language Notes

Use the section that matches the SDK repo you are changing.

TypeScript

  • Stay Effect-first when the repo already uses Effect.
  • Keep Schema at boundaries for request, response, config, and error shapes.
  • Keep Promise and Effect clients aligned when both are public.
  • Prefer discriminated unions, explicit exports, and parameter-aware return types over loose option bags.
  • Do not weaken the surface with unsafe casts or ignored type failures unless explicitly approved.

Swift

  • Prefer async throws and native Swift value types.
  • Keep the package surface open-source-safe and preserve package-manager install paths.
  • Verify the example app when auth or integration behavior changes.
  • Avoid callback-first APIs, raw JSON public results, and JavaScript-style compatibility layers as long-term surfaces.

Kotlin

  • Prefer coroutine-first APIs.
  • Keep models serialization-friendly.
  • Prefer explicit error contracts over generic failures.
  • Stay close to the TypeScript contract shape without forcing full endpoint parity.
  • Preserve forward-compatible backend values when the server can evolve faster than the client.

references

language-notes.md

patterns.md

sdk-vision.md

SKILL.md

tile.json