Security audit
Security checks for vulnerabilities and agentic risk
This action-planning skill has inconsistent spending controls that can turn an expected preview into paid analysis.
Prefer a corrected package that enforces its fixed workflow and keeps previews free of execution. If proceeding, require confirmation before every charge, use the dedicated operations quote/run workflow, and select manual collection for one-time work. Do not use deepdive as a quote-only preview. The skill stores an ARI API key locally and uses ARI's online service.
scripts/ari.pyQuote-only deepdive can silently enter paid analysis
Account credits can be consumed during a workflow represented as quote-only. When the primary subscription is absent and --confirm was supplied, the command can additionally report that analysis was downgraded and no credits were charged even though its helper executed paid analysis.
The declared purpose is action-plan generation, but the supplied commands manage recurring monitoring subscriptions rather than produce priorities or checklists. Persistent watch lifecycle changes and explicit per-refresh price acceptance are material capabilities not disclosed in the description, rather than ordinary supporting details of a one-time action-planning workflow. The implementation of scripts/ari.py is not supplied, so actual billing or additional behavior cannot be confirmed.
The document mixes a fixed, explicitly confirmed action-plan workflow with generic instructions to execute paid VOC generation without prior price confirmation. Although the final section restricts this entry point, the contradictory actionable instructions create a credible route to unintended credit spending; the claimed code-level enforcement gaps cannot be verified from this file.
Recurring monitoring lifecycle management and explicit per-refresh price acceptance materially extend beyond generating a single-ASIN seller action plan. Optional competitor tracking also expands the stated scope. Digests and historical data could support planning, but creating, resuming, and deleting scheduled watches are distinct operational capabilities not disclosed in the description. The snippet lists commands rather than their implementation, so it does not establish that any watch was actually created or any charge incurred.
The declared purpose is action-plan generation, but the supplied commands expose a stateful monitoring lifecycle with recurring refreshes and price acceptance. These are material capabilities beyond analyzing product details and reviews to produce priorities or checklists. Monitoring data could support planning, but creating and managing potentially chargeable scheduled watches is not merely an implementation detail. The chunk is reference documentation rather than implementation code, so it establishes the advertised command capabilities, not that any watch was actually created or any charge incurred.
Obtaining product data could support the declared planning purpose, but configuring persistent monitoring and recurring collection is a separate operational capability not disclosed in the description. The snippet demonstrates scheduling controls rather than action-plan generation. This assessment is limited to the supplied commands; the implementation of scripts/ari.py is not shown.
The comparison workflow recommends binding a competitor and states that binding triggers weekly collection, without attaching a specific recurring-cost disclosure and consent step to that command. This can turn a one-time comparison request into persistent collection and potentially ongoing credit consumption, despite broader authorization safeguards elsewhere.
The supplied command targets an entire category and requests a leaderboard ordered by a negative-rate metric. It neither identifies a single ASIN nor requests an action plan or checklist. This is a materially different scope and output from the declared purpose. The underlying script is not supplied, so no additional API access, mutations, or effects of --confirm can be established.
The supplied commands expose watch-service pricing and listing capabilities that are not described in the declared single-ASIN action-planning purpose. The chunk shows no product-detail or review analysis, prioritization, or checklist generation. Although watch queries could support a broader workflow, their connection to the declared task is not established here. The snippet does not show watch creation or modification.
The supplied command explicitly selects '--type compare' and supplies '--competitor', indicating a competitive-comparison workflow not described in the declared single-ASIN planning purpose. The chunk does not show generation of operational priorities or checklists. Because the script implementation is not supplied, no additional behavior or resource access can be established.
The supplied commands expose monitoring-related quotation and listing functionality that the description does not declare. The chunk does not show product-detail or review analysis, action prioritization, or checklist generation. Although monitoring could inform seller planning, these watch-management operations are distinct user-facing capabilities rather than merely implementation details of the declared action-plan workflow.
The supplied commands target watch-monitoring resources rather than explicitly retrieving product details and reviews or generating a single-ASIN action plan. Although monitoring data could potentially support planning, that relationship is not established in this chunk. The visible behavior therefore introduces an undeclared monitoring capability. No account modification, inventory decision, or profit decision is shown.
The supplied command explicitly selects '--type compare' and supplies '--competitor'. Its visible purpose is comparative analysis, which is not disclosed in the single-ASIN action-planning description. The script implementation is not supplied, so no additional behavior or side effects can be established.
The supplied entry point targets alerts, while the description promises single-ASIN analysis and operational prioritization. No product/review analysis or action-plan generation is visible. The script implementation is not supplied, so the exact alert behavior and any external access cannot be established.
run_analysis changes confirm=False to True based on the server's autoConfirm field, allowing chargeable execution without the explicitly promised --confirm flag. cmd_voc similarly extends a server analysis policy to combined collection and analysis, while deepdive can unexpectedly execute analysis through the same helper; sufficient balance does not establish user consent.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- 重新发布：各市场首批上架的 1.5.0 包早于免确认修复，新注册的免费版用户仍会被要求先确认报价。
1.5.1 与当前官网下发的修复版一致，市场侧以新版本号覆盖旧包。
- 免确认只认服务端报价返回的 `autoConfirm`；采集报价扣除首次采集免费页；
非美国站首次采集可用赠送积点时不再提示「赠送积点不可用」（行为与修复后的 1.5.0 相同）。
- 命令、字段与计费规则不变，不提高最低支持版本。
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- 行为变更：新用户（注册并验证邮箱后）第一次要 VOC，只给 ASIN 即可（站点默认美国站），
`voc` 直接执行——自动补采集（默认 3 页）、生成报告、按服务端定价扣费并归档，
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
为 true 时赠送积点计入 `nonUsCollectCredits`、`siteNote` 为空；UK/DE/JP 卖家的第一份 VOC 同样一步直出。
- 余额不足仍在执行前拦截（402）并引导充值；定价以服务端配置为准，代码常量仅为兜底。
- 一致性：`analyze` 各类型（insight / keywords / trend / variant / compare）走同一口径，
`autoConfirm=true` 即直接生成并返回 `charges`。
- 文档：移除所有写死的单价与合计示例。采集/分析单价与页数由后台 `pricing` 配置决定，
一律以本次报价返回的 `credits` / `totalCredits` 为准，不得凭文档或记忆报数。
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- 能力层收窄：44 个专属包不再只是「声明窄」，包体 `scripts/ari.py` 同时按各自契约裁剪。
构建期用 AST 删除文档未承诺的命令、它们的解析器注册块，以及只被它们引用的辅助函数与
常量；专属包因此不再包含 `export`（任意路径写文件）、`autoconfirm`（撤销逐次确认）、
`workbench`（改写差评处理状态）、`alerts`（标记预警已读）、`competitors`、`schedule`、
`voc` / `analyze` / `charts` / `deepdive` 等母版命令。
- 新增运行期兜底闸：专属包在包内写入 `allowedCommands` 白名单，`ari.py`
Without declared permissions the skill's intent is opaque and cannot be validated.
This instruction permits credit deduction based on server-default first-use allowances without an amount limit, rather than requiring user-established spending authority. Explicit user-configured thresholds can legitimately authorize spending, but the documented default allowance does not establish equivalent consent.
`voc <ASIN>`（没说站点就用默认的美国站，不要为此追问）。
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）
A returned autoConfirm flag is treated as sufficient authorization even when it reflects a service promotion or default rather than a user's spending policy. Reliance on that flag can bypass informed approval of a variable-cost operation.
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）
才报出 `totalCredits` 与余额并等待同意，同意后追加 `--confirm`。
The workflow directs execution before price disclosure and explicitly describes first-use behavior as delivering the report before discussing payment. A report identifier proves completion, not prior authorization, so post-execution charge reporting does not resolve the consent gap.
1. 运行 `check`，确认账户、邮箱验证状态和可用积点。
2. 用户要 VOC / 评论分析报告时，默认运行 `voc <ASIN> --site <站点>`，**不要再先跑一次报价**。
**返回里有 `autoConfirmed: true`（或直接带 `reportId` / 正文）就说明报告已经生成并扣点了**
（1.5.0：新用户首次体验直接出结果，用户先拿到报告再谈钱）。
此时把报告讲给用户，并转述 `charges` — 本次采集扣了多少、分析扣了多少、合计多少、扣后还剩多少。
**不要在拿到结果后再补问「要不要生成」，也不要再回头补一次报价。**
The passage instructs immediate paid generation when autoConfirm is returned and says initial paid runs have no amount ceiling. This can consume credits without informed approval when auto-confirmation originates from service defaults instead of the user's explicit settings.
- **价格一律以服务端本次报价为准**（`analysis/quote` 与 `collect` 报价返回的 `credits` /
`totalCredits`）。文档与示例里出现的任何单价、页数、合计都只是演示，后台可调，
**不要凭记忆或旧文档报数，也不要把示例价当成承诺价。**
- 报价返回 `autoConfirm: true` 时直接生成，不要再问「要不要」。
生成后一句话交代本次实际扣了多少、扣后余额（读 `charges` 字段）。
1.5.0 起服务端对新用户前几次付费生成不看金额上限：新用户验证邮箱后只给一个 ASIN，就一次性出报告。
- 用户说「以后别问了 / 50 以内直接做」→ 运行 `autoconfirm 50`；说「以后每次先问我」→ `autoconfirm off`；