feature-risk-assessment

작성자: anthropic

단일 기능 또는 제품 영역에 대한 심층 위험 평가로, 출시 검토에서 한 줄 항목 이상이 필요한 사항이 발견된 경우에 사용합니다. 구조화된 분석: 무엇…

npx skills add https://github.com/anthropics/claude-for-legal --skill feature-risk-assessment

Feature Risk Assessment

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /product-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/product-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.


Purpose

The launch review is broad. This is deep. When a single issue needs more than a table row — a novel AI feature, a children's product, something a regulator is actively looking at — this skill produces a standalone assessment.

Not every launch needs one. Most don't. This is for the 10% where "PIA done, shipped" isn't the right level of scrutiny.

When to run this

  • Launch review found a pattern that's not in the calibration table (novel)
  • Launch review found something in the "usually blocks" category
  • GC or leadership asked "what's the risk here" and wants more than a one-liner
  • The feature is in an area with active regulatory attention (AI, children, biometric, health)
  • Someone outside legal is worried and a structured answer would help

If none of the above, the launch review is enough. Don't generate paperwork for its own sake.

Structure

1. What we're assessing

One paragraph. What the feature does, what's new about it, why it got escalated to a full assessment.

2. The risks

For each distinct risk (aim for 2-5, not 15):

### Risk [N]: [Short name]

