---

name: agent-creator description: 'Create production-grade agent .md files aligned with the current Anthropic subagent contract.

Also validates existing agents against the marketplace compliance rules. Use when building custom

subagents, reviewing agent quality, or creating parallel agent architectures for orchestrator skills.

Trigger with "/agent-creator", "create an agent", "build a subagent", or "validate my agent".

Make sure to use this skill whenever creating agents/*.md files for plugins or standalone use.

' allowed-tools: Read,Write,Edit,Glob,Grep,Bash(python:*),AskUserQuestion,Agent argument-hint: "<create|validate> [agent path or requirements]" version: 5.23.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags:

• agent-creation
• validation
• meta-tooling
• subagents model: inherit effort: high compatibility: Designed for Claude Code

---

Agent Creator

Creates spec-compliant agent .md files following Anthropic's current documented subagent frontmatter contract. Supports both creation of new agents and validation of existing ones.

Overview

Agent Creator fills the gap between ad-hoc agent files and production-grade agents that pass marketplace validation. It distinguishes the 16 fields in Anthropic's public frontmatter table from runtime-recognized experimental options, then layers the stricter Intent Solutions required set on top. It prevents common mistakes (using allowed-tools instead of disallowedTools, adding invalid fields like capabilities or expertise_level), and produces agents with substantive body content that actually guides Claude's behavior.

Key difference from skill-creator: agents support both tools (allowlist) AND disallowedTools (denylist). Skills use allowed-tools (allowlist) and, since schema 3.7.0, an optional kebab-case disallowed-tools denylist — a parallel field, not a unification. Agents also support effort, maxTurns, skills, memory, isolation, permissionMode, background, color, and initialPrompt — fields that don't exist for skills. Claude Code also recognizes a separately labeled runtime experimental object; do not present it as part of the public 16-field table. The agent body becomes the system prompt that drives the subagent — it does NOT receive the full Claude Code system prompt.

Field-naming warning: Agents use camelCase disallowedTools: (canonical sub-agents spec); skills use kebab-case disallowed-tools: (schema 3.7.0+). The validator rejects either mismatch — never copy-paste between agent and skill frontmatter without renaming.

Prerequisites

• Claude Code CLI with agent support
• Target directory writable (agents/ within a plugin or ~/.claude/agents/ for standalone)
• Familiarity with what the agent should specialize in

Instructions

Mode Detection

Determine user intent from their prompt:

• Create mode: "create an agent", "build a subagent", "new agent" -> Step 1
• Validate mode: "validate agent", "check agent", "grade agent" -> Validation Workflow

Step 1: Understand Requirements

Ask the user with AskUserQuestion:

Agent Identity:

• Name (kebab-case, 1-64 chars, e.g., risk-assessor, clause-analyzer)
• Specialty description (20-1536 chars under the IS contract; keep it concise for the selection UI)

Execution Context:

• Plugin agent (plugins/*/agents/) or standalone (~/.claude/agents/)?
• Will it run as the main --agent, or be spawned through the Agent tool?
• May it delegate to nested subagents? If yes, include Agent; if no, omit or deny it.
• Does it need to preload specific skills? (skills: [skill-name])

Behavioral Controls:

• Model override? (sonnet, opus, haiku, fable, inherit, or a full Claude model ID)
• Reasoning effort? (low for simple, medium default, high for complex analysis)
• Max iterations? (maxTurns — how many tool-use loops before stopping)
• Tools to deny? (disallowedTools — denylist approach, opposite of skills)

Plugin Restrictions (if plugin agent):

• hooks — NOT supported in plugin agents (use plugin-level hooks)
• mcpServers — NOT supported in plugin agents
• permissionMode — standalone only, NOT plugin agents

Step 2: Plan the Agent

Before writing, determine:

Agent Role Clarity: The agent body must make three things unambiguous:

1. What it IS responsible for — its specific domain/methodology
2. What it is NOT responsible for — boundaries with other agents
3. How it communicates results — output format and structure

Body Structure Pattern: All production agents should follow this body structure:

| Section | Purpose | Required? | |---------|---------|-----------| | # Title | Agent name as heading | Yes | | ## Role | 2-3 sentence domain description with boundaries | Yes | | ## Inputs | Parameters the agent receives when spawned | Yes (if spawned by orchestrator) | | ## Process | Step-by-step methodology (numbered steps with ### headings) | Yes | | ## Output Format | Structured output spec (JSON, markdown, or table) | Yes | | ## Guidelines | Do/don't behavioral rules | Yes | | ## When Activated | Trigger conditions (when spawned or auto-detected) | Recommended | | ## Communication Style | Tone and formatting preferences | Recommended | | ## Success Criteria | What good vs poor output looks like | Recommended | | ## Examples | Concrete interaction examples | For complex agents |

Output Structure Decision:

• If the agent feeds into an orchestrator: use JSON output (machine-parseable)
• If the agent is user-facing: use markdown output (human-readable)
• If the agent produces both: JSON primary with markdown summary

Step 3: Write the Agent File

Generate the agent .md using the template from ${CLAUDE_SKILL_DIR}/../skill-creator/templates/agent-template.md. Use Write for a new definition and Edit for a targeted remediation of an existing definition; do not replace unrelated project content.

