canon-feedbacklisted

# Canon feedback Format a `## Toolkit feedback` block from the current session, then open it as a GitHub issue on the toolkit repo, labeled `feedback` plus the domain label its surface type names. `canon-feedback-triage` reads that queue. ## Guards - If nothing in session context points to a toolkit issue, stop: `❌ No toolkit issue in session context. Describe what broke, then re-invoke.` - If the surface type is ambiguous (snippet vs. plugin skill vs. CLI vs. seed), ask one line before formatting. - Do not probe the project, list files, grep, or read toolkit surfaces. Use only what the session already contains. ## Step 1: build the block From the conversation so far, identify: - Target project name or kind, never its full path. The path names a folder on one machine and says nothing a triage session can route on, where the project's own name does. Name a private project by its kind instead, such as `a Next.js app`, since the report leaves the machine. - Toolkit surface and its type (plugin skill, snippet, tooling config, governance rule, seed, or CLI). The type leads the `### Surface` field, ahead of the first comma, because the CLI picks the issue's domain labels from that text alone. - Specific toolkit file or name when the session cites one - Observed behavior - Expected behavior, or `unclear` - Repro details already in context (commands run, files touched), or `none` - Proposed fix, or `open` when the session settled on no direction Format as a single fenced markd