Agent skill

Orchestrator Container Spawn

by samugit83 in samugit83/redamon

Spawning and hardening scan containers from the recon orchestrator: the security flags that look correct and break the container, and the sibling bind-mount path handling.

MITAuto-check passedSecurity

Install Orchestrator Container Spawn

skills CLI
$ npx skills add samugit83/redamon --skill orchestrator-container-spawn -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install samugit83/redamon orchestrator-container-spawn --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/samugit83/redamon.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/orchestrator-container-spawn .claude/skills/orchestrator-container-spawn && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
orchestrator-container-spawn
GitHub stars
3k
Token cost
~1.7k tokens
SKILL.md length
688 words
Files
1
Skills in repo
15
Repo updated
First seen
Licence
MIT

At a glance

Spawning and hardening scan containers from the recon orchestrator: the security flags that look correct and break the container, and the sibling bind-mount path handling.

  • Tasks that involve Penetration testing
  • SKILL.md covers When to Use, Critical Rules, Why these flags break here and Commands, plus 1 more section
  • Calls docker
  • Tasks that involve Bug bounty

What it does

Orchestrator Container Spawn is an agent skill from samugit83/redamon. Spawning and hardening scan containers from the recon orchestrator: the security flags that look correct and break the container, and the sibling bind-mount path handling. capdrop and no-new-privileges were each reverted after breaking real scans. Trigger: editing reconorchestrator/containermanager.py; changing how a scan container is spawned or hardened; touching scannerhardening, siblinghostpath, capdrop, securityopt, or a bind mount for a spawned container.

Its SKILL.md is about 1.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Security, covering Penetration testing and Bug bounty. The repository describes itself as: Open-source, self-hosted AI penetration testing framework: maps your attack surface into a graph, autonomously exploits it from a Kali sandbox with human approval gates, and… The licence is MIT.

When your agent uses it

  • Tasks that involve Penetration testing
  • Tasks that involve Bug bounty

Example prompts

  • “/orchestrator-container-spawn”

Requirements

  • Docker

What it can do on your machine

Read from SKILL.md and the folder at commit d90c940. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • docker

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use docker, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Orchestrator Container Spawn loads about 1.7k tokens when it runs. Until then it costs about 126 tokens; SKILL.md has 688 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~126
When it runs · the whole SKILL.md, loaded when a task matches
~1.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from samugit83/redamon at commit d90c940, republished under its MIT licence (© samugit83). 688 words, ~1,690 tokens.

