gqcn

为LinaPro以及SubModule仓库自动提交、推送并创建 PR。必须用户手动触发，禁止自动触发该技能。

手动生成 LinaPro 版本更新日志。用户要求生成 changelog、release notes、版本更新日志、发布说明，或提到 lina-community-release-changelog 时必须使用本技能。技能会基于 Git 历史、源码差异和 OpenSpec 内容整理详尽的双语 Markdown 更新日志，涉及数据库变更时必须单独列出，支持默认比较范围和用户指定两个版本/标签/提交进行比较，固定写入 localdocs/changelog.md。

仅手动触发。只有当用户明确要求 lina-perf-audit，或确认要运行完整审计时， 才执行 LinaPro 后端 API 全量性能审计。该流程会通过 make db.init/mock 重置数据库、重启服务、安装并启用所有内置插件、准备压测数据，并启动并发子代理； 通常需要几十分钟到数小时，且会消耗大量 Token。不得从其他技能、CI、定时任务、 Git 钩子或模糊的性能请求中触发。

审查 LinaPro 社区 GitHub Issues，并按项目规范和源码实现分类处理。用户要求审查 LinaPro issue、社区 issue、GitHub issue、question、feature、bug、关闭无效 issue，或提到 lina-community-issue-review 时必须使用本技能。

审查 LinaPro 社区 GitHub Pull Request，并按项目规范发表评论。用户要求审查 LinaPro PR、社区 PR、pull request、bot 审批、bot-approved 标签、GitHub PR 治理，或提到 lina-community-pr-review 时必须使用本技能。

用于处理用户对已有实现的反馈分诊与执行闭环：先判断是否需要纳入 OpenSpec 活跃变更或新建变更，再完成根因分析、实现、验证和必要测试。凡是用户针对已有实现反馈 Bug、缺陷、改进点、建议或实现遗漏，即使没有明确提到“反馈”或 OpenSpec，也必须使用本技能。

扫描并归档 LinaPro 仓库中已经完成的所有 OpenSpec 活跃变更，并在归档前校验插件相关规范目录使用 <plugin-id> 前缀。

按功能职责对已归档的 OpenSpec 迭代内容进行聚合分类和高价值摘要压缩，并要求插件相关聚合归档和 specs 目录以 <plugin-id> 前缀区分主框架内容。

Track, fix, verify, and test any bugs, improvements, or gaps reported against an OpenSpec change. MUST use this skill whenever user reports problems, defects, issues, bugs, or gaps related to existing implementations, even if they don't explicitly say "feedback" or mention OpenSpec.

Code and specification review for OpenSpec workflow. Triggers automatically after /opsx:apply task completion, after /opsx:feedback task completion, and before /opsx:archive. Use when user requests code review, spec compliance check, or when explicitly invoked via /openspec-review.

GoFrame v2 development skill. TRIGGER when writing/modifying Go files, implementing services, creating APIs, or database operations. DO NOT TRIGGER for frontend/shell scripts.

Playwright E2E test case management conventions for the OpenSpec workflow. Defines test file naming (TC{NNNN}), directory organization by module, TC ID allocation, file independence rules, and sub-assertion patterns. Use when creating, planning, or reviewing E2E test cases within an OpenSpec change.

GoFrame v2 development skill. TRIGGER when writing/modifying Go files, implementing services, creating APIs, or database operations. DO NOT TRIGGER for frontend/shell scripts.

Organize, fix, verify, and cover with tests any bugs, improvements, or gaps reported during verification of an OpenSpec change. Use this skill when the user reports bugs, issues, defects, problems, missing test cases, missing coverage, improvement points, or UX feedback — whether discovered during manual verification, testing, or daily use. Trigger phrases include (but are not limited to): "bug", "issue", "fix", "feedback", "问题反馈", "问题", "反馈", "缺陷", "修复", "改进", "优化", "改善", "功能改进", "改进点", or numbered/bulleted lists of problems or improvements (中文或英文编号列表均可触发). This skill ensures every reported issue is tracked as a task artifact before any fix begins, and that each fix is covered by E2E test cases following the openspec-e2e conventions. IMPORTANT: This skill MUST be activated whenever the user provides any form of bug report, issue list, improvement suggestion, or feedback — regardless of language. If the message contains multiple numbered items describing problems or desired changes, this skill takes priority

Playwright E2E test case management conventions for the OpenSpec workflow. Defines test file naming (TC{NNNN}), directory organization by module, TC ID allocation, file independence rules, and sub-assertion patterns. Use when creating, planning, or reviewing E2E test cases within an OpenSpec change.

Track, fix, verify, and test any bugs, improvements, or gaps reported against an OpenSpec change. MUST use this skill whenever user reports problems, defects, issues, bugs, or gaps related to existing implementations, even if they don't explicitly say "feedback" or mention OpenSpec.

Code and specification review for OpenSpec workflow. Triggers automatically after /opsx:apply task completion, after /opsx:feedback task completion, and before /opsx:archive. Use when user requests code review, spec compliance check, or when explicitly invoked via /openspec-review.