Frontmatter Rules (documented schema plus runtime extension):

See Anthropic Agent Spec for the full official reference.

Upstream-required fields:

name: {agent-name}         # Lowercase letters and hyphens, unique identifier
description: "{specialty}"  # When Claude should delegate to this subagent

For marketplace output, the IS overlay also emits tools, model, color, version, author, tags, disallowedTools, skills, and background. Standalone agents additionally emit hooks, mcpServers, and permissionMode; omit those three from plugin agents. The remaining tuning fields stay optional until the requested behavior needs them.

Marketplace fields and optional tuning controls:

tools: "Read, Glob, Grep"  # Allowlist — inherits all tools if omitted
disallowedTools: [Write]   # IS denylist form — removed from inherited/specified list
model: sonnet              # sonnet|haiku|opus|fable|inherit|full Claude model ID
color: blue                # Display: red|blue|green|yellow|purple|orange|pink|cyan
version: 1.0.0
author: "Name <email@example.com>"
tags: [specialty, workflow]
effort: medium             # low|medium|high|xhigh|max (availability depends on model)
maxTurns: 15               # Max agentic turns before stopping
skills: [skill-name]       # Skills to preload (unlisted skills remain invocable)
memory: project            # user|project|local — persistent cross-session
background: false          # Always run as background task
isolation: worktree        # Run in temporary git worktree
initialPrompt: "..."       # Auto-submitted first turn (--agent mode only)
permissionMode: default    # Also accepts manual as a default alias; ignored in plugins
hooks: {}                  # Standalone only, NOT plugin agents
mcpServers: []             # Standalone only; names or inline definitions
experimental:              # Claude Code v2.1.248+; optional
  cacheTtl: 5m             # 5m|1h

Tool access:

• tools = allowlist (like skills' allowed-tools)
• disallowedTools = denylist (remove specific tools)
• If both set: disallowed applied first, then tools resolved
• If neither set: inherits all tools from parent conversation
• Naming: always emit camelCase disallowedTools on agents. Skills spell their denylist kebab-case (disallowed-tools, schema 3.7.0+) — the validator rejects camelCase on skills and kebab-case on agents, so never copy-paste between the two without renaming

Invalid fields (ERROR — never use these):

• capabilities — looks valid but flagged by validator
• expertise_level — invented, not in Anthropic spec
• activation_priority — invented, not in Anthropic spec
• activation_triggers, type, category — not in spec
• allowed-tools — that's the skill-only syntax; agents use tools or disallowedTools
• disallowed-tools (kebab-case) — skill-only spelling (schema 3.7.0+); agents use camelCase disallowedTools

Body Content Guidelines:

1. Role section must set boundaries. Don't just say what the agent does — say what it does NOT do. Example: "You analyze contract clauses for risk. You do NOT provide legal advice or make recommendations — that is the recommendations agent's responsibility."

2. Process steps must be concrete. Each step should tell Claude exactly what to do, not vaguely gesture at an activity. Bad: "Analyze the document." Good: "Read the full contract. For each clause, extract: (a) the exact text, (b) the clause category from the taxonomy below, (c) a plain English summary in one sentence."

3. Output format must be machine-parseable if feeding an orchestrator. Use JSON with a concrete schema example. Include field descriptions so Claude knows what each field means.

4. Guidelines should include both DO and DON'T rules. Example:

   • DO: "Be specific — quote exact clause text, don't paraphrase"
   • DON'T: "Don't make legal recommendations — only identify and score risks"

5. Keep under 300 lines (agent body limit — prevents context bloat in subagent window). If the agent needs extensive reference material, create a companion skill with references/ directory and preload it via the skills field.

Step 4: Validate the Agent

Run validation against the documented Anthropic schema and the runtime extension allowlist:

Manual checklist:

| Check | Rule | |-------|------| | name present | 1-64 chars, kebab-case | | description present | 20-1536 chars under the IS contract; concise and selection-specific | | No invalid fields | None of: capabilities, expertise_level, activation_priority, type, category | | No skill-only fields | No allowed-tools, no kebab-case disallowed-tools (agents use tools / camelCase disallowedTools) | | Plugin restrictions | No hooks/mcpServers/permissionMode if plugin agent | | Body has Role section | Clear domain + boundaries | | Body has Process section | Numbered steps | | Body has Output Format | Concrete schema example | | Body has Guidelines | Do/don't rules | | Body under 300 lines | Offload to references if longer (prevents context bloat) |

Automated validation:

python3 ${CLAUDE_SKILL_DIR}/../skill-creator/scripts/validate-skill.py --agents-only {plugin-dir}/

Step 5: Test the Agent

Test the agent by spawning it via the Agent tool:

1. Write a test prompt that exercises the agent's core capability
2. Spawn the agent with that prompt
3. Check: Does the output match the declared Output Format?
4. Check: Does the agent stay within its declared Role boundaries?
5. Check: Does it follow the Process steps?
6. Iterate on the body content if the agent strays

Step 6: Report

Provide a summary:

• Agent name and file path
• Documented frontmatter fields used, plus any runtime extension and IS overlay fields used
• Body line count
• Sections present
• Validation result (pass/fail with specific issues)