> ## Documentation Index
> Fetch the complete documentation index at: https://filepacks.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> The four public CLI commands, when to use each one, and how the CLI maps to @filepacks/core.

The current public CLI is intentionally narrow.

Supported commands:

```bash theme={null}
filepacks pack <input> --output <file>
filepacks inspect <file>
filepacks verify <file>
filepacks compare <baseline> <candidate>
```

Unsupported commands are not part of the public OSS surface, including `show`, `import`, `registry`, `list`, `tag`, `baseline`, `unpack`, and `config`.

## Choose the right command

| If you want to...                   | Run                                        |
| ----------------------------------- | ------------------------------------------ |
| package a directory as one artifact | `filepacks pack <input> --output <file>`   |
| read the artifact summary           | `filepacks inspect <file>`                 |
| confirm the artifact is intact      | `filepacks verify <file>`                  |
| see whether packaged files changed  | `filepacks compare <baseline> <candidate>` |

## Global help

```bash theme={null}
filepacks --help
```

For a clean-shell trial, use:

```bash theme={null}
npx filepacks --help
```

Command-specific help is also available:

```bash theme={null}
filepacks pack --help
filepacks inspect --help
filepacks verify --help
filepacks compare --help
```

## Command behavior summary

| Command   | What it does                                            | Exit behavior                                                     |
| --------- | ------------------------------------------------------- | ----------------------------------------------------------------- |
| `pack`    | Create a deterministic `.fpk` artifact from a directory | `0` on success, `1` on usage or file errors                       |
| `inspect` | Read artifact metadata from a `.fpk` file               | `0` on success, `1` on usage or file errors                       |
| `verify`  | Check payload files against the manifest                | `0` when valid, `1` when invalid or on usage/file errors          |
| `compare` | Structurally compare two artifacts                      | `0` when identical, `20` when different, `1` on usage/file errors |

## Output style

The CLI uses line-oriented plain text output rather than JSON. That makes it easy to read in a terminal and easy to consume from shell scripts.

Examples:

* `pack` prints `input=`, `output=`, `name=`, `digest=`, `files=`, `bytes=`
* `inspect` prints `path=`, `name=`, `version=`, `digest=`, `files=`, `bytes=`
* `verify` prints `ok=true` or `ok=false`
* `compare` prints `ok=`, summary counts, and per-file change lines

## Recommended flow

Most users start here:

1. `pack` the output directory.
2. `inspect` the resulting artifact.
3. `verify` it before trusting or sharing it.
4. `compare` it against a baseline when you care about repeated-run drift.

Use [CLI workflows](/cli/workflows) for end-to-end patterns.

## Core library mapping

The CLI is a conservative wrapper around `@filepacks/core`:

* CLI `pack` -> `pack()`
* CLI `inspect` -> `inspect()`
* CLI `verify` -> `verify()`
* CLI `compare` -> `compare()`

Use the core package when you need structured results in code.