@hasna/skills 0.10.76 → 0.10.78

package/README.md

@@ -80,7 +80,11 @@ Stations provisioned with a fleet key keep using the internal gateway
 no recorded URL (the Keychain item, `HASNA_SKILLS_API_KEY` alone, or an older
 credentials file) always stays on that gateway and is never sent anywhere else.
 The gateway has no interactive login service, so on such a station
-`skills login` says so, sends nothing, and names the credential to unset first.
+`skills login` says so and sends nothing. A stored gateway credential or vault
+reference is preserved even with `--url`. Use a separate credential profile for
+customer sign-in: `skills --profile skillsmd login`. Later product commands use that
+profile too, for example `skills --profile skillsmd whoami --json`; fleet
+commands keep their original configuration.
 Obtain a workspace API key through your administrator's provisioning process
 and configure it using the [credential resolution](#credentials) below. Check
 the selected identity and available capabilities before syncing:
@@ -2026,6 +2030,14 @@ Stable command shapes:
   snapshot plan.
 - MCP registration: `mcp --register <agent> --json` returns
   `{ "registered": number, "results": [...] }`.
+  Claude re-registration updates only `mcpServers.skills` in the active user
+  `.claude.json` (respecting `CLAUDE_CONFIG_DIR` and an active legacy
+  `.config.json`). Before changing an existing file it preserves and reads back
+  a mode-0600 sibling `.skills-mcp-<id>.backup`. A competing native config lock
+  or a changed config refuses the update; retry after the other writer finishes.
+  A native policy or unknown refusal also fails closed. Updating an existing
+  entry requires Claude's exact admitted duplicate-name refusal; configuring
+  before CLI installation is supported only when the executable is missing.
 
 ## Query a caller-owned catalog
 
@@ -2272,6 +2284,15 @@ skills mcp --register claude    # Auto-register with Claude Code
 skills mcp --register all       # Register with all supported agents
 ```
 
+Register from the same credential profile you use for the product, for example
+`skills --profile customer setup agents`. Registrations retain that profile and
+any invocation-specific API origin, including
+`skills setup --api-url <origin> agents`, and start `skills-mcp --stdio`. Supported configuration-home overrides
+are retained so the later process resolves the same credential files. Keys,
+sessions and vault values are never copied into agent configuration. With no
+selectors, the MCP process keeps its usual credential resolution. Existing
+credential-to-origin checks still refuse a key bound to a different instance.
+
 ## Skills API
 
 Use a named profile for each independently operated instance. A commercial Skills instance
@@ -2342,6 +2363,8 @@ current version UUID (or `--expect-empty`). Request a code with `auth signup`
 first, then enter it over stdin; do not put verification codes in shell history.
 
 ```sh
+skills --profile customer publication create my-skill --display-name "My skill" \
+  --email you@example.com --code-stdin --confirm --json
 skills --profile customer publication publish ./my-skill \
   --skill-id <skill-uuid> --expect-empty --recovery-dir "$PWD/publication-receipt" \
   --email you@example.com --code-stdin --confirm --json
@@ -2349,6 +2372,22 @@ skills --profile customer publication status --recovery-dir "$PWD/publication-re
   --email you@example.com --code-stdin --json
 ```
 
+`publication create` creates an empty private skill and returns its `id` for
+`publication publish --skill-id`. It requires Pro and fresh interactive session
+verification; an API key cannot create or publish a private skill. Use
+`--visibility team` for a team skill. Slugs use lowercase kebab-case (at most
+128 characters), display names are nonempty (at most 256 characters), and
+descriptions are limited to 8192 UTF-8 bytes. JSON returns only validated IDs,
+the slug, visibility and source type, bound to the selected workspace. Creation
+does not write a recovery directory or save the session. If its result is
+uncertain, run `skills --profile customer info my-skill --remote --json` on
+the same workspace to recover its validated `id`, then use that ID with
+`publication publish --skill-id`. `list --remote --json` also includes server
+UUIDs when supplied. Newly created rows with no category display as `Remote`.
+Do not repeat creation to recover a lost result; the command never retries its
+create POST automatically. The selected profile, origin and credential files
+are captured before code entry; a change during that wait refuses the action.
+
 Without an enrolled named profile, also supply the observed `--user-id` and
 `--membership-id`. `publication resume` and `publication cancel` use the same
 recovery directory, fresh verification, and `--confirm`. The directory must be
@@ -2366,7 +2405,10 @@ server's current boolean capability; it does not authorize an individual run.
 
 The SDK exports `RemotePrivatePublicationsClient` through both the root and
 `./sdk`; `RemoteSkillsAuthClient.openPrivatePublications` creates one from fresh
-workspace verification. The shared `preparePrivatePublication`,
+workspace verification. Call its `createSkill({ slug, displayName, confirm: true })`
+with optional `description` and `visibility` to obtain the validated skill ID.
+`CreatePrivateSkillInput` and `CreatedPrivateSkill` are exported by both entry
+points. The shared `preparePrivatePublication`,
 `continuePrivatePublication`, `inspectPrivatePublication`, and
 `readPrivatePublicationRecovery` functions implement the same durable workflow.
 MCP exposes `publish_private_skill`, `get_private_publication`,
@@ -3318,6 +3360,6 @@ membership too; an executable digest does not prove dynamic backend behavior or
 native adoption. These captures read files and never launch a native consumer.
 
 
-Codex cache witnesses migrate separately through `skills hook rebind-cache --agent codex`. Preview requires the exact current policy and configuration SHA-256 values. Name each reviewed remote app-only parent with `--app-only-parent`; name each already reviewed native `mcp_tool` parent with `--reviewed-hook-parent`. Hook parents require exact enrolled manifest and hook bytes. When the owning installer created a remote-install receipt, its exact schema, identity and bytes are required. A local marketplace install with no receipt is accepted only when the exact full marketplace source is already enrolled and the unchanged Codex settings enable that exact plugin identity. The complete cache census refuses unknown parents, cache-member aliases, new skills, direct hooks selecting cache inputs, and changed app/MCP/hook/receipt or marketplace capabilities. Reviewed whole Codex root aliases keep their existing identity/CAS guards; hook selection through either the alias or canonical cache path is refused. Commands containing the direct `plugins/cache` selector are conservatively refused, including HOME, tilde and relative spellings; no shell evaluation is performed. App-only bootstrap verifies the old full manifest and receipt sources, then explicitly reviews current app capabilities; it does not claim those app bytes were historically witnessed.
+Codex cache witnesses migrate separately through `skills hook rebind-cache --agent codex`. Preview requires the exact current policy and configuration SHA-256 values. Name each reviewed remote app-only parent with `--app-only-parent`; name each already reviewed native `mcp_tool` parent with `--reviewed-hook-parent`. Hook parents require exact enrolled manifest and hook bytes. When the owning installer created a remote-install receipt, its exact schema, identity and bytes are required. A local marketplace install with no receipt is accepted only when the exact full marketplace source is already enrolled and the unchanged Codex settings enable that exact plugin identity. The complete cache census refuses unknown parents, cache-member aliases, new skills, direct hooks selecting cache inputs, and changed app/MCP/hook/receipt or marketplace capabilities. It also refuses every capability location Codex reads in a plugin version root that the witness does not bind (the Agent Plugins root `plugin.json`, `.claude-plugin` and `.cursor-plugin` manifests, a root `hooks.json`, `commands/` and `agents/` directories, and a skill document not spelled exactly `SKILL.md`), compared without regard to case; the vendor-refresh guard reads the same list. A semantic binding captured by an earlier release is checked against this census at every guard run, so one of these paths makes it refuse until a fresh discovery review. Reviewed whole Codex root aliases keep their existing identity/CAS guards; hook selection through either the alias or canonical cache path is refused. Commands containing the direct `plugins/cache` selector are conservatively refused, including HOME, tilde and relative spellings; no shell evaluation is performed. App-only bootstrap verifies the old full manifest and receipt sources, then explicitly reviews current app capabilities; it does not claim those app bytes were historically witnessed.
 
 Review the returned semantic cache digest, then repeat with `--expected-cache-witness-sha256 <digest> --apply`. The owning apply path preserves/readbacks the original policy, recomputes the whole plan, compares policy/config/cache preimages, writes only the Skills policy, and verifies the resulting consumer. Historical directory hashes and source rows remain retained as provenance; this command cannot reconstruct an unavailable old directory tree or waive an ancestor directory containing unrelated inputs. Equivalent version materializations and inert assets then leave the new Codex-specific witness unchanged. Every other discovery source, directory, settings witness, native control and session pin stays under its existing contract. Settings and cache upgrades remain independent; neither silently repairs drift in the other.