---
name: command-preflight
description: Explain a terminal command's intended behavior, risks, and unresolved context before a non-coder runs it. Use before running commands supplied by another person or AI tool.
license: All-Rights-Reserved
metadata:
  author: Zain Haseeb
  version: 1.0.1
  changed: "2026-09-08"
  category: ai-safety
  tags: [terminal, safety, non-coders, preflight]
---

# Command Preflight

Explain a terminal command in plain language before it runs, so a non-coder can decide whether to run it rather than trusting it blindly.

## Critical behavior

1. Explain, do not run. This skill produces an explanation and a verdict, never an execution.
2. State plainly whether the command reads, writes, deletes, installs, changes permissions, or sends data elsewhere.
3. If the command is destructive or hard to reverse, say so in the first sentence, not buried later.
4. State the undo path if one exists, and say clearly if none exists.
5. Never suggest adding a force flag, disabling a safety prompt, or skipping a confirmation to make a command run more smoothly.
6. If behavior depends on flags, versions, or context not supplied, say so and ask rather than guessing.

## When to use

Use this before running a command from a forum post, a colleague's message, or an AI assistant's suggestion, especially in a system the person depends on for real work. It is built for people who are not programmers and cannot read the command themselves.

Do not use it as a substitute for a real security review on production systems; it is a plain-language preflight check, not an audit.

## Run the preflight

### 1. Break down the command

Split the command into its parts: the program being run, its flags, its arguments, and any piping or redirection. Explain each part in plain language.

Before an affirmative verdict, establish the relevant shell and working directory, executable or script provenance, aliases/functions, expanded operands and symlink targets, and any remote payload involved. Request missing evidence without executing the command to obtain it. Mark any unresolved behavior unknown; command text alone does not prove the eventual effect.

### 2. Classify its behavior

State which of these apply: reads data only, writes or changes data, deletes something, installs software, changes permissions, sends data over the network, or requires elevated privileges.

### 3. Surface the risk first

If the command is destructive, irreversible, or affects more than the immediate folder, lead with that fact before explaining the rest.

### 4. State the undo path

Describe what recovering from this command would look like if it goes wrong, or state plainly that no undo path exists.

### 5. Give a verdict

Conclude with one of three verdicts: no blocking issue identified in the supplied command and verified context; unresolved context—do not run yet; or a blocking risk requiring a named change or expert review. List the evidence and assumptions behind the verdict. This is not safety certification or execution approval; a proposed modification needs its own preflight.

## Output format

Return, in order: a one-line risk flag if applicable, a plain-language breakdown of each part, the classification of what the command does, the undo path or its absence, and the final verdict with reasoning.

## Example

A user pastes a command an AI assistant suggested to "clean up old files." The preflight identifies it as a recursive delete with no confirmation prompt and no trash or backup step, flags it as irreversible in the first sentence, and returns a verdict of do not run without a named expert's review, along with a safer alternative that moves files to a temporary folder first.

## Troubleshooting

- If the command's effect depends on the current directory, ask what directory it would run in before giving a verdict.
- If the command references a file or path the user has not identified, ask before assuming its contents or importance.
- If multiple commands are chained together, preflight each one individually before evaluating the chain as a whole.

## What not to do

- Do not run the command as part of this process.
- Do not soften a destructive verdict to avoid seeming alarmist.
- Do not suggest workarounds that bypass a safety prompt or confirmation step.
- Do not guess at undocumented behavior; say what is unknown.