> 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`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://developer.celigo.com/cli/commands/feedback.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.