han-feedback
FeaturedCapture structured feedback on the Han skills and agents used in the current session and optionally post it as a GitHub issue to testdouble/han. Use at the end of any session where one or more han-* skills or agents ran, to rate a run, log what worked and what didn't, or submit observations for maintainers. Does not review code, investigate bugs, or research options; use code-review, investigate, or research for those. Does not provide feedback on skills or agents from non-Han plugins.
Install
Quality Score: 91/100
Skill Content
Details
- Author
- testdouble
- Repository
- testdouble/han
- Created
- 4 months ago
- Last Updated
- today
- Language
- Shell
- License
- MIT
Bundled in these plugins
Similar Skills
Semantically similar based on skill content — not just same category
code-review
Run a comprehensive code review on local source files. Use this skill when the user asks to review, audit, inspect, evaluate, or check code, even if they never use the word "review." Does not post comments to GitHub pull requests — use post-code-review-to-pr for that. Does not analyze architectural structure or module boundaries — use architectural-analysis for that. Does not explain code or a PR to build understanding before reviewing — use code-overview for a written overview, or code-walkthrough to be paced through it one step at a time. Does not capture feedback on Han's own skills — use han-feedback for that.
skill-feedback
Review recent Claude Code sessions that used a specific agent or skill and submit per-session feedback as GitHub issues. Use when the user says "submit [agent/skill] feedback", "review my [agent/skill] sessions", or "file [agent/skill] feedback issues".
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 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