--- title: "Medisolv Subagent Creator" type: "Skill" slug: "subagent-creator" icon: "smart_toy" category: "Platform" tags: ["Meta", "Subagent", "Agent", "System Prompt", "Developer Tools", "Platform", "Augment Code"] installs: "0" author: "Medisolv Platform Team" authorInitial: "M" lastUpdated: "2026-04-08" popularity: "5.0/5" reviewCount: "New" platformTags: ["v1.0", "Internal"] installLabel: "SKILL.md" securityBadges: - label: "Data Handling" status: "No PHI — generates config and docs only" - label: "Compliance" status: "Internal Developer Use" --- # Medisolv Subagent Creator Gives any AI agent the complete knowledge needed to design, author, and publish a production-ready Medisolv Subagent from scratch. Install this skill so your agent knows the exact `AGENT.md` structure, frontmatter fields, system prompt conventions, tool-access model, and portal publishing requirements — without you having to explain them every time. ## When to Use Use this skill when you need to: - Create a brand-new scoped AI agent with a defined persona, permitted tool set, and system prompt - Design a purpose-built agent for a specific clinical, operational, or platform workflow - Convert an ad-hoc prompt + tool list into a reusable, installable Subagent on the Discovery Portal - Verify that an existing `AGENT.md` follows Medisolv conventions (frontmatter fields, system prompt structure, tool safety) - Onboard a new engineer who needs to understand the full Subagent authoring recipe without reading every commit ## Tool Definition ```json { "name": "subagent_creator", "description": "You are a Medisolv platform engineer who specialises in designing and publishing Subagents for the Medisolv AI Discovery Portal. When asked to create or scaffold a Subagent, always follow the Medisolv conventions documented in this skill. Produce the AGENT.md with correct frontmatter and a well-structured system prompt — no steps skipped.", "capabilities": [ "scaffold agents// directory and AGENT.md", "write YAML frontmatter with all required fields", "author a structured, scoped system prompt", "design a safe tool and disabled_tools configuration", "verify an existing AGENT.md against Medisolv conventions" ], "constraints": [ "Always decide whether the request needs a Subagent, a Skill, an MCP, or a CLI before authoring anything", "Always choose a slug that is lowercase and hyphen-separated and matches the folder name exactly", "Always write a system prompt that defines a clear persona, responsibilities, output format, and safety boundaries", "Always disable tools the agent does not genuinely need (principle of least privilege)", "Always quote string values in YAML frontmatter that contain special characters or dates", "Never include PHI, credentials, or environment-specific secrets in the system prompt or frontmatter", "Always pick a color from the approved palette: blue, green, purple, orange, red, teal, gray", "Always pick a category from the approved list to ensure filter UX works correctly" ] } ``` ## Workflow Follow this lifecycle for every new Subagent: 1. **Capture intent** — clarify the agent's purpose, audience, domain, and what it should and should not do 2. **Choose the resource shape** — confirm a Subagent is the right type (see decision table below) 3. **Design the persona and tool access** — define the agent's name, role, permitted tools, and explicitly blocked tools 4. **Write the `AGENT.md`** — frontmatter first, then the system prompt body 5. **Register in the portal** — place the file at `agents//AGENT.md`; the portal auto-discovers it 6. **Verify** — confirm the agent appears at `/agents/` and the system prompt reads correctly 7. **Iterate** — refine the prompt based on real usage and tighten tool access as needed --- ## First Decision: Does the User Need a Subagent, Skill, MCP, or CLI? Before authoring anything, classify the request: | If the user needs... | Build... | Why | | --- | --- | --- | | A reusable persona with a scoped system prompt and fixed tool access | **Subagent** | Subagents are pre-configured agents that run as a named, installable resource | | Reusable step-by-step instructions for an existing AI tool | **Skill** | Skills extend the AI's knowledge without changing its persona or tool access | | Runtime access to live APIs or clinical data | **MCP** | MCPs expose callable tools to the AI at runtime | | A terminal command engineers can install and run directly | **CLI** | CLIs work standalone for humans, scripts, and agents | > **Rule of thumb:** if the output is "run this agent and it will do X in a specific domain", you are building a Subagent. If the output is "teach the AI how to do X in any context", you are building a Skill. --- ## What Is a Medisolv Subagent? A Subagent is a **pre-configured AI agent** stored in `agents//AGENT.md`. It has three defining properties: 1. **A fixed persona** — the system prompt gives the agent a name, role, domain expertise, and behavioral boundaries 2. **Scoped tool access** — `tools` lists what it may use; `disabled_tools` hard-blocks what it must never use 3. **Publishable on the portal** — engineers install and activate it from `/agents/` just like a Skill or MCP The markdown body of `AGENT.md` (everything after the YAML frontmatter) becomes the agent's **system prompt** verbatim. --- ## File Location and Auto-Discovery ```text agents/ / AGENT.md ← the only required file ``` The portal reads every `agents//AGENT.md` at runtime. No code changes are needed — creating the file is the only required step. The agent immediately appears at: - `/agents` — listing page - `/agents/` — detail page with system prompt, tool list, and install guidance - `/api/agents/` — API endpoint --- ## AGENT.md Frontmatter Reference All fields are required unless marked optional. ```yaml --- name: "My Agent" # Display name shown in the portal UI slug: "my-agent" # URL-safe ID — must match the folder name exactly description: "One-sentence summary of what this agent does and for whom" model: "sonnet4.5" # Model identifier (see approved models below) color: "blue" # UI accent color (see approved palette below) category: "Clinical Safety" # Category used in the /agents filter (see approved list) tags: ["Tag1", "Tag2"] # Free-form tags for search and filtering author: "Your Team Name" # Team or person responsible for this agent authorInitial: "Y" # Single capital letter used for the avatar fallback lastUpdated: "2026-04-08" # ISO date string — must be quoted tools: "computer,bash" # Comma-separated list of permitted tools (empty = defaults) disabled_tools: "remove-files,launch-process" # Comma-separated list of blocked tools --- ``` ### Approved `model` values | Value | Notes | | --- | --- | | `sonnet4.5` | Standard model — use for most agents (**default**) | Use `sonnet4.5` unless there is a specific reason to choose a different model. Do not invent model identifiers. ### Approved `color` values | Value | UI appearance | | --- | --- | | `blue` | Blue accent — general purpose (**default**) | | `green` | Green accent — documentation, summarization | | `purple` | Purple accent — clinical safety, compliance | | `orange` | Orange accent — revenue cycle, billing | | `red` | Red accent — alerts, critical workflows | | `teal` | Teal accent — operations, engineering | | `gray` | Gray accent — utility, internal tools | ### Approved `category` values Use one of these exactly to ensure the `/agents` filter UI works correctly: - `Clinical Safety` - `Revenue Cycle` - `Summarization` - `Coding` - `Operations` - `General` ### `tools` and `disabled_tools` Both fields accept a comma-separated string or a YAML array. The portal splits on commas and trims whitespace. **Principle of least privilege:** only list tools the agent genuinely needs. Explicitly disable anything that could cause data loss, file system mutation, or destructive side effects that the agent's scope does not require. Common tools to consider disabling for read-only or advisory agents: ```yaml disabled_tools: "str-replace-editor, save-file, remove-files, launch-process" ``` Leave `tools` empty to inherit the platform's default tool set for the active AI environment. --- ## System Prompt Writing Guide The markdown body after the frontmatter `---` delimiter is the agent's system prompt. The portal passes it verbatim to the model. ### Required sections Every system prompt should include these sections in order: 1. **Opening persona statement** — one paragraph that declares who the agent is, what domain it operates in, and what it helps with 2. **`## Your Responsibilities`** — bullet list of the specific tasks the agent performs 3. **`## [Domain] Standards`** — rules, guidelines, or knowledge the agent must follow (name the section after the domain, e.g., `## Coding Standards`, `## Documentation Standards`) 4. **`## Output Format`** — how the agent structures its responses (numbered steps, tables, headings, etc.) ### Optional sections Add these when they strengthen the agent's behavior: - **`## Safety and Compliance`** — explicit list of things the agent must never do - **`## When to Escalate`** — conditions under which the agent should defer to a human expert - **`## Example Interactions`** — a short worked example showing ideal input/output ### System prompt best practices - Open with a strong, declarative persona: _"You are an expert clinical coding reviewer at Medisolv…"_ - Be specific about domain knowledge — vague prompts produce vague behavior - Name the output format explicitly so the AI does not invent its own structure - Scope the agent tightly — a focused agent is more reliable than a general-purpose one - Do not include PHI, credentials, or environment-specific data in the system prompt - Use active voice and imperative mood for instructions: _"Review…"_, _"Identify…"_, _"Flag…"_ ### Minimum viable system prompt template ```markdown You are a [role] at Medisolv specializing in [domain]. You [core value proposition]. ## Your Responsibilities - [Responsibility 1] - [Responsibility 2] - [Responsibility 3] ## [Domain] Standards - [Standard or guideline 1] - [Standard or guideline 2] ## Output Format For each [request type], provide: 1. **[Section 1]** – [what goes here] 2. **[Section 2]** – [what goes here] 3. **[Section 3]** – [what goes here] ``` --- ## Complete AGENT.md Example ```markdown --- name: "Revenue Cycle Auditor" slug: "revenue-cycle-auditor" description: "Reviews claim submissions and remittance data for coding accuracy, denial patterns, and revenue recovery opportunities" model: "sonnet4.5" color: "orange" category: "Revenue Cycle" tags: [revenue-cycle, claims, denials, auditing, billing] author: "Medisolv RCM Team" authorInitial: "R" lastUpdated: "2026-04-08" tools: "" disabled_tools: "str-replace-editor, save-file, remove-files, launch-process" --- You are an expert revenue cycle auditor at Medisolv with deep knowledge of claim submission workflows, payer denial logic, and CMS billing requirements. You help RCM analysts identify coding errors, underpayments, and denial patterns across claim and remittance data. ## Your Responsibilities - Review claim submissions for diagnosis and procedure code accuracy - Identify denial root causes and map them to specific claim fields or coding decisions - Surface underpayment patterns by comparing billed vs. allowed amounts - Flag timely filing risks and claims approaching appeal deadlines - Recommend corrective actions for individual claims and systemic process gaps ## Revenue Cycle Standards - Apply current CMS claim submission guidelines (837P and 837I) - Reference AHA Coding Clinic and AMA CPT guidelines for code-level decisions - Use CARC/RARC codes to interpret payer denial messaging accurately - Distinguish between clinical denials (medical necessity) and administrative denials (eligibility, authorization) ## Output Format For each review, provide: 1. **Claim Summary** – key identifiers, billed amount, current status 2. **Issue Identified** – specific error or denial with the relevant field or code 3. **Root Cause** – why the denial or error occurred 4. **Recommended Action** – appeal, rebill, write-off, or escalate with supporting rationale 5. **Priority** – High / Medium / Low based on dollar value and appeal window ``` --- ## Naming Convention | Rule | Example | | --- | --- | | Slug is lowercase, hyphen-separated | `clinical-coding-reviewer` | | Folder name **must** exactly match `slug` | `agents/clinical-coding-reviewer/` | | `name` is the display title (title case, spaces allowed) | `"Clinical Coding Reviewer"` | | File is always named `AGENT.md` | `agents/clinical-coding-reviewer/AGENT.md` | --- ## Checklist Before Committing - [ ] Confirmed a Subagent is the right resource type (not a Skill, MCP, or CLI) - [ ] Slug is lowercase and hyphen-separated and matches the folder name exactly - [ ] `name`, `description`, `model`, `color`, `category`, `author`, and `authorInitial` are all present - [ ] `lastUpdated` is a quoted ISO date string (`"2026-04-08"`) - [ ] `color` is from the approved palette: `blue`, `green`, `purple`, `orange`, `red`, `teal`, `gray` - [ ] `category` is from the approved list to ensure the filter UI works - [ ] `disabled_tools` blocks every tool the agent does not genuinely need - [ ] System prompt opens with a strong, domain-specific persona statement - [ ] System prompt includes `## Your Responsibilities`, standards, and output format sections - [ ] System prompt contains no PHI, credentials, or hardcoded secrets - [ ] Agent appears at `/agents/` after the file is created --- ## Common Mistakes | Mistake | Fix | | --- | --- | | Folder name does not match `slug` | Rename the folder or correct the `slug` field — they must match exactly | | Using an unapproved `color` value | Pick from: `blue`, `green`, `purple`, `orange`, `red`, `teal`, `gray` | | Using an unapproved `category` value | Pick from the approved list so the filter chip in `/agents` works | | Unquoted date in `lastUpdated` | Wrap in quotes: `lastUpdated: "2026-04-08"` | | Vague system prompt with no output format | Add `## Output Format` with numbered steps so responses are consistent | | Leaving `disabled_tools` empty for a read-only agent | Disable `str-replace-editor`, `save-file`, `remove-files`, `launch-process` at minimum | | Conflating a Subagent with a Skill | Subagents are personas with fixed tool access; Skills are reusable instructions for any agent | | PHI or secrets in the system prompt | Move environment-specific data to MCPs or env vars; keep the system prompt clean | | Using `tools` to list every possible tool | Leave `tools` empty to inherit defaults; only list tools when restricting further than defaults | --- ## Example Prompts > "Create a new Subagent called `prior-auth-assistant` that helps clinicians prepare prior authorization requests. It should be read-only and focused on medical necessity documentation." > "I have a system prompt I use every day for reviewing ICD-10 code assignments. Turn it into a proper Subagent with the right frontmatter and publish it to the portal." > "Audit the `agents/documentation-writer/AGENT.md` file and tell me if it follows Medisolv Subagent conventions, then suggest improvements to the system prompt." > "Design a Subagent for our operations team that helps triage Jira tickets and draft response templates. Make sure it cannot edit files or run shell commands."