**Scenario:** [What would have to happen for this to go wrong. Be specific —
not "data breach" but "the recommendation algo surfaces a user's sensitive
category interest to someone who shouldn't see it because X."]

**Who gets hurt:** [Users? The company? A third party? Specific.]

**How likely:** [Low / Medium / High — with a reason. "Low — would require
both X and Y to fail simultaneously." Not just a vibes rating.]

**How bad if it happens:** [Low / Medium / High — with a reason. "High —
regulatory fine + class action exposure + press" vs. "Low — one angry
tweet, no actual harm."]

**Existing mitigations:** [What already reduces the likelihood or impact]

**Gap:** [What's missing, if anything]

**Residual risk:** [After existing mitigations — is this acceptable or does
it need more?]

3. Regulatory landscape (if relevant)

Only include if a regulator is actively interested in this space. If so:

  • Which regulator, what they've said/done recently
  • How this feature would look to them
  • Whether we'd rather they hear about it from us or from a headline

4. Precedent (if any)

Has another company done something similar? What happened?

  • If nothing bad happened → useful, not dispositive
  • If something bad happened → what was different about their situation, does it apply here

Don't overweight precedent. Regulators change priorities; one company getting away with something doesn't mean the next one will.

5. Options

Present 2-3 realistic paths:

| Option | Description | Risk reduction | Cost |
|---|---|---|---|
| A: Ship as designed | [current plan] | None | None |
| B: Ship with [mitigation] | [change] | [how much] | [eng effort, timeline, UX] |
| C: Don't ship [component] | [scope cut] | [how much] | [product impact] |

6. Recommendation

Pick one. Explain why. Acknowledge what you're trading off.

**Recommended: Option [X]**

[Why. What risk remains. Why that's acceptable. Who accepts it.]

**If the answer is "not my call":** [Who decides, what they need to know]

Calibration check

Before finalizing, check against ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md → Risk calibration:

  • Is this risk assessment calibrated to this company, or is it generic?
  • A risk that's "High" at a company under a consent decree might be "Medium" at one that isn't
  • The assessment should reflect the actual regulatory posture, litigation history, and risk appetite captured in the practice profile

Handoffs

  • To AI governance: If the deep-dive was triggered by an AI feature — which it often is — run /ai-governance-legal:aia-generation [feature] in parallel or immediately after. The feature risk assessment frames the decision; the AIA documents the AI system specifically in the format AI governance needs. They're not duplicates: the FRA is a product-legal decision doc; the AIA is the governance record.
  • To privacy: If the feature involves new data collection or processing, run /privacy-legal:pia-generation [feature]. The FRA's risk section will likely overlap with the PIA's — flag that overlap so work isn't duplicated, but both docs need to exist.
  • To AI governance vendor review: If the feature uses a new AI vendor, run /ai-governance-legal:vendor-ai-review [vendor agreement] if not already done during the launch review.

Output format

Standalone doc, 2-4 pages. Prepend the work-product header from ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md ## Outputs (it differs by user role — see ## Who's using this).

Not a slide deck, not a memo to file — a decision document someone reads and then decides.

Save where ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md → Launch review process says review docs go. If the doc is going to be shared with anyone outside the privileged loop (e.g., posted to a broadly-shared ticket), drop the work-product header only for that externally-facing copy and keep the privileged original in the matter file.

Citation check

If the assessment cites cases, statutes, regulations, or enforcement actions — in the Regulatory landscape or Precedent sections especially — those citations were generated by an AI model and have not been verified against a primary source. Before the decision document goes to a decisionmaker, verify each citation against a legal research tool (Westlaw, CourtListener, or your firm's research platform) for accuracy, good law status, and current enforcement posture. A risk assessment built on a fabricated enforcement action is worse than no assessment.

No silent supplement. If a research query to the configured legal research tool returns few or no results for the regime or precedent the assessment needs, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [regime / precedent]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged [web search — verify] and should be checked against the issuing authority before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.

Source attribution. Tag every citation in the Regulatory landscape and Precedent sections with where it came from: [Westlaw], [CourtListener], [regulator site], or the MCP tool name for citations retrieved from a legal research connector; [web search — verify] for web-search citations; [model knowledge — verify] for citations recalled from training data; [user provided] for citations from the feature team. Citations tagged verify carry higher fabrication risk and should be checked first. Never strip or collapse the tags — the decisionmaker needs to see which citations to verify first.

Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

What this skill does not do

  • It doesn't assess every feature. Most features get a launch review and that's it.
  • It doesn't make the decision. It frames the decision. Someone with authority picks an option.
  • It doesn't do quantitative risk modeling. If the company has a formal risk framework with numbers, use that — this is qualitative.

anthropic의 다른 스킬

access
anthropic
Discord 채널 접근을 관리합니다 — 페어링 승인, 허용 목록 편집, DM/그룹 정책 설정. 사용자가 페어링 요청, 승인, 허용된 사람 확인 등을 요청할 때 사용합니다.
official
session-report
anthropic
~/.claude/projects 트랜스크립트에서 Claude Code 세션 사용량(토큰, 캐시, 하위 에이전트, 스킬, 고비용 프롬프트)에 대한 탐색 가능한 HTML 보고서를 생성합니다.
official
build-mcp-server
anthropic
이 스킬은 사용자가 "MCP 서버 구축", "MCP 생성", "MCP 통합 만들기", "Claude용 API 래핑", "도구 노출" 등을 요청할 때 사용해야 합니다.
official
cookbook-audit
anthropic
Anthropic Cookbook 노트북을 루브릭에 따라 감사합니다. 노트북 리뷰나 감사가 요청될 때마다 사용하세요.
official
handle-complaint
anthropic
들어오는 고객 불만을 처음부터 끝까지 처리합니다 — 맥락을 파악하고, 응답을 작성하며, 운영상의 수정을 제안합니다. 선택적으로 이메일이나 티켓 ID를 받습니다…
official
use-case-triage
anthropic
처리 활동이 PIA, 필수 GDPR DPIA가 필요한지 또는 진행 가능한지 신속히 판단하여 개인정보 처리방침 충돌을 표시하고 적절한 경로로 안내합니다…
official
board-minutes
anthropic
이사회 또는 위원회 회의록을 사내 형식으로 작성합니다. 캘린더에서 예정된 이사회 및 위원회 회의를 자동으로 감지하고, 안건을 요청한 후…
official
renewal-tracker
anthropic
유지 관리되는 갱신 등록부를 기반으로 취소 마감일이 다가오는 계약을 표시하고 통지 기간이 종료되기 전에 경고합니다. 사용자가 요청할 때 사용합니다.
official