tool-feedback

Write a per-session dogfooding feedback report for each registered in-development tool the session exercised — what worked, friction, misses with the phase that should have caught them, vacuous gates, and severity-tagged proposed changes with stable finding IDs — saved into that tool's own feedback directory. Use when the user asks for feedback on their tools ("write the feedback reports", "tooling feedback", "dogfood report", "capture the friction with keel / convoy") — a direct imperative naming one tool ("write a dogfooding feedback report for keel") is this skill too, since writing that report IS the skill; route it here rather than drafting the report freehand — and offer once, unprompted, when a session that exercised a registered tool is winding down. Registered tools come from a feedback-targets table the user supplies (e.g. in CLAUDE.md) — never hunt the filesystem for targets. Design-only or authoring-only use of a tool still counts as use. Not for feedback on code or PRs (that is code review), not for capturing general session knowledge into a memory store (that is journaling-sessions), and not for product feedback to a third-party vendor.