forge-delegate

Delegate Forge phase implementation to a chosen runtime while preserving phase ownership.

6|3|Updated Mar 31, 2026
One-click install
npx skills add https://github.com/alo-exp/silver-bullet --skill forge-delegate
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: forge-delegate
Source: https://github.com/alo-exp/silver-bullet/tree/main/forge/skills/forge-delegate
Command: npx skills add https://github.com/alo-exp/silver-bullet --skill forge-delegate

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The Forge runtime often holds exclusive ownership over a phase, which can create bottlenecks and rigidity. This skill enables delegating the current phase's implementation work from the Forge runtime to another runtime (Claude-SB, Codex-SB, OpenCode-SB, or a sibling Forge) under the parent's existing phase-lock, then integrates the child results back into the parent phase artifacts.

Core Features & Use Cases

  • Cross-runtime phase delegation: transfer execution responsibilities to a target runtime while preserving the parent phase context.
  • Inherited lock semantics: spawn and run the child with SB_PHASE_LOCK_INHERITED=true to avoid double-claiming the phase.
  • Result integration: parse and merge the child runtime's output into the parent's phase summary, preserving provenance and state.

Quick Start

Provide the target runtime to delegate to and initiate the delegation workflow from the Forge.

Frequently Asked Questions about forge-delegate

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

FAQPage Schema
How do I delegate a Forge phase to another runtime without losing the parent phase context?

Phase delegation transfers execution to a target runtime like Claude-SB, Codex-SB, or OpenCode-SB while preserving the parent's phase-lock and context. It solves bottlenecks by allowing another runtime to implement the phase without double-claiming ownership.

Can I hand off a Forge phase to Claude-SB or Codex-SB under an existing phase-lock?

Yes, you can hand off Forge phase execution to Claude-SB, Codex-SB, OpenCode-SB, or a sibling Forge. The child runtime inherits the phase-lock to prevent double-claiming and operates within the parent's established phase context.

How do I merge child runtime results back into a parent Forge phase summary?

After child runtime execution completes, the delegation workflow parses the child's output and merges the FILES_CHANGED, ASSUMPTIONS, and REQ-IDS sections directly back into the parent's phase summary artifacts, preserving full provenance and state.

What does SB_PHASE_LOCK_INHERITED do when spawning a child runtime in Forge?

SB_PHASE_LOCK_INHERITED is a flag set to true when spawning a child runtime to ensure the child inherits the parent's phase-lock semantics. This prevents concurrent double-claiming of the phase while allowing the child to execute the implementation work.

When should I use multi-runtime phase delegation instead of executing directly in the Forge runtime?

Multi-runtime phase delegation is ideal when the Forge runtime's exclusive phase ownership creates execution bottlenecks or rigidity. Delegating to a specialized runtime like Codex-SB or OpenCode-SB allows parallelized or context-specific implementation while preserving the parent phase state.