Download SKILL.mdSave it as .claude/skills/orchestrator-container-spawn/SKILL.md (or your agent's skills folder).
name
orchestrator-container-spawn
description
Spawning and hardening scan containers from the recon orchestrator: the security flags that look correct and break the container, and the sibling bind-mount path handling. cap_drop and no-new-privileges were each reverted after breaking real scans. Trigger: editing recon_orchestrator/container_manager.py; changing how a scan container is spawned or hardened; touching _scanner_hardening, sibling_host_path, cap_drop, security_opt, or a bind mount for a spawned container.
license
MIT
metadata.author
redamon
metadata.version
1.0.0
metadata.scope
recon_orchestrator
metadata.auto_invoke
Spawning or hardening a scan container from the orchestrator, Editing container_manager.py bind mounts or security options

When to Use

For the no-env_file knob rule, see the recon_orchestrator AGENTS.md CRITICAL RULES (not repeated here).


Critical Rules

  • NEVER add cap_drop: [ALL] to a scan container that writes to a host-owned source bind mount. It strips CAP_DAC_OVERRIDE, so root-in-container can no longer write the host-owned files, and the scan breaks. This was reverted after breaking recon/partial spawns; hardening is deliberately deferred with drop_caps=False at every spawn site (container_manager.py:837, :1798, :2168). Keep it deferred unless the mount is not host-owned.
  • NEVER add security_opt: no-new-privileges to these spawns. It breaks execve for non-root users inside the recon image (reverted once already): container_manager.py:939.
  • NEVER add a tmpfs mount without uid/gid/mode when the container runs as a NON-ROOT user and the mount lands on a path that user must write. Docker mounts a tmpfs root-owned 0755 unless told otherwise (only /tmp gets the 1777 default), and the mount SHADOWS whatever the image built at that path - so a tmpfs added to give a non-root user writable scratch is what takes it away. This shipped: the TruffleHog spawn's /home/trufflehog tmpfs hid the home dir useradd --create-home had given uid 10001, and github_experimental died on "failed to create .trufflehog folder in user's home directory" while the other thirteen sources were fine, because it is the only one that writes to $HOME. Build the spec in _trufflehog_tmpfs(), not inline, and size-cap every entry - an uncapped tmpfs is host RAM a hostile archive can exhaust.
  • ALWAYS apply hardening through _scanner_hardening() (container_manager.py:567), not ad-hoc per spawn, so all three spawn sites stay consistent.
  • **ALWAYS keep sibling_host_path() robust to BOTH POSIX (/) and Windows (\) host paths** (container_manager.py:53). It derives a sibling source dir's host path for bind mounts; a POSIX-only assumption breaks spawns on Windows hosts. Its two companions parent_host_path() and join_host_path() carry the same POSIX+Windows discipline - never swap in pathlib / Path(...).parent, which collapses a Windows host path on the Linux orchestrator.
  • NEVER assume a scanner source dir is a repo-root sibling. Scanners live two levels deep under scanners/<name>/, so a bind mount to a repo-root sibling (e.g. graph_db) must climb out of scanners/ first: sibling_host_path(parent_host_path(scanner_path), "graph_db"), and a scanners/-nested sibling is reached with join_host_path(parent_host_path(recon_path), "scanners", "supply_chain_common"). The old sibling_host_path(scanner_path, "graph_db") now resolves to a nonexistent scanners/graph_db; Docker silently binds an empty root-owned dir there and graph writes / imports fail with no error. The build context climbs two parents: parent_host_path(parent_host_path(scanner_path)).
  • NEVER bind /app/graph_db directly at a spawn site. Always route it through self._graph_db_mount(<derived>, baked_into_image=...) (container_manager.py:605). Deriving graph_db's host path is a LAST RESORT, not the mechanism: the real path is auto-detected from the orchestrator's own ./graph_db:/app/graph_db:ro mount (GRAPH_DB_PATH, resolved in api.py exactly like RECON_PATH). The derivation is only right when Docker reports the literal repo path - Docker Desktop on Windows/WSL2 reports rewritten bind Source strings whose sibling is nowhere, Docker auto-creates that path EMPTY, and the empty dir shadows the graph_db baked into the scan image. Every spawned scan then dies with cannot import name 'Neo4jClient' from 'graph_db' (unknown location) (issue #169). baked_into_image=True for recon / gvm / github-hunt (they COPY graph_db, so no mount beats a wrong mount); False only for supply-chain, which does not bake it. TruffleHog has NO graph_db mount at all: its container is the dirty half of a dirty/clean split and holds no Neo4j credentials, so the orchestrator ingests its findings afterwards.
  • ALWAYS resolve a new host source path with _get_host_path() + a compose mount, not by string surgery on another path. If a spawn needs host dir X, mount X into the orchestrator so Docker itself reports its source. A missing bind source is not an error to Docker; it silently becomes an empty directory.
Show full SKILL.md (79 more words)Show less

Why these flags break here

Scan containers run as root and bind-mount host-owned source (the live working tree) so a .py change is picked up without a rebuild. Standard container hardening (drop all caps, no-new-privileges) assumes the container owns its filesystem and runs unprivileged - neither holds here, so the "secure defaults" a reviewer would add are exactly what broke production twice.

Commands

bash
docker compose restart recon-orchestrator     # container_manager.py is volume-mounted
./redamon.sh test unit                        # recon_orchestrator section

Resources

© samugit83, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/orchestrator-container-spawn of samugit83/redamon.

Open the folder on GitHubat commit d90c940

Compare with similar skills

Orchestrator Container Spawn next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Orchestrator Container Spawn compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Orchestrator Container Spawn this skillsamugit83/redamon3k—~1.7kAutomated safety check: PassMIT
Metabigor OSINT Reconj3ssie/metabigor1.9k—~2.4kAutomated safety check: PassMIT
Wooyun Legacytanweai/wooyun-legacy1.8k—~1.9kAutomated safety check: PassCustom licence
Client Request Signature Reversalawarexone/Agentic-Bug-Hunter5.3k—~4.7kAutomated safety check: PassMIT
Web3 Bug Bounty AI Toolstradecatlabs/vibe-coding-cn17k2 repos~3.9kAutomated safety check: WarnMIT
Bug Bounty Campaign DriverEncod3d-Sec/TORCH3291 repos~1.8kAutomated safety check: PassMIT

Similar skills

  • Metabigor OSINT Recon

    j3ssie/metabigor

    Operates the metabigor CLI to map a target's network ranges, subdomains, ports, related domains, CDNs and archived URLs from free sources without API keys.

    1.9k GitHub stars~2.4k tokensUpdated 2 mo ago
    SecurityAuto-check passed
  • Wooyun Legacy

    tanweai/wooyun-legacy

    WooYun business logic vulnerability methodology — 22,132 real cases across 6 domains (authentication bypass, authorization bypass, payment tampering, information disclosure, logic flaws…

    1.8k GitHub stars~1.9k tokensUpdated 2 mo ago
    SecurityAuto-check passed
  • Client Request Signature Reversal

    awarexone/Agentic-Bug-Hunter

    Recovers a client-side request signature or anti-bot token just far enough to replay blocked requests in bug bounty testing, starting from a captured packet.

    5.3k GitHub stars~4.7k tokensUpdated 3 days ago
    SecurityAuto-check passed
  • Web3 Bug Bounty AI Tools

    tradecatlabs/vibe-coding-cn

    A selection guide to AI-driven tools for Web3 bug bounty work, from autonomous web pentesters to smart contract bug finders, with notes on authorization.

    17k GitHub starsUsed in 2 repos~3.9k tokens
    SecurityAuto-check: warnings
  • Runs a bug-bounty engagement through a script that tracks the current pass, builds a board of rows from recon and prints the next required action each turn.

    329 GitHub starsUsed in 1 repo~1.8k tokens
    SecurityAuto-check passed
  • Adaptive Web Fuzzing

    Encod3d-Sec/TORCH

    Adaptive web fuzzing for pentests, bug bounty and CTF work: picks the smallest suitable SecLists wordlist per target surface and calibrates filters against soft-404 responses.

    329 GitHub starsUsed in 1 repo~1.3k tokens
    SecurityAuto-check passed

More from samugit83/redamon

All 15 skills in this repo
  • Add Community Skill

    samugit83/redamon

    Adding a Community Agent Skill: a Markdown attack-workflow file that users import from the catalog, which then competes in the Intent Router and is injected into the agent's system prompt.

    3k GitHub stars~775 tokensUpdated yesterday
    Auto-check passed
  • Add Partial Recon

    samugit83/redamon

    Adding partial-recon support for a tool: running a single pipeline phase on demand from the workflow graph, reading its inputs from the existing Neo4j graph and merging results back.

    3k GitHub stars~1.1k tokensUpdated yesterday
    Auto-check passed
  • Agentic Tool Integration

    samugit83/redamon

    Wiring a new tool the AI agent can call (not the recon pipeline): the tool registry, the phase map, the hardcoded dispatch chokepoint, and the duplicated execution paths that make a tool work in…

    3k GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed
  • Builtin Agent Skill

    samugit83/redamon

    Adding a built-in Agent Skill (an attack technique like ssrf, xxe, rce) that ships hardcoded in RedAmon: classified by the Intent Router, injected into the agent prompt, toggled per project, badged…

    3k GitHub stars~1.4k tokensUpdated yesterday
    Auto-check passed
  • Graph DB Writes

    samugit83/redamon

    Writing to the Neo4j attack-surface graph in RedAmon: the tenant-isolation MERGE key every entity node must carry, where graph methods live (mixins, not the client), and the schema places that must…

    3k GitHub stars~2.2k tokensUpdated yesterday
    Auto-check passed
  • LLM Provider Integration

    samugit83/redamon

    Adding an LLM provider to RedAmon: the credential boundary (keys must never reach scan containers), prefix-routed model ids, and the provider registry.

    3k GitHub stars~1.1k tokensUpdated yesterday
    Auto-check passed

Categories

Questions about Orchestrator Container Spawn

What does Orchestrator Container Spawn do?

Spawning and hardening scan containers from the recon orchestrator: the security flags that look correct and break the container, and the sibling bind-mount path handling. Orchestrator Container Spawn is an agent skill from samugit83/redamon. Spawning and hardening scan containers from the recon orchestrator: the security flags that look correct and break the container, and the sibling bind-mount path handling.

When should I use Orchestrator Container Spawn?

Orchestrator Container Spawn fits situations like: tasks that involve Penetration testing; tasks that involve Bug bounty.

How do I install Orchestrator Container Spawn in Claude Code?

Run `npx skills add samugit83/redamon --skill orchestrator-container-spawn -a claude-code`. Or copy the skill folder (skills/orchestrator-container-spawn in samugit83/redamon) into .claude/skills/orchestrator-container-spawn in your project. Claude Code loads it when a task matches its description.

How do I install Orchestrator Container Spawn in Codex?

Run `npx skills add samugit83/redamon --skill orchestrator-container-spawn -a codex`. Or copy the skill folder (skills/orchestrator-container-spawn in samugit83/redamon) into .agents/skills/orchestrator-container-spawn in your project. Codex loads it when a task matches its description.

Can I use Orchestrator Container Spawn in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add samugit83/redamon --skill orchestrator-container-spawn -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/orchestrator-container-spawn, .gemini/skills/orchestrator-container-spawn, .github/skills/orchestrator-container-spawn and .opencode/skills/orchestrator-container-spawn in your project.

What does Orchestrator Container Spawn need to run?

Going by SKILL.md and its folder, Orchestrator Container Spawn needs the command-line tools its instructions call (docker). Our summary lists: Docker.

Does Orchestrator Container Spawn access the network?

SKILL.md contains no URLs. Its commands use docker, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Orchestrator Container Spawn safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Orchestrator Container Spawn use?

Orchestrator Container Spawn is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Orchestrator Container Spawn use?

About 1.7k tokens (SKILL.md is roughly 6.8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Orchestrator Container Spawn?

Skills that share tags, products or a category with Orchestrator Container Spawn: Metabigor OSINT Recon (j3ssie/metabigor, 1.9k stars), Wooyun Legacy (tanweai/wooyun-legacy, 1.8k stars), Client Request Signature Reversal (awarexone/Agentic-Bug-Hunter, 5.3k stars) and Web3 Bug Bounty AI Tools (tradecatlabs/vibe-coding-cn, 17k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Orchestrator Container Spawn?

samugit83 (a GitHub user) maintains it in samugit83/redamon, which has 2,961 GitHub stars. The repository holds 15 skills in this directory. The repository was last updated on October 7, 2026.

Source: samugit83/redamon on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.