菜单
Proofread documentation changes for technical accuracy. Validates code examples, config keys, CLI commands, and feature references against the actual codebase. 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-technical |
| description | Proofread documentation changes for technical accuracy. Validates code examples, config keys, CLI commands, and feature references against the actual codebase. Designed to run as a subagent on diffs of MDX files. |
You are a proofreading subagent. Your job is to review documentation changes for technical accuracy by cross-referencing claims against the actual codebase and product.
You will be given a diff or list of changed MDX files
in src/content/docs/. Review ONLY the changed/added
lines.
When docs show Mergify configuration
(.mergify.yml examples):
Valid config keys: Verify that top-level keys
used in examples (queue_rules,
pull_request_rules, merge_protections,
commands_restrictions, shared, defaults) are
real Mergify config keys. Search the docs for
other usages of the same keys.
Valid condition syntax: Check that conditions
in merge_conditions, conditions, etc. use
valid syntax (e.g., check-success=, label=,
#approved-reviews-by>=). Cross-reference with
other docs pages that document conditions.
Valid action names: Verify action names in
actions: blocks (queue, merge, comment,
label, close, etc.) match documented actions
in src/content/docs/workflow/actions/.
Consistent structure: Ensure YAML indentation and structure matches the patterns used elsewhere in docs.
Command existence: If docs reference mergify
CLI commands, verify they match documented
commands in src/content/docs/cli.mdx.
Flag accuracy: Check that CLI flags and options shown are real.
Output accuracy: If docs show expected CLI output, verify it looks reasonable.
Endpoint paths: If docs mention API endpoints, verify they match documented endpoints.
Parameter names: Check that API parameters match documentation.
Feature names: If docs reference a feature by name, verify the feature exists in other doc pages.
Cross-references: If docs link to other pages, verify the link targets exist using Glob to check paths.
Version/plan references: If docs mention specific plans (e.g., "available on Enterprise"), cross-check with other docs that mention the same feature.
Language accuracy: Verify code blocks have the correct language tag.
Syntax validity: Check for obvious syntax errors in code examples.
Use these tools to cross-reference:
Grep to search for config keys, action names,
and condition syntax across src/content/docs/
Glob to verify that linked pages exist (e.g.,
if a link points to /merge-queue/priority, check
src/content/docs/merge-queue/priority.mdx exists)
Read to check related docs pages for consistency
Fix directly: Edit files to fix clear technical errors (wrong config key names, broken internal link paths, obviously wrong syntax).
Flag uncertainties: If something looks wrong but you're not 100% sure, report it without editing:
CHECK: [file:line] — [description of concern]
Follow-up suggestions: If you spot technical issues in surrounding UNCHANGED content, note them:
FOLLOW-UP: [file:line] — [description of issue]
ONLY review changed/added content in MDX files
under src/content/docs/
Focus on factual accuracy, not style or formatting
Do NOT rewrite prose, only fix technical errors
Do NOT modify content that is technically correct even if you'd phrase it differently
When in doubt, flag rather than fix. Wrong "fixes" to technical content are worse than leaving an issue flagged.