Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

release

Étoiles33

Forks3

Mis à jour26 juin 2026 à 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

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

alien-id

alien-id/agent-id

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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

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.