Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

release

Sterne33

Forks3

Aktualisiert26. Juni 2026 um 12:21

Drive the changesets-based release flow for the agent-id npm packages. Use when the user wants to release packages, cut a version, declare a release intent, enter or exit a beta cycle, or check what's pending for the next release.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

alien-id

alien-id/agent-id

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	release
description	Drive the changesets-based release flow for the agent-id npm packages. Use when the user wants to release packages, cut a version, declare a release intent, enter or exit a beta cycle, or check what's pending for the next release.
disable-model-invocation	false
user-invocable	true

Release

Only two packages publish to npm: @alien-id/agent-id-core and @alien-id/agent-id-vault. The four consuming plugins (agent-id-auth, agent-id-git, agent-id-proxy, agent-id-browser) are private and ignored by changesets — they ship through the Claude Code marketplace, not npm.

The pipeline is fully automated by changesets. A maintainer's only manual gates are: write a .changeset/*.md on the feature PR, merge the bot-opened "chore: release packages" Version PR, and approve the npm-publish environment.

See RELEASING.md for the full mental model. This skill drives the conversational shape of the flow.

Decision tree

When invoked, first run bun changeset status --verbose and figure out which branch applies:

Feature PR in progress. If the change touches plugins/agent-id-core/** or plugins/agent-id-vault/**, help the user declare a release intent with bun changeset and commit the resulting .changeset/*.md alongside the code. Stop after that. (Changes to only the private plugins need no changeset.)
Pending changesets on main, no Version PR yet. changesets/action opens it on the next push to main. If they just merged, wait ~30s then point them at the PR list.
Version PR open. Read it (it lists computed bumps + cascade + the synced plugin.json/marketplace.json versions). If ready: review → squash-merge → approve the npm-publish environment → watch the workflow. Surface the GitHub Actions URL.
Beta cycle decision. If .changeset/pre.json is absent and the user wants a beta cycle, run bun changeset pre enter beta and open a one-line PR. If pre.json exists and they want stable, run bun changeset pre exit and open a one-line PR.
Partial publish failure. Re-run the workflow from the GitHub Actions UI. publish-topological.ts skips already-published packages (via npm view) and resumes. Do NOT manually edit versions or tags.
First-ever publish (bootstrap). @alien-id/agent-id-core@7.0.0 and @alien-id/agent-id-vault@7.0.0 must exist on npm before the dependent marketplace plugins can install. Either let the gated publish job do it on the first merge, or publish manually once (see RELEASING.md → Bootstrap).

How to add a changeset (verbatim)

bun changeset
# Interactive: pick core and/or vault, bump type (patch/minor/major), summary.
git add .changeset/<id>.md

The summary line becomes the per-package CHANGELOG entry. Write it for a consumer: "Add X", "Fix Y", "Breaking: rename Z."

Behaviours to surface to the user

Cascade is automatic. Bumping @alien-id/agent-id-core patches @alien-id/agent-id-vault (the only published dependent). The four ignored plugins are NOT version-bumped, but changeset version DOES rewrite their @alien-id/agent-id-{core,vault} dependency ranges — so the Version PR carries package.json diffs for them too. That is intended (the runtime install hook copies each plugin's package.json).
Version propagation. ci:version runs changeset version && bun install && bun run sync-plugin-versions. The sync step copies each plugin's package.json version into its .claude-plugin/plugin.json and the marketplace.json entry. package.json is the single source of truth; CI fails on drift either way.
No build step. Plugins are plain ESM .mjs; ci:publish packs and publishes raw — there is no compile.
Internal deps are ^semver, not workspace:*. The marketplace installer runs npm, which can't resolve workspace:. bun workspaces still link locally.
Trusted publishing, no NPM_TOKEN. Auth is OIDC + sigstore provenance. An npm publish auth failure means the trusted-publisher config on npm needs to authorize release.yml for the failing package — an operator task, not code.
Version PR force-pushes on every new changeset, resetting prior approvals. Re-review before merging.

Hard rules

NEVER edit plugins/*/package.json version fields by hand. changeset version computes them, and sync-plugin-versions propagates them.
NEVER hand-edit plugin.json / marketplace.json versions — they are derived.
NEVER edit bun.lock manually after changeset version; ci:version's bun install regenerates it.
NEVER push a tag directly. changeset tag (inside ci:publish) creates them.
NEVER bypass the npm-publish environment reviewer gate.

