Greater Restoration 是一个用于处理系统性退化问题的技能，其名称借用了“高等复原术”的隐喻，但实际指向可操作的运维与工程恢复流程。它区分于“Lesser Restoration”式的小修小补：后者针对单一问题直接修复，例如重置标志、清理缓存或移除诅咒；而 Greater Restoration 面向的是多个问题因长期共同衰减而同时出现、单独修复其中一项无法奏效的情形。
用途方面，该技能适合在用户描述“经过数月/数年逐渐退化”“累积”“漂移”“膨胀”“蔓延”等时间加衰减特征时启用，也适合出现多个相关问题并列（配置不一致、孤立资源、过期制品）、使用“全面”“系统化”“完整审计”“恢复健康”“清理并恢复”等范围词，或表明增量修复已失败（“没有单一修复能奏效”“分诊不够”“创可贴式修补让情况更糟”）的场景。典型领域包括模式漂移、技术债务、基础设施即代码漂移、告警疲劳、镜像膨胀、依赖纠缠、过期功能开关、文档腐化和数据管道损坏。
主要能力体现为一套结构化流程。第一步是在行动前重申目标、成功条件和不可触碰边界。第二步是界定退化范围：清点所有受影响子系统，评估数量、相互关联程度，并明确“健康”状态的定义。第三步是寻找根因：判断是什么引入了衰减，以及该原因是否仍在活跃，例如损坏的 CI 步骤仍在运行、错误配置仍在生效。第四步是设计恢复计划：给出有依赖顺序的步骤，明确哪些必须先修、哪些可以并行，并在各阶段之间设置验证检查点。第五步是带检查点执行：不在一批变更后不做验证就继续，每个阶段必须确认改善后才能推进。第六步是恢复后健康检查：确认系统恢复完整功能，记录变更内容及防止复发的方法。最后将结果打包为交付物，并明确区分已确认事实、假设和未解决风险。
使用方式上，该技能以 Hermes Agent 和本次会话常规工具集为运行前提，不引入额外运行时依赖。调用示例为“/greater-restoration assess this [system/codebase/database] for accumulated damage and design a comprehensive restoration plan”，即对指定系统、代码库或数据库评估累积损坏并设计全面恢复计划。交付物包括：按顺序撤销累积损坏的恢复计划、根因识别及防复发说明、确认系统恢复完整功能的恢复后健康检查。
适用场景集中于一次性、综合性的系统恢复任务，而非持续自动化或预防性工作。限制方面，该技能明确不适用于：单一事故或热修复（如部署后 API 崩溃、空指针异常）；简单开关或重置（如断路器跳闸、标志卡在启用状态）；从备份复活（如删除账户后从备份恢复）；迁移或搬迁（如从 Heroku 迁到 AWS）；自愈或持续运行（如自动重启 Pod、维持 99.99% 可用性）；预防性维护（如添加监控、设置 lint）。此外，使用时应保持隐喻锚定真实机制，避免滑向虚构设定。验证环节需确认结果包含上述每项交付物、已确认事实与假设及推断可见分离，并且隐喻仍能清晰映射到真实运维机制。关于该技能的官方详细文档、版本信息或收费情况，资料暂未提供。