{"owner":"Aethersailor","repo":"Custom_OpenClash_Rules","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":4135,"categories":["copilot-instructions"],"hasMcp":false,"mcpConfig":null,"found":[".github/copilot-instructions.md"],"skills":{".github/copilot-instructions.md":"# Commit message generation rules\n\nGenerate commit messages from the actual staged diff, not merely from file\nnames, directory names, or the number of changed files.\n\nThe commit title must precisely describe the primary intentional change.\n\n## Output format\n\nUse Conventional Commits:\n\n```text\ntype(scope): subject\n```\n\nThe first line must be a complete and accurate title that can stand alone.\n\nGenerate a body only when the staged changes contain multiple inseparable\ndetails or require important rationale. Never rely on the body to correct a\nvague or inaccurate title.\n\n## Required analysis before generating the title\n\nBefore writing the commit message, silently perform these steps:\n\n1. Inspect every staged file and its actual diff.\n2. Identify the primary intentional change.\n3. Distinguish:\n\n   * behavior changes from documentation changes;\n   * source files from generated files;\n   * manual changes from automated refreshes;\n   * implementation changes from accompanying tests and documentation;\n   * functional workflow changes from routine dependency updates.\n4. Determine what the repository will do differently after the commit.\n5. Select the type and scope from the semantic effect of the change.\n6. Write a subject that names the concrete resource, behavior, or defect.\n7. Verify the complete title length before returning it.\n\nDo not infer functionality from a filename alone.\n\nDo not claim an effect that is not demonstrated by the diff.\n\n## Hard title requirements\n\n* Use English only.\n* Use exactly the format `type(scope): subject`.\n* Keep the complete title, including type and scope, at 72 characters or fewer.\n* Prefer 50–65 characters when accuracy is not reduced.\n* Use a lowercase type and lowercase scope.\n* Begin the subject with a lowercase imperative verb unless it starts with a\n  proper name or established acronym.\n* Do not end the subject with a period.\n* Do not include Markdown, quotation marks, issue numbers, or a trailing colon.\n* Do not repeat the type or scope in the subject.\n* Preserve established names and capitalization:\n\n  * OpenClash\n  * Mihomo\n  * GeoIP\n  * GeoSite\n  * DNS\n  * IPv4\n  * IPv6\n  * YAML\n  * MRS\n  * CDN\n  * COCR\n  * Sub-Store\n  * GitHub Actions\n  * jsDelivr\n* Return one best title, not several alternatives.\n\nBefore returning the title, count every character. If it exceeds 72\ncharacters, shorten the subject without removing the concrete object or effect.\n\n## Allowed types\n\nUse only:\n\n```text\nfeat, fix, docs, style, refactor, perf, test, build, ci, chore, revert\n```\n\nChoose the type according to the actual semantic effect.\n\n### `feat`\n\nUse `feat` for a new user-visible capability, usable resource, routing\nbehavior, configuration option, script feature, or automation capability.\n\nExamples include:\n\n* adding a new manually maintained direct or proxy rule;\n* adding a new OpenClash override;\n* adding a new Subconverter policy or configuration capability;\n* adding a new Shell-script operation;\n* adding a new validation or publishing capability.\n\nCreating a new file does not automatically make the change a feature.\n\n### `fix`\n\nUse `fix` only when the diff corrects incorrect behavior, incorrect data, a\nbroken path, an invalid rule, a failed workflow, or another identifiable\ndefect.\n\nThe subject must state what was corrected.\n\nDo not use `fix` for:\n\n* clearer wording;\n* additional comments;\n* metadata changes;\n* formatting;\n* general cleanup;\n* speculative hardening without an identifiable defect.\n\n### `docs`\n\nUse `docs` when all meaningful changes affect documentation, comments,\ninstructions, examples, descriptions, or metadata intended for humans.\n\nThis rule applies even when comments are inside:\n\n* `.conf`;\n* `.ini`;\n* `.yaml`;\n* `.yml`;\n* `.sh`;\n* `.py`;\n* `.js`.\n\nComment-only changes are `docs`, not `fix`, `style`, or `chore`.\n\n### `style`\n\nUse `style` only for formatting changes with no behavior, data, documentation,\nor semantic effect.\n\nExamples include whitespace, indentation, line wrapping, or ordering that does\nnot alter meaning.\n\nDo not use `style` for rewritten documentation.\n\n### `refactor`\n\nUse `refactor` for internal restructuring that preserves intended behavior.\n\nExamples include:\n\n* renaming internal identifiers;\n* reorganizing implementation code;\n* deduplicating shared logic;\n* changing internal structure without adding a feature or fixing a defect.\n\nA rename that changes only provider identifiers should use `refactor`, while\nits scope must still identify the owning repository component.\n\n### `perf`\n\nUse `perf` only when the primary purpose is a measurable or clearly\ndemonstrated performance improvement.\n\nDo not infer a performance improvement merely because code became shorter.\n\n### `test`\n\nUse `test` when the primary change adds, removes, or corrects tests without\nchanging production behavior.\n\nTests added together with an implementation change normally inherit the\nimplementation commit's type and scope.\n\n### `build`\n\nUse `build` for build systems, packaging, documentation build dependencies, or\nartifact construction tooling when the change is not primarily a CI workflow\nchange.\n\n### `ci`\n\nUse `ci` for GitHub Actions workflows and their supporting scripts when the\nprimary change affects repository automation, validation, publishing,\nscheduling, permissions, concurrency, or automated commits.\n\nFor workflow commits, choose the scope from the workflow's purpose, not merely\n`workflow`.\n\n### `chore`\n\nUse `chore` for routine maintenance that does not introduce user-visible\nbehavior or fix a defect.\n\nTypical examples include:\n\n* regenerating derived rule files;\n* refreshing automatically collected upstream data;\n* synchronizing a submodule;\n* bumping dependencies;\n* updating pinned action versions;\n* repository housekeeping.\n\nA manually selected new routing rule is normally `feat(rules)`, not\n`chore(rules)`. An automated upstream refresh of an existing rule list is\nnormally `chore(rules)`.\n\n### `revert`\n\nUse `revert` only when the commit reverts an earlier commit.\n\nDescribe the reverted change precisely. Do not copy a malformed original title\nwithout correcting its format.\n\n## Allowed scopes\n\nPrefer one of these repository scopes:\n\n```text\nrules\noverwrite\nconfig\nsubconverter\nshell\nsubstore\nreadme\nwiki\ndocs\nvalidation\npages\nsync\ndeps\nsecurity\ncdn\nworkflow\nrepo\n```\n\nUse these spellings consistently.\n\nDo not invent singular, plural, or synonymous variants such as:\n\n```text\nrule\nmodule\nmodules\nscript\nscripts\nworkflows\nconfigs\nconfiguration\n```\n\nUse `rules`, not `rule`.\n\nUse `overwrite`, not `module` or `modules`, for OpenClash override resources.\n\nUse `shell`, not `script`, for files under `shell/`.\n\nUse `workflow` only for genuinely cross-cutting workflow infrastructure. Prefer\nthe workflow's functional scope whenever one is available.\n\nUse `repo` only as a last resort for genuinely repository-wide maintenance.\nNever use `repo` to hide unrelated staged changes.\n\n## Repository path and scope mapping\n\n### Root documentation\n\nFor:\n\n```text\nREADME.md\nDO_NOT_README.md\n```\n\nuse:\n\n```text\ndocs(readme)\n```\n\nFor a README inside a component directory, use `docs` with that component's\nscope:\n\n```text\ndocs(rules)\ndocs(overwrite)\ndocs(config)\ndocs(shell)\ndocs(substore)\n```\n\n### Wiki and documentation site\n\nFor content under:\n\n```text\nwiki/**\n```\n\nuse:\n\n```text\ndocs(wiki)\n```\n\nFor documentation-site configuration or build dependencies such as:\n\n```text\nmkdocs.yml\nrequirements-docs.txt\n```\n\nuse `docs`, `build(docs)`, or `ci(pages)` according to the actual change.\n\n### Subconverter templates\n\nFor maintained INI templates under:\n\n```text\ncfg/*.ini\n```\n\nprefer:\n\n```text\nsubconverter\n```\n\nExamples:\n\n```text\nfeat(subconverter): add gaming download policy\nfix(subconverter): correct rule provider ordering\n```\n\nFor automatically copied or derived INI templates, use `chore(subconverter)`\nwhen only generated output changes.\n\n### Complete YAML configurations\n\nFor maintained configuration files under:\n\n```text\ncfg/yaml/**\n```\n\nprefer:\n\n```text\nconfig\n```\n\nUse the actual configuration behavior in the subject, not a generic phrase\nsuch as “update config”.\n\n### Rule source files\n\nThe maintained rule sources include files such as:\n\n```text\nrule/Custom_Direct.list\nrule/Custom_Proxy.list\nrule/Steam_CDN.list\nrule/Encrypted_DNS.list\nrule/Game_Download_CDN.list\n```\n\nUse:\n\n```text\nrules\n```\n\nExamples:\n\n```text\nfeat(rules): add hbymfswz.com to direct rules\nfix(rules): move example.com from proxy to direct\nchore(rules): refresh encrypted DNS sources\n```\n\nState the affected domain, service, platform, source set, or routing behavior\nwhenever it fits within the title limit.\n\n### Generated rule files\n\nFiles under `rule/` with derived formats such as:\n\n```text\n*_Classical.yaml\n*_Classical_IP.yaml\n*_Classical_Port.yaml\n*_Domain.yaml\n*_IP.yaml\n*.mrs\n```\n\nare generated artifacts when produced from the maintained `.list` sources.\n\nWhen only generated files change, use:\n\n```text\nchore(rules): regenerate derived rule files\n```\n\nWhen a source `.list` and its generated files change together, describe the\nsource-rule change. Do not make regeneration the primary title.\n\nCorrect:\n\n```text\nfeat(rules): add Steam CDN IP ranges\n```\n\nIncorrect:\n\n```text\nchore(rules): update YAML and MRS files\n```\n\n### OpenClash override resources\n\nFor files under:\n\n```text\noverwrite/**\n```\n\nuse:\n\n```text\noverwrite\n```\n\nExamples:\n\n```text\nfeat(overwrite): add encrypted DNS blocking override\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): set mainland IP whitelist sources\nfix(overwrite): correct rule provider paths\ndocs(overwrite): standardize encrypted DNS metadata\nrefactor(overwrite): rename providers with COCR prefix\nchore(overwrite): sync upstream overwrite submodules\n```\n\nAn override that references rules is still scoped to `overwrite` when the\nchanged artifact is the override itself.\n\nDo not use `rules`, `module`, `modules`, or `openclash` merely because an\noverride contains `rules` or `rule-providers`.\n\n### Shell utilities\n\nFor files under:\n\n```text\nshell/**\n```\n\nuse:\n\n```text\nshell\n```\n\nExamples:\n\n```text\nfeat(shell): verify OpenClash startup after updates\nfix(shell): restore package sources after failure\nperf(shell): reduce repeated release metadata requests\ndocs(shell): clarify full update behavior\ntest(shell): cover installer rollback paths\n```\n\n### Sub-Store scripts\n\nFor files under:\n\n```text\nscript/sub-store/**\n```\n\nuse:\n\n```text\nsubstore\n```\n\nExamples:\n\n```text\nfeat(substore): filter nodes without IPv6 egress\nfix(substore): preserve nodes with valid IPv6 routes\ntest(substore): cover mixed IPv4 and IPv6 nodes\n```\n\n### Python maintenance tools\n\nChoose the scope from the tool's target rather than from the `py/` directory.\n\nExamples:\n\n```text\npy/generate_rules.py           -> rules\npy/generate_game_cdn.py        -> rules\npy/update_encrypted_dns.py     -> rules\npy/sync_installer_common.py    -> shell\n```\n\nTests inherit the target scope:\n\n```text\ntest(rules): cover empty provider generation\ntest(shell): verify shared installer synchronization\n```\n\nDo not use `python`, `py`, or `script` as a scope unless the Python tooling\nitself becomes an independent repository component.\n\n### GitHub Actions and supporting scripts\n\nFor:\n\n```text\n.github/workflows/**\n.github/scripts/**\n```\n\nuse `ci` when the primary change affects automation.\n\nSelect the scope from the automation's responsibility:\n\n```text\nrule generation or rule refresh          -> rules\nrepository validation                    -> validation\nwiki publishing or backup                -> wiki\nGitHub Pages deployment                   -> pages\nDependabot automation                     -> deps\nCodeQL or security scanning               -> security\njsDelivr cache purging                    -> cdn\nOpenClash overwrite submodule syncing     -> overwrite\ncross-workflow concurrency or permissions -> workflow\n```\n\nExamples:\n\n```text\nci(rules): serialize generated rule commits\nci(validation): validate Sub-Store filter syntax\nci(wiki): back up wiki before publishing\nci(pages): pin documentation build dependencies\nci(overwrite): prevent stale submodule sync pushes\nci(workflow): share the main branch writer queue\n```\n\nDo not automatically use `ci(workflow)` for every file under\n`.github/workflows/`.\n\n### Dependencies\n\nFor routine dependency or pinned action updates, use:\n\n```text\nchore(deps): bump actions checkout to v7.0.1\nchore(deps): update CodeQL actions\n```\n\nUse `fix(deps)` only when a dependency change corrects an actual compatibility\nor security defect demonstrated by the change.\n\n### Archived files\n\nUse the scope of the owning component.\n\nMention `archived` in the subject only when moving, restoring, documenting, or\nremoving archived resources is the primary purpose.\n\nChanges that affect only archived resources are normally `docs`, `chore`, or\n`refactor`, not `feat`.\n\n## Multiple-file commits\n\nDetermine whether all staged files serve one coherent objective.\n\nApply these rules:\n\n1. Implementation plus tests:\n\n   * describe the implementation;\n   * do not title the commit as a test change.\n\n2. Implementation plus documentation:\n\n   * describe the implementation;\n   * mention documentation only in the body when needed.\n\n3. Source rule plus generated providers:\n\n   * describe the source-rule change;\n   * do not title the commit as regeneration.\n\n4. Workflow plus supporting script:\n\n   * use `ci`;\n   * scope it to the automation's actual purpose.\n\n5. Renames across several files:\n\n   * describe the shared renamed concept;\n   * use the owning component as scope.\n\n6. Several files with one corrected defect:\n\n   * use `fix`;\n   * name the defect or corrected behavior.\n\n7. Truly unrelated changes:\n\n   * describe the highest-impact intentional change in the title;\n   * summarize secondary changes in the body;\n   * never invent a vague umbrella statement;\n   * do not use `chore(repo)` merely to avoid identifying the primary change.\n\nDo not join unrelated changes with a generic subject such as:\n\n```text\nupdate rules and workflows\nimprove repository files\nmake various fixes\nupdate configuration and docs\n```\n\n## Subject-writing rules\n\nThe subject must answer:\n\n```text\nWhat concrete behavior, resource, data set, or defect changed?\n```\n\nPrefer specific verbs such as:\n\n```text\nadd\nremove\nblock\nallow\nroute\ndirect\nreject\nset\ncorrect\nrestore\nprevent\nvalidate\ngenerate\nregenerate\nrefresh\nsync\nrename\ndocument\nclarify\npin\nbump\n```\n\nAvoid weak verbs unless followed by a precise object and effect:\n\n```text\nupdate\nchange\nimprove\nmodify\nadjust\nenhance\noptimize\nclean up\n```\n\nAvoid subjects that merely restate a filename.\n\nIncorrect:\n\n```text\nfeat(overwrite): add Set_GeoIP_Database_URL.conf\n```\n\nCorrect:\n\n```text\nfeat(overwrite): set GeoIP database sources\n```\n\nDo not include implementation details when the observable effect is clearer.\n\nIncorrect:\n\n```text\nfeat(overwrite): add CHNR_CUSTOM_URL variables\n```\n\nCorrect:\n\n```text\nfeat(overwrite): set mainland IP whitelist sources\n```\n\nUse file or resource names only when they are established public names and\nprovide the clearest description.\n\n## Prohibited vague messages\n\nNever generate titles such as:\n\n```text\nupdate files\nupdate rules\nupdate config\nchange configuration\nfix bug\nmisc changes\nvarious improvements\nimprove metadata\nenhance workflow\nrefactor code\nclean up files\nsync changes\nadjust settings\n```\n\nNever claim:\n\n```text\nimprove performance\nincrease stability\nfix compatibility\nenhance security\n```\n\nunless the diff specifically demonstrates that effect.\n\n## Repository-specific examples\n\nGood:\n\n```text\nfeat(rules): add Alibaba mainland IP ranges\nfeat(rules): add hbymfswz.com to direct rules\nfix(rules): remove an invalid Steam CDN prefix\nchore(rules): refresh encrypted DNS sources\nchore(rules): regenerate derived rule files\n\nfeat(overwrite): add encrypted DNS blocking override\nfeat(overwrite): add direct game download rules\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): set mainland IP whitelist sources\nfix(overwrite): correct rule provider paths\ndocs(overwrite): standardize encrypted DNS metadata\nrefactor(overwrite): rename providers with COCR prefix\nchore(overwrite): sync upstream overwrite submodules\n\nfeat(subconverter): add gaming download policy\nfix(subconverter): preserve fallback rule ordering\nchore(subconverter): regenerate mainland template\n\nfeat(config): add IPv6 DNS routing example\nfix(config): correct GeoSite rule ordering\n\nfeat(shell): verify OpenClash service startup\nfix(shell): restore package feeds on failed installation\nperf(shell): reuse fetched release metadata\ndocs(shell): clarify lightweight update exclusions\ntest(shell): cover missing package manager handling\n\nfeat(substore): filter nodes without IPv6 egress\nfix(substore): retain dual-stack nodes\ntest(substore): cover empty node collections\n\nci(rules): serialize generated rule commits\nci(validation): validate complete Mihomo templates\nci(wiki): prevent empty wiki backup commits\nci(overwrite): reset stale submodule sync state\nci(cdn): purge changed rule resources\nci(workflow): serialize main branch writers\n\ndocs(readme): expand configuration resource guide\ndocs(wiki): clarify Fake-IP DNS routing\nbuild(docs): pin MkDocs dependencies\nchore(deps): bump CodeQL actions\n```\n\nIncorrect:\n\n```text\nfeat(module): add GeoIP config\nfeat(rules): add Direct Game Download overwrite\nfix(overwrite): improve metadata\nchore(rule): update Encrypted_DNS.list\nci(workflows): improve automation\ndocs(script): update README\nchore(config): update OpenClash rule sources\n```\n\nCorrected versions:\n\n```text\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): add direct game download rules\ndocs(overwrite): standardize encrypted DNS metadata\nchore(rules): refresh encrypted DNS sources\nci(rules): prevent stale generated rule commits\ndocs(shell): clarify installer usage\nchore(subconverter): refresh rule source references\n```\n\n## Optional body rules\n\nGenerate a body only when it adds information that cannot fit in the title.\n\nWhen a body is needed:\n\n* leave one blank line after the title;\n* explain what changed and why;\n* mention important secondary changes;\n* do not repeat the title;\n* do not invent validation results;\n* mention tests only when the diff or available context shows they were run;\n* wrap body lines at approximately 72 characters where practical.\n\n## Final validation checklist\n\nBefore returning a commit message, verify all of the following:\n\n1. The title reflects the actual diff.\n2. The type matches the semantic effect.\n3. The scope uses the repository's canonical vocabulary.\n4. The scope identifies the owning component, not an incidental keyword.\n5. Source files and generated files are correctly distinguished.\n6. Comment-only changes use `docs`.\n7. Automated refreshes use `chore` unless automation behavior itself changed.\n8. Workflow changes use a functional scope.\n9. The subject names a concrete object or behavior.\n10. No effect or test result was invented.\n11. The complete title is no longer than 72 characters.\n12. The title contains no trailing period.\n13. The output contains one best commit title.\n"},"files":{".github/copilot-instructions.md":"# Commit message generation rules\n\nGenerate commit messages from the actual staged diff, not merely from file\nnames, directory names, or the number of changed files.\n\nThe commit title must precisely describe the primary intentional change.\n\n## Output format\n\nUse Conventional Commits:\n\n```text\ntype(scope): subject\n```\n\nThe first line must be a complete and accurate title that can stand alone.\n\nGenerate a body only when the staged changes contain multiple inseparable\ndetails or require important rationale. Never rely on the body to correct a\nvague or inaccurate title.\n\n## Required analysis before generating the title\n\nBefore writing the commit message, silently perform these steps:\n\n1. Inspect every staged file and its actual diff.\n2. Identify the primary intentional change.\n3. Distinguish:\n\n   * behavior changes from documentation changes;\n   * source files from generated files;\n   * manual changes from automated refreshes;\n   * implementation changes from accompanying tests and documentation;\n   * functional workflow changes from routine dependency updates.\n4. Determine what the repository will do differently after the commit.\n5. Select the type and scope from the semantic effect of the change.\n6. Write a subject that names the concrete resource, behavior, or defect.\n7. Verify the complete title length before returning it.\n\nDo not infer functionality from a filename alone.\n\nDo not claim an effect that is not demonstrated by the diff.\n\n## Hard title requirements\n\n* Use English only.\n* Use exactly the format `type(scope): subject`.\n* Keep the complete title, including type and scope, at 72 characters or fewer.\n* Prefer 50–65 characters when accuracy is not reduced.\n* Use a lowercase type and lowercase scope.\n* Begin the subject with a lowercase imperative verb unless it starts with a\n  proper name or established acronym.\n* Do not end the subject with a period.\n* Do not include Markdown, quotation marks, issue numbers, or a trailing colon.\n* Do not repeat the type or scope in the subject.\n* Preserve established names and capitalization:\n\n  * OpenClash\n  * Mihomo\n  * GeoIP\n  * GeoSite\n  * DNS\n  * IPv4\n  * IPv6\n  * YAML\n  * MRS\n  * CDN\n  * COCR\n  * Sub-Store\n  * GitHub Actions\n  * jsDelivr\n* Return one best title, not several alternatives.\n\nBefore returning the title, count every character. If it exceeds 72\ncharacters, shorten the subject without removing the concrete object or effect.\n\n## Allowed types\n\nUse only:\n\n```text\nfeat, fix, docs, style, refactor, perf, test, build, ci, chore, revert\n```\n\nChoose the type according to the actual semantic effect.\n\n### `feat`\n\nUse `feat` for a new user-visible capability, usable resource, routing\nbehavior, configuration option, script feature, or automation capability.\n\nExamples include:\n\n* adding a new manually maintained direct or proxy rule;\n* adding a new OpenClash override;\n* adding a new Subconverter policy or configuration capability;\n* adding a new Shell-script operation;\n* adding a new validation or publishing capability.\n\nCreating a new file does not automatically make the change a feature.\n\n### `fix`\n\nUse `fix` only when the diff corrects incorrect behavior, incorrect data, a\nbroken path, an invalid rule, a failed workflow, or another identifiable\ndefect.\n\nThe subject must state what was corrected.\n\nDo not use `fix` for:\n\n* clearer wording;\n* additional comments;\n* metadata changes;\n* formatting;\n* general cleanup;\n* speculative hardening without an identifiable defect.\n\n### `docs`\n\nUse `docs` when all meaningful changes affect documentation, comments,\ninstructions, examples, descriptions, or metadata intended for humans.\n\nThis rule applies even when comments are inside:\n\n* `.conf`;\n* `.ini`;\n* `.yaml`;\n* `.yml`;\n* `.sh`;\n* `.py`;\n* `.js`.\n\nComment-only changes are `docs`, not `fix`, `style`, or `chore`.\n\n### `style`\n\nUse `style` only for formatting changes with no behavior, data, documentation,\nor semantic effect.\n\nExamples include whitespace, indentation, line wrapping, or ordering that does\nnot alter meaning.\n\nDo not use `style` for rewritten documentation.\n\n### `refactor`\n\nUse `refactor` for internal restructuring that preserves intended behavior.\n\nExamples include:\n\n* renaming internal identifiers;\n* reorganizing implementation code;\n* deduplicating shared logic;\n* changing internal structure without adding a feature or fixing a defect.\n\nA rename that changes only provider identifiers should use `refactor`, while\nits scope must still identify the owning repository component.\n\n### `perf`\n\nUse `perf` only when the primary purpose is a measurable or clearly\ndemonstrated performance improvement.\n\nDo not infer a performance improvement merely because code became shorter.\n\n### `test`\n\nUse `test` when the primary change adds, removes, or corrects tests without\nchanging production behavior.\n\nTests added together with an implementation change normally inherit the\nimplementation commit's type and scope.\n\n### `build`\n\nUse `build` for build systems, packaging, documentation build dependencies, or\nartifact construction tooling when the change is not primarily a CI workflow\nchange.\n\n### `ci`\n\nUse `ci` for GitHub Actions workflows and their supporting scripts when the\nprimary change affects repository automation, validation, publishing,\nscheduling, permissions, concurrency, or automated commits.\n\nFor workflow commits, choose the scope from the workflow's purpose, not merely\n`workflow`.\n\n### `chore`\n\nUse `chore` for routine maintenance that does not introduce user-visible\nbehavior or fix a defect.\n\nTypical examples include:\n\n* regenerating derived rule files;\n* refreshing automatically collected upstream data;\n* synchronizing a submodule;\n* bumping dependencies;\n* updating pinned action versions;\n* repository housekeeping.\n\nA manually selected new routing rule is normally `feat(rules)`, not\n`chore(rules)`. An automated upstream refresh of an existing rule list is\nnormally `chore(rules)`.\n\n### `revert`\n\nUse `revert` only when the commit reverts an earlier commit.\n\nDescribe the reverted change precisely. Do not copy a malformed original title\nwithout correcting its format.\n\n## Allowed scopes\n\nPrefer one of these repository scopes:\n\n```text\nrules\noverwrite\nconfig\nsubconverter\nshell\nsubstore\nreadme\nwiki\ndocs\nvalidation\npages\nsync\ndeps\nsecurity\ncdn\nworkflow\nrepo\n```\n\nUse these spellings consistently.\n\nDo not invent singular, plural, or synonymous variants such as:\n\n```text\nrule\nmodule\nmodules\nscript\nscripts\nworkflows\nconfigs\nconfiguration\n```\n\nUse `rules`, not `rule`.\n\nUse `overwrite`, not `module` or `modules`, for OpenClash override resources.\n\nUse `shell`, not `script`, for files under `shell/`.\n\nUse `workflow` only for genuinely cross-cutting workflow infrastructure. Prefer\nthe workflow's functional scope whenever one is available.\n\nUse `repo` only as a last resort for genuinely repository-wide maintenance.\nNever use `repo` to hide unrelated staged changes.\n\n## Repository path and scope mapping\n\n### Root documentation\n\nFor:\n\n```text\nREADME.md\nDO_NOT_README.md\n```\n\nuse:\n\n```text\ndocs(readme)\n```\n\nFor a README inside a component directory, use `docs` with that component's\nscope:\n\n```text\ndocs(rules)\ndocs(overwrite)\ndocs(config)\ndocs(shell)\ndocs(substore)\n```\n\n### Wiki and documentation site\n\nFor content under:\n\n```text\nwiki/**\n```\n\nuse:\n\n```text\ndocs(wiki)\n```\n\nFor documentation-site configuration or build dependencies such as:\n\n```text\nmkdocs.yml\nrequirements-docs.txt\n```\n\nuse `docs`, `build(docs)`, or `ci(pages)` according to the actual change.\n\n### Subconverter templates\n\nFor maintained INI templates under:\n\n```text\ncfg/*.ini\n```\n\nprefer:\n\n```text\nsubconverter\n```\n\nExamples:\n\n```text\nfeat(subconverter): add gaming download policy\nfix(subconverter): correct rule provider ordering\n```\n\nFor automatically copied or derived INI templates, use `chore(subconverter)`\nwhen only generated output changes.\n\n### Complete YAML configurations\n\nFor maintained configuration files under:\n\n```text\ncfg/yaml/**\n```\n\nprefer:\n\n```text\nconfig\n```\n\nUse the actual configuration behavior in the subject, not a generic phrase\nsuch as “update config”.\n\n### Rule source files\n\nThe maintained rule sources include files such as:\n\n```text\nrule/Custom_Direct.list\nrule/Custom_Proxy.list\nrule/Steam_CDN.list\nrule/Encrypted_DNS.list\nrule/Game_Download_CDN.list\n```\n\nUse:\n\n```text\nrules\n```\n\nExamples:\n\n```text\nfeat(rules): add hbymfswz.com to direct rules\nfix(rules): move example.com from proxy to direct\nchore(rules): refresh encrypted DNS sources\n```\n\nState the affected domain, service, platform, source set, or routing behavior\nwhenever it fits within the title limit.\n\n### Generated rule files\n\nFiles under `rule/` with derived formats such as:\n\n```text\n*_Classical.yaml\n*_Classical_IP.yaml\n*_Classical_Port.yaml\n*_Domain.yaml\n*_IP.yaml\n*.mrs\n```\n\nare generated artifacts when produced from the maintained `.list` sources.\n\nWhen only generated files change, use:\n\n```text\nchore(rules): regenerate derived rule files\n```\n\nWhen a source `.list` and its generated files change together, describe the\nsource-rule change. Do not make regeneration the primary title.\n\nCorrect:\n\n```text\nfeat(rules): add Steam CDN IP ranges\n```\n\nIncorrect:\n\n```text\nchore(rules): update YAML and MRS files\n```\n\n### OpenClash override resources\n\nFor files under:\n\n```text\noverwrite/**\n```\n\nuse:\n\n```text\noverwrite\n```\n\nExamples:\n\n```text\nfeat(overwrite): add encrypted DNS blocking override\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): set mainland IP whitelist sources\nfix(overwrite): correct rule provider paths\ndocs(overwrite): standardize encrypted DNS metadata\nrefactor(overwrite): rename providers with COCR prefix\nchore(overwrite): sync upstream overwrite submodules\n```\n\nAn override that references rules is still scoped to `overwrite` when the\nchanged artifact is the override itself.\n\nDo not use `rules`, `module`, `modules`, or `openclash` merely because an\noverride contains `rules` or `rule-providers`.\n\n### Shell utilities\n\nFor files under:\n\n```text\nshell/**\n```\n\nuse:\n\n```text\nshell\n```\n\nExamples:\n\n```text\nfeat(shell): verify OpenClash startup after updates\nfix(shell): restore package sources after failure\nperf(shell): reduce repeated release metadata requests\ndocs(shell): clarify full update behavior\ntest(shell): cover installer rollback paths\n```\n\n### Sub-Store scripts\n\nFor files under:\n\n```text\nscript/sub-store/**\n```\n\nuse:\n\n```text\nsubstore\n```\n\nExamples:\n\n```text\nfeat(substore): filter nodes without IPv6 egress\nfix(substore): preserve nodes with valid IPv6 routes\ntest(substore): cover mixed IPv4 and IPv6 nodes\n```\n\n### Python maintenance tools\n\nChoose the scope from the tool's target rather than from the `py/` directory.\n\nExamples:\n\n```text\npy/generate_rules.py           -> rules\npy/generate_game_cdn.py        -> rules\npy/update_encrypted_dns.py     -> rules\npy/sync_installer_common.py    -> shell\n```\n\nTests inherit the target scope:\n\n```text\ntest(rules): cover empty provider generation\ntest(shell): verify shared installer synchronization\n```\n\nDo not use `python`, `py`, or `script` as a scope unless the Python tooling\nitself becomes an independent repository component.\n\n### GitHub Actions and supporting scripts\n\nFor:\n\n```text\n.github/workflows/**\n.github/scripts/**\n```\n\nuse `ci` when the primary change affects automation.\n\nSelect the scope from the automation's responsibility:\n\n```text\nrule generation or rule refresh          -> rules\nrepository validation                    -> validation\nwiki publishing or backup                -> wiki\nGitHub Pages deployment                   -> pages\nDependabot automation                     -> deps\nCodeQL or security scanning               -> security\njsDelivr cache purging                    -> cdn\nOpenClash overwrite submodule syncing     -> overwrite\ncross-workflow concurrency or permissions -> workflow\n```\n\nExamples:\n\n```text\nci(rules): serialize generated rule commits\nci(validation): validate Sub-Store filter syntax\nci(wiki): back up wiki before publishing\nci(pages): pin documentation build dependencies\nci(overwrite): prevent stale submodule sync pushes\nci(workflow): share the main branch writer queue\n```\n\nDo not automatically use `ci(workflow)` for every file under\n`.github/workflows/`.\n\n### Dependencies\n\nFor routine dependency or pinned action updates, use:\n\n```text\nchore(deps): bump actions checkout to v7.0.1\nchore(deps): update CodeQL actions\n```\n\nUse `fix(deps)` only when a dependency change corrects an actual compatibility\nor security defect demonstrated by the change.\n\n### Archived files\n\nUse the scope of the owning component.\n\nMention `archived` in the subject only when moving, restoring, documenting, or\nremoving archived resources is the primary purpose.\n\nChanges that affect only archived resources are normally `docs`, `chore`, or\n`refactor`, not `feat`.\n\n## Multiple-file commits\n\nDetermine whether all staged files serve one coherent objective.\n\nApply these rules:\n\n1. Implementation plus tests:\n\n   * describe the implementation;\n   * do not title the commit as a test change.\n\n2. Implementation plus documentation:\n\n   * describe the implementation;\n   * mention documentation only in the body when needed.\n\n3. Source rule plus generated providers:\n\n   * describe the source-rule change;\n   * do not title the commit as regeneration.\n\n4. Workflow plus supporting script:\n\n   * use `ci`;\n   * scope it to the automation's actual purpose.\n\n5. Renames across several files:\n\n   * describe the shared renamed concept;\n   * use the owning component as scope.\n\n6. Several files with one corrected defect:\n\n   * use `fix`;\n   * name the defect or corrected behavior.\n\n7. Truly unrelated changes:\n\n   * describe the highest-impact intentional change in the title;\n   * summarize secondary changes in the body;\n   * never invent a vague umbrella statement;\n   * do not use `chore(repo)` merely to avoid identifying the primary change.\n\nDo not join unrelated changes with a generic subject such as:\n\n```text\nupdate rules and workflows\nimprove repository files\nmake various fixes\nupdate configuration and docs\n```\n\n## Subject-writing rules\n\nThe subject must answer:\n\n```text\nWhat concrete behavior, resource, data set, or defect changed?\n```\n\nPrefer specific verbs such as:\n\n```text\nadd\nremove\nblock\nallow\nroute\ndirect\nreject\nset\ncorrect\nrestore\nprevent\nvalidate\ngenerate\nregenerate\nrefresh\nsync\nrename\ndocument\nclarify\npin\nbump\n```\n\nAvoid weak verbs unless followed by a precise object and effect:\n\n```text\nupdate\nchange\nimprove\nmodify\nadjust\nenhance\noptimize\nclean up\n```\n\nAvoid subjects that merely restate a filename.\n\nIncorrect:\n\n```text\nfeat(overwrite): add Set_GeoIP_Database_URL.conf\n```\n\nCorrect:\n\n```text\nfeat(overwrite): set GeoIP database sources\n```\n\nDo not include implementation details when the observable effect is clearer.\n\nIncorrect:\n\n```text\nfeat(overwrite): add CHNR_CUSTOM_URL variables\n```\n\nCorrect:\n\n```text\nfeat(overwrite): set mainland IP whitelist sources\n```\n\nUse file or resource names only when they are established public names and\nprovide the clearest description.\n\n## Prohibited vague messages\n\nNever generate titles such as:\n\n```text\nupdate files\nupdate rules\nupdate config\nchange configuration\nfix bug\nmisc changes\nvarious improvements\nimprove metadata\nenhance workflow\nrefactor code\nclean up files\nsync changes\nadjust settings\n```\n\nNever claim:\n\n```text\nimprove performance\nincrease stability\nfix compatibility\nenhance security\n```\n\nunless the diff specifically demonstrates that effect.\n\n## Repository-specific examples\n\nGood:\n\n```text\nfeat(rules): add Alibaba mainland IP ranges\nfeat(rules): add hbymfswz.com to direct rules\nfix(rules): remove an invalid Steam CDN prefix\nchore(rules): refresh encrypted DNS sources\nchore(rules): regenerate derived rule files\n\nfeat(overwrite): add encrypted DNS blocking override\nfeat(overwrite): add direct game download rules\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): set mainland IP whitelist sources\nfix(overwrite): correct rule provider paths\ndocs(overwrite): standardize encrypted DNS metadata\nrefactor(overwrite): rename providers with COCR prefix\nchore(overwrite): sync upstream overwrite submodules\n\nfeat(subconverter): add gaming download policy\nfix(subconverter): preserve fallback rule ordering\nchore(subconverter): regenerate mainland template\n\nfeat(config): add IPv6 DNS routing example\nfix(config): correct GeoSite rule ordering\n\nfeat(shell): verify OpenClash service startup\nfix(shell): restore package feeds on failed installation\nperf(shell): reuse fetched release metadata\ndocs(shell): clarify lightweight update exclusions\ntest(shell): cover missing package manager handling\n\nfeat(substore): filter nodes without IPv6 egress\nfix(substore): retain dual-stack nodes\ntest(substore): cover empty node collections\n\nci(rules): serialize generated rule commits\nci(validation): validate complete Mihomo templates\nci(wiki): prevent empty wiki backup commits\nci(overwrite): reset stale submodule sync state\nci(cdn): purge changed rule resources\nci(workflow): serialize main branch writers\n\ndocs(readme): expand configuration resource guide\ndocs(wiki): clarify Fake-IP DNS routing\nbuild(docs): pin MkDocs dependencies\nchore(deps): bump CodeQL actions\n```\n\nIncorrect:\n\n```text\nfeat(module): add GeoIP config\nfeat(rules): add Direct Game Download overwrite\nfix(overwrite): improve metadata\nchore(rule): update Encrypted_DNS.list\nci(workflows): improve automation\ndocs(script): update README\nchore(config): update OpenClash rule sources\n```\n\nCorrected versions:\n\n```text\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): add direct game download rules\ndocs(overwrite): standardize encrypted DNS metadata\nchore(rules): refresh encrypted DNS sources\nci(rules): prevent stale generated rule commits\ndocs(shell): clarify installer usage\nchore(subconverter): refresh rule source references\n```\n\n## Optional body rules\n\nGenerate a body only when it adds information that cannot fit in the title.\n\nWhen a body is needed:\n\n* leave one blank line after the title;\n* explain what changed and why;\n* mention important secondary changes;\n* do not repeat the title;\n* do not invent validation results;\n* mention tests only when the diff or available context shows they were run;\n* wrap body lines at approximately 72 characters where practical.\n\n## Final validation checklist\n\nBefore returning a commit message, verify all of the following:\n\n1. The title reflects the actual diff.\n2. The type matches the semantic effect.\n3. The scope uses the repository's canonical vocabulary.\n4. The scope identifies the owning component, not an incidental keyword.\n5. Source files and generated files are correctly distinguished.\n6. Comment-only changes use `docs`.\n7. Automated refreshes use `chore` unless automation behavior itself changed.\n8. Workflow changes use a functional scope.\n9. The subject names a concrete object or behavior.\n10. No effect or test result was invented.\n11. The complete title is no longer than 72 characters.\n12. The title contains no trailing period.\n13. The output contains one best commit title.\n"},"items":[{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/Aethersailor/Custom_OpenClash_Rules/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Commit message generation rules\n\nGenerate commit messages from the actual staged diff, not merely from file\nnames, directory names, or the number of changed files.\n\nThe commit title must precisely describe the primary intentional change.\n\n## Output format\n\nUse Conventional Commits:\n\n```text\ntype(scope): subject\n```\n\nThe first line must be a complete and accurate title that can stand alone.\n\nGenerate a body only when the staged changes contain multiple inseparable\ndetails or require important rationale. Never rely on the body to correct a\nvague or inaccurate title.\n\n## Required analysis before generating the title\n\nBefore writing the commit message, silently perform these steps:\n\n1. Inspect every staged file and its actual diff.\n2. Identify the primary intentional change.\n3. Distinguish:\n\n   * behavior changes from documentation changes;\n   * source files from generated files;\n   * manual changes from automated refreshes;\n   * implementation changes from accompanying tests and documentation;\n   * functional workflow changes from routine dependency updates.\n4. Determine what the repository will do differently after the commit.\n5. Select the type and scope from the semantic effect of the change.\n6. Write a subject that names the concrete resource, behavior, or defect.\n7. Verify the complete title length before returning it.\n\nDo not infer functionality from a filename alone.\n\nDo not claim an effect that is not demonstrated by the diff.\n\n## Hard title requirements\n\n* Use English only.\n* Use exactly the format `type(scope): subject`.\n* Keep the complete title, including type and scope, at 72 characters or fewer.\n* Prefer 50–65 characters when accuracy is not reduced.\n* Use a lowercase type and lowercase scope.\n* Begin the subject with a lowercase imperative verb unless it starts with a\n  proper name or established acronym.\n* Do not end the subject with a period.\n* Do not include Markdown, quotation marks, issue numbers, or a trailing colon.\n* Do not repeat the type or scope in the subject.\n* Preserve established names and capitalization:\n\n  * OpenClash\n  * Mihomo\n  * GeoIP\n  * GeoSite\n  * DNS\n  * IPv4\n  * IPv6\n  * YAML\n  * MRS\n  * CDN\n  * COCR\n  * Sub-Store\n  * GitHub Actions\n  * jsDelivr\n* Return one best title, not several alternatives.\n\nBefore returning the title, count every character. If it exceeds 72\ncharacters, shorten the subject without removing the concrete object or effect.\n\n## Allowed types\n\nUse only:\n\n```text\nfeat, fix, docs, style, refactor, perf, test, build, ci, chore, revert\n```\n\nChoose the type according to the actual semantic effect.\n\n### `feat`\n\nUse `feat` for a new user-visible capability, usable resource, routing\nbehavior, configuration option, script feature, or automation capability.\n\nExamples include:\n\n* adding a new manually maintained direct or proxy rule;\n* adding a new OpenClash override;\n* adding a new Subconverter policy or configuration capability;\n* adding a new Shell-script operation;\n* adding a new validation or publishing capability.\n\nCreating a new file does not automatically make the change a feature.\n\n### `fix`\n\nUse `fix` only when the diff corrects incorrect behavior, incorrect data, a\nbroken path, an invalid rule, a failed workflow, or another identifiable\ndefect.\n\nThe subject must state what was corrected.\n\nDo not use `fix` for:\n\n* clearer wording;\n* additional comments;\n* metadata changes;\n* formatting;\n* general cleanup;\n* speculative hardening without an identifiable defect.\n\n### `docs`\n\nUse `docs` when all meaningful changes affect documentation, comments,\ninstructions, examples, descriptions, or metadata intended for humans.\n\nThis rule applies even when comments are inside:\n\n* `.conf`;\n* `.ini`;\n* `.yaml`;\n* `.yml`;\n* `.sh`;\n* `.py`;\n* `.js`.\n\nComment-only changes are `docs`, not `fix`, `style`, or `chore`.\n\n### `style`\n\nUse `style` only for formatting changes with no behavior, data, documentation,\nor semantic effect.\n\nExamples include whitespace, indentation, line wrapping, or ordering that does\nnot alter meaning.\n\nDo not use `style` for rewritten documentation.\n\n### `refactor`\n\nUse `refactor` for internal restructuring that preserves intended behavior.\n\nExamples include:\n\n* renaming internal identifiers;\n* reorganizing implementation code;\n* deduplicating shared logic;\n* changing internal structure without adding a feature or fixing a defect.\n\nA rename that changes only provider identifiers should use `refactor`, while\nits scope must still identify the owning repository component.\n\n### `perf`\n\nUse `perf` only when the primary purpose is a measurable or clearly\ndemonstrated performance improvement.\n\nDo not infer a performance improvement merely because code became shorter.\n\n### `test`\n\nUse `test` when the primary change adds, removes, or corrects tests without\nchanging production behavior.\n\nTests added together with an implementation change normally inherit the\nimplementation commit's type and scope.\n\n### `build`\n\nUse `build` for build systems, packaging, documentation build dependencies, or\nartifact construction tooling when the change is not primarily a CI workflow\nchange.\n\n### `ci`\n\nUse `ci` for GitHub Actions workflows and their supporting scripts when the\nprimary change affects repository automation, validation, publishing,\nscheduling, permissions, concurrency, or automated commits.\n\nFor workflow commits, choose the scope from the workflow's purpose, not merely\n`workflow`.\n\n### `chore`\n\nUse `chore` for routine maintenance that does not introduce user-visible\nbehavior or fix a defect.\n\nTypical examples include:\n\n* regenerating derived rule files;\n* refreshing automatically collected upstream data;\n* synchronizing a submodule;\n* bumping dependencies;\n* updating pinned action versions;\n* repository housekeeping.\n\nA manually selected new routing rule is normally `feat(rules)`, not\n`chore(rules)`. An automated upstream refresh of an existing rule list is\nnormally `chore(rules)`.\n\n### `revert`\n\nUse `revert` only when the commit reverts an earlier commit.\n\nDescribe the reverted change precisely. Do not copy a malformed original title\nwithout correcting its format.\n\n## Allowed scopes\n\nPrefer one of these repository scopes:\n\n```text\nrules\noverwrite\nconfig\nsubconverter\nshell\nsubstore\nreadme\nwiki\ndocs\nvalidation\npages\nsync\ndeps\nsecurity\ncdn\nworkflow\nrepo\n```\n\nUse these spellings consistently.\n\nDo not invent singular, plural, or synonymous variants such as:\n\n```text\nrule\nmodule\nmodules\nscript\nscripts\nworkflows\nconfigs\nconfiguration\n```\n\nUse `rules`, not `rule`.\n\nUse `overwrite`, not `module` or `modules`, for OpenClash override resources.\n\nUse `shell`, not `script`, for files under `shell/`.\n\nUse `workflow` only for genuinely cross-cutting workflow infrastructure. Prefer\nthe workflow's functional scope whenever one is available.\n\nUse `repo` only as a last resort for genuinely repository-wide maintenance.\nNever use `repo` to hide unrelated staged changes.\n\n## Repository path and scope mapping\n\n### Root documentation\n\nFor:\n\n```text\nREADME.md\nDO_NOT_README.md\n```\n\nuse:\n\n```text\ndocs(readme)\n```\n\nFor a README inside a component directory, use `docs` with that component's\nscope:\n\n```text\ndocs(rules)\ndocs(overwrite)\ndocs(config)\ndocs(shell)\ndocs(substore)\n```\n\n### Wiki and documentation site\n\nFor content under:\n\n```text\nwiki/**\n```\n\nuse:\n\n```text\ndocs(wiki)\n```\n\nFor documentation-site configuration or build dependencies such as:\n\n```text\nmkdocs.yml\nrequirements-docs.txt\n```\n\nuse `docs`, `build(docs)`, or `ci(pages)` according to the actual change.\n\n### Subconverter templates\n\nFor maintained INI templates under:\n\n```text\ncfg/*.ini\n```\n\nprefer:\n\n```text\nsubconverter\n```\n\nExamples:\n\n```text\nfeat(subconverter): add gaming download policy\nfix(subconverter): correct rule provider ordering\n```\n\nFor automatically copied or derived INI templates, use `chore(subconverter)`\nwhen only generated output changes.\n\n### Complete YAML configurations\n\nFor maintained configuration files under:\n\n```text\ncfg/yaml/**\n```\n\nprefer:\n\n```text\nconfig\n```\n\nUse the actual configuration behavior in the subject, not a generic phrase\nsuch as “update config”.\n\n### Rule source files\n\nThe maintained rule sources include files such as:\n\n```text\nrule/Custom_Direct.list\nrule/Custom_Proxy.list\nrule/Steam_CDN.list\nrule/Encrypted_DNS.list\nrule/Game_Download_CDN.list\n```\n\nUse:\n\n```text\nrules\n```\n\nExamples:\n\n```text\nfeat(rules): add hbymfswz.com to direct rules\nfix(rules): move example.com from proxy to direct\nchore(rules): refresh encrypted DNS sources\n```\n\nState the affected domain, service, platform, source set, or routing behavior\nwhenever it fits within the title limit.\n\n### Generated rule files\n\nFiles under `rule/` with derived formats such as:\n\n```text\n*_Classical.yaml\n*_Classical_IP.yaml\n*_Classical_Port.yaml\n*_Domain.yaml\n*_IP.yaml\n*.mrs\n```\n\nare generated artifacts when produced from the maintained `.list` sources.\n\nWhen only generated files change, use:\n\n```text\nchore(rules): regenerate derived rule files\n```\n\nWhen a source `.list` and its generated files change together, describe the\nsource-rule change. Do not make regeneration the primary title.\n\nCorrect:\n\n```text\nfeat(rules): add Steam CDN IP ranges\n```\n\nIncorrect:\n\n```text\nchore(rules): update YAML and MRS files\n```\n\n### OpenClash override resources\n\nFor files under:\n\n```text\noverwrite/**\n```\n\nuse:\n\n```text\noverwrite\n```\n\nExamples:\n\n```text\nfeat(overwrite): add encrypted DNS blocking override\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): set mainland IP whitelist sources\nfix(overwrite): correct rule provider paths\ndocs(overwrite): standardize encrypted DNS metadata\nrefactor(overwrite): rename providers with COCR prefix\nchore(overwrite): sync upstream overwrite submodules\n```\n\nAn override that references rules is still scoped to `overwrite` when the\nchanged artifact is the override itself.\n\nDo not use `rules`, `module`, `modules`, or `openclash` merely because an\noverride contains `rules` or `rule-providers`.\n\n### Shell utilities\n\nFor files under:\n\n```text\nshell/**\n```\n\nuse:\n\n```text\nshell\n```\n\nExamples:\n\n```text\nfeat(shell): verify OpenClash startup after updates\nfix(shell): restore package sources after failure\nperf(shell): reduce repeated release metadata requests\ndocs(shell): clarify full update behavior\ntest(shell): cover installer rollback paths\n```\n\n### Sub-Store scripts\n\nFor files under:\n\n```text\nscript/sub-store/**\n```\n\nuse:\n\n```text\nsubstore\n```\n\nExamples:\n\n```text\nfeat(substore): filter nodes without IPv6 egress\nfix(substore): preserve nodes with valid IPv6 routes\ntest(substore): cover mixed IPv4 and IPv6 nodes\n```\n\n### Python maintenance tools\n\nChoose the scope from the tool's target rather than from the `py/` directory.\n\nExamples:\n\n```text\npy/generate_rules.py           -> rules\npy/generate_game_cdn.py        -> rules\npy/update_encrypted_dns.py     -> rules\npy/sync_installer_common.py    -> shell\n```\n\nTests inherit the target scope:\n\n```text\ntest(rules): cover empty provider generation\ntest(shell): verify shared installer synchronization\n```\n\nDo not use `python`, `py`, or `script` as a scope unless the Python tooling\nitself becomes an independent repository component.\n\n### GitHub Actions and supporting scripts\n\nFor:\n\n```text\n.github/workflows/**\n.github/scripts/**\n```\n\nuse `ci` when the primary change affects automation.\n\nSelect the scope from the automation's responsibility:\n\n```text\nrule generation or rule refresh          -> rules\nrepository validation                    -> validation\nwiki publishing or backup                -> wiki\nGitHub Pages deployment                   -> pages\nDependabot automation                     -> deps\nCodeQL or security scanning               -> security\njsDelivr cache purging                    -> cdn\nOpenClash overwrite submodule syncing     -> overwrite\ncross-workflow concurrency or permissions -> workflow\n```\n\nExamples:\n\n```text\nci(rules): serialize generated rule commits\nci(validation): validate Sub-Store filter syntax\nci(wiki): back up wiki before publishing\nci(pages): pin documentation build dependencies\nci(overwrite): prevent stale submodule sync pushes\nci(workflow): share the main branch writer queue\n```\n\nDo not automatically use `ci(workflow)` for every file under\n`.github/workflows/`.\n\n### Dependencies\n\nFor routine dependency or pinned action updates, use:\n\n```text\nchore(deps): bump actions checkout to v7.0.1\nchore(deps): update CodeQL actions\n```\n\nUse `fix(deps)` only when a dependency change corrects an actual compatibility\nor security defect demonstrated by the change.\n\n### Archived files\n\nUse the scope of the owning component.\n\nMention `archived` in the subject only when moving, restoring, documenting, or\nremoving archived resources is the primary purpose.\n\nChanges that affect only archived resources are normally `docs`, `chore`, or\n`refactor`, not `feat`.\n\n## Multiple-file commits\n\nDetermine whether all staged files serve one coherent objective.\n\nApply these rules:\n\n1. Implementation plus tests:\n\n   * describe the implementation;\n   * do not title the commit as a test change.\n\n2. Implementation plus documentation:\n\n   * describe the implementation;\n   * mention documentation only in the body when needed.\n\n3. Source rule plus generated providers:\n\n   * describe the source-rule change;\n   * do not title the commit as regeneration.\n\n4. Workflow plus supporting script:\n\n   * use `ci`;\n   * scope it to the automation's actual purpose.\n\n5. Renames across several files:\n\n   * describe the shared renamed concept;\n   * use the owning component as scope.\n\n6. Several files with one corrected defect:\n\n   * use `fix`;\n   * name the defect or corrected behavior.\n\n7. Truly unrelated changes:\n\n   * describe the highest-impact intentional change in the title;\n   * summarize secondary changes in the body;\n   * never invent a vague umbrella statement;\n   * do not use `chore(repo)` merely to avoid identifying the primary change.\n\nDo not join unrelated changes with a generic subject such as:\n\n```text\nupdate rules and workflows\nimprove repository files\nmake various fixes\nupdate configuration and docs\n```\n\n## Subject-writing rules\n\nThe subject must answer:\n\n```text\nWhat concrete behavior, resource, data set, or defect changed?\n```\n\nPrefer specific verbs such as:\n\n```text\nadd\nremove\nblock\nallow\nroute\ndirect\nreject\nset\ncorrect\nrestore\nprevent\nvalidate\ngenerate\nregenerate\nrefresh\nsync\nrename\ndocument\nclarify\npin\nbump\n```\n\nAvoid weak verbs unless followed by a precise object and effect:\n\n```text\nupdate\nchange\nimprove\nmodify\nadjust\nenhance\noptimize\nclean up\n```\n\nAvoid subjects that merely restate a filename.\n\nIncorrect:\n\n```text\nfeat(overwrite): add Set_GeoIP_Database_URL.conf\n```\n\nCorrect:\n\n```text\nfeat(overwrite): set GeoIP database sources\n```\n\nDo not include implementation details when the observable effect is clearer.\n\nIncorrect:\n\n```text\nfeat(overwrite): add CHNR_CUSTOM_URL variables\n```\n\nCorrect:\n\n```text\nfeat(overwrite): set mainland IP whitelist sources\n```\n\nUse file or resource names only when they are established public names and\nprovide the clearest description.\n\n## Prohibited vague messages\n\nNever generate titles such as:\n\n```text\nupdate files\nupdate rules\nupdate config\nchange configuration\nfix bug\nmisc changes\nvarious improvements\nimprove metadata\nenhance workflow\nrefactor code\nclean up files\nsync changes\nadjust settings\n```\n\nNever claim:\n\n```text\nimprove performance\nincrease stability\nfix compatibility\nenhance security\n```\n\nunless the diff specifically demonstrates that effect.\n\n## Repository-specific examples\n\nGood:\n\n```text\nfeat(rules): add Alibaba mainland IP ranges\nfeat(rules): add hbymfswz.com to direct rules\nfix(rules): remove an invalid Steam CDN prefix\nchore(rules): refresh encrypted DNS sources\nchore(rules): regenerate derived rule files\n\nfeat(overwrite): add encrypted DNS blocking override\nfeat(overwrite): add direct game download rules\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): set mainland IP whitelist sources\nfix(overwrite): correct rule provider paths\ndocs(overwrite): standardize encrypted DNS metadata\nrefactor(overwrite): rename providers with COCR prefix\nchore(overwrite): sync upstream overwrite submodules\n\nfeat(subconverter): add gaming download policy\nfix(subconverter): preserve fallback rule ordering\nchore(subconverter): regenerate mainland template\n\nfeat(config): add IPv6 DNS routing example\nfix(config): correct GeoSite rule ordering\n\nfeat(shell): verify OpenClash service startup\nfix(shell): restore package feeds on failed installation\nperf(shell): reuse fetched release metadata\ndocs(shell): clarify lightweight update exclusions\ntest(shell): cover missing package manager handling\n\nfeat(substore): filter nodes without IPv6 egress\nfix(substore): retain dual-stack nodes\ntest(substore): cover empty node collections\n\nci(rules): serialize generated rule commits\nci(validation): validate complete Mihomo templates\nci(wiki): prevent empty wiki backup commits\nci(overwrite): reset stale submodule sync state\nci(cdn): purge changed rule resources\nci(workflow): serialize main branch writers\n\ndocs(readme): expand configuration resource guide\ndocs(wiki): clarify Fake-IP DNS routing\nbuild(docs): pin MkDocs dependencies\nchore(deps): bump CodeQL actions\n```\n\nIncorrect:\n\n```text\nfeat(module): add GeoIP config\nfeat(rules): add Direct Game Download overwrite\nfix(overwrite): improve metadata\nchore(rule): update Encrypted_DNS.list\nci(workflows): improve automation\ndocs(script): update README\nchore(config): update OpenClash rule sources\n```\n\nCorrected versions:\n\n```text\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): add direct game download rules\ndocs(overwrite): standardize encrypted DNS metadata\nchore(rules): refresh encrypted DNS sources\nci(rules): prevent stale generated rule commits\ndocs(shell): clarify installer usage\nchore(subconverter): refresh rule source references\n```\n\n## Optional body rules\n\nGenerate a body only when it adds information that cannot fit in the title.\n\nWhen a body is needed:\n\n* leave one blank line after the title;\n* explain what changed and why;\n* mention important secondary changes;\n* do not repeat the title;\n* do not invent validation results;\n* mention tests only when the diff or available context shows they were run;\n* wrap body lines at approximately 72 characters where practical.\n\n## Final validation checklist\n\nBefore returning a commit message, verify all of the following:\n\n1. The title reflects the actual diff.\n2. The type matches the semantic effect.\n3. The scope uses the repository's canonical vocabulary.\n4. The scope identifies the owning component, not an incidental keyword.\n5. Source files and generated files are correctly distinguished.\n6. Comment-only changes use `docs`.\n7. Automated refreshes use `chore` unless automation behavior itself changed.\n8. Workflow changes use a functional scope.\n9. The subject names a concrete object or behavior.\n10. No effect or test result was invented.\n11. The complete title is no longer than 72 characters.\n12. The title contains no trailing period.\n13. The output contains one best commit title.\n","isInternal":false,"tokens":4135,"sizeBytes":19085}],"systemPromptSnippet":"<yakaai_skills repo=\"Aethersailor/Custom_OpenClash_Rules\">\n<!-- File: .github/copilot-instructions.md (Tokens: ~4135 | Category: copilot-instructions) -->\n# Commit message generation rules\n\nGenerate commit messages from the actual staged diff, not merely from file\nnames, directory names, or the number of changed files.\n\nThe commit title must precisely describe the primary intentional change.\n\n## Output format\n\nUse Conventional Commits:\n\n```text\ntype(scope): subject\n```\n\nThe first line must be a complete and accurate title that can stand alone.\n\nGenerate a body only when the staged changes contain multiple inseparable\ndetails or require important rationale. Never rely on the body to correct a\nvague or inaccurate title.\n\n## Required analysis before generating the title\n\nBefore writing the commit message, silently perform these steps:\n\n1. Inspect every staged file and its actual diff.\n2. Identify the primary intentional change.\n3. Distinguish:\n\n   * behavior changes from documentation changes;\n   * source files from generated files;\n   * manual changes from automated refreshes;\n   * implementation changes from accompanying tests and documentation;\n   * functional workflow changes from routine dependency updates.\n4. Determine what the repository will do differently after the commit.\n5. Select the type and scope from the semantic effect of the change.\n6. Write a subject that names the concrete resource, behavior, or defect.\n7. Verify the complete title length before returning it.\n\nDo not infer functionality from a filename alone.\n\nDo not claim an effect that is not demonstrated by the diff.\n\n## Hard title requirements\n\n* Use English only.\n* Use exactly the format `type(scope): subject`.\n* Keep the complete title, including type and scope, at 72 characters or fewer.\n* Prefer 50–65 characters when accuracy is not reduced.\n* Use a lowercase type and lowercase scope.\n* Begin the subject with a lowercase imperative verb unless it starts with a\n  proper name or established acronym.\n* Do not end the subject with a period.\n* Do not include Markdown, quotation marks, issue numbers, or a trailing colon.\n* Do not repeat the type or scope in the subject.\n* Preserve established names and capitalization:\n\n  * OpenClash\n  * Mihomo\n  * GeoIP\n  * GeoSite\n  * DNS\n  * IPv4\n  * IPv6\n  * YAML\n  * MRS\n  * CDN\n  * COCR\n  * Sub-Store\n  * GitHub Actions\n  * jsDelivr\n* Return one best title, not several alternatives.\n\nBefore returning the title, count every character. If it exceeds 72\ncharacters, shorten the subject without removing the concrete object or effect.\n\n## Allowed types\n\nUse only:\n\n```text\nfeat, fix, docs, style, refactor, perf, test, build, ci, chore, revert\n```\n\nChoose the type according to the actual semantic effect.\n\n### `feat`\n\nUse `feat` for a new user-visible capability, usable resource, routing\nbehavior, configuration option, script feature, or automation capability.\n\nExamples include:\n\n* adding a new manually maintained direct or proxy rule;\n* adding a new OpenClash override;\n* adding a new Subconverter policy or configuration capability;\n* adding a new Shell-script operation;\n* adding a new validation or publishing capability.\n\nCreating a new file does not automatically make the change a feature.\n\n### `fix`\n\nUse `fix` only when the diff corrects incorrect behavior, incorrect data, a\nbroken path, an invalid rule, a failed workflow, or another identifiable\ndefect.\n\nThe subject must state what was corrected.\n\nDo not use `fix` for:\n\n* clearer wording;\n* additional comments;\n* metadata changes;\n* formatting;\n* general cleanup;\n* speculative hardening without an identifiable defect.\n\n### `docs`\n\nUse `docs` when all meaningful changes affect documentation, comments,\ninstructions, examples, descriptions, or metadata intended for humans.\n\nThis rule applies even when comments are inside:\n\n* `.conf`;\n* `.ini`;\n* `.yaml`;\n* `.yml`;\n* `.sh`;\n* `.py`;\n* `.js`.\n\nComment-only changes are `docs`, not `fix`, `style`, or `chore`.\n\n### `style`\n\nUse `style` only for formatting changes with no behavior, data, documentation,\nor semantic effect.\n\nExamples include whitespace, indentation, line wrapping, or ordering that does\nnot alter meaning.\n\nDo not use `style` for rewritten documentation.\n\n### `refactor`\n\nUse `refactor` for internal restructuring that preserves intended behavior.\n\nExamples include:\n\n* renaming internal identifiers;\n* reorganizing implementation code;\n* deduplicating shared logic;\n* changing internal structure without adding a feature or fixing a defect.\n\nA rename that changes only provider identifiers should use `refactor`, while\nits scope must still identify the owning repository component.\n\n### `perf`\n\nUse `perf` only when the primary purpose is a measurable or clearly\ndemonstrated performance improvement.\n\nDo not infer a performance improvement merely because code became shorter.\n\n### `test`\n\nUse `test` when the primary change adds, removes, or corrects tests without\nchanging production behavior.\n\nTests added together with an implementation change normally inherit the\nimplementation commit's type and scope.\n\n### `build`\n\nUse `build` for build systems, packaging, documentation build dependencies, or\nartifact construction tooling when the change is not primarily a CI workflow\nchange.\n\n### `ci`\n\nUse `ci` for GitHub Actions workflows and their supporting scripts when the\nprimary change affects repository automation, validation, publishing,\nscheduling, permissions, concurrency, or automated commits.\n\nFor workflow commits, choose the scope from the workflow's purpose, not merely\n`workflow`.\n\n### `chore`\n\nUse `chore` for routine maintenance that does not introduce user-visible\nbehavior or fix a defect.\n\nTypical examples include:\n\n* regenerating derived rule files;\n* refreshing automatically collected upstream data;\n* synchronizing a submodule;\n* bumping dependencies;\n* updating pinned action versions;\n* repository housekeeping.\n\nA manually selected new routing rule is normally `feat(rules)`, not\n`chore(rules)`. An automated upstream refresh of an existing rule list is\nnormally `chore(rules)`.\n\n### `revert`\n\nUse `revert` only when the commit reverts an earlier commit.\n\nDescribe the reverted change precisely. Do not copy a malformed original title\nwithout correcting its format.\n\n## Allowed scopes\n\nPrefer one of these repository scopes:\n\n```text\nrules\noverwrite\nconfig\nsubconverter\nshell\nsubstore\nreadme\nwiki\ndocs\nvalidation\npages\nsync\ndeps\nsecurity\ncdn\nworkflow\nrepo\n```\n\nUse these spellings consistently.\n\nDo not invent singular, plural, or synonymous variants such as:\n\n```text\nrule\nmodule\nmodules\nscript\nscripts\nworkflows\nconfigs\nconfiguration\n```\n\nUse `rules`, not `rule`.\n\nUse `overwrite`, not `module` or `modules`, for OpenClash override resources.\n\nUse `shell`, not `script`, for files under `shell/`.\n\nUse `workflow` only for genuinely cross-cutting workflow infrastructure. Prefer\nthe workflow's functional scope whenever one is available.\n\nUse `repo` only as a last resort for genuinely repository-wide maintenance.\nNever use `repo` to hide unrelated staged changes.\n\n## Repository path and scope mapping\n\n### Root documentation\n\nFor:\n\n```text\nREADME.md\nDO_NOT_README.md\n```\n\nuse:\n\n```text\ndocs(readme)\n```\n\nFor a README inside a component directory, use `docs` with that component's\nscope:\n\n```text\ndocs(rules)\ndocs(overwrite)\ndocs(config)\ndocs(shell)\ndocs(substore)\n```\n\n### Wiki and documentation site\n\nFor content under:\n\n```text\nwiki/**\n```\n\nuse:\n\n```text\ndocs(wiki)\n```\n\nFor documentation-site configuration or build dependencies such as:\n\n```text\nmkdocs.yml\nrequirements-docs.txt\n```\n\nuse `docs`, `build(docs)`, or `ci(pages)` according to the actual change.\n\n### Subconverter templates\n\nFor maintained INI templates under:\n\n```text\ncfg/*.ini\n```\n\nprefer:\n\n```text\nsubconverter\n```\n\nExamples:\n\n```text\nfeat(subconverter): add gaming download policy\nfix(subconverter): correct rule provider ordering\n```\n\nFor automatically copied or derived INI templates, use `chore(subconverter)`\nwhen only generated output changes.\n\n### Complete YAML configurations\n\nFor maintained configuration files under:\n\n```text\ncfg/yaml/**\n```\n\nprefer:\n\n```text\nconfig\n```\n\nUse the actual configuration behavior in the subject, not a generic phrase\nsuch as “update config”.\n\n### Rule source files\n\nThe maintained rule sources include files such as:\n\n```text\nrule/Custom_Direct.list\nrule/Custom_Proxy.list\nrule/Steam_CDN.list\nrule/Encrypted_DNS.list\nrule/Game_Download_CDN.list\n```\n\nUse:\n\n```text\nrules\n```\n\nExamples:\n\n```text\nfeat(rules): add hbymfswz.com to direct rules\nfix(rules): move example.com from proxy to direct\nchore(rules): refresh encrypted DNS sources\n```\n\nState the affected domain, service, platform, source set, or routing behavior\nwhenever it fits within the title limit.\n\n### Generated rule files\n\nFiles under `rule/` with derived formats such as:\n\n```text\n*_Classical.yaml\n*_Classical_IP.yaml\n*_Classical_Port.yaml\n*_Domain.yaml\n*_IP.yaml\n*.mrs\n```\n\nare generated artifacts when produced from the maintained `.list` sources.\n\nWhen only generated files change, use:\n\n```text\nchore(rules): regenerate derived rule files\n```\n\nWhen a source `.list` and its generated files change together, describe the\nsource-rule change. Do not make regeneration the primary title.\n\nCorrect:\n\n```text\nfeat(rules): add Steam CDN IP ranges\n```\n\nIncorrect:\n\n```text\nchore(rules): update YAML and MRS files\n```\n\n### OpenClash override resources\n\nFor files under:\n\n```text\noverwrite/**\n```\n\nuse:\n\n```text\noverwrite\n```\n\nExamples:\n\n```text\nfeat(overwrite): add encrypted DNS blocking override\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): set mainland IP whitelist sources\nfix(overwrite): correct rule provider paths\ndocs(overwrite): standardize encrypted DNS metadata\nrefactor(overwrite): rename providers with COCR prefix\nchore(overwrite): sync upstream overwrite submodules\n```\n\nAn override that references rules is still scoped to `overwrite` when the\nchanged artifact is the override itself.\n\nDo not use `rules`, `module`, `modules`, or `openclash` merely because an\noverride contains `rules` or `rule-providers`.\n\n### Shell utilities\n\nFor files under:\n\n```text\nshell/**\n```\n\nuse:\n\n```text\nshell\n```\n\nExamples:\n\n```text\nfeat(shell): verify OpenClash startup after updates\nfix(shell): restore package sources after failure\nperf(shell): reduce repeated release metadata requests\ndocs(shell): clarify full update behavior\ntest(shell): cover installer rollback paths\n```\n\n### Sub-Store scripts\n\nFor files under:\n\n```text\nscript/sub-store/**\n```\n\nuse:\n\n```text\nsubstore\n```\n\nExamples:\n\n```text\nfeat(substore): filter nodes without IPv6 egress\nfix(substore): preserve nodes with valid IPv6 routes\ntest(substore): cover mixed IPv4 and IPv6 nodes\n```\n\n### Python maintenance tools\n\nChoose the scope from the tool's target rather than from the `py/` directory.\n\nExamples:\n\n```text\npy/generate_rules.py           -> rules\npy/generate_game_cdn.py        -> rules\npy/update_encrypted_dns.py     -> rules\npy/sync_installer_common.py    -> shell\n```\n\nTests inherit the target scope:\n\n```text\ntest(rules): cover empty provider generation\ntest(shell): verify shared installer synchronization\n```\n\nDo not use `python`, `py`, or `script` as a scope unless the Python tooling\nitself becomes an independent repository component.\n\n### GitHub Actions and supporting scripts\n\nFor:\n\n```text\n.github/workflows/**\n.github/scripts/**\n```\n\nuse `ci` when the primary change affects automation.\n\nSelect the scope from the automation's responsibility:\n\n```text\nrule generation or rule refresh          -> rules\nrepository validation                    -> validation\nwiki publishing or backup                -> wiki\nGitHub Pages deployment                   -> pages\nDependabot automation                     -> deps\nCodeQL or security scanning               -> security\njsDelivr cache purging                    -> cdn\nOpenClash overwrite submodule syncing     -> overwrite\ncross-workflow concurrency or permissions -> workflow\n```\n\nExamples:\n\n```text\nci(rules): serialize generated rule commits\nci(validation): validate Sub-Store filter syntax\nci(wiki): back up wiki before publishing\nci(pages): pin documentation build dependencies\nci(overwrite): prevent stale submodule sync pushes\nci(workflow): share the main branch writer queue\n```\n\nDo not automatically use `ci(workflow)` for every file under\n`.github/workflows/`.\n\n### Dependencies\n\nFor routine dependency or pinned action updates, use:\n\n```text\nchore(deps): bump actions checkout to v7.0.1\nchore(deps): update CodeQL actions\n```\n\nUse `fix(deps)` only when a dependency change corrects an actual compatibility\nor security defect demonstrated by the change.\n\n### Archived files\n\nUse the scope of the owning component.\n\nMention `archived` in the subject only when moving, restoring, documenting, or\nremoving archived resources is the primary purpose.\n\nChanges that affect only archived resources are normally `docs`, `chore`, or\n`refactor`, not `feat`.\n\n## Multiple-file commits\n\nDetermine whether all staged files serve one coherent objective.\n\nApply these rules:\n\n1. Implementation plus tests:\n\n   * describe the implementation;\n   * do not title the commit as a test change.\n\n2. Implementation plus documentation:\n\n   * describe the implementation;\n   * mention documentation only in the body when needed.\n\n3. Source rule plus generated providers:\n\n   * describe the source-rule change;\n   * do not title the commit as regeneration.\n\n4. Workflow plus supporting script:\n\n   * use `ci`;\n   * scope it to the automation's actual purpose.\n\n5. Renames across several files:\n\n   * describe the shared renamed concept;\n   * use the owning component as scope.\n\n6. Several files with one corrected defect:\n\n   * use `fix`;\n   * name the defect or corrected behavior.\n\n7. Truly unrelated changes:\n\n   * describe the highest-impact intentional change in the title;\n   * summarize secondary changes in the body;\n   * never invent a vague umbrella statement;\n   * do not use `chore(repo)` merely to avoid identifying the primary change.\n\nDo not join unrelated changes with a generic subject such as:\n\n```text\nupdate rules and workflows\nimprove repository files\nmake various fixes\nupdate configuration and docs\n```\n\n## Subject-writing rules\n\nThe subject must answer:\n\n```text\nWhat concrete behavior, resource, data set, or defect changed?\n```\n\nPrefer specific verbs such as:\n\n```text\nadd\nremove\nblock\nallow\nroute\ndirect\nreject\nset\ncorrect\nrestore\nprevent\nvalidate\ngenerate\nregenerate\nrefresh\nsync\nrename\ndocument\nclarify\npin\nbump\n```\n\nAvoid weak verbs unless followed by a precise object and effect:\n\n```text\nupdate\nchange\nimprove\nmodify\nadjust\nenhance\noptimize\nclean up\n```\n\nAvoid subjects that merely restate a filename.\n\nIncorrect:\n\n```text\nfeat(overwrite): add Set_GeoIP_Database_URL.conf\n```\n\nCorrect:\n\n```text\nfeat(overwrite): set GeoIP database sources\n```\n\nDo not include implementation details when the observable effect is clearer.\n\nIncorrect:\n\n```text\nfeat(overwrite): add CHNR_CUSTOM_URL variables\n```\n\nCorrect:\n\n```text\nfeat(overwrite): set mainland IP whitelist sources\n```\n\nUse file or resource names only when they are established public names and\nprovide the clearest description.\n\n## Prohibited vague messages\n\nNever generate titles such as:\n\n```text\nupdate files\nupdate rules\nupdate config\nchange configuration\nfix bug\nmisc changes\nvarious improvements\nimprove metadata\nenhance workflow\nrefactor code\nclean up files\nsync changes\nadjust settings\n```\n\nNever claim:\n\n```text\nimprove performance\nincrease stability\nfix compatibility\nenhance security\n```\n\nunless the diff specifically demonstrates that effect.\n\n## Repository-specific examples\n\nGood:\n\n```text\nfeat(rules): add Alibaba mainland IP ranges\nfeat(rules): add hbymfswz.com to direct rules\nfix(rules): remove an invalid Steam CDN prefix\nchore(rules): refresh encrypted DNS sources\nchore(rules): regenerate derived rule files\n\nfeat(overwrite): add encrypted DNS blocking override\nfeat(overwrite): add direct game download rules\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): set mainland IP whitelist sources\nfix(overwrite): correct rule provider paths\ndocs(overwrite): standardize encrypted DNS metadata\nrefactor(overwrite): rename providers with COCR prefix\nchore(overwrite): sync upstream overwrite submodules\n\nfeat(subconverter): add gaming download policy\nfix(subconverter): preserve fallback rule ordering\nchore(subconverter): regenerate mainland template\n\nfeat(config): add IPv6 DNS routing example\nfix(config): correct GeoSite rule ordering\n\nfeat(shell): verify OpenClash service startup\nfix(shell): restore package feeds on failed installation\nperf(shell): reuse fetched release metadata\ndocs(shell): clarify lightweight update exclusions\ntest(shell): cover missing package manager handling\n\nfeat(substore): filter nodes without IPv6 egress\nfix(substore): retain dual-stack nodes\ntest(substore): cover empty node collections\n\nci(rules): serialize generated rule commits\nci(validation): validate complete Mihomo templates\nci(wiki): prevent empty wiki backup commits\nci(overwrite): reset stale submodule sync state\nci(cdn): purge changed rule resources\nci(workflow): serialize main branch writers\n\ndocs(readme): expand configuration resource guide\ndocs(wiki): clarify Fake-IP DNS routing\nbuild(docs): pin MkDocs dependencies\nchore(deps): bump CodeQL actions\n```\n\nIncorrect:\n\n```text\nfeat(module): add GeoIP config\nfeat(rules): add Direct Game Download overwrite\nfix(overwrite): improve metadata\nchore(rule): update Encrypted_DNS.list\nci(workflows): improve automation\ndocs(script): update README\nchore(config): update OpenClash rule sources\n```\n\nCorrected versions:\n\n```text\nfeat(overwrite): set GeoIP database sources\nfeat(overwrite): add direct game download rules\ndocs(overwrite): standardize encrypted DNS metadata\nchore(rules): refresh encrypted DNS sources\nci(rules): prevent stale generated rule commits\ndocs(shell): clarify installer usage\nchore(subconverter): refresh rule source references\n```\n\n## Optional body rules\n\nGenerate a body only when it adds information that cannot fit in the title.\n\nWhen a body is needed:\n\n* leave one blank line after the title;\n* explain what changed and why;\n* mention important secondary changes;\n* do not repeat the title;\n* do not invent validation results;\n* mention tests only when the diff or available context shows they were run;\n* wrap body lines at approximately 72 characters where practical.\n\n## Final validation checklist\n\nBefore returning a commit message, verify all of the following:\n\n1. The title reflects the actual diff.\n2. The type matches the semantic effect.\n3. The scope uses the repository's canonical vocabulary.\n4. The scope identifies the owning component, not an incidental keyword.\n5. Source files and generated files are correctly distinguished.\n6. Comment-only changes use `docs`.\n7. Automated refreshes use `chore` unless automation behavior itself changed.\n8. Workflow changes use a functional scope.\n9. The subject names a concrete object or behavior.\n10. No effect or test result was invented.\n11. The complete title is no longer than 72 characters.\n12. The title contains no trailing period.\n13. The output contains one best commit title.\n</yakaai_skills>"}