How to make product feedback useful for reading tools
Useful product feedback gives a maintainer enough information to understand a problem and decide what to do next. For reading tools, this often requires separating a calculation or interface problem from disagreement with an interpretation. Both can deserve attention, but they need different evidence.
Start with the task you were trying to complete. "I wanted to compare the cards in a completed draw with the answer" identifies a workflow. "The reading was bad" leaves open whether the issue involved missing inputs, an incorrect card order, or prose the reader found unconvincing.
Use a fictional reproduction whenever possible. Public feedback should not require a real person's birth details, relationship history, or full conversation transcript.
Identify the type of problem
An input problem concerns what entered the system: a changed date, a missing profile field, or a card order different from the one supplied. A display problem concerns what the interface showed. A reasoning problem concerns how the answer used otherwise correct inputs.
For example, a hypothetical tarot report might say that the draw showed one card in the final position while the response discussed it in the first position. The maintainer can investigate whether the stored result, presentation, or AI response introduced the mismatch. Calling it simply a draw bug would prematurely assign the cause.
A feature request needs a different framing. If you want to compare two answers side by side, explain what you currently do and which decision the comparison would support. Avoid describing a proposed interface as an existing control that has failed.
Build the smallest reproduction
Repeat the issue in a disposable session with synthetic content. Remove unrelated attachments and context one step at a time. The goal is a short sequence that preserves the problem. If removing an element makes it disappear, that observation belongs in the report.
The inspected Mystilink desktop tarot source accepts one, three, five, cross, and decision spread identifiers and records a completed draw or skipped state. A report about this path should say which spread was used and whether the user completed or closed the inquiry. This gives the maintainer a concrete branch to examine.
For a profile issue, name the affected field and use a fictional replacement value. The inspected birth-profile README distinguishes identity fields from chart-calculation values. If a mismatch involves those fields, identify both labels and the observed result. Do not expose the original profile to demonstrate the distinction.
Record expectations without assuming the cause
State what you expected and why. A visible label, documentation passage, or earlier successful action can explain the expectation. Then state exactly what happened. Keep a proposed explanation in a separate sentence: "This may involve the position mapping; I have not established the cause."
Include the application build and operating system when available. If a report concerns model behavior, include the selected model and connection route without credentials. The inspected platform documentation distinguishes a Newton gateway route from direct-provider BYOK, so route information may help narrow a report involving request behavior.
Avoid pasting tokens, provider keys, or unredacted request headers. A maintainer can ask for a safer diagnostic artifact if the minimal reproduction is insufficient. Include error wording only after checking it for identifying details.
Share enough history to explain the transition
Some problems occur after a correction or interruption. Record the relevant sequence: completed a draw, sent a correction, reopened the session, then observed a mismatch. A screenshot of the final state alone may hide the step that triggered it.
The inspected session documentation describes persisted transcripts and continuation from them. If recovery is the issue, distinguish a completed exchange from a pending inquiry. Note whether the problem occurs on reopening the same session or starting a new one. These differences can matter more than the length of the report.
Use short excerpts with their role labels. A user message, tool result, and AI answer are different evidence. Keeping those labels prevents the report from making a guessed statement look like an input supplied by the user.
Describe the cost of the problem
Explain what you could no longer do. Perhaps you had to manually reconstruct a spread, could not tell which profile was used, or needed to reattach source context before sharing a note. This helps a maintainer assess the practical effect without requiring exaggerated language.
For a proposed improvement, offer one example of successful behavior. A request that exports include the original question can show a short fictional question and explain where it is lost in the current workflow. The maintainer can then consider several possible solutions.
End the report with unresolved information you can still provide safely. Keep any public follow-up focused on the reproduction and outcome. If a later build resolves it, record the tested build and steps. That gives future readers useful evidence and keeps a support thread from becoming an unsupported claim about every version of the product.