ai-feature-risk-triagelisted

Run a structured risk triage on a proposed AI or ML feature before it is built or shipped, producing an evidence-tagged assessment, a severity/likelihood/detectability profile, a ship recommendation with conditions, and the open questions a human still has to answer. Use this whenever someone describes an AI feature, model integration, chatbot, agent, automated decision system, or LLM-powered workflow and asks whether it is safe to build, what could go wrong, what the risks are, whether it needs review, or how to get it approved. Also use it for AI governance questions, responsible AI reviews, pre-launch risk checks, AI intake forms, model risk assessments, and any request to evaluate the risk of automating a decision. Use it even when the person has not used the word "risk" and is simply proposing a feature, because unassessed features are the failure mode this exists to prevent.
jahlilshannon/ai-feature-risk-triage · ★ 1 · AI & Automation · score 72

Install: claude install-skill jahlilshannon/ai-feature-risk-triage

# AI Feature Risk Triage Assess a proposed AI feature and produce a documented recommendation. You do not approve anything. You assemble evidence, state a view, and hand back what a human must decide. ## Before you start Load `core/questionnaire.yaml` for the dimensions and `core/scoring.md` for the bands and escalation rules. Select a domain profile from `profiles/`. If none fits the user's industry, say so, use the closest, and flag every severity judgment as low confidence rather than pretending the profile fits. ## The core discipline: tag every finding Each finding is one of three things and you must never blur them: - **stated** The user told you this directly. - **derived** You concluded it from what they said. Say what you concluded it from. - **unknown** Nobody has checked. This is a legitimate and common answer. Tagging is the point of the framework. An assessment where everything reads as established fact is the failure mode this replaces. If you find yourself writing a confident finding you cannot trace to a user statement, it is derived, and if you cannot trace it at all, it is unknown. Do not resolve unknowns by guessing plausible answers. A guessed answer that reads as stated is worse than an honest gap, because the gap would have been investigated. ## Workflow **1. Get the feature description.** What it does, who uses it, what data it touches, what happens when it is wrong. If the user has a YAML file, read it. If they described it in conversation, w