name: agent-creator description: "Scaffold vexjoy-agent operator .md files: frontmatter, routing block, operator context, reference loading table, phase/gate workflow." routing: triggers: - create agent - new agent - scaffold agent - agent template - build agent - agent design - make agent force_route: true not_for: "creating real estate agents, ML agents, OS agents (e.g. SNMP), travel agents, customer service agents — only for vexjoy-agent .md operator files" pairs_with: - skill-creator - agent-evaluation complexity: Medium category: meta allowed-tools:
- Read
- Edit
- Write
- Bash
- Glob
- Grep user_invocable: false
Agent Creator
Scaffold correctly-formed vexjoy-agent operator .md files. An agent file is a system-prompt contract: it sets identity, constraints, expertise, and routing — not application code.
Phases: DISCOVER → DESIGN → SCAFFOLD → REGISTER → VALIDATE
Phase 1 — DISCOVER
Check for domain overlap before creating anything.
grep -i "<domain-keyword>" agents/*.md | grep "^agents/" | cut -d: -f1 | sort -u
ls agents/ | grep "<domain-prefix>"
Gate 1: If an existing agent covers the domain, add a references/ file to that agent instead of creating a new one. Proceed only when no existing agent covers the domain, or the user confirms after seeing the overlap.
Read docs/PHILOSOPHY.md before proceeding — the philosophy governs operator context structure, progressive disclosure, positive framing, and tool restrictions. Components that violate it will fail CI.
Phase 2 — DESIGN
Decide the agent's identity and routing contract before writing a single line.
| Decision | Question to answer |
|---|---|
| Role type | Reviewer/auditor, code modifier/engineer, or orchestrator? |
| Allowed tools | Matches role: reviewers→Read/Glob/Grep; engineers→+Edit/Write/Bash; orchestrators→Read/Agent/Bash |
| Complexity | Low (single-file, read-only), Medium (multi-file, routing), High (full sweeps, orchestration) |
| Triggers | 3–6 specific phrases a user would naturally say — not generic verbs |
| pairs_with | 2–3 agents commonly co-dispatched; verify each exists on disk before listing |
| Reference files | Domains needing depth — each goes in agents/{name}/references/ loaded on demand |
| Description craft | Intent verb + domain object, 2–3 adjacent terms, one false-positive boundary clause with redirect |
| Activation cases | 3 should-trigger / 2 should-not-trigger / 2 near-miss phrases drafted now, saved at scaffold time |
Load references/agent-design-patterns.md for operator context structure, hook design, routing design, authority/trust framing, and smells-to-rewrite guidance.
Load references/agent-eval-design.md when drafting the description and activation cases — the case classes and worked example live there.
Gate 2: All eight decisions answered before writing agent file content.
Phase 3 — SCAFFOLD
Write the agent file using the annotated template.
Load references/agent-frontmatter-template.md for the complete template with all required fields and valid values.
File layout:
agents/
├── {agent-name}.md # operator file — the system prompt contract
└── {agent-name}/
├── references/
│ └── *.md # deep context, loaded on demand
├── SPEC.md # optional: contract for complex/high-impact agents
└── EVAL.md # optional: repeatable eval cases
Writing the operator context (body after frontmatter):
- Role statement: what the agent does, what domain it owns
- Expertise list: concrete capabilities with specific sub-skills
- Mandatory pre-action protocol: what to read before acting and why
- Operator context block: hardcoded behaviors, default behaviors (ON), optional behaviors (OFF)
- Capabilities and limitations table: CAN / CANNOT with agent suggestions for out-of-scope requests
- Reference loading table:
| Signal | Load These Files | Why |— required when areferences/directory exists - Workflow section: phase-by-phase with gates
- Error handling: cause/solution pairs for common failures
- Preferred patterns: what good looks like (positive framing)
- Anti-rationalization table: common rationalizations with required action
Positive framing (CI gate): Every instruction tells the reader what to do. Run the check after writing:
python3 scripts/validate_positive_instruction_docs.py
Exit code 1 means violations. Rewrite flagged instructions in action form before proceeding.
Progressive disclosure: Main agent file stays navigable. Deep reference material goes in {agent-name}/references/ loaded on demand. If the file exceeds 600 lines, extract content to references/ first.
Gate 3: Agent file written, YAML frontmatter parses cleanly:
python3 -c "import yaml; yaml.safe_load(open('agents/{agent-name}.md').read().split('---')[1]); print('OK')"
Phase 4 — REGISTER
Add the agent to the routing index.
python3 scripts/generate-agent-index.py
Verify the count increased by exactly one:
python3 -c "
import json
d = json.load(open('agents/INDEX.json'))
agents = d.get('agents', [])
print(f'Registered agents: {len(agents)}')"
Gate 4: agents/INDEX.json contains the new agent entry. The router cannot discover unregistered agents.
Phase 5 — VALIDATE
Run all validation checks before declaring the agent shippable.
# Structural checks: filenames, frontmatter, line counts, loading tables
python3 scripts/validate-references.py --agent {agent-name}
# Positive framing gate (scans all tracked .md files)
python3 scripts/validate_positive_instruction_docs.py
# YAML parse
python3 -c "import yaml; yaml.safe_load(open('agents/{agent-name}.md').read().split('---')[1]); print('YAML OK')"
# Verify pairs_with entries exist on disk
python3 -c "
import yaml, os
txt = open('agents/{agent-name}.md').read()
fm = yaml.safe_load(txt.split('---')[1])
for p in fm.get('routing', {}).get('pairs_with', []):
exists = os.path.exists(f'agents/{p}.md') or os.path.exists(f'skills/{p}/SKILL.md')
print(f' {p}: {\"OK\" if exists else \"MISSING\"}')"
Gate 5: All scripts exit 0. No phantom pairs_with entries. No positive-framing violations.
Manual review (the scripts cannot check these):
- Description craft: read the description aloud. Does it state intent, name 2–3 adjacent terms, mark one false-positive boundary? See
references/agent-frontmatter-template.mdDescription Craft. - Activation cases recorded: confirm
agents/{name}/references/activation-cases.md(or equivalent notes section) lists 3 should-trigger / 2 should-not-trigger / 2 near-miss phrases. Mental-pass each phrase against the description. Seereferences/agent-eval-design.md.
Error Handling
YAML parse error on frontmatter
Cause: Unquoted colon in description, or bad indentation in routing block. Solution: Wrap description in double quotes. Run the YAML parse command above — the traceback pinpoints the line.
Trigger conflict with existing agent
Cause: Two agents claim the same trigger phrase.
Solution: Run the duplicate detection script in agents/toolkit-governance-engineer/references/routing-table-patterns.md. Make this agent's trigger more specific.
Agent not appearing in routing after INDEX regeneration
Cause: Agent file path not matching the expected pattern, or frontmatter missing routing.triggers.
Solution: Confirm file is at agents/{name}.md. Confirm routing.triggers is a non-empty list.
Reference loading table missing from validation
Cause: Agent body has no | Signal | Load These Files | Why | table.
Solution: Add a reference loading table with at least one row. See references/agent-design-patterns.md for the required format.
Preferred Patterns
Role-matched allowed-tools
Set allowed-tools to match what the agent actually does — reviewers read only, engineers write, orchestrators dispatch. This ensures agents stay within their domain and cannot make out-of-scope changes.
Triggers that match natural speech
Write triggers as phrases a first-time user would naturally say, not internal system identifiers. "fix a bug in Go" routes better than "golang-debugging-invocation".
Reference loading table as required section
Every agent that has a references/ directory includes a loading table mapping signals to files. Agents without this table load references eagerly, violating the progressive disclosure principle from docs/PHILOSOPHY.md.
Expertise list over motivational framing
List concrete capabilities the agent has: version-specific idiom tables, failure mode catalogs, concrete commands. Skip "you are an expert in X" — it adds no information the model will act on.
Reference Loading Table
| Signal | Load These Files | Why |
|---|---|---|
| operator context structure, reference loading table format, phase/gate pattern, hook design, routing design, authority/trust framing, smells to rewrite | references/agent-design-patterns.md |
Vexjoy-specific architecture patterns, instruction hierarchy, and rewrite catalog for vague framing |
| frontmatter fields, YAML template, complexity tiers, INDEX.json registration, description craft | references/agent-frontmatter-template.md |
Complete annotated template with all required fields, valid values, and description-writing guide |
| activation eval, output eval, should-trigger / should-not-trigger / near-miss, routing failure, description tuning | references/agent-eval-design.md |
How to design activation and output evals at scaffold time so the right agent gets picked and produces correct work |