engineering-workflow

name	engineering-workflow
description	统筹 Lingchu Bot 的代码理解、GitNexus 影响分析、调试交付、设计原型、前端质量和议题规划。Use when 用户要理解架构、追踪影响、修 bug、做 TDD/代码审查、设计 API/UI/架构方案、打磨 docs 站点、拆 PRD/issue/QA/refactor 计划，或需要 GitNexus/knowledge graph/onboarding 相关工作。

工程工作流

这是项目内工程类技能的统一入口。先判断用户真正需要的是理解、影响分析、调试交付、设计探索、前端质量，还是计划拆解；只读取对应 reference。

路由

• GitNexus 代码理解、影响分析、调试、重构、PR review、CLI 和工具 schema：优先读工具同步的顶层入口 ../gitnexus/<skill-name>/SKILL.md。这些文件由 GitNexus 机械同步，不在 engineering-workflow/references/ 保留归档副本，避免工具能力变化后加载旧指南。
• PR 或 diff review：优先读工具同步的 ../gitnexus/gitnexus-pr-review/SKILL.md；需要一般审查循环时再读 references/delivery-loop/delivery-loop-skill.md。
• Bug、失败追踪、性能或 flaky、TDD、实现后验证：读 references/delivery-loop/delivery-loop-skill.md。
• 新增、修改、删除或重构 handle、QQ command、adapter handler、matcher、command_key、菜单/触发词/权限/配置耦合面：读 references/delivery-loop/references/handle-feature-workflow.md，再读 references/delivery-loop/delivery-loop-skill.md 执行和验证。
• NapCat/QQ UI/实机才失败的 handle 问题：读 ../interactive-runtime-debugging/SKILL.md，用现场证据定位后再回到 handle 变更路线补齐联动面。
• 产品/API/UI/架构设计、方案对比、grill 提问、一次性原型：读 references/design-prototyping/design-prototyping-skill.md。
• React/docs 站点诊断、可访问性、响应式、视觉打磨、浏览器验证：读 references/frontend-quality/frontend-quality-skill.md。
• PRD、issue 拆分、triage、QA 会话、重构计划：读 references/issue-planning/issue-planning-skill.md。

项目规则

1. 先看当前工作区状态、用户最新要求和相关 AGENTS 规则，再相信旧图谱或旧计划。
2. 修改函数、类或方法前，按项目 GitNexus 规则做影响分析；如果返回 HIGH/CRITICAL 风险，先提醒用户。
3. 用户要 review 时保持审查姿态：发现项优先，附文件和行号。
4. 用户要实现时不要停在建议；完成编辑、针对性验证，并说明结果。
5. reference 内若提到脚本或子 reference，路径按该 reference 所在目录解析。
6. GitNexus、grep、测试覆盖和既有 skill 都可能漏掉业务关联；涉及业务行为时，必须结合当前源码结构手动核查关联面，并在结论里说明工具缺口。