@lenardangeloolajay/len-toolkit 1.1.0

package/templates/skills/refactoring-guru/refactoring-guru.mini.md

@@ -0,0 +1,64 @@
+# OBEY Refactoring.Guru
+
+## When to use
+
+Use when changing existing code where code smells, refactoring technique choice, behavior preservation, and cleanup scope control matter.
+
+## Primary bias to correct
+
+Refactoring is not general cleanup or pattern application. It is a small, smell-driven, behavior-preserving treatment with verification and a stop condition.
+
+## Decision rules
+
+- Separate refactoring from feature work and bug fixes. If behavior changes, name it as behavior change and isolate it from structural edits.
+- Diagnose the smell before choosing a technique: symptom, maintenance cost, scope, expected cleaner end state, verification path, and stop condition.
+- Prefer the smallest treatment that directly reduces the diagnosed smell; escalate only when the smaller technique is blocked.
+- Keep the code runnable and understandable through small named transformations rather than broad redesign.
+- Run relevant checks after risky moves, public interface changes, state-flow changes, or algorithm substitution.
+- Stop when the named smell is gone or materially reduced; record new smells separately unless they block the current change.
+- Use the Rule of Three: tolerate uncertain duplication early, but refactor the third similar occurrence unless the similarity is coincidental.
+- Treat technical debt as compounding cost; pay down the debt that slows current change speed, correctness, or team understanding.
+- Scan smells by category: bloaters, object-orientation abusers, change preventers, dispensables, couplers, and incomplete library gaps.
+- For bloaters, prefer extraction, parameter/data modeling, and responsibility splits before creating method objects, subclasses, or interfaces.
+- For switch/type-code smells, isolate the decision first; use polymorphism, subclasses, or state/strategy only when variation is stable and repeated.
+- For change preventers, move behavior and data toward the owner of the changing concept so one conceptual change has one main edit site.
+- For dispensables, delete or inline unused structure, but check public, generated, reflected, serialized, plugin-facing, and framework extension uses first.
+- For couplers, reduce navigation and private knowledge; keep delegating layers only when they hide volatile structure, policy, or a real boundary.
+- Use comments for rationale, constraints, contracts, or hard algorithms; use names, variables, methods, or assertions when comments explain unclear code.
+- Keep behavior with the data it changes unless separation deliberately supports interchangeable behavior.
+- Encapsulation is not finished by adding getters and setters; move behavior inward when callers are still manipulating exposed data.
+- Avoid speculative abstractions: do not create wrappers, parameter objects, interfaces, superclasses, or hierarchy variants without a real concept or client.
+- Preserve public compatibility or provide a transition path when changing signatures, constructors, visibility, type hierarchy, or externally reachable APIs.
+- Before extraction or movement, identify inputs, outputs, mutated variables, callers, visibility, construction paths, and invariants.
+- Before condition consolidation or algorithm substitution, verify side effects, ordering, truth tables, edge cases, and performance-sensitive behavior.
+- Before data reorganization, decide identity, value/reference semantics, mutability, equality, lifecycle ownership, association direction, and synchronization.
+- Before generalization changes, prove shared behavior is real; preserve substitutability and avoid inheriting unused behavior.
+- Choose exceptions deliberately: a simple conditional, useful comment, intentional strategy separation, small extension point, or clear duplication may be better than a mechanical treatment.
+
+## Trigger rules
+
+- When a method needs comments, scrolling, or local-state reconstruction, try `Extract Method`; use `Replace Temp with Query`, `Introduce Parameter Object`, or `Preserve Whole Object` when locals block extraction.
+- When a class has multiple reasons to change, use `Extract Class`; use subclass/interface extraction only for stable variants or real client-facing subsets.
+- When primitives, arrays, magic numbers, or type codes carry meaning, model the concept only if the model adds naming, validation, behavior, or safer variation handling.
+- When a parameter list grows beyond local reasoning, replace derived parameters, preserve a whole object, or introduce a parameter object only for a real recurring concept.
+- When the same change requires edits across many files, move methods/fields or extract ownership so the knowledge is centralized.
+- When client code navigates object chains, hide the delegate or move behavior closer to the data; do not add pure forwarding.
+- When a class mostly forwards, remove the middle man unless it protects boundary policy or volatile structure.
+- When a method both queries and mutates, separate query from modifier unless atomic read-modify behavior is the public contract.
+- When branches repeat behavior, decompose, consolidate, or move duplicate fragments only after checking side effects and execution order.
+- When null checks dominate, introduce a null object only if absence can obey the same interface; keep absence explicit when it is an error.
+- When inheritance creates refused bequest or intimacy, push members down or replace inheritance with delegation.
+- When deleting dead or speculative code, verify external reachability and test-only access before removal.
+- When a library class is incomplete, use a foreign method for one narrow gap and a local extension only for substantial repeated gaps.
+- When cleanup keeps expanding, stop at the diagnosed smell and report the next smell separately.
+
+## Final checklist
+
+- Is this change clearly refactoring, feature work, or bug fixing?
+- Which smell was diagnosed, and what cost did it create?
+- Was the smallest suitable treatment used before riskier structure?
+- Did behavior stay preserved under relevant checks?
+- Did the named smell become materially better?
+- Did the change avoid speculative abstraction and mechanical pattern use?
+- Were public compatibility, state flow, and ownership checked?
+- Is any intentionally untreated smell documented rather than hidden?

