Converts hardware safety certifications into trust-building GTM content: safety pages, transparency reports, certification-to-content conversion, and incident communication protocols. Safety is the highest-leverage trust signal with the stakeholders who block hardware deals — procurement, legal, EHS, and insurance. This skill treats safety documentation as a growth asset, not a legal obligation.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Converts hardware safety certifications into trust-building GTM content: safety pages, transparency reports, certification-to-content conversion, and incident communication protocols. Safety is the highest-leverage trust signal with the stakeholders who block hardware deals — procurement, legal, EHS, and insurance. This skill treats safety documentation as a growth asset, not a legal obligation.
triggers
["/safety-trust","user needs to create safety documentation or a safety page","a hardware deal is stalling at procurement or EHS review","a safety incident has occurred and needs to be communicated","user wants to differentiate on safety against competitors"]
Safety content is always data-first, not certification-logo-first
Every certification produces at least one piece of content (not just a logo on the website)
Safety page meets the minimum content standard before product goes to market
Incident communication follows the five-step protocol — no silence
The output names which stakeholder the content is designed to move, and why
Role: Safety Communication Architect. Safety is the highest-leverage trust signal with the stakeholders who block hardware deals — procurement, legal, EHS, and insurance. Teams that treat safety as a legal department problem lose deals to teams that treat it as a marketing asset. A robot that passes technical evaluation but fails the safety review never deploys.
Inputs
Required before proceeding:
Product name and product type
Certifications currently held (or in progress)
Available safety test data (published or internal)
Context: new content build / deal stall / incident response
The core principle
THE TRANSPARENCY PARADOX
Publishing safety data is rare in hardware.
Companies that publish it are trusted more than companies that display certification logos.
Why:
An EHS engineer can evaluate data. They cannot evaluate a logo.
Procurement can see a certificate number and verify it. They cannot evaluate a claim.
Insurance underwriters ask for test data, not marketing copy.
The companies that win safety reviews are the ones who answer questions
before they are asked — not the ones who have the most certifications.
This also applies to incidents:
A company with a documented incident history that they handled transparently
often scores HIGHER on procurement safety reviews than competitors with no
documented incidents — because reviewers know incidents happen and they
evaluate your PROCESS, not your luck.
Step 0 — Certification landscape by market
Know what is required for your launch market before designing content. This table is directional — verify current requirements with a legal or regulatory specialist.
REQUIRED CERTIFICATIONS BY MARKET
Market | Robot / automation hardware | AI-adjacent hardware
EU | CE marking (Machinery Directive / | CE marking; AI Act compliance
| Machinery Regulation 2023); | if AI component is in a
| collaborative robots require | high-risk category
| ISO 10218-1/2 + ISO/TS 15066 |
US | No mandatory federal standard for | FCC for radio emissions;
| industrial robots; OSHA defers to | FDA for medical devices
| ANSI/RIA R15.06; UL listing for |
| electrical safety |
China | GB standards; CCC mark for | MIIT regulations for
| electronic products | intelligent robots (evolving)
Japan | PSE mark for electrical safety; | (PSE applies)
| JIS standards |
Medical devices | FDA 510(k) / PMA (US); | High-risk AI Act category
(global) | MDR (EU); varies by device class | in EU if diagnostic
Automotive (global) | IATF 16949 quality management; | ISO 26262 functional safety
| OEM-specific audits | if component is in-vehicle
TIMING RULE:
Get the certification required for your launch market first.
Start the process 6–12 months before expected commercial launch.
Certification timelines are long and non-negotiable — they cannot be
compressed in the last 60 days before launch.
MULTI-MARKET NOTE:
If you plan to launch in EU and US simultaneously, start both certification
processes at the same time. CE and UL/ANSI certification requirements diverge
enough that sequential processing will delay one market by 3–6 months.
Step 1 — Certification-to-content conversion
Every certification produces content. A certification that does not produce content is a cost, not an asset.
CERTIFICATION → CONTENT CONVERSION TABLE
From this certification Make this content
CE testing completed "How we designed for CE compliance: the specific
changes we made to meet the Machinery Directive"
ISO 10218 risk assessment "Our robot risk assessment framework: what we
evaluated, what we changed, and how we validated"
ISO/TS 15066 (collaborative ops) "How we validated collaborative operation safety:
speed and force limits in each operating mode"
OSHA audit or third-party review "Third-party safety audit results: published"
(link to summary document, not just the logo)
Safety test data (force limits, Data sheet + explainer: "What our safety numbers
stop times, load capacity) mean in real operating conditions"
Example: "Maximum contact force: 150N. In practice,
this means: [relatable physical comparison]"
CE Declaration of Conformity Published as a downloadable PDF with certificate
number, issuing body, and expiry date visible
CONTENT FORMAT BY AUDIENCE:
EHS engineer: numerical test data, standards references, test methodology
Procurement: certificate numbers, issuing body, expiry dates, download links
Legal / insurance: third-party audit reports, risk assessment summaries
Operations manager: "what does this mean for day-to-day operation" explainer
Executive: one-paragraph safety posture summary with key certifications named
Step 2 — Safety page minimum content standard
This standard must be met before product goes to market. No launch without a safety page.
SAFETY PAGE MINIMUM CONTENT CHECKLIST
[ ] Which certifications the product holds
Format: Certification name + Standard number + Issuing body + Certificate number + Expiry date
NOT: a logo grid without details
[ ] Safety standards the product was designed to meet
Name the standards, not just "we are compliant"
Example: "Designed to meet ISO 10218-1:2011 and ISO/TS 15066:2016"
[ ] Key safety specifications (product-category specific)
For collaborative robots: maximum contact force (N), stopping time (ms),
payload limits (kg), operating speed limits
For industrial machinery: guarding requirements, emergency stop specs,
hazardous energy lockout provisions
For consumer hardware: IP rating, operating temperature range, applicable
electrical safety standards
[ ] Contact for safety inquiries
Named contact or dedicated email address
NOT: "contact us" form that routes to a general inbox
Response SLA stated: "Safety inquiries are acknowledged within 24 hours"
[ ] Third-party certification body name
NOT: "certified" — who certified it?
Format: "Certified by [body name], certificate [number], valid through [date]"
[ ] Download link for Declaration of Conformity or equivalent
PDF, directly accessible without a form or login
ANTI-PATTERN: a safety page that exists only to display logos.
The logos tell a sophisticated buyer nothing they couldn't assume.
The data tells them something they can actually evaluate.
Step 3 — Deal stall: safety objection response
Use when a deal is stalling at procurement, legal, EHS, or insurance review.
SAFETY OBJECTION DIAGNOSIS
Objection type 1: "We need to see your certifications"
Likely cause: standard procurement requirement; not a real blocker
Response: send the safety page URL + Declaration of Conformity PDF + certificate numbers
If they ask for more: they have a specific concern — ask what specific standard
or scenario they need addressed
Objection type 2: "Our EHS team has questions about [specific scenario]"
Likely cause: real technical concern; they've identified a specific use case
Response:
- Ask for the specific scenario in writing
- Provide specific test data for that scenario (force limits, stopping behavior,
detection range) — not general certification claims
- If data doesn't exist for that exact scenario: acknowledge it, propose a
controlled test at their site, give a timeline
Objection type 3: "We need a third-party safety assessment for our site"
Likely cause: internal policy requirement; not product-specific
Response:
- Confirm which standard or assessment format they require
- Offer to support the assessment with technical documentation and an
application engineer on-site
- If no third-party assessor: name two certified assessors who work with your
product type; facilitate the connection
Objection type 4: "We had an incident with a [competitor product] and now have concerns"
Likely cause: procurement and legal are risk-averse after a relevant incident
Response:
- Acknowledge the concern directly — do not minimize the incident
- Provide your incident history transparently (see Step 4 for format)
- Explain specifically how your product's design addresses the failure mode
involved in the competitor's incident
- Offer a supervised demo or site visit to demonstrate the safety behavior
RULE: never respond to a safety objection with general certification claims.
Name the specific data that addresses the specific concern.
Step 4 — Incident communication protocol
Use when a safety incident has occurred (or is reported by a customer or third party).
INCIDENT COMMUNICATION — FIVE-STEP PROTOCOL
Step 1: ACKNOWLEDGE FIRST (within 24 hours of becoming aware)
Acknowledge publicly before the investigation is complete.
Silence is interpreted as hiding.
Format: "We are aware of a reported [incident description] involving [product].
We are investigating. We will provide a full update by [specific date].
Safety inquiry contact: [email/name]."
Do NOT: wait for the full investigation before acknowledging.
Do NOT: issue a "no comment" response.
Step 2: DESCRIBE THE FAILURE MODE SPECIFICALLY
When communicating about the incident:
"The system stopped unexpectedly when [specific condition]" is better than
"a software issue was identified"
Specific descriptions:
- Show that you understand what happened
- Give affected customers information they can act on immediately
- Prevent speculation from filling the information vacuum
Step 3: DESCRIBE THE INVESTIGATION
What you found, what you changed, how to verify the fix.
Include: root cause, corrective action, verification method.
Exclude: blame attribution, legal disclaimers in place of information.
Step 4: UPDATE AFFECTED CUSTOMERS DIRECTLY
Every deployed customer hears about a safety incident from you before they
hear about it elsewhere.
Channel: direct email or call from a named contact (not a system notification)
Timing: before any public disclosure
Content: what happened, whether their system is affected, what action to take
Step 5: PUBLISH THE ROOT CAUSE AND FIX
Publish a summary of the root cause and corrective action publicly.
Format: technical summary accessible to an EHS engineer.
Include:
- Specific failure condition
- Root cause determination
- Corrective action taken
- How to verify the fix on an existing deployment
- Whether a field update / recall / advisory is required
THE TRANSPARENCY PARADOX IN PRACTICE:
Companies that publish their incident handling process often score higher on
enterprise procurement safety reviews than competitors with no documented incidents.
Reviewers know incidents happen. They are evaluating your process.
Step 5 — Safety as positioning content
Safety data that lives only on the safety page is underutilized.
SAFETY CONTENT DISTRIBUTION
Surface | Content type | Audience
Safety page | Full data + certifications | EHS, procurement, legal
Demo (Step 4 in sequence)| Key specs in one sentence | All
Sales email sequence | "Safety review package" | EHS, procurement
Partner enablement | Safety FAQ for SI partners | Partners fielding objections
LinkedIn / industry media| Certification + explainer | General industry awareness
| "How we designed for CE" |
Trade press | Third-party audit results | Technical community
PR | Transparency report | Media, general public
DIFFERENTIATION PRINCIPLE:
If your top 3 competitors display certification logos without data,
publishing data is a competitive differentiator.
Frame: "We publish our safety test data because procurement and EHS engineers
evaluate data, not logos. Here is what we tested, how we tested it, and what
it means for your application."
SAFETY AS SALES ACCELERANT (for sales teams):
The safety review is often the longest step in hardware procurement.
A "safety review package" (safety page URL + Declaration of Conformity PDF +
third-party audit summary + relevant test data for the customer's use case)
handed to the prospect's EHS team at the start of the conversation — not at
the end — reduces sales cycle by eliminating a reactive step.
Output format
## Safety Trust Brief
**Product:** [Name]
**Context:** [New content build / Deal stall / Incident response]
**Certifications held:** [List with numbers and expiry dates]
### Safety page status
[ ] Certifications with issuing body, number, expiry date
[ ] Standards designed to meet (named specifically)
[ ] Key safety specifications (product-appropriate)
[ ] Safety inquiry contact with SLA
[ ] Third-party certification body named
[ ] Declaration of Conformity download link
Overall: [Complete / Missing: list missing items]
### Certification-to-content conversion
| Certification | Content piece | Status |
|---|---|---|
| [Cert name] | [Content type] | [Published / Draft / Planned / Not started] |
### Deal stall response (if applicable)
Objection type: [Which pattern]
Specific concern: [What the stakeholder needs]
Response: [Specific data or action]
### Incident communication (if applicable)
Acknowledgment: [Sent / Not yet — deadline: date]
Failure mode description: [Specific language]
Customer notification: [Sent to N customers / Pending]
Public summary: [Published / Draft / Timeline: date]
Brain reads / writes
If a companion brain repo is connected:
Before starting:
Read knowledge/icp-map.md — ICP segment determines which safety stakeholders are involved in procurement (factory automation buyers always involve EHS; consumer hardware buyers rarely do)
Read playbooks/messaging.md — safety positioning should be consistent with the product's overall positioning narrative
