add-shared-runtime

Registers and prepares shared runtime workspaces for project task silos.

1|Updated Jul 3, 2026
One-click install
npx skills add https://github.com/Ryokuman/new_human_ochestrator --skill add-shared-runtime-ryokuman
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: add-shared-runtime
Source: https://github.com/Ryokuman/new_human_ochestrator/tree/main/system/20-skills/add-shared-runtime
Command: npx skills add https://github.com/Ryokuman/new_human_ochestrator --skill add-shared-runtime-ryokuman

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Task silos often need the same backend, frontend, worker, or mock services running, and cloning them repeatedly per task wastes effort and causes port or branch conflicts. This Skill standardizes how project-level shared runtime sets are registered, prepared, and referenced across silos. ## Core Features & Use Cases - Runtime Registry Management: Defines a structured registry schema with fields like project_id, runtime_kind, workspace_path, branch, commit, ports, and health_check for long-lived runtime checkouts. - Layered Governance: Separates 0-tier system rules, 1-tier project registry values, and 3-tier silo-local runtime references so secrets and project data never leak into the system layer. - Health Check & Safety Gates: Verifies dirty state, running processes, and port conflicts before preparing checkouts, and records structured health check results. - Use Case: A project needs a shared backend and DB emulator that five task silos reference. Use this Skill to register the runtime set, prepare it under shared-runtime/<project-id>/, and record branch, commit, and health check results for each silo's goal.md. ## Quick Start Ask the agent to register a shared backend runtime for your project and prepare its workspace checkout with branch, commit, and health check recorded.

Frequently Asked Questions about add-shared-runtime

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I set up a shared runtime for multiple task silos?

Register the runtime in the project registry with fields like project_id, runtime_name, workspace_path, branch, and commit, then prepare the checkout under shared-runtime/<project-id>/<runtime-name>/. Each task silo references it in goal.md rather than cloning its own copy.

What is a shared runtime set in a multi-silo workflow?

A shared runtime set is a group of long-lived checkouts such as backend, frontend, worker, DB emulator, or service mocks that several task silos reference together. It avoids per-task cloning and keeps branch, commit, and port information consistent.

Can I store secrets or tokens in the runtime registry?

No. The registry, status files, goal.md, and PR bodies must never contain secrets, tokens, passwords, or credentials. Only record env file paths or secret provider policies, keeping actual values in gitignored local config.

How are health checks handled for shared runtimes?

Server-type runtimes set requires_health_check to true and record a structured health_check object with command, url, expected result, timeout, and on_fail behavior. If skipped, a skipped_reason is recorded instead.

What happens if a shared runtime itself needs modification?

Runtime changes must not be mixed into the current task PR or made on protected branches. They are split into a separate task, branch, and PR so the referencing silos stay unaffected.