package/templates/skills/refactoring-guru/refactoring-guru.nano.md

@@ -0,0 +1,41 @@
+# OBEY Refactoring.Guru
+
+## When to use
+
+Use as a compact always-on bias for safe, smell-driven refactoring during existing-code changes.
+
+## Primary bias to correct
+
+Refactoring is not cleanup for its own sake: diagnose one smell, treat it with the smallest behavior-preserving move, verify, then stop.
+
+## Decision rules
+
+- Separate structural refactoring from feature and bug behavior; if behavior changes, name and isolate it.
+- Diagnose the smell before choosing a technique: symptom, cost, smallest treatment, verification, and stop condition.
+- Prefer small named transformations over broad redesign.
+- Keep the program runnable and run relevant checks after risky movement, state-flow changes, public API changes, or algorithm replacement.
+- Stop when the diagnosed smell is reduced; do not chase new smells unless they block the current change.
+- Prefer extraction, naming, movement, inlining, and encapsulation before adding hierarchy, polymorphism, wrappers, or method objects.
+- Do not create abstractions from coincidental similarity, random parameter bags, simple conditionals, or speculative future needs.
+- Keep behavior with the data it changes unless separation intentionally supports interchangeable behavior.
+- Preserve public compatibility when changing signatures, constructors, visibility, hierarchy, or externally reachable code.
+- Delete or inline dispensable code only after checking public, generated, reflected, serialized, plugin-facing, framework, and test-only uses.
+
+## Trigger rules
+
+- When a method needs comments or local-state reconstruction, extract a named method after checking inputs, outputs, and mutated variables.
+- When a class changes for unrelated reasons, extract the responsibility; use subclass/interface only for stable variants or real client subsets.
+- When conditionals repeat by type or state, isolate the decision before using polymorphism; leave simple honest conditionals alone.
+- When duplicate code appears the third time, refactor unless the similarity is likely to diverge.
+- When parameter lists or primitive clumps carry one concept, model the concept; do not pass a huge object to hide dependency.
+- When clients navigate chains or internals, hide the delegate or move behavior; remove pass-through middle men that add no policy.
+- When null, error code, assertion, value/reference, or association changes are considered, verify semantics before changing structure.
+
+## Final checklist
+
+- Smell named?
+- Smallest treatment?
+- Behavior verified?
+- Stop condition reached?
+- No hidden feature change?
+- No speculative abstraction?

package/templates/skills/release-it/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: release-it
+description: Apply Michael T. Nygard-inspired production reliability rules when designing failure handling, timeouts, retries, circuit breakers, observability, or deployment behavior.
+license: MIT
+---
+
+# Release It! Skill
+
+Use this skill when a task involves production reliability, integration failure, timeouts, retries, circuit breakers, bulkheads, backpressure, observability, capacity, deployment, or operational readiness.
+
+Before making design or code decisions, read and apply [release-it.mini.md](release-it.mini.md). Use [release-it.md](release-it.md) only as a deeper reference when the mini rules are not enough for the current production-reliability tradeoff.

