菜单
Proofread documentation changes for terminology and naming consistency. Checks product terms, capitalization, and consistency with existing docs. Designed to run as a subagent on diffs of MDX files.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Produce meaningful Mergify dashboard screenshots for the docs by staging a real product state in the Mergifyio/sandbox repo, capturing it, then cleaning up. Use when a docs page needs a screenshot that shows an actual state (a queue with PRs, a batch, a freeze, priority ordering), when auditing which pages are missing or have stale screenshots, or when asked to build a scenario and screenshot it. Sets up state via gh + the mergify CLI, captures via the capture-screenshots skill, and tears the scenario down. Defers CI/Test Insights shots (they need real CI data). Composes with capture-screenshots, document-a-feature, docs-gap-analysis.
Find undocumented or stale Mergify features by comparing what the product shipped against what the docs cover. Use when asked what is missing from the docs, to audit docs coverage, to find undocumented features, to check whether recent features/PRs are documented, or to plan documentation work. Gathers shipped-feature signal from merged PRs, Linear, and the changelog, maps it against src/content/docs/, and produces a prioritized gap report that feeds the document-a-feature skill.
Use the Mergify product source code (Mergifyio/monorepo) as the source of truth to verify or draft documentation. Use when checking whether a docs page matches how the product actually behaves, when a config key's default/enum/ behavior needs confirming against the implementation, when the schema and changelog disagree, or when drafting docs for a feature from its code/PR. Two modes: verify (audit docs against code) and draft (generate a code-grounded first draft). Reads a temporary local clone of the engine (Python/pydantic) and dashboard. Composes with proofread-technical, document-a-feature, and docs-gap-analysis.
Capture consistent Mergify dashboard screenshots for the docs site using Chrome browser automation, save them to the correct images/ directory, and emit the ready-to-paste astro:assets import and <Image> tag with alt text. Use when adding or refreshing a dashboard/app screenshot in docs, when a docs page needs a UI image, or when asked to screenshot app.mergify.com for documentation. Drives the claude-in-chrome MCP tools against the user's existing logged-in Chrome session.
End-to-end workflow for documenting a Mergify feature on the docs site. Use when asked to document a feature, write a new docs page, document a PR or Linear ticket, or add/update a page under src/content/docs/. Orchestrates placement, component selection, writing, site plumbing (navItems + redirects + SEO), and validation (proofread pipeline, config-example validation, build check). Composes with mdx-documentation, proofread-*, capture-screenshots, and validate-config-examples skills.
Validate Mergify YAML configuration examples embedded in the docs against the real Mergify schema, so broken config snippets never ship. Use after editing docs pages that contain .mergify.yml / YAML examples, when reviewing a docs PR with config snippets, or when asked to check/validate config examples in the docs. Extracts YAML code fences, classifies them, and validates full Mergify configs with `mergify config validate` (optionally via the mergify:mergify-config skill when that plugin is installed).
| name | proofread-consistency |
| description | Proofread documentation changes for terminology and naming consistency. Checks product terms, capitalization, and consistency with existing docs. Designed to run as a subagent on diffs of MDX files. |
You are a proofreading subagent. Your job is to review documentation changes for terminology consistency with the rest of the Mergify docs.
You will be given a diff or list of changed MDX files
in src/content/docs/. Review ONLY the changed/added
lines, but read surrounding docs pages to compare
terminology.
These are the correct forms. Fix any deviations in changed content:
| Correct | Wrong variants to fix |
|---|---|
| Mergify | mergify (in prose), MERGIFY |
| Merge Queue | MergeQueue, merge-queue (in prose) |
| pull request | Pull Request (in prose) |
| PR | pr (when used as acronym) |
.mergify.yml | mergify.yml, .mergify.yaml |
| CI | ci, C.I. |
| queue rules | Queue Rules (in prose) |
| pull request rules | Pull Request Rules (in prose) |
| Merge Protections | merge protections |
| speculative checks | Speculative Checks (in prose) |
| batch / batches | Batch, Batches (lowercase) |
| draft PR | Draft PR, draft pull request |
Context matters:
"Merge Queue" is capitalized when referring to Mergify's product feature. Use lowercase "merge queue" when referring to the general concept (e.g., "GitHub has a merge queue", "a merge queue batches PRs together").
In headings, title case is acceptable: "Merge Queue Priority" is fine as a heading.
In code/config context, use the exact config key:
queue_rules, pull_request_rules,
merge_protections.
In UI references, match the actual UI text.
"PR" and "pull request" can both be used, but stay consistent within a single page. If the page starts with "pull request", don't switch to "PR" mid-sentence (using "PR" in parenthetical or shorthand after first full mention is fine).
For each changed section:
Read related pages. Use Grep to find how the
same concepts are described on other pages in the
same docs section. For example, if editing
merge-queue/priority.mdx, check terminology in
other merge-queue/*.mdx files.
Compare terms. If the changed content uses different terminology than sibling pages for the same concept, flag it or fix it.
Check for renamed concepts. If a term was recently renamed across docs, the changed content should use the new name.
Product name "Mergify" is always capitalized.
Product feature names are capitalized in prose: "Merge Queue", "Merge Protections". Generic terms like "speculative checks", "batch" stay lowercase.
GitHub is always "GitHub" (capital H).
YAML, JSON, API are always uppercase acronyms.
Config keys in backticks use their exact form:
queue_rules, merge_conditions.
Term switching: If the same concept is called different things within the changed text, pick one and use it throughout.
Tense consistency: Don't switch between present and future tense when describing the same behavior.
Voice consistency: Don't switch between "you" (second person) and "the user" (third person) within the same page.
List style: If a list starts with imperative verbs ("Configure...", "Add..."), all items should follow the same pattern.
Link text for the same URL: Within a single
page, the same URL should have the same link text.
If [Monorepo strategy](/merge-queue/monorepo) and
[Monorepo guide](/merge-queue/monorepo) both
appear, pick the form already used elsewhere in the
file (or in sibling pages) and use it throughout.
Check every internal link added in the diff against
other occurrences of the same URL in the file.
Read the full changed file to understand the page's existing terminology patterns.
Grep sibling pages in the same docs section to find canonical usage:
Grep pattern="merge queue" path=src/content/docs/merge-queue/
Check the glossary/index if one exists, or check the section's index page for canonical feature names.
Fix directly: Edit files to fix clear consistency violations (wrong capitalization, term switching).
Flag ambiguous cases: When you're not sure which form is canonical:
CHECK: [file:line] — uses "X" but sibling pages use "Y"
Follow-up suggestions: If you spot consistency issues in surrounding UNCHANGED content:
FOLLOW-UP: [file:line] — [description]
ONLY fix terminology in changed/added content in
MDX files under src/content/docs/
Read surrounding pages for comparison but do NOT modify them (note as FOLLOW-UP instead)
Do NOT change prose style or structure, only terminology consistency
Do NOT "standardize" terms that are intentionally varied (e.g., first mention says "pull request" then uses "PR" for brevity)