Nelson
Classify agent tasks by blast radius and apply the right review, rollback, and go/no-go controls before execution.
Overview
Nelson is a journey-wide agent skill that classifies each task into Patrol–Trafalgar risk stations and applies the minimum required validation, review, and rollout controls before execution.
Install
npx skills add https://github.com/harrymunro/nelson --skill nelsonWhat is this skill?
- Four risk stations (Patrol through Trafalgar) with escalating required controls
- Risk classification decision tree plus failure-mode checklist
- Independent and adversarial review requirements at Caution and Action tiers
- Admiral go/no-go checkpoint before merge or release at Action tier
- Marine-themed deployment guidance for staged and guarded rollouts
- Four risk stations from Patrol (0) through Trafalgar (3)
- Dedicated failure-mode checklist for higher tiers
Adoption & trust: 1.2k installs on skills.sh; 379 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You delegate work to coding agents without a shared rule for when a change needs review, rollback planning, or a release gate.
Who is it for?
Solo builders running multi-step agent workflows on SaaS, CLIs, or internal tools where some tasks are trivial and others are security- or revenue-critical.
Skip if: Pure local prototyping with no users, data, or deploy path where you already have an approved change-management process you will not replace.
When should I use this skill?
Before the agent executes any non-trivial task where blast radius, rollback, or compliance is unclear.
What do I get? / Deliverables
Every task gets a documented risk tier, required controls, and rollback or go/no-go steps matched to blast radius before the agent proceeds.
- Risk station assignment with required controls list
- Rollback or staged rollout note tied to the task
- Review or go/no-go checkpoint when tier requires it
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Rate a pricing-page experiment as Caution so a second agent reviews copy before it goes live.
Mark a migrations task Action-tier for data-integrity controls and explicit rollback.
Require admiral go/no-go and guarded launch for a customer-facing release.
Treat irreversible infra changes as Trafalgar with maximum checklist rigor.
How it compares
Use as a structured risk gate before ad-hoc “just ship it” agent execution—not as a substitute for automated SAST or dependency scanning tools.
Common Questions / FAQ
Who is nelson for?
Indie and solo builders who use Claude Code, Cursor, or similar agents and need proportionate controls when tasks range from doc tweaks to compliance-sensitive releases.
When should I use nelson?
Before any agent-executed task across Idea scoping, Validate prototypes, Build features, Ship reviews, Launch rollouts, Grow experiments, or Operate hotfixes—especially when rollback is hard or data and security are in play.
Is nelson safe to install?
It is procedural guidance only; review the Security Audits panel on this skill’s catalog page and treat Nelson as policy you enforce in your own repo, not as audited executable code.
SKILL.md
READMESKILL.md - Nelson
# Action Stations Classify each task before execution. Apply the minimum required controls. ## Contents - [Station 0: Patrol](#station-0-patrol) - [Station 1: Caution](#station-1-caution) - [Station 2: Action](#station-2-action) - [Station 3: Trafalgar](#station-3-trafalgar) - [Risk Classification Decision Tree](#risk-classification-decision-tree) - [Failure-Mode Checklist](#failure-mode-checklist) - [Marine Deployments](#marine-deployments) ## Station 0: Patrol Criteria: - Low blast radius. - Easy rollback. - No sensitive data, security, or compliance impact. Required controls: - Basic validation evidence. - Record rollback step. ## Station 1: Caution Criteria: - User-visible behavior changes. - Moderate reliability or cost impact. - Partial coupling to other tasks. Required controls: - Independent review by non-author agent. - Validation evidence plus negative test or failure case. - Explicit rollback note in task output. ## Station 2: Action Criteria: - Security, privacy, compliance, or data integrity implications. - High customer or financial blast radius. - Difficult rollback or uncertain side effects. Required controls: - Dedicated red-cell navigator participation. - Adversarial review with failure-mode checklist. - Pre-merge or pre-release go/no-go checkpoint by admiral. - Staged rollout or guarded launch when possible. ## Station 3: Trafalgar Criteria: - Irreversible actions. - Regulated or safety-sensitive effects. - Mission failure likely causes severe incident. Required controls: - Keep scope minimal and isolate risky changes. - Require explicit human confirmation before irreversible action. - Two-step verification and documented contingency plan. - If controls are unavailable, do not execute. ## Risk Classification Decision Tree Walk through these questions in order. Stop at the first "yes" — that determines the Station tier. **1. Is the action irreversible or regulated?** - Could it destroy data with no backup? → **Station 3** - Does it touch regulated, safety-critical, or compliance-governed systems? → **Station 3** - Could failure cause a severe incident that cannot be undone? → **Station 3** - If none apply, proceed to question 2. _Examples: Dropping a production database table (Station 3), deleting a cloud storage bucket without snapshots (Station 3), modifying HIPAA-regulated data pipelines (Station 3)._ **2. Does it affect security, privacy, or data integrity?** - Does it modify authentication, authorization, or encryption? → **Station 2** - Could it expose user data or PII? → **Station 2** - Does it have high financial or customer blast radius? → **Station 2** - If none apply, proceed to question 3. _Examples: Changing auth middleware or token validation (Station 2), updating payment processing logic (Station 2), modifying API rate-limiting or access controls (Station 2)._ **3. Is the change visible to users or coupled to other work?** - Does it alter user-facing behavior, UI, or API responses? → **Station 1** - Could it affect reliability, performance, or cost in a noticeable way? → **Station 1** - Is it tightly coupled to other in-flight tasks? → **Station 1** - If none apply, proceed to question 4. _Examples: Changing an API response format (Station 1), updating a shared configuration file (Station 1), refactoring a function used by multiple modules (Station 1)._ **4. None of the above?** → **Station 0** - Low blast radius, easy rollback, no sensitive impact. _Examples: Renaming an internal variable (Station 0), fixing a typo in a code comment (Station 0), adding a unit test for existing logic (Station 0)._ ## Failure-Mode Checklist Run this checklist for Station 1+ tasks. - What could fail in production? - How would we detect it quickly? - What is the fastest safe rollback? - What dependency could invalidate this plan? - What assumption is least certain? ## Marine Deployments Marine deployments inherit the parent ship's sta