Metadata check
Reviews short, high-value strings where every character counts — titles, meta descriptions, schema descriptions, FAQ answers, taglines, bios, and social-card copy. Flesch scoring and the ten-category readability rubric don't fit a 5–30 word string; this skill applies the checks that do.
Use this skill for anything in the metadata-string shape. For multi-paragraph prose (blog posts, READMEs, CONTRIBUTING files), use readability-check instead.
What to check
For each string, check these points. Every check is either ✓ (pass), ⚠ (needs work), or ✗ (problem).
- Front-load the distinguishing word. The most specific, searchable term sits near the start. "Astro SEO: the definitive guide" beats "The definitive guide to Astro SEO" — the reader's eye hits the topic first.
- Concrete over abstract. Names, numbers, specific claims. "Reduce LCP by 40%" beats "Improve performance significantly."
- Filler and hedging — aggressive. Every word costs shelf space. Cut really, just, very, actually, basically, simply, a bit, kind of, I think. In metadata these aren't style ticks, they're wasted SERP characters.
- Active voice unless the object is the subject. "Audit your GitHub profile" beats "Your GitHub profile can be audited."
- No title/description duplication. A meta description that restates the title burns ~60 of 200 characters for nothing. The description should promise what's inside the page, not re-announce what it is.
- Difficult words. Prefer the common synonym unless the domain term is what the user searches for. Between utilize and use, use use. Domain terms the target audience expects are fine (hydration, middleware, structured data).
- SERP and platform truncation. Know the limit for the surface:
- Google SERP: titles clipped around 55–65 characters, descriptions around 155–160.
- GitHub repo description: ~350 chars, but only the first ~100 show in search results and on profile cards.
- Twitter/X bio: 160 chars.
- Open Graph description: usually shown at ~200 chars. Anything past the cut should be disposable, not a key promise.
- One idea per field. Titles and descriptions that try to promise two things land fuzzy. Pick the sharpest one.
What to skip
Don't run this skill on:
- URLs, schema
@idvalues, filenames, enum values, or any technical identifier. - Multi-paragraph prose — route that to
readability-check. - Strings the user did not write and cannot change (imported content, upstream defaults).
Output format
Per string, return:
markdown### [Field name] — [length] chars > [The string itself] - Front-loading: [✓/⚠/✗] [one-line reason if not ✓] - Concreteness: [✓/⚠/✗] [reason] - Filler: [✓/⚠/✗] [reason] - Active voice: [✓/⚠/✗] [reason] - Duplication: [✓/⚠/✗] [reason] - Word choice: [✓/⚠/✗] [reason] - Truncation fit: [✓/⚠/✗] [reason] — platform: [SERP/GitHub/Twitter/OG] - One idea: [✓/⚠/✗] [reason] **Rewrite:** [only if any check failed — a concrete replacement string, not a suggestion]
Keep the audit tight — metadata feedback should be actionable in seconds, and you're almost always running it across a batch of strings at once. If a string is already clean, don't pad the output; just mark all ✓ and move on.
