Documentation Creator

Required Standards

• Never leave a shell command unexplained.
• If a command has flags, explain every flag that appears.
• If a command has no flags, still explain the command itself and important arguments.
• Prefer short paragraphs and short bullets over dense prose.
• Call out whether a command runs on the local machine, remote server, container, or another environment.
• Keep steps in execution order.
• Use Markdown headings that make the document skimmable.
• Keep placeholders consistent across the document.
• If the doc offers multiple paths, make the branching explicit early and keep the steps for each path grouped together.
• If you introduce a "why this option" note, place it next to the relevant command, flag, or decision point.

Recommended Structure

Use this structure by default:

# Title

## What This Does

## Replace These Values

## Prerequisites

## Command Summary

## Steps

### Step 1. ...

Command:
```bash
...
```

What this command does:
- ...

Flag breakdown:
- `-x`: ...
- `--long-option`: ...

What to expect:
- ...

Add these sections when useful:

• ## Faster Option for an alternate path
• ## Command Summary for a quick overview of the full workflow
• ## Troubleshooting for common failures
• ## Cleanup for undo or removal steps

Writing Rules

• Prefer one command per code block when that makes explanations clearer.
• If multiple commands must stay together, explain each line separately.
• Avoid unexplained jargon.
• Tell the reader what success looks like after important steps.
• Keep command examples copy-pasteable.
• Preserve security-sensitive warnings such as permissions, secrets, and cleanup steps.
• If an alternate path makes earlier or later steps unnecessary, say so in one sentence with explicit step names or commands.

Review Checklist

• Every command is explained
• Every flag is explained
• Steps are easy to follow in order
• Local vs remote context is explicit
• Expected results are described
• Cleanup or rollback steps are included when relevant