菜单
Use when auditing or fixing discoverability metadata for a website before publication, including titles, descriptions, canonical URLs, robots policy, Open Graph, structured data, and sitemaps. Not for content strategy or keyword research.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the current session needs an answer or a work product from a model on ANOTHER vendor's stack - a second opinion from a different model family, a cheap fast model for bulk work, or a cross-model review - by dispatching that vendor's own CLI as a one-shot worker. Triggers include "ask grok/composer/gemini/claude/codex what it thinks", "get a second opinion from a different model", "cross-model review", "run this by another model", "poll several models". No orchestration framework required; if a Brigade roster exists, prefer `brigade run --worker` instead.
Use when setting up, checking, writing, linting, or troubleshooting Brigade memory handoffs for a repo or agent workspace, especially when a user wants durable agent memory, handoff inboxes, cross-harness memory routing, or a safe first Brigade setup.
Use when asked to find bugs, hunt for correctness issues, sweep a codebase for defects, or verify a repo behaves as intended. Not for style or architecture review; this is defect-finding only.
Use when about to claim anything works, is fixed, is complete, or passes - before committing, replying to the user, or moving to the next task. Also use when relaying a subagent's or tool's success report, and especially at the end of a long session when the pull to say "done" is strongest.
Use before implementing, scaffolding, prototyping, or adding a feature when the work should start with the smallest useful code path, avoid speculative architecture, or prevent overbuilding before reduce would be needed.
Use when the user wants to act on an audit, fix the findings in a line-check/bug-hunt/security-sweep report, work a prioritized backlog, or asks to "fix the findings", "work the backlog", "clear the audit", or "do the high-leverage items". The step after the audit trio.
| name | garnish |
| license | MIT |
| description | Use when auditing or fixing discoverability metadata for a website before publication, including titles, descriptions, canonical URLs, robots policy, Open Graph, structured data, and sitemaps. Not for content strategy or keyword research. |
Garnish checks the metadata and indexing controls that surround a site's actual content. It works with the framework and policy already present in the target repository. It does not carry domains, account names, brand values, or fleet conventions from one site into another.
If the request says only "audit", stop after the report. Never turn an indexing review into an unrequested production change.
Before checking tags, find the site's declared policy and public identity:
Project policy wins over generic advice. If the repository does not declare a production domain or indexing policy, report that gap and stop before inventing one.
Walk five stations. Score each 0-5, where 5 is correct and verified, 3 works with material gaps, 1 is mostly absent, and 0 actively blocks discovery.
| # | Station | What to verify |
|---|---|---|
| 1 | Page identity | One useful title and description per indexable page, one canonical URL, declared language, and no duplicate head tags |
| 2 | Social metadata | Open Graph type, title, description, URL, image, and image alt text; platform-specific tags only when project policy requires them |
| 3 | Indexing policy | Production robots directives match intent; previews and private environments are not indexed; robots.txt does not contradict page metadata |
| 4 | URL inventory | Sitemap exists when the site needs one; sitemap URLs, canonical URLs, redirects, and trailing-slash policy agree |
| 5 | Structured and rendered output | Structured data matches visible content and parses; a production build renders the expected tags without duplicates |
Read rendered output when the framework generates metadata at build time. A correct-looking component import is not evidence that each route receives correct values.
For cross-page checks, collect titles, descriptions, canonicals, and indexability across the route set. One page cannot reveal duplicates or contradictory URL forms.
# garnish audit: <site> (<date>)
## Verdict
State whether metadata is ready, drifted, or blocking discovery. Name the first fix.
## Scorecard
| Station | Score (0-5) | Evidence |
## Findings
### [SEVERITY] Imperative title
- **Station:** one of the five stations
- **Where:** exact file, route, or rendered page
- **What:** the observed mismatch
- **Why it matters:** the concrete search, preview, or indexing effect
- **Fix:** the smallest action that resolves it
- **Effort:** S / M / L
## Not checked
List live indexing systems, webmaster consoles, or production responses that were unavailable.
Severity is critical for an unintended production noindex or a canonical that sends an entire site to the wrong host, high for missing or conflicting core metadata, medium for page-level duplication or invalid structured data, and low for presentation polish.
Work the accepted backlog in impact order:
Do not change the production domain, indexing status, redirect policy, analytics identity, or account metadata unless the user explicitly approved that value.
Use check before any readiness claim. Evidence must include the build command and rendered output for the tags or files changed. A source diff alone does not prove what a crawler receives.
Run public prose through plate, including descriptions, social preview copy, robots.txt comments, and public examples.
Stop and ask when: