Claude Code Subagent Check vs. reading the subagent file by eye
Reading a short subagent definition with an obviously empty tools list catches that list. It reliably misses a description that reads fine to a person but carries no trigger cue an orchestrator matches on, a duplicated tool name buried in a long comma-separated list, a name that doesn't match its own filename, and an unrecognized model alias that looks plausible — which is what this free, no-upload checker computes exactly, in one pass.
Where reading it yourself stops being enough
Anyone writing a subagent definition already does this: read the frontmatter and the prompt body and
decide whether it looks right before trusting the orchestrator to pick it up. For a file with an
obviously empty tools field, that read catches it. The problem is the other checks below
are not the kind of thing a skim of readable prose and a comma-separated list reliably surfaces.
| What you're trying to confirm | Reading the subagent file yourself | This checker |
|---|---|---|
The tools field isn't empty or missing. | Works. This is the one case a plain read reliably catches. | Also catches it, in the same pass as everything below. |
The name field is kebab-case and matches the file's own filename. | Two separate strings in two separate places; a rename to one and not the other is easy to miss. | Compared directly, every time. |
The description gives the orchestrator a concrete trigger cue, not just readable prose about what the subagent does. | "Handles code review" and "use PROACTIVELY when a PR is opened" both read as fine sentences to a person. | Checked for length, a trigger-cue pattern, and distinctive vocabulary, the same way every time. |
No tool name is duplicated, and every one is recognized, across a long comma-separated tools list. | Read left to right for the names that matter; a repeat from copying a sibling's frontmatter doesn't stand out. | Every entry compared against every other entry, and checked against a documented list. |
The model alias is one this tool recognizes, as a caution against a typo. | Requires recognizing the current set of aliases from memory. | Checked against a dated reference list automatically. |
| The prompt body isn't missing or near-empty. | Visible at a glance for an entirely blank body; a few thin sentences can still read as "something is there." | Checked against a length threshold, every time. |
| Re-checking an entire subagent definition again after editing the frontmatter. | Read start to finish again, remembered by hand. | One paste, every field, every time. |
A quick read is still the fastest way to catch an obviously empty field in a short file, and this checker is not doing anything a careful review couldn't — it is reading the same frontmatter and prompt body a careful review would, just checking every field against fixed rules automatically instead of judging the description's wording and comparing the tools list by eye.
This tool needs no account and no sign-in: the browser page parses text you paste entirely in your own browser. It never sends your subagent definition anywhere.
Common questions
Can't I just read the subagent file myself?
For a file with an obviously empty tools list or a missing description, yes -- that case is visible on a single read. What reading does not reliably catch is a description that reads as perfectly good prose to a person but carries no concrete trigger cue an orchestrator matches on, a tool name duplicated inside a long comma-separated list, a name that doesn't match its own filename, or an unrecognized model alias that looks like a real one. Those need the same fixed checks run against the frontmatter every time, not judged by eye.
Why is a description that reads fine but won't trigger delegation hard to catch by eye?
Because "this subagent handles code review" and "use PROACTIVELY when a PR is opened" are both grammatically fine, readable sentences -- the difference is whether the wording gives the orchestrator a concrete condition to match a request against, not whether it reads well. A person skimming the frontmatter judges the sentence as prose; this tool checks it for length, a trigger-cue pattern, and distinctive vocabulary, the same way for every subagent.
Why is a duplicate tool name in a long list easy to miss?
A tools field with a dozen comma-separated names is read left to right for the names that matter, not compared entry by entry against itself. A name repeated once in the middle of the list -- often from copying and editing a sibling subagent's frontmatter -- does not stand out visually the way a missing or malformed field does.
What about a name that doesn't match its own filename?
The frontmatter's name field and the file's own filename are two separate strings in two separate places -- one inside the YAML block, one in the file browser or path -- and nothing forces a reader comparing them from memory to notice a mismatch, especially after a rename. This tool checks the two strings against each other directly.
Is this page making a live comparison against a tool or company?
No. This page describes a manual habit anyone writing a Claude Code subagent definition already has -- reading the frontmatter and prompt by eye before trusting it to be picked up. It names no competing product or company. The checker itself makes no network request of any kind: the browser page parses pasted text in your own browser, and nothing you paste is ever uploaded.