Mehr aus diesem Repository

gleiches Repository

agent-id-browser

alien-id/agent-id

Drive Alien Browser with an anonymous L0 profile created automatically for public pages, or a logged-in profile sealed in the agent vault. Inspect forms compactly and fill/verify up to 50 fields, checks, selects, and file uploads in one call; use fine-grained refs, screenshots, tabs, dialogs, and downloads for the rest. By default all sites share ONE session; pass --name only for a separate isolated session. Credentials and 2FA use the secure vault injection path and are never seen by the agent. Sessions may be sealed READ-ONLY, where writes are blocked at the network layer.

2026-07-1633

agent-id-proxy

alien-id/agent-id

Local credential-injecting HTTP proxy. The agent calls `http://localhost:PORT/<credname>/<upstream-host>/<path>`; the proxy looks up the credential in the vault, validates the host against that credential's allowlist (default-deny), materializes the credential into the appropriate request location, and forwards over real HTTPS. For vault-generated wallet credentials it signs blockchain transactions in-process — Solana `sendTransaction` bodies are ed25519-signed, EVM `eth_sendTransaction` becomes a signed EIP-1559 `eth_sendRawTransaction`. The agent never sees the credential value or private key. Use whenever the agent calls an external service with a vaulted credential, or needs to send a blockchain transaction from a vault-held wallet (payments, trading, x402, transfers).

2026-07-0233

agent-id-vault

alien-id/agent-id

Portable encrypted credential vault with LUKS-style slots (passkey/Touch ID, passphrase, agent-key, phone) and typed/domain-scoped credential records. Credentials can carry an ACCESS LEVEL (--access ro) so the agent can read a service but never write to it — enforced by the proxy and the sealed browser, widened only with the owner's out-of-band confirmation (set-access). Pairs with agent-id-proxy so the agent never sees credential values — the proxy injects them at request time. Can also GENERATE blockchain wallet keys (Solana ed25519, EVM secp256k1) inside the vault — the private key is sealed, only the address is printed, and transactions are signed by the proxy. Use whenever the user asks to save, fetch, or remove a service credential, create a crypto wallet for the agent, or whenever a downstream tool needs an external-service secret that must not appear in shell history, source files, or process arguments.

2026-07-0233

agent-id-auth

alien-id/agent-id

DPoP-signed (RFC 9449) authenticated calls to Alien-aware services. Discover any Alien-aware service's manifest at /.well-known/alien-agent-id.json, render its operations as actionable markdown, emit DPoP headers for one request, or one-shot a signed HTTP call with the agent's identity attached. Use when the user gives you a URL on an Alien-aware service (alien-api.com, alien.org, agent-sso.*), asks to call an Alien-aware endpoint, asks what an Alien-aware service can do, or mentions DPoP, agent-bound access tokens, or `cnf.jkt`.

2026-06-2633

agent-id-core

alien-id/agent-id

Create and manage an AI agent's cryptographic identity — a local Ed25519 key that works immediately (sign, verify, run the vault, make commits) with no account or sign-up. Optionally bind it to a verified human via Alien Network SSO (OIDC + DPoP) when you want third-party-provable provenance; check or refresh the identity's state; sign or verify operations in the agent's local hash-chained audit trail. Use when the user asks to set up or bootstrap an agent identity, check whether one exists, add or refresh human binding, migrate a pre-v3 binding, or sign / verify / export-proof an operation. Also triggers on "Alien ID", "Agent ID", "agent identity", "DPoP", "cnf.jkt", or "owner binding".

2026-06-2633

agent-id-git

alien-id/agent-id

