Generate Custom AI Subagents with Routing Skills

Automates the entire process of creating a new subagent packaged inside a plugin: interviewing the user for the agent's name, purpose, plugin placement, and whether to add a companion routing skill; expanding even a one-line purpose (e.g. "for reviewing code") into a rich, detailed persona covering identity, expertise areas, personality, working style, output format, constraints, and quality standards; scaffolding the correct folder structure under <appDataDir>\config\plugins\<plugin-name>\; and writing the plugin.json, the <agent-name>.md agent file (with YAML frontmatter, the model name, and a mandatory "Prompt Defense Baseline" section copied verbatim), and, if requested, a companion SKILL.md that auto-routes matching user requests to the new subagent. It defaults new agents to a read-only tool set and only grants Bash when the user explicitly asks for command execution and the task genuinely needs it.

Before creating any path, it validates the agent and plugin names against ^[a-z0-9]+(-[a-z0-9]+)*$, rejects path separators, ./.., whitespace, and shell or YAML metacharacters, confirms the resolved path stays under the plugins directory, and stops to ask for a safe replacement rather than silently sanitizing a suspicious name.

Use it whenever a dedicated, isolated "brain" is needed for a specific repetitive task, or when the same large system prompt or constraint set keeps getting pasted into the main chat - a dedicated subagent keeps the main conversation lightweight and focused. It is not for simple tasks a single command or one-line request can already handle - a full subagent there is overkill, and the main thread should just do it directly.

Inputs gathered through a mandatory, step-by-step interview: the agent's name, its purpose (even a single line), which plugin it belongs to (existing or a new <agent-name>-plugin), and whether to generate a companion routing skill.

Output is a complete plugin folder: plugin.json (name, description, version) if a new plugin was created, agents/<agent-name>.md containing YAML frontmatter (name, description, tools, model), the verbatim Prompt Defense Baseline, the full generated persona written in second person, and Expertise / Process / Output Format / Constraints / Quality Checklist sections, plus - if a companion skill was requested - skills/use-<agent-name>/SKILL.md with a trigger table mapping user phrases to delegation decisions. After creation it presents a tree view of everything created, the full agent file for review, instructions for triggering the agent manually or via the companion skill, and an offer to refine the persona or add more agents to the same plugin.

Multiple related agents can share one plugin (e.g. a dev-team-plugin with architect.md, frontend-dev.md, backend-dev.md, and qa-tester.md), with a single routing skill handling delegation across all of them by task type. Subagents created this way do not automatically see the main chat history - a companion skill passes only the specific packaged prompt for that turn - and any specialized tools beyond the default read-only set, such as browser automation or custom APIs, must be explicitly granted in the agent's own file or plugin configuration.

Anyone building out a plugin ecosystem of specialized subagents who wants each one to start with a genuinely detailed, security-conscious persona and a properly registered folder structure - rather than a thin one-line prompt or a manually hand-rolled agents/ directory that's easy to get subtly wrong.