القائمة
执行语言和框架特定的安全最佳实践审查并提出改进建议。仅在用户明确请求安全最佳实践指导、安全审查/报告或默认安全编码帮助时触发。仅对受支持的语言（python、javascript/typescript、go）触发。不要为一般代码审查、调试或非安全任务触发。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/CSlawyer1985/legal-skillhub --skill security-review-openaiيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
88查企业风险查询与分析工具 —— 专注于中国大陆企业的法务风险查询与分析，覆盖经营异常、行政处罚、监管措施、被执行人、失信被执行人、司法案件等风险类型。支持公司名称、统一社会信用代码、companyId 三种输入方式，自动完成风险查询并输出结构化风险分析总结。 触发场景：仅当用户意图为查询企业风险/法务风险时触发。包括但不限于：企业风险查询、公司风险、经营异常、行政处罚、监管措施、被执行人、失信被执行人、司法风险、风险扫描、风险评估、企业合规审查、风险报告、XX公司有什么风险、XX公司安全吗、XX公司有没有处罚、XX公司被执行过吗。 不触发场景：纯粹的企业信息查询（如查公司、搜企业、工商信息、注册资本、法人代表、股东结构、专利商标等）不应触发本技能，请使用其他 cha88 系列工具。
Manages Rule 30(b)(6) corporate representative deposition workflows — drafting notice topics with reasonable particularity, building examination outlines, defending designees, handling objections, and preserving binding admissions for summary judgment or trial. Use when drafting or responding to 30(b)(6) notices, selecting and preparing designees, building topic-by-topic outlines, or triaging scope and privilege disputes. Trigger keywords: 30(b)(6), corporate representative deposition, topic list, designee, notice analysis, deposition objections, corporate admissions.
Guides taking and defending Rule 30(b)(6) corporate representative depositions. Drafts topic lists with reasonable particularity, builds examination outlines for binding corporate admissions, analyzes noticed topics for objections, and prepares designees. Use when drafting 30(b)(6) notices, preparing corporate deposition topics, selecting or preparing designees, or defending corporate representative depositions.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | security-review-openai |
| description | 执行语言和框架特定的安全最佳实践审查并提出改进建议。仅在用户明确请求安全最佳实践指导、安全审查/报告或默认安全编码帮助时触发。仅对受支持的语言（python、javascript/typescript、go）触发。不要为一般代码审查、调试或非安全任务触发。 |
| metadata | {"author":"OpenAI","license":"Apache-2.0","version":"2026.02.02"} |
本技能提供如何识别当前上下文所用的语言和框架，然后从本技能的 references 目录加载关于该语言和/或框架的安全最佳实践信息的说明。
此信息（如存在）可用于编写新的默认安全代码，或被动检测现有代码中的重大安全问题，或（如用户要求）提供漏洞报告并建议修复。
本技能的第一步是识别您被要求使用或已存在于您工作项目范围内的所有语言和所有框架。聚焦主要核心框架。通常您会希望同时识别前端和后端的语言与框架。
然后检查本技能的 references 目录，看是否有任何与该语言和/或框架相关的文档。确保阅读与特定框架或语言相关的所有参考文件。文件名格式为 <language>-<framework>-<stack>-security.md。您还应检查是否存在与您所用框架无关的 <language>-general-<stack>-security.md。
如果正在处理一个包含前端和后端的 Web 应用，确保您已检查了前端和后端两者的参考文档！
如果您被要求制作一个将同时包含前端和后端的 Web 应用，但未指定前端框架，也请查看 javascript-general-web-frontend-security.md。理解如何同时保护前端和后端很重要。
如果技能的 references 目录中没有相关信息，稍微思考一下您对该语言、框架及其所有众所周知的安全最佳实践的了解。如果不确定，可以尝试在线搜索安全最佳实践的文档。
从那里，它可以以几种方式运作。
主要模式是从此刻起仅使用这些信息编写默认安全的代码。这对于启动新项目或编写新代码很有用。
次要模式是在项目中工作和为用户编写代码时被动检测漏洞。关键或非常重要的漏洞或严重违反安全指导的重大问题可以被标记并告知用户。此被动模式应聚焦于影响最大的漏洞和安全默认值。
用户可以要求安全报告或改进代码库的安全性。在这种情况下，应产出一份完整报告，描述项目在哪些方面未遵循安全最佳实践指导。报告应排定优先级，并有清晰的严重性和紧迫性部分。然后提议开始修复这些问题。参见下方 #修复。
references/ 中存在匹配的指导，只加载相关文件并遵循其指示。虽然这些参考文件包含语言和框架的安全最佳实践，客户可能有需要绕过或覆盖这些实践的情况。注意项目文档和提示词文件中的特定规则和指示，它们可能要求您覆盖某些最佳实践。覆盖最佳实践时，您可以向用户报告，但不要与他们争论。如果某安全最佳实践因项目特定原因需要被绕过/忽略，您也可以建议向项目添加关于此事的文档，以便清楚为何未遵循该最佳实践，并在未来遵循该绕过。
产出报告时，您应将报告写为 security_best_practices_report.md 中的 markdown 文件，或用户提供的其他位置。您可以询问用户希望报告写到哪里。
报告顶部应有简短的高管摘要。
报告应根据漏洞的严重性清晰划分为多个部分。报告应聚焦最关键发现，因为它们对用户影响最大。所有发现都应标注数字 ID 以便引用。
对关键发现，包含一句影响陈述。
报告写好后，也直接向用户报告，不过可以更简洁。如果用户想了解更多关于任何发现的信息，您可以主动解释任何发现或安全最佳实践指导背后的理由。
重要：在报告中引用代码时，确保找到并包含您所引用代码的行号。
写完报告文件后，向用户总结发现。
还要告诉用户最终报告写在了哪里。
如果您产出了报告，让用户阅读报告并请求开始执行修复。
如果您被动发现关键发现，通知用户并询问是否希望您修复此发现。
执行修复时，聚焦一次修复单个发现。修复应有简明清晰的注释，说明新代码基于特定的安全最佳实践，也许还有为什么不以这种方式做会危险的极短理由。
始终考虑您要做的更改是否会影响用户代码的功能。考虑更改是否可能导致项目当前工作方式出现回归。不安全的代码经常因其他原因被依赖（这就是不安全代码长期存活的原因）。避免破坏用户的项目，因为这可能使他们在未来不愿应用安全修复。写一个深思熟虑、充分了解项目其余部分的修复，胜过草率仓促的更改。
始终遵循用户配置的任何正常变更或提交流程。如果进行 git 提交，提供清晰的提交信息，说明这是为了与安全最佳实践保持一致。尽量避免将多个无关发现捆绑到单个提交中。
始终遵循用户配置的任何正常测试流程（如有）以确认您的更改没有引入回归。考虑更改可能产生的二阶影响，并在有任何影响时在作出更改前告知用户。
以下是几乎适用于任何语言或框架的几条安全编码建议。
为某个资源分配 ID（该 ID 随后将暴露于互联网）时，避免使用小的自动递增 ID。改使用更长的、随机的 UUID4 或随机十六进制字符串。这将防止用户得知资源的数量并能够猜测资源 ID。
虽然 TLS 对生产部署很重要，但大多数开发工作都是在禁用 TLS 或由某个范围外的 TLS 代理提供的情况下进行的。因此，要非常小心不要把缺乏 TLS 报告为安全问题。对"secure"饼干的使用也要非常小心。它们只应在应用实际通过 TLS 运行时设置。如果它们在非 TLS 应用上设置（如为本地开发或测试部署时），会破坏应用。您可以提供 env 或其他标志来覆盖设置 secure，以保持它在 TLS 生产部署前关闭。此外，避免推荐 HSTS。在未完全理解其持久影响的情况下使用它是危险的（可能导致重大中断和用户锁定），且对于 codex 所审查项目的一般范围而言通常不被推荐。