Skip to main content

​
Overview

skill_runtime_tools now focus on administrative, self-add, and legacy inspection flows for AgentSkills packages. Skill packages can include shell steps, but Genesis refuses to run those steps when hosted as a Databricks App. They would otherwise run unconfined as the App user with the server’s environment and credentials. This refusal applies even when the skill policy allows shell execution; the command is not run. On deployments where Genesis runs as root and the image provides the restricted cortex_sandbox user (Snowflake, EKS and self-hosted Docker), shell steps run as cortex_sandbox, the same user execute_python_code runs as. A step then gets no server credentials: its environment holds only PATH, locale and TLS trust-store settings (no proxy settings), its own HOME, TMPDIR, USER and SHELL, and the SKILL_ARG_* values described below. In the Genesis image it cannot read the Genesis installation, its configuration or its storage. All shell steps of one execution run in the same new working directory, which they can write and which is deleted when the execution finishes; relative paths resolve there, so keep files a skill must keep in a repository it commits to, not in that directory. Where Genesis cannot switch users (Genesis Desktop, a local development server, or any server not running as root), shell steps run as before, as the server’s own user with its environment and working directory. On every deployment, the processes a shell step starts stop when the step ends. When the step’s command exits, or is stopped at its timeout, every process it started that is still in its session (command &, nohup command &, and jobs moved to their own process group) is sent SIGTERM, given one second to exit, and then killed. So a background server started in one step is not available to later steps or after the skill finishes. On Linux this includes a process that leaves the session with setsid or detaches itself with a double fork, as a daemon does: the step runs under a small supervisor that adopts such processes and stops them with the rest. Only processes the step started are stopped, never other processes of the same user. On macOS (Genesis Desktop) a process that leaves the session with setsid is not stopped. When a shell-step command uses a ${key} placeholder supplied by the execution payload, Genesis passes that value as the SKILL_ARG_key environment variable and puts a variable reference in the command instead of inserting the value into shell text. The reference is double-quoted unless the author’s own double quotes already enclose the placeholder; in that case Genesis leaves the reference unquoted so it remains one quoted word and is not subject to word splitting or globbing. If the payload key is missing or null, ${key:-default} inserts the skill author’s default (or an empty string when there is no default). This protects the shell parsing the command, but commands that pass the expanded value to another evaluator such as sh -c or eval still allow that evaluator to parse it as input. Executing a skill through the API requires manage_skills; see the API reference. When those self-add flows create or approve a skill package, Genesis now stores it in the same managed agent_skills Git repository used by imported skills, so runtime inspection and follow-on editing see one unified package source. Actual Genesis Skills page showing importable skills and assign-to-agent actions.

​
What moved to context_tools

For normal agent work, assigned-skill discovery and file reading now happen through the always-on context_tools group:
  • activate a skill with manage_context,
  • read SKILL.md with read_assigned_skill_file (including description fallback for registry-only skills without bundled package files),
  • browse bundled files with list_assigned_skill_files.

​
What remains in skill_runtime_tools

  • self-add and governance workflows,
  • approval and request management,
  • legacy/debug inspection such as get_assigned_skill_spec.
Genesis checks self-added package ownership from the package metadata rather than from a legacy storage path, so migrated self-added skills in the shared agent_skills Git repository still follow the same owner-only update and removal rules.

​
Primary tool surfaces

​
register_uploaded_skill_to_self

Register an uploaded .zip or .md file as an AgentSkill for the current bot, subject to that bot’s self-add policy (allow, deny, or require_approval).
When inspecting a .zip upload, Genesis ignores editor and OS housekeeping paths instead of rejecting the package: directories .history, .git, __MACOSX, and .ipynb_checkpoints; files .DS_Store and Thumbs.db; and names ending in .swp, .swo, or ~. Those entries are not included in the registered package.

​
remove_self_added_agentskill

Use remove_self_added_agentskill when a bot needs to delete one of its own self-added AgentSkills packages. Example
On success, the response includes removed_from_registry, removed_from_disk, and cleared_assignment so you can confirm whether the package was unassigned, unregistered, and deleted from disk. Self-add create, update, and remove flows write through the same AgentSkill source registry as imported packages. Each mutation marks the capability registry dirty so skill discovery and default-policy checks pick up the change on the next reconcile (typically within seconds).