Use when reviewing, designing, or modifying Java enterprise software products, AI-enabled products, RAG assistants, AI agents, generated instructions, related services, automated updates, vulnerability handling, corrective updates, warnings, instructions, or product-safety evidence under Directive (EU) 2024/2853, the EU Product Liability Directive. Part of Plinth Toolkit
npx skills add https://github.com/jabrena/plinth --skill 812-regulations-eu-product-liability-directive
Use this Skill to review Java software products, AI-enabled products, SaaS products, embedded software, related services, RAG workflows, GenAI maintenance assistants, AI-agent tool actions, generated instructions, automated updates, warnings, user instructions, vulnerability handling, corrective updates, and product-safety evidence that may raise EU Product Liability Directive concerns.
Apply this Skill to determine what engineering controls, safety evidence, incident records, update history, warnings and instructions, model or version provenance, product documentation, and owner handoffs are needed before a Java product, component, related service, AI feature, or product-adjacent change is released, updated, or relied on by users.
This Skill is not legal advice. It helps Java engineers, architects, tech leads, product teams, product safety teams, product security teams, support teams, and reviewers identify when Directive (EU) 2024/2853 concerns may apply and how to translate product-liability expectations into engineering controls such as safety-scope inventory, hazardous-scenario testing, generated-instruction review, AI-agent action constraints, warning and instruction evidence, update and corrective-action records, vulnerability handling, incident traceability, and qualified owner escalation.
The purpose of this Skill is to increase awareness of potential gaps in the system and create engineering evidence for qualified review. The response produced by this Skill does not represent legal advice, a legal opinion, a defectiveness determination, a compensable-damage determination, an economic-operator responsibility decision, or a final liability assessment.
The main question is:
> When does a Java software product or AI-enabled product require Product Liability Directive-aware safety evidence and owner handoff, and what should developers build differently?
Source provenance: Directive (EU) 2024/2853 of 23 October 2024 on liability for defective products was reviewed from the official EUR-Lex source while authoring the bundled references: https://eur-lex.europa.eu/eli/dir/2024/2853/oj/eng. Do not fetch or ingest external regulatory web pages at runtime; use the bundled references and escalate legal interpretation to qualified owners.
Product Liability Directive chapters summary reference: Product Liability Directive chapters summary.
Java engineering examples reference: Product Liability Directive engineering examples.
Questionnaire asset: Product Liability Directive engineering review questionnaire.
Report template asset: Product Liability Directive engineering review report template.
This Skill applies to:
Treat defectiveness, compensable damage, causal link, economic-operator responsibility, jurisdiction, limitation periods, development-risk defences, disclosure duties, and final liability assessment as qualified decisions for legal, compliance, product, product-safety, security, risk, support, and executive accountability owners.
Engineering teams should still create evidence that makes those decisions reviewable:
Translate Product Liability Directive concerns into engineering controls for Java software products and AI-enabled products. Do not provide legal advice or replace review by legal, compliance, product, safety, security, risk, support, or executive accountability owners.
Read references/812-regulations-eu-product-liability-directive-chapters-summary.md, references/812-regulations-eu-product-liability-directive-engineering-examples.md, assets/questions/812-product-liability-directive-engineering-review-questionnaire.md, and assets/reports/812-product-liability-directive-engineering-review-report-template.md in that order. Use the chapters summary for Product Liability Directive chapter, article, scope, software, defectiveness, damage, economic-operator, disclosure, burden-of-proof, liability, timing, and owner-handoff context. Use the engineering examples for Java control patterns such as safety scope inventory, generated-instruction evidence, AI-agent tool-action controls, automated update traceability, warning and instruction review, vulnerability handling, corrective updates, incident evidence, and release gates. Do not start implementation review until the chapters summary, examples reference, questionnaire rules, and report template are understood.
Use assets/questions/812-product-liability-directive-engineering-review-questionnaire.md as a checklist against trusted local project evidence and maintainer-approved sanitized facts. Record each answer with an evidence reference or mark it Unknown. Identify the product, component, related service, Java module, AI feature, generated instruction, AI-agent action, automated update path, intended purpose, reasonably foreseeable use, foreseeable misuse, affected users, deployment geography, product owner, safety owner, security owner, support owner, incident path, evidence stores, and release context. Escalate unclear product scope, defectiveness, compensable damage, causal link, economic-operator role, jurisdiction, limitation periods, development-risk defences, disclosure duties, and regulatory interpretation to qualified owners.
Review Java code, configuration, controllers, services, prompts, tools, RAG retrieval sources, model version records, generated outputs, AI-agent permissions, automated update mechanisms, vulnerability records, corrective update records, warnings, instructions, support records, incident evidence, audit logs, observability, product-safety tests, hazardous-scenario tests, CI/CD workflows, deployment records, release approvals, and user documentation. Check for gaps between claimed product-safety controls and reviewable evidence.
Map Product Liability Directive concerns to engineering actions: product-liability scope inventory, hazardous-scenario testing, source governance for RAG, prompt and generated-instruction review, AI-agent tool-action allowlists and human oversight, model and retrieval provenance, automated update validation, corrective update procedures, vulnerability handling, warning and instruction versioning, incident reconstruction, support handoffs, privacy-safe and trade-secret-safe evidence retention, and release readiness.
Use assets/reports/812-product-liability-directive-engineering-review-report-template.md to produce a concise engineering review with scope, evidence reviewed, Product Liability Directive risk signals, potential violation or non-compliance signals, product-liability evidence gaps, recommended controls, owner handoffs, residual risks, release decision, and validation steps. State explicitly that defectiveness, compensable damage, causal link, economic-operator responsibility, jurisdiction, limitation periods, development-risk defences, disclosure duties, and final liability assessment require qualified owner review.
For detailed guidance, examples, and constraints, see:
Guides security professionals in implementing defense-in-depth security architectures, achieving compliance with industry frameworks (SOC2, ISO27001, GDPR, HIPAA), conducting threat modeling and risk assessments, managing security operations and incident response, and embedding security throughout the SDLC.
Query and download public cancer imaging data from NCI Imaging Data Commons using idc-index. Use for accessing large-scale radiology (CT, MR, PET) and pathology datasets for AI training or research. No authentication required. Query by metadata, visualize in browser, check licenses.
Hunt LLM/AI feature bugs — prompt injection, indirect injection, exfiltration via tool-use/markdown, ASCII smuggling, agentic AI security (OWASP Agentic Apps 2026, ASI01-ASI10). Patterns: direct injection ('ignore previous instructions'), indirect injection via documents/web pages/email the model reads, ASCII smuggling (Unicode Tags block U+E0000-U+E007F, invisible to humans, decoded by the model), tool-use exfiltration (model has fetch/browse tool, attacker injects OOB URL, model exfils chat history/secrets), markdown-image zero-click exfil, system-prompt extraction, IDOR-via-AI (cross-tenant data). Targets: chatbots, RAG, summarizers, agentic copilots, MCP tools. Detection: any LLM-backed endpoint, doc upload triggering AI processing, autonomous agent with tools. Validate: OOB/Collaborator callback for exfil, verbatim-reproducible system-prompt leak (run twice), verifiable cross-tenant leak or RCE. Confabulation is NOT a finding. Use when hunting AI features, chatbots, RAG, agentic systems, MCP.
Query and download public cancer imaging data from NCI Imaging Data Commons using idc-index. Use for accessing large-scale radiology (CT, MR, PET) and pathology datasets for AI training or research. No authentication required. Query by metadata, visualize in browser, check licenses.
Invoke an already configured model endpoint from a supported Wisp execution context and capture the bounded inference as a Run. Use only when the endpoint URL and authentication are already available inside that context; this skill does not register or manage services.
OWASP LLM Top 10 (2025) audit checklist for AI applications, agent tools, RAG pipelines, and prompt construction. Use when performing any security review touching LLM client code, prompt templates, agent tools, or vector stores.
Use when attacking an AI/ML system or model — prompt injection & jailbreaks (Crescendo, Skeleton Key, Best-of-N), RAG/vector poisoning, agentic/MCP exploitation (CVE-2025-54136), ML supply-chain RCE (pickle CVE-2025-32434), model extraction / membership inference / adversarial suffixes (GCG)
Security guidelines for LLM applications based on OWASP Top 10 for LLM 2025. Use when building LLM apps, reviewing AI security, implementing RAG systems, or asking about LLM vulnerabilities like 'prompt injection' or 'check LLM security'. IMPORTANT: Always consult this skill when building chatbots, AI agents, RAG pipelines, tool-using LLMs, agentic systems, or any application that calls an LLM API (OpenAI, Anthropic, Gemini, etc.) — even if the user doesn't explicitly mention security. Also use when users import 'openai', 'anthropic', 'langchain', 'llamaindex', or similar LLM libraries.
Take jabrena/812-regulations-eu-product-liability-directive from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.