/outsystems-feedback

description: Send feedback about your OutSystems agent experience
argument-hint: [--dry-run] [--quiet] [<your feedback>] (leave empty for guided form)

The user typed `/outsystems-feedback $ARGUMENTS`. They want to report something about the OutSystems agent experience (a bug, a thumbs-up / thumbs-down, a comment about a tool that misbehaved, etc.).

Optional flags (direct mode only)

Parse and strip leading flags from `$ARGUMENTS` before deciding the mode:

• `--dry-run` -- Show the exact feedback tool call that WOULD be made (name, value, rationale, agent_context, mentor_session_id, mentor_turn_id, experiment_id) as a code block, but do NOT invoke the tool. Reply with the preview and ask the user to confirm ("send it? [y / n]") before firing. On "n" or silence, do not send and say "OK, discarded."
• `--quiet` -- Fire the feedback call as normal but skip the confirmation narration on success. On `status: "accepted"`, reply with a single-word acknowledgment ("sent.") instead of the full "Thanks..." block. Errors and `not_configured` still surface with their normal text. Useful for CI-driven or scripted callers.

Both flags may be combined (`--dry-run --quiet` shows the preview without narration decoration). Flags are only recognized in direct mode; the guided-form flow ignores them.

Two modes

Decide the mode from `$ARGUMENTS` (after stripping leading flags above):

• **Direct mode** -- `$ARGUMENTS` is non-empty and contains at least one non-whitespace character. The message body is whatever is left. Skip the guided-form steps and go straight to redaction + tool call.
• **Guided-form mode** -- `$ARGUMENTS` is empty or whitespace-only. Do NOT reply with an error. Drive the guided form below so the user picks values instead of typing them. This is the closest thing plugins have to Claude Code's built-in `/feedback` modal.

Guided-form mode

Run these steps IN ORDER. Do not batch them into one `AskUserQuestion` call -- the two picker steps need to happen in sequence so the user's category choice is visible before they type the message.

**Step 1 -- category picker.** Call `AskUserQuestion` exactly once:

• `question`: "What kind of feedback would you like to send?"
• `header`: "Category"
• `multiSelect`: false
• `options` (in this order, each with a concrete example to help disambiguate):
• `label`: "Thumbs up" -- `description`: "Something worked well or is delightful. Example: 'the mentor turn was fast and the OML edit was exactly what I wanted'."
• `label`: "Thumbs down" -- `description`: "Something felt off but is not a full bug. Example: 'the deploy took 3 minutes, felt slow' or 'the output was correct but not what I hoped for'."
• `label`: "Bug report" -- `description`: "Something is broken and should not be. Example: 'the publish call returned OS-BEW-1234 and never recovered'."
• `label`: "Feature request" -- `description`: "You would like the OutSystems agent to do something it does not currently do. Example: 'I want an env-diff tool that compares two environments'."

Map the user's pick to the `value` argument of the feedback call:

• "Thumbs up" -> `"thumbs-up"`
• "Thumbs down" -> `"thumbs-down"`
• "Bug report" -> `"bug-report"`
• "Feature request" -> `"feature-request"`
• Any custom / "Other" free-text answer the user typed instead of picking -> default `value` to `"bug-report"` and include the user's free-text at the top of the message body.

Do NOT offer numeric ratings ("4", "5") or booleans ("true", "false") in the picker. The server accepts them for schema flexibility, but users find rating scales less intuitive than named tags; a picker of four named categoricals is the whole surface.

**Step 2 -- free-text message.** After the pick lands, reply to the user in a single conversational turn:

> "Got it, <category>. What is the message you would like to include? (Skip this if the category above already says enough -- just reply 'none' or 'skip'.)"

Wait for the user's next message. Treat that message as the raw feedback body (subject to the redaction step below). If the user replies "none" / "skip" / an empty line, use an empty rationale.

**Step 2b -- expected-vs-actual (bug-report only).** If the category is "Bug report" (picked at Step 1, or pre-filled by the skill doc's bounded-exception entry point that skips Step 1), ask ONE follow-up question after Step 2:

> "Quick tip: a good bug report has three parts -- what you did, what happened, what you expected. To help the team reproduce: what did you expect to happen instead? (Optional -- reply 'skip' if the message above already covers it.)"

Wait for the user's reply. If they answered anything other than "skip" / empty, combine the two parts into the final `rationale` as:

> Expected: <the Step 2b reply> > > Actual: <the Step 2 message>

If they skipped, use the Step 2 message alone. This step fires ONLY for bug reports; thumbs-up / thumbs-down / feature-request keep the single-message rationale from Step 2.

**Step 3 -- optional agent_context clarification (skip when the feedback is clearly general).** After Step 2's message lands, decide whether the message is about a specific tool interaction (e.g., "the deploy failed", "the publish returned garbage", "the diagram tool crashed on merge") vs general sentiment ("love it", "thumbs-up", "not intuitive"). If specific:

• Entering from the skill doc's bounded exception: skip the yes/no ask below -- the prompt already asked and the user already agreed. Build the JSON blob directly from the failing tool call: `error_details.step` is the tool name, `error_details.message` is the verbatim error text (including its error code and any pod/build identifier it carried), redacted per the redaction step, so the prompt's promise is honored.
• Otherwise: summarize in ONE sentence what you would attach as `agent_context` (e.g., "I'll include: your last three tool calls were an environment lookup, the publish call (error OS-BEW-1234), and an app-traces lookup on app