package/templates/skills/release-it/release-it.md

@@ -0,0 +1,382 @@
+# OBEY Release It! by Michael T. Nygard
+
+## Purpose
+
+This repository follows **Release It!** in the sense of Michael Nygard:
+design and implement software that survives production reality - failures, overload, latency, partial outages, bad data, hostile traffic, and operational mistakes.
+
+All code generation, edits, and reviews must optimize for:
+- production readiness
+- failure isolation
+- graceful degradation
+- back pressure and overload protection
+- timeouts and retries with discipline
+- observability
+- survivability over ideal-path elegance
+
+This file is a binding engineering policy: `MUST` is binding, `SHOULD` is a strong default, and `MUST NOT` is forbidden.
+
+---
+
+## Primary Directive
+
+Assume production will be messy.
+
+When uncertain, prefer the design that:
+1. fails visibly instead of hanging silently
+2. limits blast radius instead of maximizing coupling
+3. sheds load instead of collapsing
+4. preserves core service under stress
+5. makes diagnosis possible
+
+Do not design only for the happy path.
+
+---
+
+## Stability Mindset Rules
+
+1. Every dependency can be slow, unavailable, or wrong.
+2. Every queue can fill.
+3. Every cache can miss or stampede.
+4. Every timeout can cascade.
+5. Every caller can retry badly.
+6. Every “temporary” degraded state can become normal for hours.
+
+The code must assume these conditions, not merely tolerate them by accident.
+
+---
+
+## Production Readiness and Release Risk Rules
+
+1. Do not treat QA success or feature completion as proof of production readiness.
+2. Design deployment, operations, security, observability, and rollback as part of the system.
+3. Reduce release risk through small exposure steps, compatibility discipline, and reversible changes.
+4. Make version, build, configuration, dependency, and runtime state visible enough to diagnose a live instance.
+5. Validate critical configuration at startup and make configuration changes auditable and reversible.
+
+---
+
+## Dependency Protection Rules
+
+### Timeouts Are Mandatory
+1. Outbound calls must have explicit time limits.
+2. Timeouts must be chosen intentionally, not left to library defaults.
+3. Different dependencies may need different timeout budgets.
+4. Infinite waits are forbidden.
+
+### Retries Must Be Disciplined
+1. Retry only where repeated attempts are safe for the caller and provider.
+2. Bound retry count and total retry time.
+3. Add jitter/backoff to avoid synchronized retry storms.
+4. Do not retry validation errors or permanent failures.
+
+### Circuit Breakers and Fast Failure
+1. Protect unstable dependencies with fast-fail mechanisms when appropriate.
+2. When a dependency is clearly unhealthy, stop flooding it.
+3. Surface fallback or degraded mode explicitly.
+
+### Bulkheads and Isolation
+1. Separate resource pools for unrelated workloads where failure isolation matters.
+2. One failing integration must not consume all threads, connections, or worker capacity.
+3. Isolate slow or risky work from core request paths.
+
+Anti-patterns (MUST NOT):
+- nested retries at multiple layers
+- no timeout around remote calls
+- one shared pool for all outbound work
+- treating all failures as transient
+
+---
+
+## Load and Capacity Rules
+
+### Back Pressure
+1. The system must have a strategy for overload.
+2. Reject, defer, queue, or degrade intentionally.
+3. Unbounded acceptance of work is forbidden.
+
+### Queues
+1. Queues are buffers, not infinite storage.
+2. Monitor queue length, age, throughput, and failure rate.
+3. Know what happens when producers outpace consumers.
+4. Define dead-letter or poison-message handling explicitly.
+
+### Demand Control
+1. Protect scarce resources with limits.
+2. Prefer early rejection over total collapse.
+3. Reserve capacity for critical traffic when appropriate.
+
+### Load Shedding
+1. Define which work is optional under stress.
+2. Shed low-value work first.
+3. Preserve core functions whenever possible.
+
+### Additional Stability Patterns
+- USE Steady State design so routine operation does not require manual cleanup, unbounded growth, or periodic rescue.
+- USE Fail Fast when continuing would hold scarce resources or hide an unrecoverable dependency problem.
+- USE Let It Crash only when supervisors, isolation, and restart behavior make crashing safer than limping.
+- USE Handshaking between instances, load balancers, and dependencies so traffic reaches only ready components.
+- USE Decoupling Middleware when it reduces direct failure propagation; monitor the middleware as a dependency.
+- USE Governors to cap expensive behavior before it harms the rest of the system.
+
+Anti-patterns (MUST NOT):
+- unbounded queues
+- accepting work with no plan to finish it
+- letting best-effort tasks crowd out critical work
+
+---
+
+## Runtime State and Restart Safety Rules
+
+1. Make runtime state visible through logs, metrics, health endpoints, administrative interfaces, and diagnostic data.
+2. Validate external responses by status, content type, shape, and semantics before trusting them.
+3. Make deployment and operational automation idempotent or restartable where practical.
+4. Avoid partial deployment or migration steps without a rollback or roll-forward path.
+5. Validate operational assumptions at system boundaries.
+
+### Restartable Automation
+Required when:
+- deployments touch many machines
+- scripts may be rerun after partial failure
+- migrations run while old and new application versions coexist
+- operational procedures must be repeatable under release pressure
+
+Anti-patterns (MUST NOT):
+- one-shot deployment scripts that cannot safely resume
+- manual repair steps with no recorded state
+- side effects before a durable release checkpoint with no recovery plan
+
+---
+
+## Resource Management Rules
+
+1. Explicitly budget scarce resources:
+   - threads
+   - DB connections
+   - sockets
+   - file descriptors
+   - memory
+   - CPU-intensive worker slots
+2. Release resources deterministically.
+3. Do not hold locks or expensive connections across slow remote calls.
+4. Use streaming or pagination for large payloads where appropriate.
+5. Guard memory-heavy operations.
+
+Anti-patterns (MUST NOT):
+- one huge in-memory batch by default
+- blocking worker threads on slow I/O when a better model exists
+- connection pools sized by guess and then ignored
+
+---
+
+## Data Boundary Rules
+
+1. Treat all external input as untrusted.
+2. Validate syntax, shape, and business plausibility separately where needed.
+3. Avoid letting malformed data poison caches, queues, or downstream systems.
+4. Normalize and sanitize data once at the right boundary.
+5. Keep parsing errors and domain rule violations distinct.
+
+---
+
+## Operational Visibility Rules
+
+### Observability Is Part of the Design
+1. Emit meaningful logs at boundaries and failure points.
+2. Include identifiers needed for correlation and diagnosis.
+3. Measure latency, throughput, error rate, saturation, queue depth, and retry behavior.
+4. Expose health information that reflects real dependency state.
+
+### Logging
+1. Log structured context, not just prose.
+2. Log failures with the dependency, operation, and outcome.
+3. Do not log secrets.
+4. Avoid log spam loops under retry storms.
+
+### Metrics
+At minimum, capture:
+- request rate
+- success/failure counts
+- dependency latency
+- timeout counts
+- queue depth
+- retry counts
+- circuit-breaker state
+- saturation signals
+
+Anti-patterns (MUST NOT):
+- only logging stack traces without context
+- no metrics for slow dependencies
+- health checks that always return green despite broken downstreams
+
+---
+
+## Incidents, Capacity, and Runtime Control
+
+1. After incidents, identify the failure chain, missing defenses, detection gaps, and design changes.
+2. For performance or capacity incidents, inspect demand, saturation, latency distribution, queue age, dependency behavior, and traffic concentration.
+3. Provide administrative interfaces or operational controls only with authorization, auditability, safe defaults, and clear stop mechanisms.
+4. Keep process code, scripts, and automation observable enough that operators can see what changed and why.
+5. Treat control planes and delivery tooling as production systems when they can affect production.
+
+---
+
+## Deployment and Startup Rules
+
+1. Startup must fail fast on missing critical configuration.
+2. Health checks must reflect actual ability to serve.
+3. Health checks must not mask deadlocks or stuck subsystems.
+4. Avoid expensive or destructive startup work in request-serving processes when possible.
+5. Migrations and one-time jobs must be deliberate, observable, and recoverable.
+
+---
+
+## Interconnect, Routing, Security, and Chaos Rules
+
+1. Keep DNS, service discovery, routing, and load balancing health-aware and current.
+2. Design interconnects to avoid concentrated demand, hidden single points of failure, and uncontrolled fan-out.
+3. Treat hostile traffic, abusive users, and malformed requests as production load cases.
+4. Include security in production readiness: secrets, permissions, administrative access, dependency trust, and input handling.
+5. Use production tests, launch checks, capacity tests, and game days to validate operational assumptions.
+6. Run chaos or disaster simulations only with a hypothesis, limited blast radius, observability, stop condition, and recovery path.
+7. Feed findings from chaos and disaster work back into design, operations, and tests.
+
+---
+
+## API and Contract Rules
+
+1. Make failure modes explicit in API contracts where they matter.
+2. Return clear retryable vs non-retryable outcomes.
+3. Prefer coarse-grained, resilient interactions over fragile chattiness.
+4. Use versioning and compatibility discipline for long-lived contracts.
+5. Document retry, timeout, version, and compatibility expectations clearly.
+
+---
+
+## Cache Rules
+
+1. Cache is an optimization, not a source of truth unless explicitly designed that way.
+2. Plan for cache miss storms, stale data, and cache outages.
+3. Avoid dogpiles with request coalescing or appropriate expiry strategies.
+4. Define what happens when the cache is unavailable.
+
+Anti-patterns (MUST NOT):
+- assuming cache hit rate is always high
+- rebuilding the whole cache synchronously on miss
+- hiding correctness assumptions inside cache behavior
+
+---
+
+## Scheduled and Background Work Rules
+
+1. Spread scheduled work so demand does not concentrate at the same instant.
+2. Do not set all periodic jobs to run on the same obvious clock boundary.
+3. Failure and retry policy must be explicit.
+4. Retried work must use increasing backoff where synchronized retry pulses would create load.
+5. Long-running work needs bounded waits, progress visibility, timeout, and cancellation strategy.
+
+---
+
+## Review Rules
+
+When reviewing code, actively look for:
+- outbound calls with no timeout
+- retries without backoff, limits, or a clear failure policy
+- no backoff or jitter
+- unbounded queues or buffers
+- shared resource pools with no isolation
+- no overload strategy
+- no failure visibility
+- health checks that say nothing meaningful
+- scheduled jobs concentrating load at the same instant
+- caches treated as always available
+
+---
+
+## Forbidden Patterns
+
+### Happy-Path Design
+- code that assumes dependencies are fast and correct
+- no timeout, no retry discipline, no degradation path
+
+### Retry Storms
+- retries at every layer
+- retries with no increasing backoff or limits
+- synchronized retries without jitter
+
+### Collapse by Queue
+- unbounded queue growth
+- taking work forever even while falling behind
+- no poison-message handling
+
+### Silent Failure
+- swallowed exceptions
+- generic “something went wrong” without context
+- missing correlation information
+
+### Blast-Radius Amplification
+- one dependency outage consuming all worker threads or DB connections
+- shared pools for all risk classes with no isolation
+
+---
+
+## Code Generation Rules
+
+When generating code, default to:
+1. explicit timeout for every remote dependency
+2. explicit retry policy only where safe
+3. restartable deployment and operational automation where practical
+4. bounded resources and queues
+5. clear failure paths
+6. useful diagnostic hooks
+7. graceful degradation or fast failure where appropriate
+
+Avoid by default:
+- infinite waits
+- implicit library retries
+- unbounded buffering
+- best-effort logging with no metrics
+- fragile startup sequences
+- one-shot release automation with no restart path
+
+---
+
+## Testing Rules
+
+1. Test timeout behavior.
+2. Test retry, backoff, and failure boundaries.
+3. Test degraded dependency scenarios.
+4. Test overload and queue saturation behavior where practical.
+5. Test restartable deployment or operational automation where practical.
+6. Test startup and health-check failure modes.
+
+---
+
+## Review Checklist
+
+Before finalizing any change, verify:
+- Does every remote call have an explicit timeout?
+- Are retries bounded and safe?
+- Are deployment and operational scripts restartable or idempotent where practical?
+- Is there an overload strategy?
+- Are queues and resource pools bounded?
+- Is failure isolated from unrelated work?
+- Are there enough diagnostics to investigate issues?
+- Are health signals meaningful?
+- Are scheduled and background workloads bounded and paced safely?
+- Did we preserve the core service under likely failure scenarios?
+
+If any answer is no, revise before shipping.
+
+---
+
+## Final Instruction
+
+When uncertain, prefer the design that:
+1. survives partial failure
+2. limits blast radius
+3. fails fast or degrades gracefully
+4. exposes enough information to operate
+5. prevents overload from becoming collapse
+
+Production reality outranks happy-path elegance.

