按项目规范审查或解释 TypeScript/React/C#…

当需要对照项目约定审查、编写或解释代码，检查命名、TSDoc/XML 文档、注释意图、ADR 与贡献者文档合规性时使用。

适用场景

解决思路

1. 先判断优先级：仓库级策略（CONTRIBUTING.md、contribute/、ADR、.github/copilot-instructions.md、AGENTS.md）> 工具配置（biome.json、tsconfig.json、.editorconfig、linter 配置）> 本技能基线规则；仓库明确收窄、放宽或冲突时以仓库策略为准，不要标记符合仓库文档约定的代码。
2. 若冲突未被文档化（无 ADR、无贡献者说明、无配置），按技能规则作为默认，并建议团队记录其意图。
3. 第 1 步——分类与路由：检测主要语言并激活对应语言 agent：TypeScript（.ts、非组件 .tsx）→ agents/typescript.agent.md；React（含 JSX 或 hooks 的 .tsx、组件文件）→ agents/react.agent.md；混合 .tsx（类型关注点 + React 组件关注点）→ 两个 agent 并行；C#（.cs、.csproj）→ agents/csharp.agent.md；Markdown（.md、.mdx）→ agents/markdown.agent.md。
4. 任何代码审查都并行激活：agents/intent.agent.md（每次审查，无论语言）；当项目有 ADR（docs/adr/、adr/）或贡献者文档（CONTRIBUTING.md、contribute/、.github/copilot-instructions.md）时激活 agents/constitution.agent.md。
5. 若无法确定语言，先询问再继续。
6. 第 2 步——应用或解释约定：每个语言 agent 先读取其权威参考文件（references/typescript.conventions.md、references/react.conventions.md、references/csharp.conventions.md、references/markdown.conventions.md），然后：对约定问题，给出规则解释和修正后的代码示例；对代码审查，指出偏差、说明规则、展示修正版本；不要标记项目已在 biome.json 或 .editorconfig 中显式配置的模式。intent 和 constitution agent 并行运行并向合并报告贡献发现。
7. 第 3 步——呈现发现：将所有 agent 的发现整理为统一报告，分为 Required（必须修复：命名违规、导出缺少 TSDoc、any 类型、违反宪法/ADR）、Recommended（应当修复：意图注释薄弱、未记录的魔法值、无理由的抑制）、Advisory（可考虑：缺少决策记录、过时 ADR、需正式化的隐式例外）。每条发现需说明规则、受影响代码、修正版本或建议操作。
8. 第 4 步——应用修正：仅应用用户明确批准的修正；使用工作区工具编辑文件；除非文件少于 50 行，否则不要重写整个文件。
9. 所需输入缺失或含糊时先询问：目标代码（内联片段或文件路径）或具体约定问题；语言或文件类型（未提供时从内容推断）；宪法检查时 ADR 目录路径和/或贡献者文档（未提供时从常见位置 docs/adr/、CONTRIBUTING.md、contribute/ 推断）。
10. 当开发者上下文或角色已知时，查阅 assets/ 中匹配的 follow-up 文件以获取针对性澄清问题，只问未回答的问题：assets/framework-core-developer.follow-up.md（Fusion Framework 内部、共享库、框架 API）、assets/react-app.follow-up.md（Fusion React 应用开发）、assets/core-service.follow-up.md（Fusion Core 后端服务 C#/.NET）。
11. 安全约束：未经用户明确确认绝不修改文件；不要标记项目已通过 biome.json 或 .editorconfig 选择的风格；不要编造 ADR 内容——只执行和质疑实际已文档化的内容。

适用边界 · 注意事项

• 安全漏洞扫描（使用专门的安全审查技能）
• 性能分析或基准测试
• 高层架构或系统设计决策
• 在没有审查目标的情况下生成全新代码
• 未经用户明确确认就修改文件