public-plugin-packaging

$npx mdskill add agentlas-ai/Agentlas-OS/public-plugin-packaging

Package an Agentlas agent repo for public release or distribution.

  • Separates public OS files from private hosted service code.
  • Depends on scripts/public_safety_check.sh and runtime plugin validators.
  • Decides what to include based on a defined list of required files.
  • Returns release surface, install command, global commands, and blockers.

SKILL.md

.github/skills/public-plugin-packagingView on GitHub ↗
---
name: public-plugin-packaging
description: "Use when packaging an Agentlas agent repo for public GitHub release, Codex plugin submission, Claude adapter distribution, or one-line terminal installation."
---

# Public Plugin Packaging

## Procedure

1. Separate public operating-system files from private hosted service code.
2. Include `README.md`, `LICENSE`, `SECURITY.md`, `AGENTS.md`, `agents/`,
   `skills/`, `.agentlas/global-commands.json`, schemas, templates, install
   scripts, runtime command files, and verification.
3. Keep private research, credentials, raw logs, and local paths out of the
   package.
4. Run `scripts/public_safety_check.sh`.
5. Run runtime-specific plugin validation when available.

## Output

Return release surface, install command, global_commands, validation commands,
and blockers.

More from agentlas-ai/Agentlas-OS

SkillDescription
agent-team-designUse when designing a new multi-agent team, visible agents folder, role boundaries, handoff flow, PM Soul, Memory Curator, Policy Gate, or evaluation role. Use for agent-team repo creation even when the user only says they want a meta-agent or agent operating system.
agentlas-auto-activationUse when adding or auditing local runtime behavior that turns a project folder into an Agentlas-aware workspace with .agentlas memory and sitemap files.
agentlas-core-engine-meta-agentUse 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.
agentlas-packagingUse when converting, repairing, or packaging an existing local or external agent/team into Agentlas architecture for local install, Agentlas import, Codex plugin use, Claude adapter use, or open-source release.
agentlas-security-scanUse when an agent folder must pass the Agentlas Cloud 2-stage security scan (static rules + BYOK LLM judgment) before private sync or public publish, or when asked to run/interpret `hephaestus security scan`.
clarify-question-loopUse when a meta-agent request is too ambiguous to safely generate, package, publish, or adapt without one to five targeted questions.
hephaestus-buildUse 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.
hephaestus-cloudUse 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.
hephaestus-networkUse when the user types /hep-network, mentions @Hephaestus, or asks Agentlas to staff a task from registered Local, owner Cloud, and public Hub agents or teams. The active host LLM is the temporary orchestrator.
hephaestus-stormUse 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 work packet as a verifier-first hardened loop that does not stall, run away, or claim false success. Use it for loop-worthy work — apps, sites, agents, automations, debugging, multi-step research, data/report generation. Trivial questions are answered directly, not stormed.