用途：为仓库中的应用添加结构化 Sentry 日志，目标是提供少量高价值日志，便于理解生产行为并作为后续插桩的示例。前提是仓库已具备基本 Sentry 配置，否则需先用相应技能完成配置。
主要能力与用法：先清点仓库内每个应用（依据 composer.json、package.json、go.mod、Gemfile、pyproject.toml、Cargo.toml 等清单），生成包含应用、路径、语言、Sentry SDK、日志抽象、状态的表格；应用超过约 2 个时先与用户确认范围。随后统一约定属性命名空间（如 myapp.<domain>.<field>）、事件名措辞与日志级别，并记录服务边界上的 trace 头传播。逐个应用完成：读取对应语言技能并确认日志配置；确定日志抽象（Monolog/PHP、slog/Go、Rails logger/Ruby、Pino 或 console/JS），Sentry 支持则配置集成，否则直接用日志 SDK；挑选少量高价值日志（运行时决策、重要算法、审计事件、可恢复失败上下文）；按约定添加结构化日志；运行 lint/type/test 并确认日志输出，工具链不可用需明确说明。
验证与取舍：对每条日志检查其回答的生产问题、信号价值、是否更适合 trace/metric/error、是否已有覆盖、结构一致性、是否含 PII/密钥/原始载荷、可操作性。优先移除仅确认常规 UI 交互、重复通用 API 失败或记录预期校验失败的日志；保留解释运行时决策、总结多步流程、记录审计/业务事件或提供可恢复失败上下文的日志。最后对照清单确认每个范围内应用达到 verified 或明确延后，报告逐应用状态。
适用场景：需要为多语言应用建立一致结构化日志、补充关键运行时决策与审计事件、或为团队提供日志示例时。
限制：不追求最大化日志覆盖；不记录每行代码或函数调用（应使用 tracing/profiling）；避免 PII、密钥、原始载荷；大块数据仅在明确目的下记录；异常优先用 errors 而非日志。具体命令与代码示例资料未提供。