智能体技能
市场

Prompt Optimizer 是一个系统性工具，用于创建、优化和迭代精炼代理提示、系统提示和可复用模板，并配合评估使用。 遵循6步流程：捕获契约、盘点外部上下文、选择模型策略、塑造提示、通过候选和评估进行优化、返回结构化包。 支持在 OpenAI、Claude 和 Gemini 之间移植提示，通过阅读模型族说明并编写适配器注释。 强调使用评估集来建立基线、聚类失败原因、生成候选修复方案，并在遇到平台期、过拟合时停止。 警告常见失败模式，如未定义评估目标就编辑、混合分层、重复规则或过拟合示例。 保持指令、示例和外部上下文之间的因果关系，通过路径引用文件而非复制内容。

arize-experiment 技能提供了一套完整的 CLI 工作流,用于创建、运行、导出和比较 Arize 实验,以评估和基准测试模型性能。 涵盖实验 CRUD(ax experiments list/get/create/export/delete),支持按数据集和空间筛选、分页,以及多种输出格式(表格、JSON、CSV、Parquet 或文件路径)。 默认通过 REST API 将实验运行导出为 JSON,也可使用 --all 参数通过 Arrow Flight 进行批量传输;若 REST 导出恰好返回 500 条运行,则可能被截断,应使用 --all 重新导出。 提供端到端工作流:导出数据集、为每个示例调用真实模型 API(OpenAI、Anthropic、Gemini 或任何兼容 OpenAI 的端点)以构建 runs 文件,然后创建并验证实验。绝不伪造或模拟输出——如果无法访问 API,应停止并报告缺失内容。 支持使用 jq 比较两个实验——平均评估分数、分数分布、逐示例差异和回归检测——并将导出的运行管道化到其他工具(计数、提取输出、筛选低分、转换为 CSV)。 需要 ax CLI 和已配置的 Arize profile;包含常见错误(命令未找到、401 Unauthorized、无效的 runs 文件、数据集缺失)的故障排除,以及安全指引:切勿读取 .env 文件或搜索凭据。

Semgrep 是快速、基于模式的静态分析工具，用于安全扫描和自定义规则创建。 MCP 工具： 可用时优先使用 MCP 工具，如 semgrep_scan 进行内置规则集扫描、semgrep_scan_with_custom_rule 内联自定义规则、semgrep_findings 获取 AppSec 平台发现、semgrep_rule_schema 获取规则模式、get_supported_languages 获取支持语言；不可用时回退到 CLI。 代码扫描： 使用 semgrep --config auto 或特定规则集（p/security-audit、p/owasp-top-ten、p/cwe-top-25 等）快速扫描，支持 SARIF/JSON 输出，可扫描文件/目录，并通过 .semgrepignore 和 # nosemgrep 注释控制范围与抑制误报。 自定义规则： 用 YAML 编写模式匹配规则处理语法模式（如弃用 API、硬编码值），或用污点模式进行数据流分析（pattern-sources、pattern-sinks、可选 pattern-sanitizers）；规则语言支持元变量（$VAR）、省略号（...）及逻辑操作符（patterns、pattern-either、pattern-not、pattern-inside、metavariable-regex）。 测试与验证： 强制测试优先，用 ruleid:/ok: 注释创建测试文件，运行 semgrep --test 至 100% 通过；使用 --validate、--dump-ast、--dataflow-traces 调试规则；避免过宽模式或缺少安全用例，拒绝“无发现即代码干净”的推理。 CI/CD 集成： 在 GitHub Actions 中集成 Semgrep，定时工作流在 push/PR 时运行 semgrep ci，PR 用 --baseline-commit 只报告新增问题，并通过 SEMGREP_RULES 环境变量选择规则集。

为 traces、spans、sessions、datasets、labeling queues、evaluators 和 annotation configs 生成指向 Arize UI 的深度链接。 需要 base64 编码的组织与空间 ID（org_id、space_id）以及资源特定 ID（如 trace_id、dataset_id）；原始数字 ID 会生成看似有效但返回 404 的 URL。 为每种资源类型提供现成的 URL 模板，包括高亮特定 span（selectedSpanId）和链接到特定 evaluator 版本的选项；annotation configs 通过列表 URL 支持。 处理关键的时间范围参数（startA/endA），优先级顺序为：复用用户提供的 URL 值、按 ±1 天填充 span start_time、或回退到最近 90 天；省略时默认 7 天窗口，可能导致旧 trace 显示“无近期数据”。 包含常见问题（“无数据”、404、span 未高亮）的故障排查参考，并在未知时提供从浏览器 URL 获取正确 org_id 的指导。 与 arize-trace 技能互补，后者导出 span 数据（包括 trace_id、span_id、start_time）以用于链接生成。

