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.

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

Supports all global flags.

---

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

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

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 — search the product documentation first; cite what it said in --expected.