--- 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. --- > 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. # 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: `, 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.