How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

release-signing - Skill - OpenSmartRoute

Name: release-signing
Author: kunchenguid

Imported from kunchenguid/no-mistakes (.agents/skills/release-signing/SKILL.md). Install upstream with npx skills add kunchenguid/no-mistakes --skill release-signing. Copyright stays with the author.

macOS Release Signing (permanent identity)

Every official macOS release artifact - both darwin/arm64 and darwin/amd64 - is Developer ID Application signed on a macOS runner with a fixed identifier, hardened runtime, secure timestamp, and no entitlements, then strictly verified before it is archived or checksummed; the Linux and Windows release paths are unchanged.
The executable identifier com.kunchenguid.no-mistakes and Team ID 9T2J7MNUP9 are the permanent Developer ID identity and MUST NEVER change: they are the invariant of the identity-based designated requirement that lets macOS permission grants survive no-mistakes update, so changing either resets every grant once.
Signing runs only in the darwin build job gated behind the release-signing GitHub environment; the certificate is the base64 CSC_LINK secret unlocked with CSC_KEY_PASSWORD, imported into an ephemeral keychain with a runtime-generated password that is deleted on success and failure, and no other job may reference those secrets.
Signing happens before tarball creation and checksum generation, and the verify gate fails the release closed on any missing or ambiguous signature, wrong Team ID, non-permanent identifier, content-based (cdhash) requirement, missing hardened runtime or timestamp, or wrong architecture.
Mechanics live in .github/workflows/release.yml; the contract is pinned by the root TestReleaseWorkflow* static tests in workflow_release_signing_test.go, and secret values are never recorded here or in any test fixture.
Notarization, stapling, a PKG, Homebrew, and universal binaries are intentionally out of scope for this phase.

Self-update channel manifest (internal/update)

no-mistakes update reads version metadata exclusively from channels.json on the GitHub release-asset CDN (releases/download/channels/channels.json), not api.github.com; a token is never required. Publisher: cmd/publish-channels, invoked from .github/workflows/publish-channels.yml (reusable workflow_call, plus workflow_dispatch / on: release backstops). release.yml calls it after finalize because GitHub does not cascade GITHUB_TOKEN release events, so release-please (pre)releases would otherwise leave the channel stale. Regressions: internal/update/channels_test.go, workflow_publish_channels_test.go, TestReleaseWorkflowCallsPublishChannelsAfterFinalize.

Install release-signing and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

{ "ocm": "1", "id": "kunchenguid-no-mistakes-release-signing", "kind": "skill", "name": "release-signing", "description": "Use when changing macOS release signing, release artifact verification, the release workflow, or the self-update channel manifest.", "publisher": "kunchenguid", "version": "1.0.0", "capabilities": { "domains": [ "coding", "legal" ], "tags": [ "skill-md", "skills-sh" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "Use when changing macOS release signing, release artifact verification, the release workflow, or the self-update channel manifest." ], "primary": false, "metadata": { "source": { "provider": "skills.sh", "repository": "https://github.com/kunchenguid/no-mistakes", "path": ".agents/skills/release-signing/SKILL.md", "ref": "HEAD", "url": "https://github.com/kunchenguid/no-mistakes/blob/HEAD/.agents/skills/release-signing/SKILL.md", "key": "kunchenguid/no-mistakes/.agents/skills/release-signing/SKILL.md" } }, "instructions": "**macOS Release Signing (permanent identity)**\n\n- Every official macOS release artifact - both `darwin/arm64` and `darwin/amd64` - is Developer ID Application signed on a macOS runner with a fixed identifier, hardened runtime, secure timestamp, and no entitlements, then strictly verified before it is archived or checksummed; the Linux and Windows release paths are unchanged.\n- The executable identifier `com.kunchenguid.no-mistakes` and Team ID `9T2J7MNUP9` are the permanent Developer ID identity and MUST NEVER change: they are the invariant of the identity-based designated requirement that let", "cost": { "context_tokens": 605 } }

release-signing

About

Install release-signing and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews