guard-process-birth

Routes Worker process birth through the host-scoped redskilled daemon.

20|2|Updated May 16, 2026
One-click install
npx skills add https://github.com/reddb-io/red-skills --skill guard-process-birth-reddb-io
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: guard-process-birth
Source: https://github.com/reddb-io/red-skills/tree/main/plugins/dev/skills/engineering/guard-process-birth
Command: npx skills add https://github.com/reddb-io/red-skills --skill guard-process-birth-reddb-io

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Per-project runtime code can accidentally spawn Worker processes locally, bypassing host admission, budgets, the host event lane, and every host-facing status surface. This Skill enforces the invariant that only the host-scoped redskilled daemon creates Worker processes when you change runtime source under apps/plugin-dev/src. ## Core Features & Use Cases - Host-Owned Birth Routing: Makes per-project runtime state (argv, workspace, opaque project label) the payload sent to the daemon through the birth port, so only the host creates Workers. - Fail-Closed Behavior: Returns the structured repair from the birth port when the daemon is unavailable instead of falling back to a local spawn. - Ratchet Tracking: Extends HOST_OWNED_BIRTH_SITES with each module's path, former responsibility, and replacement route, keeping removed modules declared with removed: true so renames or resurrections stay observable. - Use Case: While refactoring a per-project module in apps/plugin-dev/src, use this Skill to ensure every Worker request reaches the daemon birth port and host-owns-birth-guard.test.ts passes. ## Quick Start Use the guard-process-birth skill to review my changes under apps/plugin-dev/src and confirm all Worker births route through the redskilled daemon.

Frequently Asked Questions about guard-process-birth

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

FAQPage Schema
How do I route Worker process creation through a host daemon?▼

Make the per-project runtime state the argv, workspace, and opaque project label, then send the request to the redskilled daemon through the birth port. Only the host-scoped daemon creates the Worker process; per-project code never spawns it directly.

What should happen when the redskilled daemon is unavailable?▼

Fail closed by returning the structured repair from the birth port. A local-spawn fallback is not allowed because it bypasses host admission, budgets, the host event lane, and host-facing status surfaces.

Does this invariant apply to helper processes like rsp wait?▼

No, the boundary governs Workers only, not the project's own runtime process or helper processes such as an rsp wait child. Put helper launches in a narrowly named runtime adapter so they cannot become a second Worker-birth route.

How do I migrate a module that currently spawns Workers locally?▼

Stop the module from birthing Workers, then add its path, former responsibility, and replacement route to HOST_OWNED_BIRTH_SITES. Keep removed modules declared with removed: true so a rename or resurrection stays observable.

How do I verify Worker birth is fully host-owned?▼

Done means every Worker request in the touched flow reaches the daemon birth port, no local fallback can create the Worker, and host-owns-birth-guard.test.ts passes. The executable inventory lives in apps/plugin-dev/src/core/host-owns-birth-guard.ts.