superloop-worker-agent
Standardizes agent-to-agent task delegation with strict scope and evidence reporting.
Install
mkdir -p .claude/skills/superloop-worker-agent && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12864" && unzip -o skill.zip -d .claude/skills/superloop-worker-agent && rm skill.zipInstalls to .claude/skills/superloop-worker-agent
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Symbolic leased ContextForge worker protocol for worker, reviewer, researcher, verifier, or Spark evidence/scaffold tasks under a primary controller. Use when Codex has a bounded work unit with controller lease, dispatch card, Agent owner value, allowed files/tools, stop condition, and reporting contract.Key capabilities
- →Read worker formal goal and lease
- →Confirm dispatch-card compliance
- →Preserve execution environment and changes
- →Report outcome and evidence to controller
- →Inspect only allowed files and tools
- →Define local acceptance criteria
How it works
This skill defines a protocol for a worker agent operating under a primary controller, ensuring the worker adheres to a formal goal, lease, and dispatch card, and reports its progress and outcome.
Inputs & outputs
When to use superloop-worker-agent
- →Assign agent subtask
- →Verify worker evidence
- →Delegate research tasks
- →Check agent lease
About this skill
SuperLoop Worker Agent
Read ../SHARED_SYMBOL_SCHEME.md. WK owns one L; SO owns sequencing,
integration, GitHub mutation, final acceptance, and successor-goal selection.
Inner Scheme
WF= worker formal goal.WI= worker identity.DC✓= dispatch-card compliance.WA= worker authority.LC= lease checks.WR= worker report.ST= stop condition.
Worker Formal Goal
WF:
worker G ≠ controller G
worker G = lease-scoped {T, DC, allowed actions, forbidden actions,
E plan, stop, report contract}
Startup:
read(WF) →
read(L) →
confirm(WF ⋈ L) →
confirm(DC present ∧ DC matches T) →
confirm(GP.Agent owner/state match assignment) ∨ stop(report mismatch)
Maintenance:
preserve {E, changed files, non-actions, risk, DC status, branch/worktree}
→ report(SO)
complete(WF) ⇔ stop_condition reached ∧ report delivered
successor WF only if SO/L authorizes same bounded scope
Prohibition:
WK ✗ {expand scope, claim global completion, close SO goal, bypass SO}
Worker Identity
WI:
worker = codex-agent:<agent-id>
child = codex-agent:<parent-agent-id>/<child-agent-id>
controller = codex-thread:<thread-id>
L must include {agent_run_id, controller_run_id, role, assigned_scope, DC, lease_state}
missing identity fields → request L before nontrivial work
report exact worker ID from L/dispatcher
✗ rotating nickname, other agent ID, stale copied ID
if runtime lacks ID → lease_id_unavailable(<observed id/source>)
✗ unknown without observed identifier
Dispatch Card Checks
DC✓:
require {task_class, risk_layer, exercised_surface, write_scope}
require observable {selected_model, reasoning_effort, agent_type, fork_context}
require concrete verification_available
require forbidden_actions
require acceptance_owner=controller
selected_model unsuitable for encountered T → stop(report mismatch)
Spark worker:
if M=Sp:
optimize exact bounded E + small mechanical transformations
Sp ✗ {architecture, target-client V judgment, readiness, governance,
runtime, GH, approval, registry, security decisions}
semantic/authority need → stop(report boundary)
Semantic boundary:
SEM claims require non-deterministic evaluator judgment.
WK ✗ use matched strings, regexes, keyword searches, or string parsing as the
oracle for free-form model/user-visible prose meaning, quality, readiness, or
semantic pass/fail. Deterministic checks may verify structure only; structured
JSON meaning still needs evaluator review when meaning matters.
Worker Loop
WK loop:
reread(WF, L) →
refresh E for assigned scope →
inspect only allowed files/systems/tools/docs/tests/GH →
define local acceptance inside L →
execute bounded T →
verify via commands/probes/readbacks/file E →
report {outcome, DC✓, E, changed files, non-actions, risk} →
stop at {integration, authority, approval, scope}
Worker Authority
WK may own {
one assigned issue/validation/audit/implementation/evidence T,
local E refresh,
local planning inside L,
focused code/docs/tests/probes when allowed,
status report
}
WK may request {
clarification,
narrowed/expanded scope,
child research/verification permission,
handoff at external decision/approval boundary
}
WK ✗ own {
final project claims,
roadmap direction outside L,
issue closure,
PR create/push/merge/promote,
GP global coordination beyond item L,
global config mutation,
runtime/service/Docker/process/systemd/registry/hook/secret/OAuth/trust-token,
Pi/global client mutation,
helper project-init apply/recovery,
Serena/destructive actions,
governance ledger mutation,
reassignment of agents
}
L asking approval-gated/controller-owned action → stop(report conflict)
L ∉ substitute for active explicit user approval
Lease Checks
LC before work:
controller_run_id ∧ agent_run_id present
GP.Agent owner matches WK ID ∨ L explicitly grants work
GP.Agent state ∈ {Active, Ready, Blocked, In Review} as allowed by SO
DC present
allowed files/systems/tools explicit
forbidden actions explicit
child delegation stance explicit
expected artifact + stop concrete
L ⊥ current GP/repo state → stop(report mismatch)
Child Delegation
child spawn ⇔ L permits
child owns one narrow {research, verification, audit, log-parse}
WK integrates child E before report
child output ∉ final claim
Reporting Template
WR := {
agent_run_id: codex-agent:<lease-or-dispatcher-id> |
lease_id_unavailable(<observed id/source>),
controller_run_id,
assigned_scope,
lease_state,
dispatch_card: {
task_class,
selected_model,
reasoning_effort,
agent_type,
fork_context,
acceptance_owner
},
branch/worktree,
changed files,
evidence,
non-actions,
residual risk,
stop condition reached,
requested controller action
}
Report exact command outputs or file references. Distinguish verified fact from inference. State clearly when no files changed.
Stop Conditions
ST if:
L complete ∨ required E fails ∨ repo/GH contradicts L
∨ another A owns same item
∨ selected M unsuitable for T
∨ authority boundary reached
∨ approval-gated/runtime/destructive/global/shared-system action required
∨ local success would need global ✓
Fidelity: preserves worker formal goal, identity, dispatch-card checks, authority limits, lease checks, child delegation, report template, and stop conditions.
When not to use it
- →When expanding scope beyond the lease
- →When claiming global completion
- →When closing the controller's goal directly
Limitations
- →Worker cannot expand its own scope
- →Worker cannot claim global completion
- →Worker cannot close the controller's goal
How it compares
This workflow establishes a strict hierarchical control and reporting structure for sub-agents, explicitly prohibiting actions outside their leased scope, unlike an autonomous agent with broader permissions.
Compared to similar skills
superloop-worker-agent side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| superloop-worker-agent (this skill) | 0 | 1mo | No flags | Advanced |
| opencode-cli | 14 | 7mo | Review | Advanced |
| claude-automation-recommender | 47 | 2mo | Review | Beginner |
| mcp-integration | 21 | 9mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by somebloke1
View all by somebloke1 →You might also like
opencode-cli
SpillwaveSolutions
This skill should be used when configuring or using the OpenCode CLI for headless LLM automation. Use when the user asks to "configure opencode", "use opencode cli", "set up opencode", "opencode run command", "opencode model selection", "opencode providers", "opencode vertex ai", "opencode mcp servers", "opencode ollama", "opencode local models", "opencode deepseek", "opencode kimi", "opencode mistral", "fallback cli tool", or "headless llm cli". Covers command syntax, provider configuration, Vertex AI setup, MCP servers, local models, cloud providers, and subprocess integration patterns.
claude-automation-recommender
anthropics
Analyze a codebase and recommend Claude Code automations (hooks, subagents, skills, plugins, MCP servers). Use when user asks for automation recommendations, wants to optimize their Claude Code setup, mentions improving Claude Code workflows, asks how to first set up Claude Code for a project, or wants to know what Claude Code features they should use.
mcp-integration
anthropics
This skill should be used when the user asks to "add MCP server", "integrate MCP", "configure MCP in plugin", "use .mcp.json", "set up Model Context Protocol", "connect external service", mentions "${CLAUDE_PLUGIN_ROOT} with MCP", or discusses MCP server types (SSE, stdio, HTTP, WebSocket). Provides comprehensive guidance for integrating Model Context Protocol servers into Claude Code plugins for external tool and service integration.
hook-development
anthropics
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.
agent-factory
alirezarezvani
Claude Code agent generation system that creates custom agents and sub-agents with enhanced YAML frontmatter, tool access patterns, and MCP integration support following proven production patterns
swarm-advanced
ruvnet
Advanced swarm orchestration patterns for research, development, testing, and complex distributed workflows