一键在 Manus 中运行任何 Skill

validate-config-examples

星标2

分支14

更新时间2026年7月2日 07:02

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).

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

Mergifyio

Mergifyio/docs

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Validate Config Examples

Mergify config snippets in the docs are the most-copied content on the site. A broken example erodes trust instantly. A config-examples CI job validates them on every PR; this skill is how you run the same check locally and fix what it finds.

Run it

pnpm check:config-examples          # validate everything under src/content/docs

Under the hood this runs node scripts/validate-config-examples.mjs. It scans MDX for yaml / yml fences, classifies each, YAML-parses the complete Mergify configs, and validates them against public/mergify-configuration-schema.json with Ajv. Exit code is non-zero if any example is invalid; each failure prints as file:line — <error>.

To validate only the files you touched, pass paths:

node scripts/validate-config-examples.mjs src/content/docs/merge-queue

To inspect the classification (which blocks are validated vs skipped and why), use --json:

node scripts/validate-config-examples.mjs --json src/content/docs | jq '.[] | {file, line, classification}'

What gets validated vs skipped

The script validates a block only when it is a complete Mergify config — i.e. it has an unindented top-level key from the config schema (queue_rules, pull_request_rules, merge_protections, merge_protections_settings, scopes, defaults, commands_restrictions, extends, shared, ...).

It automatically skips:

Fragments — a snippet with no top-level key (e.g. a single rule or a bare list of conditions shown inline). Cannot be validated as a whole config.
... placeholders — any block containing a bare ... line is treated as deliberately incomplete.
GitHub Actions / other CI YAML — detected by on: + jobs:/steps:/etc.
Anything marked # partial in its first lines.

For a block that looks like a full config but should not be validated — most often deprecated syntax shown in a migration guide — put a reader-invisible MDX comment on the line before the fence:

{/* validate-config-examples: skip — deprecated partition_rules syntax, shown for migration */}

```yaml
partition_rules:
  ...
```

Do not skip a block just to make CI pass. If an example is meant to be a real, copy-pasteable config, fix it instead.

Fixing failures

invalid YAML: ... — the snippet isn't valid YAML. The most common cause is an unquoted Mergify template at the start of a value ({{ ... }} or a leading @): message: @{{author}} ... must be message: "@{{author}} ...", and bot_account: {{ author }} must be bot_account: "{{ author }}".
/ must NOT have additional properties — an unknown or misspelled key at the top level (or a deprecated top-level key). Fix the key, or mark the block skipped if the old syntax is shown on purpose.
/path must be <type> — a value has the wrong type or shape. Match the schema.

Fix clear errors directly in the MDX. For anything ambiguous, flag it rather than guess — a wrong "fix" to a config example is worse than a flagged one.

Scope, guardrails & limitations

Validation is structural (keys, types, shapes). It does not check the semantics of condition expressions (base=main), nor Mergify's custom string formats (duration, template) — a generic JSON-Schema duration validator would wrongly reject valid values like checks_timeout: 5 min, so all format keywords are intentionally ignored. For deep semantic validation of a single config, mergify config validate --config-file <file> (the mergify:mergify-config skill) remains authoritative — but it fetches the schema from docs.mergify.com, so it is not used in CI.
The schema at public/mergify-configuration-schema.json is kept fresh by an automated sync ("chore: sync Mergify JSON Schema files"); the check always runs against the copy in the repo, so a PR is validated against its own schema.
Only yaml/yml fences are considered. Never edits src/content/changelog/.
Fix only genuine errors; leave valid examples alone.

同仓库更多 Skills

同仓库

screenshot-scenarios

Mergifyio/docs

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.

2026-07-132

docs-gap-analysis

Mergifyio/docs

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.

2026-07-132

docs-from-code

Mergifyio/docs

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.

2026-07-102

capture-screenshots

Mergifyio/docs

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.

2026-07-022

document-a-feature

Mergifyio/docs

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.

2026-07-022

mdx-documentation

Mergifyio/docs

MDX and Astro documentation patterns for the Mergify docs site. Use when creating, editing, or reviewing documentation pages. Covers frontmatter, imports, components, and content structure.

2026-04-302

name

validate-config-examples

description

Validate Config Examples

Run it

pnpm check:config-examples          # validate everything under src/content/docs

To validate only the files you touched, pass paths:

node scripts/validate-config-examples.mjs src/content/docs/merge-queue

To inspect the classification (which blocks are validated vs skipped and why), use --json:

node scripts/validate-config-examples.mjs --json src/content/docs | jq '.[] | {file, line, classification}'

What gets validated vs skipped

It automatically skips:

Fragments — a snippet with no top-level key (e.g. a single rule or a bare list of conditions shown inline). Cannot be validated as a whole config.
... placeholders — any block containing a bare ... line is treated as deliberately incomplete.
GitHub Actions / other CI YAML — detected by on: + jobs:/steps:/etc.
Anything marked # partial in its first lines.

{/* validate-config-examples: skip — deprecated partition_rules syntax, shown for migration */}

```yaml
partition_rules:
  ...
```

Do not skip a block just to make CI pass. If an example is meant to be a real, copy-pasteable config, fix it instead.

Fixing failures

invalid YAML: ... — the snippet isn't valid YAML. The most common cause is an unquoted Mergify template at the start of a value ({{ ... }} or a leading @): message: @{{author}} ... must be message: "@{{author}} ...", and bot_account: {{ author }} must be bot_account: "{{ author }}".
/ must NOT have additional properties — an unknown or misspelled key at the top level (or a deprecated top-level key). Fix the key, or mark the block skipped if the old syntax is shown on purpose.
/path must be <type> — a value has the wrong type or shape. Match the schema.

Fix clear errors directly in the MDX. For anything ambiguous, flag it rather than guess — a wrong "fix" to a config example is worse than a flagged one.

Scope, guardrails & limitations

Validation is structural (keys, types, shapes). It does not check the semantics of condition expressions (base=main), nor Mergify's custom string formats (duration, template) — a generic JSON-Schema duration validator would wrongly reject valid values like checks_timeout: 5 min, so all format keywords are intentionally ignored. For deep semantic validation of a single config, mergify config validate --config-file <file> (the mergify:mergify-config skill) remains authoritative — but it fetches the schema from docs.mergify.com, so it is not used in CI.
The schema at public/mergify-configuration-schema.json is kept fresh by an automated sync ("chore: sync Mergify JSON Schema files"); the check always runs against the copy in the repo, so a PR is validated against its own schema.
Only yaml/yml fences are considered. Never edits src/content/changelog/.
Fix only genuine errors; leave valid examples alone.