Imported from zznabil/lean-agent-skill-collection (packs/remaining-standards/gated-skills/guard-safety-critical-standards/SKILL.md). Install upstream with npx skills add zznabil/lean-agent-skill-collection --skill guard-safety-critical-standards. Copyright stays with the author.

Safety-critical domain standards

Task and boundary

• Determine the required authoritative workflow when a project enters a safety-critical or regulated domain.
• Do not treat this generic register category as one named standard or invent domain certification requirements.
• Work only on the selected artifact or assessment. This routine does not grant permission to run attacks, deploy, publish or change policy.
• OFF-DEFAULT GUARD: use only for the stated selection or review request; do not install as an always-on workflow.

Source and limits

• Read SOURCES.md for the selected edition, official files, source boundaries and copying terms.
• Read the relevant source sections before making a source-specific decision. A compact routine is not the complete specification.
• Historical adoption decision: Project-local only. Keep this boundary unless an authorised decision explicitly changes it.

Procedure

1. Identify the product, intended use, hazards, deployment setting, jurisdiction and responsible domain authority.
2. Obtain the applicable laws, standards, editions and contractual requirements from authorised sources and qualified reviewers.
3. Separate source discovery from a determination of legal or regulatory applicability.
4. Record the required safety lifecycle, assurance evidence, independence and approval responsibilities as actually established.
5. Preserve traceability from hazards and risk controls to implementation and verification.
6. Do not claim that generic Lean, a language pass, unit tests or a standards checklist satisfies the domain process.
7. Perform safe preparatory analysis without conducting unauthorised consequential actions.
8. Escalate unresolved safety-critical requirements to the designated qualified owner.
9. Record limitations and hold points that prevent release or use; do not waive them to complete the task.
10. Return the domain-source and responsibility map. No canonical PDF exists for this heterogeneous register category.

Preserve and verify

• Preserve facts, identifiers, links, required checks, permissions, negation, exceptions and failure/recovery paths.
• Separate planned work, actual evidence and unknown results. Missing or stale evidence is not a pass.
• Do not delete requirements to improve a score or satisfy the line budget; record an unresolved source or task conflict.
• Use the smallest check that can detect the relevant defect. A schema, linter or inventory alone does not prove task success.

Worked case — authored, not an executed model result

• Situation: A medical-device feature is declared safe because it passed the general code-review checklist.
• Expected: Require the actual qualified domain assessment and evidence; the generic checklist is not a substitute.
• Missing-evidence case: Applicable jurisdiction, product classification or qualified approval authority is unknown.

Finish and stop

• Return the scoped result, evidence, unresolved requirements and next permitted action.
• Make one correction pass and recheck affected evidence. If a required issue remains, report it rather than looping or claiming completion.
• Identify the checked scope, source edition, evidence and limits. Do not claim formal conformance or model-behaviour improvement from this routine.