agent-creator
Skill8 starsChanged 6 months agoMITView on GitHub
Interactive agent builder: guides the user through defining a new agent as a behavioral spec, then generates the agent .md and installs it.
26 other projects use a version of this.
Adopted by
Most recently taken up by
- Arcanea-Labs/Starlight-Intelligence-Systemtheir own version, first seen Nov 8, 2026
- krzysztofsurdy/code-virtuosotheir own version, first seen Nov 1, 2026
- coroboros/agent-skillstheir own version, first seen Oct 29, 2026
- 10CG/aria-plugintheir own version, first seen Oct 20, 2026
- Ronnasayd/aipptheir own version, first seen Oct 20, 2026
- AllanSantos-DV/skill-kittheir own version, first seen Oct 15, 2026
Used with
Projects with it also use security.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
0xSeroSkillsecurity
Also in 4 projects that use this
Other versions26 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 26
- OpenHands/extensions★ 167same name
- 9thLevelSoftware/legion★ 76same name
- DGouron/review-flow★ 42same name
- monaccode/astromesh★ 39same name
- krzysztofsurdy/code-virtuoso★ 36same name
- different-ai/openwork-hub★ 35same name
- HashLips/agent-skills★ 29same name
- mhylle/claude-skills-collection★ 20same name
- WalletConnect/skills★ 14same name
- Arcanea-Labs/Starlight-Intelligence-System★ 10same name
16 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- .claude/rules/common/agents.mdAGENTS.md
- architect-reviewSkill
- build-fixSkill
- code-reviewSkill
- deep-diveSkill
- docsSkill
- incident-debugSkill
- performance-reviewSkill
- planSkill
- qaSkill
- ralphSkill
- refactor-cleanSkill
- rule-creatorSkill
- security-reviewSkill
- skill-creatorSkill
- tdd-workflowSkill
The file
We split this skill into the rules it gives an agent
10 rules. 0 are common, 9 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 24 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
No args — ask the user what agent they want to create
- Distinctive: line 80
Check for name collisions:
- Distinctive: line 86
Ask the user these questions (batch them):
- Very specific: line 98
If domain-specific (domain:<tech> argument or user says yes):
- Distinctive: line 99
Ask what tech stack markers to detect (file extensions, config files)
- Distinctive: line 100
Ask for domain-specific checklists or conventions
- Distinctive: line 108
Read 2-3 existing agents in the same category for reference:
- Distinctive: line 139
When to escalate vs. handle autonomously
- Distinctive: line 148
APPROVAL GATE: Wait for user to approve. Accept modifications.
- Distinctive: line 224
If domain-specific, ask if the user wants to add it to the toolkit's detection:
“Common” is measured: kept by at least 6 in 10 of the 24 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/agent-creator
Build a new toolkit agent interactively. Agents are behavioral specifications — they define how an autonomous specialist thinks, analyzes, and reports. Not steps to execute, but a persona with responsibilities, analysis patterns, and output templates.
Arguments: $ARGUMENTS
<agent-name>— name for the new agent (e.g.,/agent-creator unreal-developer)domain:<tech>— create a domain-specific agent (e.g.,/agent-creator domain:unreal)- No args — ask the user what agent they want to create
Goal
Generate a production-ready agent .md file following the toolkit's behavioral spec structure, install it into the project's .claude/agents/ directory (or templates/agents/domain/<tech>/ for domain agents).
Dependencies
Tools
Read— read existing agents for pattern referenceWrite— create the agent .md fileGlob— find existing agents to avoid collisions and study patternsBash— install to project
Connectors
- None required (fully local)
Context
Agents follow a behavioral specification structure — fundamentally different from skills:
Frontmatter:
name, description, allowed_tools
Body:
1. Role Definition — who you ARE (one sentence persona)
2. Core Responsibilities — what you OWN (3-5 areas, not steps)
3. Analysis Process — how to THINK (phases with concrete guidance)
4. Output Format — exact template for findings/reports
5. Behavioral Constraints — scope limits, anti-patterns, hard rules
6. ECC Enrichments — optional advanced edge casesKey distinctions from skills:
- Agents say "here's how you should think" — skills say "run these steps"
- Agents use
allowed_toolsfor access control — skills use APPROVAL GATEs - Agents output reports/findings — skills output artifacts (code, PRs, files)
- Agents are spawned as subagents — skills are invoked as
/commands
Agent categories and their tool access patterns:
| Category | Tools | Writes Files? |
| Reviewer (code, security, perf) | Read, Glob, Grep, Bash | No |
| Planner (architecture, design) | Read, Glob, Grep, Bash | No |
| Implementer (build-fix, refactor) | Read, Glob, Grep, Bash, Edit, Write | Yes |
| Specialist (incident, domain) | Read, Glob, Grep, Bash + deep-think | Depends |
Process
Phase 1: Intake — Understand the Agent
- Parse
$ARGUMENTSfor agent name and type. If empty, ask:"What agent do you want to create? Describe the role in 1-2 sentences."
- Check for name collisions:
Glob: .claude/agents/*.md Glob: templates/agents/**/*.md Ask the user these questions (batch them):
Agent Definition Questionnaire:
- What role does this agent play? (e.g., "Unreal Engine C++ specialist")
- What category? (reviewer / planner / implementer / specialist)
- What are its 3-5 core responsibilities? (areas it owns)
- Should it modify files or only analyze? (determines tool access)
- What does its output look like? (report, checklist, diff suggestions)
- Is it domain-specific? (tied to a tech stack like Unreal, Unity, Rust)
- Does it need deep-think? (for complex reasoning, cross-module analysis)
- If domain-specific (
domain:<tech>argument or user says yes):- Ask what tech stack markers to detect (file extensions, config files)
- Ask for domain-specific checklists or conventions
APPROVAL GATE: Present the interpreted agent spec. Wait for confirmation.
Phase 2: Design — Define the Behavioral Spec
- Read 2-3 existing agents in the same category for reference:
- Reviewer? Read
code-reviewer.md,security-reviewer.md - Implementer? Read
build-error-resolver.md - Specialist? Read any domain agent in
templates/agents/domain/ - Planner? Read
planner.md
- Reviewer? Read
Design the agent's sections:
Role Definition — one sentence: "You are a [role]. Your job is to [purpose]."
Core Responsibilities — 3-5 bullet points of what the agent owns.
allowed_tools — based on category:
- Read-only:
[Read, Glob, Grep, Bash] - With LEANN: add
mcp__leann-server__leann_search - With deep-think: add
mcp__deep-think__think,mcp__deep-think__reflect,mcp__deep-think__strategize - With write access: add
Edit,Write
Analysis Process — 2-5 phases:
- Phase 1 is always "Gather" (read code, understand context)
- Middle phases are analysis-specific
- Final phase is always "Report" (produce output)
Output Format — design the exact report template:
- Severity levels if reviewer (CRITICAL / HIGH / MEDIUM / LOW / PRAISE)
- Sections matching the responsibilities
- Concrete examples of good vs bad findings
Behavioral Constraints — hard limits:
- What the agent must NOT do
- Scope boundaries
- When to escalate vs. handle autonomously
ECC Enrichments — if the agent needs advanced patterns:
- Edge case handling
- Framework-specific gotchas
- Common false positives to avoid
- Read-only:
- Present the full spec outline to the user.
APPROVAL GATE: Wait for user to approve. Accept modifications.
Phase 3: Generate — Write the Agent File
Generate the full agent .md file:
---
name: <agent-name>
description: "<role in one line>"
allowed_tools:
- Read
- Glob
- Grep
- Bash
- <additional tools>
---
# <Agent Title>
You are a <role>. Your job is to <purpose>.
## Core Responsibilities
1. <Responsibility 1>
2. <Responsibility 2>
3. <Responsibility 3>
## Analysis Process
### Phase 1: <Gather/Understand>
<steps with specific tool usage, grep patterns, file paths>
### Phase 2: <Analyze/Evaluate>
<domain-specific analysis guidance>
### Phase 3: <Report/Recommend>
<synthesis and output generation>
## Output Format
<exact template with severity levels, sections, metrics>
## Behavioral Constraints
- <constraint 1>
- <constraint 2>
- <scope boundary>
## ECC Enrichments
<advanced patterns, edge cases, special handling>Present the generated content to the user.
APPROVAL GATE: User reviews the full agent definition. Accept edits before writing.
Phase 4: Install — Deploy the Agent
- Determine install location:
- Generic agent:
.claude/agents/<agent-name>.md - Domain agent:
.claude/agents/<agent-name>.md(project) ANDtemplates/agents/domain/<tech>/<agent-name>.md(toolkit source, if in toolkit repo)
- Generic agent:
- Write the file:
Write: .claude/agents/<agent-name>.md - If domain-specific, ask if the user wants to add it to the toolkit's detection:
"Want to add
<tech>detection to the installer? This would auto-install this agent for all future<tech>projects." - Verify:
Glob: .claude/agents/<agent-name>.md - Report:
"Agent installed:
.claude/agents/<agent-name>.md- Category: <reviewer/implementer/planner/specialist>
- Tools: <allowed_tools summary>
Claude will now use this agent when tasks match its responsibilities."
Error Handling
| Situation | Action |
| Agent name already exists | Warn, offer to overwrite or rename |
| User gives vague role description | Present 2-3 role interpretations |
| Too many responsibilities (>7) | Suggest splitting into two agents |
| Tool access too broad for category | Warn about principle of least privilege |
| Domain tech not in installer detection | Offer to add detection pattern |
Checklist (Internal — verify before completing)
- Agent name is unique
- Frontmatter has
name,description,allowed_tools - Role definition is one clear sentence
- Core responsibilities are 3-5 items (areas, not steps)
- Analysis process has 2-5 phases with concrete guidance
- Output format is an exact template (not vague)
- Behavioral constraints define scope boundaries
allowed_toolsfollows least-privilege for the category- File written to
.claude/agents/<name>.md - Domain detection offered if domain-specific
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

