/team-builder-packaging
Use when generating or auditing a multi-role agent team package with orchestrator, PM Soul, Memory Curator, Policy Gate, workers, eval, QA, handoffs, and runtime adapters.
$ npx -y skills add agentlas-ai/Agentlas-OS --skill team-builder-packaging --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/team-builder-packaging
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when generating or auditing a multi-role agent team package with orchestrator, PM Soul, Memory Curator, Policy Gate, workers, eval, QA, handoffs, and runtime adapters.
SKILL.md
team-builder-packaging.SKILL.mdname: team-builder-packaging
description: "Use when generating or auditing a multi-role agent team package with orchestrator, PM Soul, Memory Curator, Policy Gate, workers, eval, QA, handoffs, and runtime adapters."
Team Builder Packaging
Procedure
1. Start with the orchestrator/HQ. 2. Run `docs/builder-interview-research-gate.md` before writing the roster: ask an 8-12 question first batch, research official sources, similar agent repositories or comparables, academic/professional theory, and plugin docs, compare tool/plugin choices, and write the domain-expert synthesis plus prompt-performance contract. 3. Add PM Soul or project owner. 4. Add Memory Curator and Memory Ticket handoff. 5. Add Policy Gate, eval judge, and QA/evidence gate. 6. Add workers only for real domain ownership proved by interview or research. 7. Add `docs/builder-interview.md`, `docs/research-sources.md`, `docs/tool-selection.md`, `docs/domain-expert-synthesis.md`, `docs/prompt-performance-contract.md`, and `.agentlas/capability-eval-plan.json` unless explicitly creating a minimal private scaffold. 8. Encode handoff and return contracts. 9. Emit one orchestrator/HQ global command in `.agentlas/global-commands.json` and runtime command files. Do not expose worker commands unless requested. 9b. Declare the execution graph in `manifest.json`. This is what the Hub runtime reads to build the team; a package that omits it is published, charged for as a team, and can never be called:
{
"entrypoints": { "orchestrator": "agents/00-orchestrator/agent.md" },
"roster": ["agents/10-<role>/agent.md", "agents/20-<role>/agent.md"]
}Write both keys explicitly. The runtime also accepts older spellings (`entrypoint`, `orchestrator`, `entry`; `workers`, `members`, `team`) and can derive the roster from `agents/<name>/agent.md`, but relying on that leaves the team's shape implicit and it drifts. Note that `entry` in `agentlas.json` is the PACKAGE entrypoint, not the team manager — never reuse it for that. 10. Emit runtime adapters and package verification. 11. Run `scripts/verify-team-package.sh <package-root>` before reporting `completed`. If it fails, do not hand off a result; correct the package by adding an orchestrator/HQ plus company-blueprint topology or by collapsing it to a valid single-agent package.
Output
Return `team_topology`, `nodes`, `edges`, `memory_architecture`, `gates`, `runtime_adapters`, `global_commands`, and `verification`.
Read more
name: team-builder-packaging description: "Use when generating or auditing a multi-role agent team package with orchestrator, PM Soul, Memory Curator, Policy Gate, workers, eval, QA, handoffs, and runtime adapters."
Team Builder Packaging
Procedure
1. Start with the orchestrator/HQ. 2. Run `docs/builder-interview-research-gate.md` before writing the roster: ask an 8-12 question first batch, research official sources, similar agent repositories or comparables, academic/professional theory, and plugin docs, compare tool/plugin choices, and write the domain-expert synthesis plus prompt-performance contract. 3. Add PM Soul or project owner. 4. Add Memory Curator and Memory Ticket handoff. 5. Add Policy Gate, eval judge, and QA/evidence gate. 6. Add workers only for real domain ownership proved by interview or research. 7. Add `docs/builder-interview.md`, `docs/research-sources.md`, `docs/tool-selection.md`, `docs/domain-expert-synthesis.md`, `docs/prompt-performance-contract.md`, and `.agentlas/capability-eval-plan.json` unless explicitly creating a minimal private scaffold. 8. Encode handoff and return contracts. 9. Emit one orchestrator/HQ global command in `.agentlas/global-commands.json` and runtime command files. Do not expose worker commands unless requested. 9b. Declare the execution graph in `manifest.json`. This is what the Hub runtime reads to build the team; a package that omits it is published, charged for as a team, and can never be called:
{
"entrypoints": { "orchestrator": "agents/00-orchestrator/agent.md" },
"roster": ["agents/10-<role>/agent.md", "agents/20-<role>/agent.md"]
}Write both keys explicitly. The runtime also accepts older spellings (`entrypoint`, `orchestrator`, `entry`; `workers`, `members`, `team`) and can derive the roster from `agents/<name>/agent.md`, but relying on that leaves the team's shape implicit and it drifts. Note that `entry` in `agentlas.json` is the PACKAGE entrypoint, not the team manager — never reuse it for that. 10. Emit runtime adapters and package verification. 11. Run `scripts/verify-team-package.sh <package-root>` before reporting `completed`. If it fails, do not hand off a result; correct the package by adding an orchestrator/HQ plus company-blueprint topology or by collapsing it to a valid single-agent package.
Output
Return `team_topology`, `nodes`, `edges`, `memory_architecture`, `gates`, `runtime_adapters`, `global_commands`, and `verification`.
Agent OS: keep specialist agents in a hub, spin up a temporary orchestrator per task. Local-first, works with any model.
Other skills on agentlas-os.
- /agentlas-core-engine-meta-agent
Use when creating a single Agentlas agent, creating a multi-agent team, or packaging an existing local/external agent into Agentlas architecture. Make sure to use this for /meta-agent requests.
Open skill - /hephaestus-build
Use when the user types /prompts:hep-build, mentions @Hephaestus for build work, asks to create a single Agentlas agent, create a multi-agent team, or package an existing local/external agent into Agentlas architecture.
Open skill - /hephaestus-cloud
Use when the user types /hep-cloud or asks to staff from THEIR OWN Agentlas cloud packages only. Cloud is one exact source scope; Network means Local + owner Cloud + public Hub.
Open skill - /hephaestus-network
Use when the user types $hephaestus-network or /hep-network, mentions @Hephaestus, or asks Agentlas to staff a durable goal from registered Local, owner Cloud, and public Hub agents or teams. The active host LLM staffs each turn; the exact roster remains goal-bound until
Open skill - /hephaestus-storm
Use when the user types /hep-storm, says @Hephaestus storm <goal>, or asks to drive a goal to verified completion through a force-robust Stormbreaker loop. Stormbreaker routes the goal to real Agentlas specialists, materializes a dependency-ordered pipeline fabric, and runs each
Open skill - /hephaestus-upload
Use when the user types $hephaestus-upload or /hep-upload, or asks to upload, publish, or list an Agentlas agent or team. Ask Cloud (private) vs Agentlas Hub (public) FIRST, then publish through the bundled Hephaestus gate.
Open skill

