
Safety Critical Patterns
Audit or harden code paths where bugs have high consequence using NASA Power of 10–style verifiable patterns.
Overview
Safety-Critical Patterns is an agent skill most often used in Ship review (also Build backend, Ship security) that applies NASA-adapted Power of 10 rules for verifiable, defensive code.
Install
npx skills add https://github.com/athola/claude-night-market --skill safety-critical-patternsWhat is this skill?
- Applies 10 NASA Power of 10 rules adapted for modern languages (control flow, loops, assertions)
- Tiered rigor: full for safety-critical/financial/medical, selective for APIs, light touch for scripts
- Restricts risky control flow (goto, unbounded recursion) with documented termination expectations
- Demands fixed or documented loop upper bounds with safety limits
- Integrates with review-core and code-refinement dependencies for structured audit output
- 10 NASA Power of 10 rules adapted for modern development
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You are shipping logic where a subtle loop, control-flow, or assertion gap could cause financial loss, harm, or unrecoverable data corruption.
Who is it for?
Solo builders auditing payment rails, medical-adjacent features, authz, or core algorithms before release.
Skip if: Pure UI polish, marketing copy, or prototypes explicitly marked disposable where formal verification would slow learning without benefit.
When should I use this skill?
Auditing financial, medical, or high-reliability system code, or selectively hardening business logic and API handlers.
What do I get? / Deliverables
Review output maps your code against bounded-loop, control-flow, and assertion expectations with rigor scaled to the module’s consequence class.
- Structured review findings aligned to Power of 10 rule categories
- Rigor-tier recommendations (full, selective, light touch)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship review is the canonical shelf because the skill is invoked as an audit/refinement pass before production trust. Review subphase matches code-quality checks, defensive coding, and verifiability—not initial feature scaffolding.
Where it fits
Harden a ledger posting routine with explicit loop caps before wiring it into your API.
Pre-merge audit of auth and payment handlers using tiered NASA rule rigor.
Second pass on data-integrity modules where unbounded loops or missing assertions are unacceptable.
How it compares
Use for consequence-scaled defensive coding audits, not for generic lint autofix or dependency CVE scanning alone.
Common Questions / FAQ
Who is safety-critical-patterns for?
Developers and agent users working on high-reliability or regulated-adjacent code who want NASA-inspired verifiable patterns during review.
When should I use safety-critical-patterns?
In Ship review before merging risky modules, in Build backend while shaping core algorithms, and in Ship security passes on integrity-critical paths—not on every stylesheet tweak.
Is safety-critical-patterns safe to install?
Check the Security Audits panel on this page; the skill reads and critiques your codebase and may chain to other review skills in the same repo.
SKILL.md
READMESKILL.md - Safety Critical Patterns
# Safety-Critical Coding Patterns Guidelines adapted from NASA's Power of 10 rules for safety-critical software. ## When to Apply **Full rigor**: Safety-critical systems, financial transactions, data integrity code **Selective application**: Business logic, API handlers, core algorithms **Light touch**: Scripts, prototypes, non-critical utilities > "Match rigor to consequence" - The real engineering principle ## The 10 Rules (Adapted) ### 1. Restrict Control Flow Avoid `goto`, `setjmp/longjmp`, and **limit recursion**. **Why**: Ensures acyclic call graphs that tools can verify. **Adaptation**: Recursion acceptable with provable termination (tail recursion, bounded depth). ### 2. Fixed Loop Bounds All loops should have verifiable upper bounds. ```python # Good - bound is clear for i in range(min(len(items), MAX_ITEMS)): process(item) # Risky - unbounded while not_done: # When does this end? process_next() ``` **Adaptation**: Document expected bounds; add safety limits on potentially unbounded loops. ### 3. No Dynamic Memory After Initialization Avoid heap allocation in critical paths after startup. **Why**: Prevents allocation failures at runtime. **Adaptation**: Pre-allocate pools; use object reuse patterns in hot paths. ### 4. Function Length ~60 Lines Functions should fit on one screen/page. **Why**: Cognitive limits on comprehension remain valid. **Adaptation**: Flexible for declarative code; strict for complex logic. ### 5. Assertion Density Include defensive assertions documenting expectations. ```python def transfer_funds(from_acct, to_acct, amount): assert from_acct != to_acct, "Cannot transfer to same account" assert amount > 0, "Transfer amount must be positive" assert from_acct.balance >= amount, "Insufficient funds" # ... implementation ``` **Adaptation**: Focus on boundary conditions and invariants, not arbitrary quotas. ### 6. Minimal Variable Scope Declare variables at narrowest possible scope. ```python # Good - scoped tightly for item in items: total = calculate(item) # Only exists in loop results.append(total) # Avoid - unnecessarily broad total = 0 # Why is this outside? for item in items: total = calculate(item) results.append(total) ``` ### 7. Check Return Values and Parameters Validate inputs; never ignore return values. ```python # Good result = parse_config(path) if result is None: raise ConfigError(f"Failed to parse {path}") # Bad parse_config(path) # Ignored return ``` ### 8. Limited Preprocessor/Metaprogramming Restrict macros, decorators, and code generation. **Why**: Makes static analysis possible. **Adaptation**: Document metaprogramming thoroughly; prefer explicit over magic. ### 9. Pointer/Reference Discipline Limit indirection levels; be explicit about ownership. **Adaptation**: Use type hints, avoid deep nesting of optionals, prefer immutable data. ### 10. Enable All Warnings Compile/lint with strictest settings from day one. ```bash # Python ruff check --select=ALL mypy --strict # TypeScript tsc --strict --noImplicitAny ``` ## Rules That May Not Apply | Rule | When to Relax | |------|---------------| | No recursion | Tree traversal, parser combinators with bounded depth | | No dynamic memory | GC languages, short-lived processes | | 60-line functions | Declarative configs, state machines | | No function pointers | Callbacks, event handlers, strategies | ## Integration Reference this skill from: - `pensive:code-refinement` - C