happy-agent: Skill for Claude Code

Releasing Happy Agent

Releases go out through GitHub Actions using trusted publishing. Never publish from local npm credentials, and never create or push a release tag by hand — the workflow creates the tag, and it only does so after the build and publication have succeeded.

The release master plan coordinates Agent, Desktop native, and hosted renderer releases. Preserve the user's authorized scope across handoffs under the runtime's trusted authorization policy. Do not re-ask preemptively for authorized work. If the runtime denies an action, stop it, explain the denial, and follow its rules for fresh approval. Publish and verify changed SDKs before updating consumers, then prepare and dispatch independent products in parallel once their dependencies are ready. Wait only at actual dependency gates, and verify every requested product before reporting completion.

Which product, which version

An unqualified "release" means a Happy Agent preview. Production must be explicit. Neither means a library unless that library is named.

Before choosing production, check that the user explicitly requested a production or stable release for this product in the current task. A request to "release", "ship", or push is not production authorization; default to preview. An existing explicit request is sufficient: do not ask for redundant confirmation.

Use the candidate ourselves in the affected workflows for at least a brief soak before releasing it to production. Passing tests or CI alone does not count as that use. If the candidate has not been used, keep it in preview and explain what still needs to be tried. No fixed soak duration or previously published preview is required.