package/templates/skills/release-it/release-it.mini.md

@@ -0,0 +1,48 @@
+# OBEY Release It! by Michael T. Nygard
+
+## When to use
+
+Use for services, APIs, jobs, queues, deployment paths, control tooling, and critical flows that must survive production failures, overload, latency, bad data, hostile traffic, and operational mistakes.
+
+## Primary bias to correct
+
+A passing happy path is not production readiness. Design the failure semantics, demand limits, isolation, recovery path, and diagnosis surface before production defines them for you.
+
+## Decision rules
+
+- Assume every dependency, queue, cache, timeout, caller retry, and degraded state can fail in slow, partial, or prolonged ways; code must assume production mess instead of merely tolerating it by accident.
+- Prefer designs that fail visibly, limit blast radius, shed load, preserve core service, and make diagnosis possible over designs that maximize coupling or ideal-path elegance.
+- Treat deployment, operations, security, observability, rollback, build and runtime state, dependency state, and configuration validation as part of the system, not after-release chores.
+- Put explicit, intentional time limits on outbound calls and waits. Do not rely on library defaults or allow infinite waits where finite response matters.
+- Retry only when the operation is safe for the caller and provider; bound count and total time, use backoff or jitter, and do not retry validation errors or permanent failures.
+- Isolate dependency and workload failures with circuit breakers, fast failure, bulkheads, separate resource pools, and slow-work isolation so one outage cannot consume all threads, connections, or workers.
+- Design overload behavior explicitly with back pressure, finite queues, demand limits, capacity reserved for critical traffic, and load shedding of lower-value work before core functions collapse.
+- Use stability patterns by failure mode: steady state for routine cleanup and bounded growth, fail fast when continuing hides unrecoverable trouble or holds scarce resources, let-it-crash only with supervision and isolation, handshaking for readiness, decoupling middleware with monitoring, and governors for expensive behavior.
+- Make runtime state, external responses, automation progress, migrations, operational assumptions, and boundary data visible and validated before trusted; keep rollback or roll-forward paths for partial operational changes.
+- Budget scarce resources explicitly, release them deterministically, avoid holding locks or expensive connections across slow remote calls, and stream or paginate large payloads instead of defaulting to huge in-memory batches.
+- Treat external input and external responses as untrusted: validate syntax, shape, business plausibility, status, content type, and semantics; prevent malformed data from poisoning caches, queues, or downstream systems.
+- Build observability into boundaries and failure points with structured context, correlation identifiers, latency, throughput, error, saturation, queue, retry, breaker, dependency, version, configuration, health, and runtime signals while avoiding secrets and retry-storm log spam.
+- Make startup, health checks, migrations, one-time jobs, administrative controls, process code, and delivery tooling fail safely, auditable, authorized, observable, stoppable, and recoverable.
+- Make interconnects, routing, API contracts, caches, scheduled work, and background work production-aware: avoid concentrated demand, hidden single points of failure, uncontrolled fan-out, fragile chattiness, cache dogpiles, stale data surprises, and synchronized job retries.
+- Include security and hostile traffic in production readiness, and use production tests, launch checks, capacity tests, game days, chaos, or disaster simulations only with limited blast radius, observability, stop conditions, and feedback into design.
+
+## Trigger rules
+
+- When adding an outbound call, dependency operation, resource checkout, queue consume, or thread wait, define timeout, retry eligibility, retry bounds, fallback or degraded mode, validation, and caller-survival behavior.
+- When adding a queue, buffer, resource pool, cache, log stream, background job, scheduled job, or collection-returning API, define capacity, full behavior, cleanup, miss/stampede/staleness behavior, pacing, pagination or streaming, and saturation monitoring.
+- When a change touches deployment, configuration, startup, migrations, one-time jobs, scripts, or operational automation, make it idempotent or restartable where practical and give it durable state, auditability, verification, and rollback or roll-forward.
+- When adding health checks, load balancing, service discovery, routing, or inter-service handshakes, ensure traffic reaches only ready components and health signals reflect real ability to serve.
+- When designing API or integration contracts, make material failure modes explicit, distinguish retryable from non-retryable outcomes, prefer coarse-grained resilient interactions, and document timeout, retry, version, and compatibility expectations.
+- When reviewing an incident, performance failure, or capacity issue, identify the failure chain, missing defenses, detection gaps, demand, saturation, latency distribution, queue age, dependency behavior, traffic concentration, and design changes.
+- When adding administrative controls, control planes, delivery tooling, hostile-traffic handling, or chaos/disaster work, require authorization, auditability, safe defaults, clear stop mechanisms, bounded blast radius, and recovery paths.
+
+## Final checklist
+
+- Explicit timeouts and no infinite waits?
+- Retries safe, bounded, backed off or jittered, and not duplicated across layers?
+- Queues, buffers, pools, caches, logs, payloads, jobs, and result sets bounded?
+- Failure isolated with breakers, bulkheads, fast failure, degradation, or load shedding?
+- External input and dependency responses validated before they affect state, caches, queues, or downstream systems?
+- Diagnostics cover logs, metrics, health, correlation, runtime, version, configuration, dependencies, saturation, queue depth, retries, and breaker state?
+- Startup, deployment, migration, automation, and operational controls restartable, observable, authorized, auditable, and recoverable where practical?
+- Interconnects, APIs, caches, scheduled work, security, and chaos tests have explicit production failure behavior?

