Menu
按功能职责对已归档的 OpenSpec 迭代内容进行聚合分类和高价值摘要压缩，并要求插件相关聚合归档和 specs 目录以 <plugin-id> 前缀区分主框架内容。 必须用户手动触发，禁止自动触发该技能。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
手动触发：将主仓库与 apps/lina-plugins 对齐最新 main 后， 按提示在两侧各建独立分支；分支就绪后继续处理提示词中的后续请求。 必须用户手动触发，禁止自动触发该技能。
用于处理用户对已有实现的反馈分诊与执行闭环：先判断是否需要纳入 OpenSpec 活跃变更或新建变更，再完成根因分析、实现、验证和必要测试。凡是用户针对已有实现反馈 Bug、缺陷、改进点、建议或实现遗漏，即使没有明确提到“反馈”或 OpenSpec，也必须使用本技能。
用于审查 LinaPro OpenSpec 工作流中的代码变更和规范合规性。在完成 /opsx:apply 任务、 完成 lina-feedback 反馈修复、执行 /opsx:archive 归档前必须使用；在用户要求代码审查、 规范合规检查，或明确调用 /lina-review 时也必须使用。
手动触发：为 LinaPro 主仓库及 apps/lina-plugins 子模块完成提交、PR 前 rebase、推送、创建 PR， 主仓 CI 修复回路，以及 PR 合并后恢复原始分支并同步 main。禁止自动触发。
审查 LinaPro 社区 GitHub Issues，并按项目规范和源码实现分类处理。 必须用户手动触发，禁止自动触发该技能。
先执行 lina-openspec-archive-changes 归档活跃变更，再执行 lina-openspec-archive-consolidate 做归档摘要。 必须用户手动触发，禁止自动触发。
| name | lina-openspec-archive-consolidate |
| description | 按功能职责对已归档的 OpenSpec 迭代内容进行聚合分类和高价值摘要压缩，并要求插件相关聚合归档和 specs 目录以 <plugin-id> 前缀区分主框架内容。 必须用户手动触发，禁止自动触发该技能。 |
扫描 openspec/changes/archive/ 下以日期开头命名的原始已归档变更，按功能职责分类，对每个分类下的多个迭代进行语义合并和高价值摘要压缩，生成一个结构与普通归档变更完全一致、内容连贯自然的新归档目录。执行压缩时必须逐个输入目录读取并理解proposal.md、design.md、tasks.md和specs/下全部规范内容；脚本只能用于目录枚举、文件检查、校验和格式验证，禁止用于生成摘要正文或替代语义覆盖判断。合并后的文档不包含"本文档聚合了 N 个迭代"等元描述，读起来像一个从头设计的完整变更，同时保证需求背景、设计决策、最终规范、反馈闭环、验证证据和审查治理影响不丢失。聚合结果写入并验证语义覆盖后，默认清理本次实际输入且已成功合并的原始日期前缀归档目录，避免archive/下同时保留原始碎片和聚合结果。归档数量 ≥ 8 时自动通过完整OpenSpec流程跟踪聚合任务。该流程生成的openspec/changes/archive-consolidation/仅是临时执行记录，不是需要长期保留的业务变更；聚合完成后必须删除该临时变更目录，避免它继续被判定为活跃变更。
默认读取边界：未指定变更列表时，只读取目录名匹配 ^[0-9]{4}-[0-9]{2}-[0-9]{2}- 的归档目录。不要把已生成的聚合归档目录（如 plugin-framework/、system-config/、i18n/ 这类不以日期开头的功能分组目录）再次作为输入，避免重复聚合。只有当用户显式指定这些目录名时，才允许按指定列表读取。
默认清理边界：聚合成功后，默认只删除本次待处理集合中目录名匹配 ^[0-9]{4}-[0-9]{2}-[0-9]{2}- 的原始归档目录。即使用户显式指定了非日期前缀目录，也不要默认删除这些目录；只有用户明确要求清理指定的非日期目录时才允许删除。
摘要压缩边界：聚合输出必须把普通任务流水压缩为维护摘要，但不得丢失 FB-* 反馈闭环、根因、修复说明、验证证据、审查结论、i18n、缓存一致性、数据权限、DI、跨平台和测试策略等高价值维护信息。tasks.md压缩以减少存储空间为首要目标，尽可能只保留最短维护证据；无法确认语义覆盖时，必须保留原始归档目录并报告阻断原因。
交互语言：与用户交互的内容语言以用户上下文使用的语言为准，用户使用英文则使用英文，用户使用中文则使用中文。
“插件相关内容”指用户在apps/lina-plugins/<plugin-id>/下开发的具体业务插件功能及其 OpenSpec 规范，例如john-content-cms插件提供的 CMS 系统能力。不包括apps/lina-core中的插件宿主框架、插件生命周期、插件治理、pluginbridge、host service、源码插件嵌入或动态插件运行时等主框架通用能力。
聚合插件相关内容时，必须优先保证输出目录能区分主框架规范和插件业务规范：
apps/lina-plugins/<plugin-id>/路径、plugin.yaml中的插件id、插件清单描述或规范正文识别<plugin-id>。<plugin-id>开头。若聚合的是某个插件的整体能力，目录使用openspec/changes/archive/<plugin-id>/；若同一插件需要拆分多个独立功能分组，目录使用openspec/changes/archive/<plugin-id>-<capability>/。specs/能力目录必须以<plugin-id>开头。允许使用specs/<plugin-id>/spec.md承载插件根能力，也允许使用specs/<plugin-id>-<capability>/spec.md承载插件内细分能力；禁止输出specs/cms/、specs/article-management/或specs/settings/这类无插件前缀目录。specs/能力目录。<plugin-id>前缀的目录；归一化事实只写入最终报告，不写进proposal.md、design.md、tasks.md或specs/正文。plugin-framework、plugin-governance、plugin-host-service-extension，不要套用某个业务插件 ID。调用技能时，用户可选择性地指定要处理的变更列表：
| 情况 | 行为 |
|---|---|
| 未指定变更列表 | 仅处理 openspec/changes/archive/ 下目录名以 YYYY-MM-DD- 开头的原始归档变更 |
| 指定了变更列表 | 仅处理用户指定的变更，忽略其余已归档变更；显式指定的目录即使不是日期前缀也可以处理 |
| 明确要求压缩既有聚合目录 | 可以读取用户指定的非日期前缀聚合目录并执行摘要压缩，但默认不得删除这些非日期目录 |
默认行为是在聚合成功后清理已成功合并的原始日期前缀归档目录。若用户明确要求保留原始归档目录，则跳过原始归档清理，并在最终报告中说明这些目录仍保留在 openspec/changes/archive/ 下。
指定方式示例（用户输入中包含变更名即视为指定）：
2026-04-12-plugin-framework 和 2026-04-13-dynamic-plugin-rest-runtime"john-content-cms 插件相关归档，输出目录必须以 john-content-cms 开头"若指定的变更目录不存在于 openspec/changes/archive/，在执行前报错并停止：
错误：以下指定变更在归档目录中不存在：
- <change-id>
请检查目录名是否正确后重新执行。
find openspec/changes/archive -mindepth 1 -maxdepth 1 -type d -exec basename {} \; | sort
^[0-9]{4}-[0-9]{2}-[0-9]{2}- 的子目录作为待处理集合<归档分组键>/、手工汇总目录、临时目录或其他非原始归档目录统计待处理数量。若少于 8 个，跳过第五步（无需进入 OpenSpec 流程）。记录所有目录名备用，并单独记录后续允许清理的目录列表：默认只包含待处理集合中匹配 ^[0-9]{4}-[0-9]{2}-[0-9]{2}- 的目录。
对第一步确定的待处理集合中的每个变更目录，逐个目录读取以下文件（文件不存在时记录缺失并跳过该文件，不得跳过同目录其他文件）：
openspec/changes/archive/<name>/proposal.md
openspec/changes/archive/<name>/design.md
openspec/changes/archive/<name>/tasks.md
openspec/changes/archive/<name>/specs/**/*.md （所有 Markdown 规范文件）
读取要求：
proposal.md、design.md、tasks.md和specs/下所有*.md文件的语义；不要只读取标题、目录名、文件名或关键字命中片段proposal.md、design.md、tasks.md或specs/的摘要正文specs/能力分批读取和压缩；每批仍需完整覆盖该目录下对应文件语义对每个变更收集以下信息：
2026-04-12-plugin-framework）specs/下每个 Markdown 规范文件的全文apps/lina-plugins/<plugin-id>/下的具体业务插件能力，记录识别到的插件 ID；若属于主框架插件基础设施，明确记录为主框架能力而非业务插件<plugin-id>前缀目录将每个变更归入唯一的功能分组。目标是把触及同一功能领域的变更聚在一起。推荐分组分类（根据实际内容增减或拆分）：
| 分组键 | 典型变更内容 |
|---|---|
foundation | 项目初始化、框架搭建、目录结构、Go/前端脚手架 |
user-auth | 登录/登出、JWT、会话管理、认证中间件、密码重置 |
user-management | 用户 CRUD、角色、权限、菜单管理 |
org-structure | 部门、岗位、字典模块 |
system-config | 系统设置、配置管理、上传配置、运行时配置 |
system-monitor | 系统信息、服务器监控、操作/登录日志 |
notification | 通知、消息、公告模块 |
file-storage | 文件上传、存储后端、静态资源 |
plugin-framework | 插件加载、注册、生命周期、嵌入、WASM/Go 插件运行时 |
plugin-governance | 插件鉴权、路由可见性、安装/启用快捷方式、Mock 数据安装 |
scheduled-jobs | 任务管理、Cron 调度、内置任务边界 |
i18n | 国际化基础、i18n 治理、硬编码字符串清除 |
e2e-testing | E2E 测试套件结构、测试隔离、Playwright 规范 |
devops-tooling | 升级治理、数据库配置去重、性能审计技能、开发工具 |
code-quality | GoFrame 规范对齐、panic 治理、代码质量改进、分布式缓存 |
distributed-infra | 分布式锁、缓存一致性 |
每个变更最多归入一个分组。有歧义时优先选择描述该变更主要交付物的分组。
插件业务能力必须先按<plugin-id>隔离，再按插件内功能职责细分：
apps/lina-plugins/<plugin-id>/下的具体业务插件能力，分组键必须是<plugin-id>或<plugin-id>-<capability>，例如john-content-cms或john-content-cms-content-workflow。plugin-framework、system-config、notification、cms等主框架或泛化业务分组，除非该变更的主要交付物确实是主框架通用能力。对至少包含一个变更的每个分组，在归档目录下新建：
openspec/changes/archive/<归档分组键>/
proposal.md
design.md
tasks.md
specs/
<能力名>/ ← 主框架能力使用 kebab-case；插件能力必须以 <plugin-id> 开头
spec.md
<能力名>/
spec.md
…
其中<归档分组键>必须满足第三步分类结果。主框架能力使用原功能分组键；插件业务能力必须使用<plugin-id>或<plugin-id>-<capability>，例如openspec/changes/archive/john-content-cms/，不得使用openspec/changes/archive/cms/。
语义合并不是拷贝，而是理解后重写。 目标是让生成的文档像一个从头完整设计的变更，而非多个迭代的拼接。具体要求：
聚合结果必须按维护目标分层承载历史信息，不要把所有过程记录都放回tasks.md。压缩必须基于每个输入目录的proposal.md、design.md、tasks.md和specs/完整语义综合判断，不能只从tasks.md抽取摘要。
| 信息类型 | 输出位置 | 处理方式 |
|---|---|---|
| 背景、痛点、目标、影响 | proposal.md | 合并为稳定背景和范围说明 |
| 架构决策、方案演进、废弃方案、关键约束 | design.md | 以最终设计为准，保留演进动机 |
| 最终需求、验收场景、能力契约 | specs/<capability>/spec.md | 同名能力语义合并，不重复拼接 |
FB-*、根因、修复说明、验证、审查、治理影响 | tasks.md | 压缩为最短维护摘要 |
| 普通 checklist、重复命令、逐文件搬迁流水 | tasks.md | 优先裁剪，必要时合并为一句关键交付摘要 |
裁剪低价值流水时，必须确认它已经被proposal.md、design.md、specs/或tasks.md摘要覆盖。无法确认时，保留最短摘要并在最终报告中列为未压缩或未清理原因。不要为了模板完整保留空章节、重复的“无”项或没有维护价值的任务清单。
将所有迭代的 Why / 背景、What Changes / 变更内容、Capabilities / 能力、Impact / 影响 合并为一份结构完整的 proposal，格式与普通归档 proposal.md 一致：
## Why
<将各迭代"Why"中的动机、背景、痛点整合为一段或几段连贯叙述。
相同动机只写一次，不同动机各自保留。>
## What Changes
<将各迭代的变更项整合为一份统一的能力/功能列表。
同一能力多个迭代都涉及时，合并为一条并体现完整语义。>
## Capabilities
### New Capabilities
<整合所有迭代新增的能力，去重后按能力主题列出>
### Modified Capabilities
<整合所有迭代修改的能力>
## Impact
<整合所有迭代的影响说明，去重后列出>
将各迭代的 design.md 内容理解后重新组织，按能力主题或架构模块分节，而非按迭代分节：
# Design
## <能力主题一>（如：插件注册与生命周期）
<融合所有迭代中与该主题相关的设计决策、架构选择、关键约束，
写成连贯的设计描述。若迭代间存在演进关系，以最终设计为准，
将演进动机作为约束或背景说明融入（"最初设计为 X，因 Y 原因改为 Z"）。>
## <能力主题二>
<同上>
…
若某迭代无 design.md，其设计信息通过 proposal.md 中的设计相关描述补充进来。
将各迭代的tasks.md压缩为一份以减少存储空间为首要目标的维护摘要，而非按迭代分节，也不是保留完整执行流水。只保留未来排障、审查或设计追溯仍需要的信息；已被proposal.md、design.md或specs/稳定承载的内容不要在tasks.md重复。
# Tasks
## Summary
- [x] <最短关键交付摘要；如设计和规范已完整覆盖，可省略普通交付流水>
- [x] FB-<N>: <反馈主题>；根因：<根因或合理假设>；处理：<最终修复方向>；验证：<验证结论>
- [x] 验证：<必要的自动化验证、手工验证、静态检查或 OpenSpec 校验摘要>
- [x] 治理：<必要的 i18n / 缓存一致性 / 数据权限 / DI / 跨平台 / 测试策略影响判断>
## Retained
- [x] <仅当存在无法安全压缩的历史片段时保留本节并说明原因>
所有已完成摘要项标记为[x]（归档变更均已完成）。不同迭代中语义相同的任务合并为一条；普通 checklist、重复验证命令、逐文件搬迁清单和已被proposal.md、design.md或specs/覆盖的执行流水必须优先裁剪。若没有FB-*、根因、关键验证、审查结论或治理影响判断，tasks.md可以只保留# Tasks和一个最短## Summary。不要为了保持固定模板写入空泛的“未压缩或保留原因：无”。包含FB-编号、用户反馈、根因、修复说明、关键验证、审查结论、i18n、缓存一致性、数据权限、DI、开发工具跨平台或测试策略的内容不得直接删除，必须进入最短维护摘要、迁移到design.md，或在最终报告中说明无法压缩原因。
与标准 OpenSpec specs/ 目录结构完全一致：每个能力对应一个子目录，目录内只有一个 spec.md：
specs/
<能力名>/
spec.md
<能力名>/
spec.md
…
能力名使用 kebab-case（如plugin-manifest-lifecycle、cron-job-management）。主框架能力与原迭代中的specs子目录命名保持一致；插件业务能力必须使用<plugin-id>或<plugin-id>-<capability>，例如john-content-cms或john-content-cms-article-management。
合并规则：
specs/<能力名>/ 子目录，将同名能力的多份 spec.md 语义合并为一份，写入 specs/<能力名>/spec.mdspecs/cms/），输出时必须按识别到的<plugin-id>归一化为specs/<plugin-id>/或specs/<plugin-id>-<capability>/；不能继续沿用无插件前缀目录specs/plugin-framework/），不要误改为某个业务插件前缀仅在归档数量 ≥ 8 时执行本步骤。
不直接创建变更文件，而是走完整的 OpenSpec 研发流程：探索 → 提案 → 实施。该流程中的 archive-consolidation 变更只用于跟踪本次归档聚合，不作为长期活跃变更保留。
调用 /opsx:explore 技能，向用户呈现以下探索输入，引导分析聚合需求：
<N> 个变更，涉及 <M> 个功能分组与用户确认分组方案和优先级后，进入提案阶段。
调用 /opsx:propose archive-consolidation 技能，基于探索阶段的结论自动生成：
tasks.md 任务格式参考：
# Tasks
## Implementation
- [ ] **T-<N>**: 语义合并 `<归档分组键>` 分组 → `archive/<归档分组键>/` — <数量> 个迭代：<逗号分隔的 change-id 列表>
提案确认后，调用 /opsx:apply 按 tasks.md 中的任务逐条执行第四步的语义合并工作。
仅在所有聚合归档目录已经写入完成、必要验证通过且语义覆盖门禁通过后执行本步骤。
删除本次实际输入且已成功合并的原始归档迭代目录：
openspec/changes/archive/<YYYY-MM-DD-...>/
清理要求：
openspec/changes/archive/ 下，且目录名匹配 ^[0-9]{4}-[0-9]{2}-[0-9]{2}-openspec/changes/archive/<归档分组键>/ 聚合结果目录、非日期前缀手工目录、未参与本次处理的目录，以及 openspec/changes/archive/ 根目录仅当第五步实际创建或复用了 openspec/changes/archive-consolidation/ 时执行本步骤。
删除整个临时跟踪目录：
openspec/changes/archive-consolidation/
清理要求：
openspec/changes/archive-consolidation/ 目录本身，而不是只清空其中的文件；只清空内容会留下空目录，仍可能被文件系统规则判定为活跃变更openspec/changes/archive-consolidation/，禁止使用通配符、父目录路径或任何会影响 openspec/changes/archive/ 的路径所有文档写入和清理完成后，输出以下报告：
## 归档聚合完成
归档数量：<N> 个变更
识别分组数：<M> 个
已生成聚合归档目录：
- openspec/changes/archive/<归档分组键>/ （<N> 个迭代）
… （每个分组一行）
已清理原始归档迭代目录：
- openspec/changes/archive/<YYYY-MM-DD-...>/
… （每个已清理目录一行；若用户要求保留或清理失败，列出原因）
摘要压缩结果：
保留的高价值信息类别：<背景 / 设计决策 / specs / FB / 根因 / 验证 / 审查 / i18n / 缓存 / 数据权限 / DI / 跨平台 / 测试策略>
裁剪的低价值信息类别：<普通 checklist / 重复命令 / 逐文件流水 / 已被设计或规范覆盖的任务>
插件规范命名处理：<无插件内容 / 已按 plugin-id 前缀输出 / 存在无法识别 plugin-id 的阻断项>
未压缩或未清理原因：<如无则写"无">
语义覆盖验证：<通过 / 未通过，并说明依据>
<如果执行了第五步：>
归档数量 ≥ 8，已进入 OpenSpec 完整流程：
探索阶段（/opsx:explore）：分组方案已与用户确认
提案阶段（/opsx:propose）：archive-consolidation 变更已生成
实施阶段（/opsx:apply）：按任务逐条执行语义合并
临时跟踪变更：已删除 openspec/changes/archive-consolidation/（若失败则列出原因）
<如果跳过了第五步：>
（归档数量少于 8 个，无需进入 OpenSpec 流程。）
^[0-9]{4}-[0-9]{2}-[0-9]{2}- 的原始归档目录；禁止删除聚合结果目录、非日期前缀手工目录、未参与本次处理的目录或 openspec/changes/archive/ 根目录openspec/changes/archive-consolidation/ 时，完成报告后必须删除该临时目录；该规则不适用于 openspec/changes/archive/ 下的任何聚合结果或原始归档目录proposal.md、design.md、tasks.md和specs/下全部 Markdown 规范文件；不得只依赖目录名、标题、关键字扫描、文件清单或片段抽取tasks.md优先减小体积 — tasks.md以减少存储空间为首要目标，只保留最短维护证据；已由proposal.md、design.md或specs/承载的执行流水必须优先裁剪FB-*、根因、修复说明、验证证据、审查结论、i18n、缓存一致性、数据权限、DI、跨平台和测试策略必须进入摘要、设计或最终报告，不得作为普通任务流水直接裁剪apps/lina-plugins/<plugin-id>/下具体业务插件能力时，输出归档目录和specs/能力目录都必须以<plugin-id>开头；无法识别唯一<plugin-id>时不得生成泛化目录，必须报告阻断原因tasks.md压缩；不得因为无需跨迭代合并而直接复制原文archive/<归档分组键>/ 目录已存在（后续有新归档迭代加入同一分组），将新迭代的语义合并进已有文档，而非覆盖或跳过；在报告中注明哪些迭代是本次新增合并的archive-consolidation 变更已存在且处于活跃状态，不再新建，而是将新任务追加到其现有 tasks.md 中；该目录仍是临时跟踪目录，完成后必须按第七步删除