dynamic-agent-lifecycle

Documents runner-owned dynamic-agent lifecycle boundaries for orchestrator rolepack history.

3.5k|342|Updated Oct 25, 2025
One-click install
npx skills add https://github.com/bfly123/claude_code_bridge --skill dynamic-agent-lifecycle
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dynamic-agent-lifecycle
Source: https://github.com/bfly123/claude_code_bridge/tree/main/docs/plantree/plans/agentic-loop-workflow/drafts/agentroles.ccb_orchestrator/adapters/ccb/skills/dynamic-agent-lifecycle
Command: npx skills add https://github.com/bfly123/claude_code_bridge --skill dynamic-agent-lifecycle

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It clarifies who owns dynamic-agent lifecycle actions in a CCB multi-agent orchestration setup, preventing provider sessions from mistakenly executing lifecycle commands or editing runtime state.

Core Features & Use Cases

  • Boundary Definition: States that lifecycle changes (add, hide, park, resume, remove, release) are runner-owned, not provider-owned.
  • Provider Restrictions: Lists explicit prohibitions against running CCB commands or editing .ccb runtime files, panes, leases, sockets, and topology files.
  • Reply Contract: Defines the semantic evidence format providers should return, including role requests, blockers, readiness recommendations, and citations.
  • Use Case: When an orchestrator identifies that a helper agent is needed or blocked, this reference ensures the provider replies with evidence only while the supervisor script executes the actual lifecycle commands.

Quick Start

Read this reference to understand which dynamic-agent lifecycle actions are reserved for the runner before responding to orchestration requests.

Frequently Asked Questions about dynamic-agent-lifecycle

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

FAQPage Schema
Who owns dynamic-agent lifecycle actions in CCB orchestration?

The supervisor/runner script owns all dynamic-agent lifecycle actions. The orchestrator may identify that a role is needed, blocked, or ready for release, but the runner performs all lifecycle commands and authority writes.

Can a provider session add or remove agents in CCB?

No. Provider sessions must not add, hide, park, resume, remove, release, or inspect agents. They also cannot run CCB commands or edit .ccb runtime files, panes, leases, sockets, mailbox records, or topology files.

How should a provider reply when lifecycle information is needed?

Reply with semantic evidence only: the requested role or profile and reason, known blockers or missing evidence, a readiness or release recommendation, and citations to the task packet, execution contract, and supplied runtime evidence.

Is this skill active for provider sessions?

No. It is retained as historical reference for the agentroles.ccb_orchestrator rolepack only and is not projected as an active provider skill. It documents boundaries rather than providing executable instructions.