package/templates/skills/release-it/release-it.nano.md

@@ -0,0 +1,38 @@
+# OBEY Release It! by Michael T. Nygard
+
+## When to use
+
+Use when operational survivability matters and context is tight.
+
+## Primary bias to correct
+
+Production failure semantics, overload behavior, isolation, recovery, and diagnosis must be designed, not discovered after release.
+
+## Decision rules
+
+- Assume dependencies, queues, caches, callers, timeouts, bad data, and degraded states fail slowly, partially, and for longer than expected.
+- Prefer visible failure, blast-radius limits, load shedding, preserved core service, and diagnosis over happy-path elegance.
+- Bound outbound calls, waits, retries, queues, pools, caches, logs, result sets, payloads, and scarce resources where finite response matters.
+- Retry only when safe, bounded, and backed off or jittered; never retry permanent failures or stack retries into storms.
+- Isolate failure with circuit breakers, bulkheads, fast failure, separate pools, degraded modes, and deterministic cleanup.
+- Treat deployment, startup, automation, health, observability, configuration, rollback, security, and runtime state as production design.
+- Validate external input and responses before trusting them; prevent bad data from poisoning caches, queues, state, or downstream systems.
+- Make APIs, interconnects, caches, jobs, and operational controls explicit about failure, capacity, recovery, authorization, and stop behavior.
+
+## Trigger rules
+
+- When adding a remote call, wait, queue, pool, cache, job, retry, or large result path, define bounds, failure behavior, validation, and saturation signals.
+- When changing startup, deployment, migration, configuration, script, or control tooling, make recovery, auditability, observability, and restartability explicit.
+- When traffic can concentrate through routing, scheduling, retries, fan-out, or hostile use, add back pressure, shedding, pacing, or isolation before expensive work.
+- When using production tests, game days, chaos, or disaster drills, require hypothesis, blast-radius limit, observability, stop condition, and recovery path.
+
+## Final checklist
+
+- Bounded?
+- Retry disciplined?
+- Failure isolated?
+- Load controlled?
+- Data validated?
+- Observable?
+- Recoverable?
+- Stoppable?