thunderid: Skill for Claude Code

SDK Development

Every ThunderID SDK implements one contract, recorded in the SDK development specification. Every SDK change goes through it: a new SDK, a capability added to an SDK that already exists, an integration package, or a review of any of those.

A change is finished when it is implemented in every SDK where it applies, validated against the specification and the threat model, covered by tests, and raised as linked pull requests across the repositories it touches.

1. Load the specification

Read both documents before writing or reviewing SDK code. Do not work from another SDK's source as the reference, and do not work from memory of this skill.

Working in	Read
thunder-id/thunderid	docs-internals/sdk-development/spec.md and docs-internals/sdk-development/threat-model.md
An SDK repository	Fetch spec.md and threat-model.md

The specification is the authority. This skill routes to the right part of it, holds the checklist, and drives the workflow. Where the two disagree, the specification wins and this file needs fixing.

This skill and the two documents live in thunder-id/thunderid and are maintained only here. An SDK repository refers to them by link from its AGENTS.md rather than keeping a copy, so there is one place to change when the contract moves. A copy of this file in an SDK repository is a bug: replace it with a link.

2. Locate the SDK repositories

A cross-SDK change needs a local checkout of each repository. Never guess a path, and never assume a path is correct because it was pre-populated as a working directory.

Read ~/.thunderid.dev.local/sdk-paths.json if it exists:

{
  "javascript": "/absolute/path/to/javascript-sdks",
  "ios": "/absolute/path/to/ios-sdks",
  "android": "/absolute/path/to/android-sdks",
  "flutter": "/absolute/path/to/flutter-sdks"
}