本技能通过 ax CLI 下载、导出并检查已有的 Arize trace 与 span,帮助理解 LLM 应用行为、排查运行时问题。 导出粒度： 可按 --trace-id、--span-id 或 --session-id 拉取单个 span,也可用 ax traces export 导出完整 trace;支持通过 Arrow Flight 批量导出 --all 及 SQL 风格 --filter 表达式。 排查工作流： 内置分步指导,包括调试失败 trace(如过滤 status_code = 'ERROR' 后检查 attributes.error.*)、下载完整对话会话、以及通过 --stdout 配合 jq 做离线分析。 安全与最佳实践： 将导出的 span 数据视为不可信内容(防 prompt 注入),要求探索性导出先用 -l 50,并推荐直接使用 trace_id 查询以获得快速、一致的结果。 限制与运维要点： 时间范围查询有 6–12 小时索引延迟(--start-time 需设在过去);ax traces export 不传 --start-time 时结果无顺序;--all 必须配 --space;项目名解析失败时需改用 base64 ID 或修复 profile。 参考材料： 提供可过滤字段与操作符文档,以及完整的 OpenInference span 字段参考,涵盖 prompt、LLM 输入输出、tool/retriever/reranker 详情及会话/用户元数据。

本指南介绍如何编写 PostHog agent 技能 —— 即“待完成工作”模板，教导 agent 如何使用 MCP 工具实现产品目标。内容包括： 工作流：通过 hogli 命令（init:skill、lint:skills、build:skills、sync:skill）搭建、编写、lint、构建和测试技能，合并后自动分发。 何时编写：当产品新增功能且需要 agent 指导时创建技能；重点是经验丰富的人如何使用工具完成任务，而不仅仅是可用工具。 保持技能聚焦：技能数量是预算有限的共享资源；偏好少量内容丰富的技能，将细节加入 references/，合并近似重复的兄弟技能。 关键规则：使用小写 kebab-case 动名词命名（不加 posthog-* 前缀），用包含触发词的具体第三人称描述，SKILL.md 入口加 references/（保持 500 行以内），描述工作流而非僵硬脚本。 模板函数：.j2 文件在构建时使用 Jinja2；pydantic_schema、render_hogql_example 和 hogql_functions 等函数让领域知识保持以代码为准。

此技能用于审计并改进 PostHog 中的 DRF 序列化器与视图集，确保 OpenAPI 规范、生成的 TypeScript 类型以及 MCP 工具正确且完整。 优先分诊：先检查生成的 api.schemas.ts 和 api.ts，找出 unknown 类型、缺失 JSDoc 描述或缺失的接口操作，再修改 Python 代码。 序列化器清单：强制每个字段具有 help_text，列表/字典字段需指定带类型的 child=，自定义 JSONField 搭配 @extend_schema_field，ChoiceField 需显式列出 choices=，读写序列化器分离，并避免易冲突的枚举字段名以防 CI 失败。 视图集注解：普通 ViewSet 方法和自定义 @action 必须添加 @extend_schema 或 @validated_request，错误响应需类型化，声明分页，核心视图集需使用 x-product 扩展以便 MCP 脚手架正确路由。 路由与边界情况：新团队嵌套端点注册到 routers.projects（遗留 /api/environments 由中间件处理），针对 facade 模式（DataclassSerializer）产品调整实践，流式响应使用 text/event-stream 文档化。 验证：修改后运行 hogli build:openapi 和 find_enum_collisions，确认生成的 schema 与 MCP 工具输入无误。

评估并响应来自 Salesforce 的 PostHog 入站销售线索，决定是否符合通话条件、引导至自助服务或取消资格，并起草相应的回复邮件。 在资格认定前，集成 Vitally 检查现有账户上下文（用户或公司是否已是 PostHog 用户），据此调整处理方式和邮件框架。 通过网页搜索对线索所属公司进行强制研究，评估其增长轨迹（加速、稳定、早期/未知、平稳/下滑）、融资情况、员工数、工程团队比例、多产品信号以及 AI/ML 信号。 根据人选、公司和留言信号，将线索映射至 PostHog 的六大用例（产品分析、发布工程、可观测性、增长与营销、AI/LLM 可观测性、数据基础设施）中的一个或多个。 应用资格认定框架：2万美元年消费门槛、增长轨迹覆盖（对加速增长且具备高价值信号的公司，即使低于门槛也予以通话资格）以及多产品消费乘数；处理特殊情况，如竞争对手迁移和高价值公司的模糊请求。 围绕识别的用例起草回复邮件，必要时包含有针对性的探索性问题，并通过抓取每个链接验证邮件草稿中的所有 URL 是否能正确解析。

将密集的技术行话转化为清晰的解释,通过前后对比、隐喻和实际背景,服务于混合受众。 输入与工作流: 以 /eli5 path/to/file.md 方式运行,支持 .md/.mdx;自动检测内容类型,然后由你选择简化范围:全部、特定部分、自动检测的复杂区域或自定义行号范围。 清晰度分析: 识别行话、未言明的假设、不清晰的逻辑和缺失的上下文;生成去重术语索引,并给出建议动作(添加术语提示、交叉链接或内联定义),同时标出质量不佳的术语条目。 前后对比输出: 生成原始版与简化版的对比,包含平实语言摘要、"为什么重要"、何时使用、技术相关隐喻(并注明隐喻失效之处)、常见陷阱及相关概念。 理念与约束: 简化语言而非事实;只改写存在真实清晰度问题的内容,保留原本清晰的部分;所有新增信息(尤其是 Cloudflare 特定行为)必须对照权威来源核实。 受众与适用范围: 通过分层解释服务混合受众(开发者、IT 管理员、市场人员、学生、爱好者);最适合概念/概览/入门文档,而非开发者 API/SDK 参考或代码密集型教程。

Sentry 的设计系统强制使用来自 @sentry/scraps 的核心布局和排版原语，而非使用 Emotion 创建 styled components。 布局原语（Container、Flex、Grid、Stack）均继承自 Container，拥有其所有属性（position、padding、border 等），同时拥有各自专属属性（flex 方向、grid 列、gap）。Stack 默认列方向，并提供 Stack.Separator 用于添加分隔符。 排版原语（Text、Heading）替代原生 HTML 元素，通过受控属性控制大小、变体、对齐等。Heading 必须通过 as 属性指定语义级别。 信息组件（InfoTip、InfoText）提供可访问的工具提示模式用于上下文帮助，优先于直接使用 Tooltip。 薄抽象（为原语包裹默认属性）仅在得到用户明确确认和合理解释后方可创建，且必须扩展原语的 props 类型。 通用指南：强制使用响应式属性（默认基于容器查询，screen: 前缀针对视口），优先使用 gap/padding 而非已弃用的 margin，并始终将布局与排版分离到独立原语中。

分析 V8/Chrome CPU 性能剖析文件 (.cpuprofile) 和 DevTools 跟踪文件 (Trace-*.json)，找出性能瓶颈、对比代码路径并理解时间分布。 支持 .cpuprofile（V8 采样剖析器）和 DevTools 跟踪文件（Chrome Trace Event 格式），并提供详细的解析步骤。 关键分析流程：识别活动区域、测量里程碑之间的时间、通过计算每个函数的自身时间对比代码路径，并以时间线、Top 函数和堆栈跟踪形式报告结果。 针对大文件（>400MB）采用基于缓冲区的提取方式，避免 V8 字符串长度限制，并提供 Node.js 分析脚本。 从跟踪文件中提取嵌入式 CPU 剖析数据（ProfileChunk 事件），并分析用户时间标记（如 VS Code 标记）、长任务、布局/渲染、GC 压力和输入延迟。 提供全面的输出，包括时间线、持续时间、Top 函数、对比表格以及进程分解（渲染器、浏览器、GPU）。

评估现有移动产品是否以及如何迁移到 React Native,基于证据生成只读的迁移决策,而非执行迁移。 通过检查仓库/工作区根目录、推断受支持平台并建立平台清单来确定产品范围;在继续前需要能够访问每个生产客户端,当范围或驱动因素未知时,首轮回复每轮只问一个问题。 在基于仓库的评估(引用文件和行号)与访谈评估(每次用一个能改变决策的问题进行追问)之间选择,并要求所有关键声明标注为 observed/measured/reported/assumed/unknown。 推荐五种结果之一:brownfield(路径 A)、greenfield(路径 B)、带 brownfield 回退的 greenfield-first checkpoint(路径 C)、推迟迁移、或不迁移,每种都有明确的决策标准。 定义代表性 checkpoint,包含两到三个纵向流程、对照原生参考的可衡量验收标准、跟踪产物的负责人以及终局决策;通过将代表性变更映射到跨平台前置时间,并对比边际收益与全部投入来检验经济性。 仅在证据闸门通过或访谈结束后输出简洁的诊断报告,涵盖推荐、证据、假设与阻塞项、checkpoint、基线/ROI 以及下一步决策。