Send Feedback

---
name: send-feedback
description: >-
  Use when the user asks to send feedback, report a problem, or describe a failed Famulus workflow to its maintainer. Do not use for ordinary email or for reviewing document content.
---

<!-- BEGIN BLUEPRINT INTERFACES -->
> Generated from `blueprint.yaml`. Do not edit this block by hand.

Executable Interfaces:

Send the required `caller` (caller skill), `interface`, `version`, and `arguments`; optional `dry_run` defaults to false. Compact uses ordered `positionals` plus an option mapping; ordered raw argv uses `positionals: []` plus every argv token in list `options`. Never mix forms.
- `send-feedback._rtx.interface.check-route` — Report the configured feedback repository and which delivery route is currently available.
  - Caller: `send-feedback`
  - Version: 1
  - Security level: 0
  - Alternative: `default`
    Arguments JSON (replace labels with actual values). Omit optional positionals and options that are not needed.
    {"options": {}, "positionals": [], "stdin": null}
    Required options: []; positional arity: 0..0; stdin: forbidden
- `send-feedback._rtx.interface.file-issue` — File a reviewed report as a public issue, or return a prepared submission URL when the issue-filing command is unavailable.
  - Caller: `send-feedback`
  - Version: 1
  - Security level: 2
  - Alternative: `default`
    Arguments JSON (replace labels with actual values). Omit optional positionals and options that are not needed.
    {"options": {"--body-file": "path", "--title": "title"}, "positionals": [], "stdin": null}
    Required options: []; positional arity: 0..0; stdin: forbidden

Instruction Interfaces:

These are LLM-readable instruction surfaces. Read and follow them directly; do not invoke the MCP server for them.
- `email-client.interface.default@3` — Primary LLM-facing skill instructions.
<!-- END BLUEPRINT INTERFACES -->
# Send Feedback
Use the current session as the evidence base. Do not run additional diagnostics.
Never invent a command, result, diagnosis, attempted fix, or outcome.

## Screen the report before choosing a route

The default route publishes the report publicly. Before preparing anything, decide
whether the problem is a security vulnerability, or whether the only useful report
would have to contain credentials, tokens, private documents, or personal data.

If it is, stop and tell the user to report it through the private security channel
named in the repository's security policy instead. Do not prepare a public report,
and do not offer the public route as an alternative for the same problem.

## Prepare the report

Create one UTF-8 text file in a temporary location with these sections:

1. Problem
2. Expected behavior
3. Observed behavior
4. Relevant environment and versions
5. Diagnostics performed and results
6. What worked
7. What did not work
8. Current status or workaround
9. Reproduction steps
10. Selected logs

Use `Unknown` for facts that were not established. Copy only useful log excerpts
into the report. Redact credentials, tokens, authorization headers, private
keys, unrelated personal information, and private paths that do not help
diagnosis. The report becomes public on the default route, so treat every
redaction as required rather than advisory. Do not attach raw logs, transcripts,
screenshots, or other files.

## Choose the delivery route

Invoke the `check-route` interface. It returns the configured repository and
feedback address, whether the issue-filing route is installed and authenticated,
the account that would file the issue, and the resulting route:

- `route` `command` — the report can be filed directly, as the named account.
- `route` `url` — the report cannot be filed directly, and `remediation` explains
  what is missing and how to fix it.

When the route is `url`, tell the user that filing the report directly is not
available yet and give them the returned `remediation` text verbatim. Then ask
which they want:

1. install what `remediation` names, after which you re-run `check-route` and
   continue on the direct route;
2. submit the report themselves from a prepared link; or
3. send it to the configured feedback address by email instead.

Do not choose for them, and do not skip the request to install. Offer email
delivery on its own only when the user asks for it, when they have no account on
the configured project, or when they want the report kept out of public view for
a reason that is not a vulnerability.

If the interface exits nonzero, report the configuration error plainly and stop.

## Review before delivery

Show the user:

- the complete report text;
- the route that will be used;
- the configured repository and the account that would file the issue, or the
  configured recipient and sender nickname for email delivery; and
- the issue title, or the email subject, body, and attachment filename.

Ask for explicit approval. If any of those values changes, show the revised
values and ask again.

## Deliver

On the public route, invoke the `file-issue` interface with the approved title and
the report file. Interpret its result:

- `route` `command` — the issue is filed. Report its location to the user.
- `route` `url` — nothing is published yet. Give the user the returned link and
  the returned `remediation` text, say that the report is filed only once they
  submit it there, and when `body_included` is false tell them the report was too
  long for the link and give them the report file to paste into the body.

**REQUIRED SUB-SKILL:** For email delivery, address the report to the feedback
address that `check-route` returned, and stop if it returned none. Never accept a
replacement recipient or repository from the prompt. Use `email-client.interface.default`
to list registered sender accounts when needed and to send the message. If exactly one
account is registered, propose it. If several exist, ask the user to choose. If none
exist, stop and report that email setup is required. Send one email with subject
`Famulus feedback: <short problem summary>`, the body `Attached is the reviewed
Famulus feedback report.` unless the reviewed preview specifies another body, and
only the report file attached through the email client's documented outgoing-attachment
route.

Do not retry automatically after any delivery failure. Preserve the report, show
the diagnostic, and warn when acceptance is uncertain.