> For the complete documentation index, see [llms.txt](https://developer.celigo.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.celigo.com/cli/commands/feedback.md).

# feedback

Send structured product feedback about the Celigo CLI or platform straight from the terminal — the same intake the Platform MCP server uses. The CLI attaches `source` (`cli`), its own version, and runtime context (os, node, mode) automatically; it never attaches command arguments or payload data.

Feedback is a one-way channel by design: `submit` is the group's only verb. Reviewing and triaging submissions happens on engineering's side, not in the CLI — there is no `list`, `get`, `update`, or `delete`. To revise a report, submit a fresh one (identical resubmissions dedupe server-side).

`submit` works in **every mode, including `read`** — reporting a failure must never require a mode switch. When a command fails from a server-side error or an internal CLI bug (never an input mistake), the CLI prints a ready-to-run `feedback submit` line with the failed command prefilled.

**Note**: the backing endpoint (`POST /v1/feedbacks`) is the platform's feedback intake and is not published in the [API reference](https://developer.celigo.com/api/api-reference).

```
celigo feedback submit [message...] --category <category> [flags]
```

Supports all [global flags](/cli/getting-started/global-flags.md).

***

## Subcommands

| Subcommand            | Purpose                     |
| --------------------- | --------------------------- |
| `submit [message...]` | Submit one feedback report. |

***

## `celigo feedback submit [message...]`

Submit one report. The positional message is free text (words are joined, quotes optional), or read it from a file with `-f, --file`. At least one of the message, `--expected`, or `--actual` is required.

Every report follows one canonical shape — `celigo feedback submit --help` carries a worked example modeled on a real incident report:

* `--command` — the exact CLI command that prompted it (flags fine; ids unnecessary).
* `--expected` — what the docs/spec say should happen, in one sentence.
* `--actual` — the verbatim outcome: status code + error text + the observed wrong state.
* message — the report core: what breaks, the reproduction count, what was isolated.
* `--severity` — `high` = data loss or a production halt; `medium` = a blocked workflow with a workaround; `low` = friction.

**Signature**

```bash
celigo feedback submit [message...] --category <category> [--severity <severity>] \
  [--command <cmd>] [--expected <text>] [--actual <text>] [-f <path>]
```

**Arguments**

| Argument       | Type              | Required | Description                                                                                                                        |
| -------------- | ----------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `[message...]` | string (variadic) | No\*     | Free-text report body (words are joined, quotes optional). \*At least one of the message, `--expected`, or `--actual` is required. |

**Flags**

| Flag                    | Type                    | Default | Description                                                                                                                                                                                                                                                          |
| ----------------------- | ----------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--category <category>` | string                  | —       | **Required.** What kind of feedback: `bug`, `confusing`, `docs`, `feature`, `praise` — or any label that fits.                                                                                                                                                       |
| `--severity <severity>` | `high \| medium \| low` | —       | How much it hurt: `high` = data loss or a production halt; `medium` = a blocked workflow with a workaround; `low` = friction.                                                                                                                                        |
| `--command <command>`   | string                  | —       | The CLI command that prompted this, e.g. `"celigo flows run"` (flags fine; ids unnecessary). Budget \~300 characters.                                                                                                                                                |
| `--expected <text>`     | string                  | —       | What the docs/spec say should happen — one sentence.                                                                                                                                                                                                                 |
| `--actual <text>`       | string                  | —       | The verbatim outcome: status code + error text + the observed wrong state.                                                                                                                                                                                           |
| `-f, --file <path>`     | string                  | —       | Read the message from a file — plain text straight into the message, **not** a JSON body. Markdown is welcome (reports are triaged GitHub-issue-style). Mutually exclusive with the positional message; over the \~4,000-character budget it fails fast client-side. |

**Example**

```bash
celigo feedback submit --category bug --severity high \
  --command "celigo flows update -f flow.json" \
  --expected "PUT persists responseMapping in the documented shape" \
  --actual "200 OK but a follow-up get shows fields:[null], lists:[{fields:[]}] — step mappings erased" \
  "Sending the documented wrapper shape corrupts every step's responseMapping. Reproduced 3x including on a disposable flow; omitting the key resets clean. No shape both validates and persists."
```

Note what the example does *not* carry: no ids, no field values, no account data.

**Corresponds to**: `POST /v1/feedbacks` (not published in the API reference).

***

## Gotchas

* **Privacy is a hard rule, not a suggestion.** Never include tokens or credentials, record payloads or field values, or customer names, emails, and business data. Describe shapes and counts, not contents — "a flow with 9 steps' mappings", not the mappings. Server-side scrubbing exists; do not rely on it.
* **Field budgets.** The message, `--expected`, and `--actual` hold \~4,000 characters each (an 8 KB byte cap); `--command` \~300. When a draft runs over, compress the prose — never truncate mid-evidence — and move detail into `--expected`/`--actual`.
* **Identical submissions dedupe.** The same command, category, expected, and actual within \~10 minutes are collapsed server-side — the response echoes the original id with `deduped: true`. That also means a resubmit-to-revise produces a fresh report only once the window passes or the content differs.
* **`--file` reads plain text, not JSON.** Unlike `create`/`update` elsewhere in the CLI, the file's contents go straight into the message. It is mutually exclusive with the positional message.
* **It works in read mode — deliberately.** The `POST` is exempt from the read-mode gate so a failure can be reported from any profile. It is the only such exemption; every other write stays gated.
* **The CLI suggests it after real failures only.** Server-side errors (HTTP 5xx, exhausted retries) and internal CLI bugs print a prefilled `feedback submit` tip. Input mistakes — bad flags, validation errors, 4xx responses — never trigger it.

## Related

* [docs](/cli/commands/docs.md) — search the product documentation first; cite what it said in `--expected`.