SSH-signed git commits with Alien Agent ID provenance trailers and a v3 proof note. Sign every line of agent-written code so it is cryptographically attributable to the agent + a verified human owner via Alien Network SSO. Verify provenance on any commit — your own or third-party — without needing the signer's local state. Use when the user asks to make a signed commit, push agent-signed work, check the Agent-ID chain on a commit, audit who signed a commit, or configure git for SSH-format signing with the bound agent key.

2026-06-2633

name	release
description	Drive the changesets-based release flow for the agent-id npm packages. Use when the user wants to release packages, cut a version, declare a release intent, enter or exit a beta cycle, or check what's pending for the next release.
disable-model-invocation	false
user-invocable	true

Release

See RELEASING.md for the full mental model. This skill drives the conversational shape of the flow.

Decision tree

When invoked, first run bun changeset status --verbose and figure out which branch applies:

Feature PR in progress. If the change touches plugins/agent-id-core/** or plugins/agent-id-vault/**, help the user declare a release intent with bun changeset and commit the resulting .changeset/*.md alongside the code. Stop after that. (Changes to only the private plugins need no changeset.)
Pending changesets on main, no Version PR yet. changesets/action opens it on the next push to main. If they just merged, wait ~30s then point them at the PR list.
Version PR open. Read it (it lists computed bumps + cascade + the synced plugin.json/marketplace.json versions). If ready: review → squash-merge → approve the npm-publish environment → watch the workflow. Surface the GitHub Actions URL.
Beta cycle decision. If .changeset/pre.json is absent and the user wants a beta cycle, run bun changeset pre enter beta and open a one-line PR. If pre.json exists and they want stable, run bun changeset pre exit and open a one-line PR.
Partial publish failure. Re-run the workflow from the GitHub Actions UI. publish-topological.ts skips already-published packages (via npm view) and resumes. Do NOT manually edit versions or tags.
First-ever publish (bootstrap). @alien-id/agent-id-core@7.0.0 and @alien-id/agent-id-vault@7.0.0 must exist on npm before the dependent marketplace plugins can install. Either let the gated publish job do it on the first merge, or publish manually once (see RELEASING.md → Bootstrap).

How to add a changeset (verbatim)

bun changeset
# Interactive: pick core and/or vault, bump type (patch/minor/major), summary.
git add .changeset/<id>.md

The summary line becomes the per-package CHANGELOG entry. Write it for a consumer: "Add X", "Fix Y", "Breaking: rename Z."

Behaviours to surface to the user

Cascade is automatic. Bumping @alien-id/agent-id-core patches @alien-id/agent-id-vault (the only published dependent). The four ignored plugins are NOT version-bumped, but changeset version DOES rewrite their @alien-id/agent-id-{core,vault} dependency ranges — so the Version PR carries package.json diffs for them too. That is intended (the runtime install hook copies each plugin's package.json).
Version propagation. ci:version runs changeset version && bun install && bun run sync-plugin-versions. The sync step copies each plugin's package.json version into its .claude-plugin/plugin.json and the marketplace.json entry. package.json is the single source of truth; CI fails on drift either way.
No build step. Plugins are plain ESM .mjs; ci:publish packs and publishes raw — there is no compile.
Internal deps are ^semver, not workspace:*. The marketplace installer runs npm, which can't resolve workspace:. bun workspaces still link locally.
Trusted publishing, no NPM_TOKEN. Auth is OIDC + sigstore provenance. An npm publish auth failure means the trusted-publisher config on npm needs to authorize release.yml for the failing package — an operator task, not code.
Version PR force-pushes on every new changeset, resetting prior approvals. Re-review before merging.

Hard rules

NEVER edit plugins/*/package.json version fields by hand. changeset version computes them, and sync-plugin-versions propagates them.
NEVER hand-edit plugin.json / marketplace.json versions — they are derived.
NEVER edit bun.lock manually after changeset version; ci:version's bun install regenerates it.
NEVER push a tag directly. changeset tag (inside ci:publish) creates them.
NEVER bypass the npm-publish environment reviewer gate.