tool-feedbacklisted

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 registry the user supplies — a file at a known path, or a table in loaded context — never hunt the filesystem for targets. Design-only or authoring-only use of a tool still counts as use. Not for feedback on c
grimaldost/craft-collection · ★ 2 · AI & Automation · score 71

Install: claude install-skill grimaldost/craft-collection

# Tool Feedback Tools in active development improve only if every session that uses them reports back. This skill writes that report — one per tool per distinct concern, into the tool's own repo — in a format the downstream `feedback-triage` pass can cluster: severity-tagged findings, stable IDs, the phase that missed, explicit links for repeats. One tool exercised across distinct phases, concerns, or surfaces (a library vs its consumer plugin) takes one report each, under distinct slugs. The quality bar: a maintainer can act on it cold. ## Registered tools — the feedback-targets binding First hit wins: `$FEEDBACK_TARGETS_FILE` → `~/.claude/feedback-targets.toml` (absolute-pathed, so it survives being copied between environments) → a `feedback-targets` table in loaded context → **ask once**. **Never hunt the filesystem.** Either shape carries the same fields: | tool | repo | feedback dir | extras | |------|------|--------------|--------| | keel | C:\Users\me\Documents\keel | docs/feedback | format: that dir's README.md | - `extras` carries per-tool obligations — a format README that stays authoritative for that directory, a registered triage template, "include cost table for engine runs". Read and honor it; if it cites a README that does not exist, fall back to this skill's template and note the gap in the report. - The session **used** a tool if it invoked any of its skills/agents/commands, ran its engine or CLI, or substantively applied its templates/doctrine.