用途：该技能用于维护项目根目录下规范化的 ACCESSIBILITY.md 文件，将其作为项目无障碍控制文档，覆盖标准、架构、验证、责任归属与已知例外。它被定位为大多数仓库进行 ACCESSIBILITY.md 维护的默认基线路径，仅在目标仓库有特殊形态时才应改用更专门的插件。
主要能力：提供 check-only（仅检查）与 apply（应用修复）两种运行模式。检查模式审计必需章节结构、必需子章节、目录、占位内容、无依据的合规声明以及单薄或缺失的验证证据；应用模式将编辑范围限定在目标 ACCESSIBILITY.md，缺失时从内置模板创建，并把文档规范化为标准结构，随后重跑同一审计确认修复状态。
使用方式：必需参数为 --project-root <path> 与 --run-mode <check-only|apply>；可选参数为 --accessibility-path <path> 与 --config <path>。基线契约来源为 config/accessibility-customization.template.yaml 与 assets/ACCESSIBILITY.template.md。基准要求顶层标题与简短摘要、必需的 ## Table of Contents、规范化顶层章节（概述、标准基线、无障碍架构、工程流程、已知差距、用户支持与报告、验证与证据）及其必需子章节，并明确区分目标标准与已验证的法律合规声明。
写作期望：默认将文档控制在约 300 行以内，350 行为软上限；多数顶层章节约 45 行以内，多数子章节约 25 行以内。概述中的状态应简短、平实且最新；范围应明确契约覆盖的项目界面；标准基线应点明目标标准或内部基线；已知差距部分应始终存在。
限制与护栏：不得自动提交、推送或发起 PR；不得编造合规声明、测试覆盖、支持的辅助技术或审计历史；除目标 ACCESSIBILITY.md 外不得编辑其他文件。默认不得声称已通过法律合规验证，应优先使用“targets WCAG 2.2 AA”等目标性表述。是否使用子代理需用户明确请求或授权，且应用编辑应留在主线程。输出为 Markdown 加 JSON，包含 run_context、schema_contract、schema_violations、claim_integrity_issues、verification_evidence_issues、content_quality_issues、fixes_applied、post_fix_status、errors；若无问题与错误则输出 No findings。