agentsclimarketplace

Ai product risk review

Skill SylphxAI/skills/skills/ai-product-risk-review

Public agent skills from SylphxAI — standards, product procedures, and one-command sync for Codex, Claude Code, and Grok Build

Install
npx -y skills add SylphxAI/skills --skill ai-product-risk-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Design or audit one AI product behavior and launch contract covering the user job, AI necessity, model role, autonomy and action rights, data use, affected parties, failure and abuse, UX disclosure, fallback, cost and latency, support, evidence dependencies, and release boundaries. Use when an assistant, copilot, generator, classifier, recommender, or agent needs a product-risk dossier. Do not use for eval implementation, adversarial red teaming, security threat modeling, provider selection, a whole-product blueprint, or incident response.

SKILL.md

5.4 KB, as published. Nobody here has run it

AI Product Risk Review

Decide what an AI feature may promise, observe, decide, and do before its implementation or launch outruns the product's evidence and recovery capacity.

Workflow

  1. Define the decision, user job, affected parties, business value, non-AI baseline, feature stage, and consequence if the AI is wrong or unavailable.
  2. Establish current authority: product specification, data-flow inventory, model/provider route, tool/action contract, permissions, policy, current eval evidence, support capability, unit cost, latency, and launch state. Label absent facts not_verified; never infer them from model memory.
  3. Read references/ai-product-risk-systems.md.
  4. Decompose the experience into input/context, inference, output, user interpretation, optional action, downstream effect, feedback, and recovery.
  5. Classify autonomy, reversibility, affected-party reach, data sensitivity, misuse potential, failure detectability, and recovery difficulty. Record both intended use and predictable misuse.
  6. Design product controls: narrower scope or deterministic path, disclosure and provenance, editable draft, confirmation, permission, preview, bounded action, fallback, undo, appeal/reporting, support trace, and safe degraded state.
  7. Specify the evidence obligations and hand them to the applicable risk-matched-verification-standard, engineering-standard, privacy, and delivery-standard owners. Consume their exact evidence; do not recreate eval or red-team standards here.
  8. Define machine-readable launch states and predeclared hold, narrow, resume, withdraw, and model/provider-change decisions. Automate safe state transitions from authoritative evidence while preserving audit and recovery.
  9. Produce the AI product-risk dossier, UX/action contract, dependency handoffs, release decision, unresolved facts, and post-launch learning plan.

Source verification

Retrieve drift-prone product, route, provider, data, policy, evidence, cost, latency, and launch facts from their current typed or primary sources. Separate verified facts, measurements, assumptions, and product judgment. If authority is unavailable, mark the affected decision blocked; this procedure grants no live provider, policy, tool, or production authority.

Routing boundaries

  • Use risk-matched-verification-standard for eval design, judges, replay, simulation, red-team execution, and nondeterministic release proof.
  • Use security-threat-modeling for threat and security-design contracts; engineering owns implementation and vulnerability remediation, while incident-standard owns active incident response.
  • Use product-analytics-instrumentation-review for event/identity pipeline implementation after this dossier states the required product signals.
  • Use app-design-blueprint or game-design-blueprint when the primary artifact is the whole product rather than one AI behavior contract.
  • Use current provider/model retrieval for capabilities, prices, limits, latency, and policy. This skill never acts as live provider authority.

Guardrails

  • Do not add AI when a deterministic interaction can satisfy the job more reliably, cheaply, transparently, or accessibly.
  • Do not present generated or inferred output as verified fact, completed action, professional judgment, or authoritative source when it is not.
  • Do not let ambiguous model output directly perform irreversible, financial, legal, safety, privacy, access, account, or external-communication actions.
  • Do not expand training, retention, logging, retrieval, or provider use beyond the verified purpose and user/enterprise controls.
  • Do not make fallback remove user rights, hide failure, or silently switch to a route whose safety, data, cost, or quality contract differs.
  • Treat model, prompt, retrieval, tool, policy, and provider changes as product behavior changes requiring current evidence and a recoverable release decision.
  • Store only the minimum support trace; redact sensitive content and keep access, retention, user visibility, deletion, and audit semantics explicit.

Output

Decision and current facts:
- job / affected parties / non-AI baseline / route / autonomy / verified facts

Product-risk register:
| Stage | Failure or misuse | Affected party | Consequence | Detectability | Product control | Evidence owner | Recovery |
| --- | --- | --- | --- | --- | --- | --- | --- |

UX and action contract:
- generated-state disclosure / provenance / edit-review-confirm / permissions
- pending-success-failure states / fallback / undo-appeal-report / support trace

Evidence and owner handoffs:
- exact question / canonical owner / required artifact / blocked decision

Launch decision:
- hold / narrow / limited exposure / expand / withdraw
- machine trigger / audit record / recovery path / unresolved facts

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.