PR Babysitter
openinterpreter/openinterpreter
Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.
Capture structured feedback on the Han skills and agents used in the current session and optionally post it as a GitHub issue to testdouble/han.
$ npx skills add testdouble/han --skill han-feedback -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install testdouble/han han-feedback --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/testdouble/han.git skills-src && mkdir -p .claude/skills && cp -r skills-src/han-feedback/skills/han-feedback .claude/skills/han-feedback && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "han-feedback" agent skill from https://github.com/testdouble/han/tree/main/han-feedback/skills/han-feedback into .claude/skills/han-feedback/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "han-feedback", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/testdouble/han/tree/main/han-feedback/skills/han-feedbackType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add testdouble/han --skill han-feedback -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install testdouble/han han-feedback --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/testdouble/han.git skills-src && mkdir -p .agents/skills && cp -r skills-src/han-feedback/skills/han-feedback .agents/skills/han-feedback && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "han-feedback" agent skill from https://github.com/testdouble/han/tree/main/han-feedback/skills/han-feedback into .agents/skills/han-feedback/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "han-feedback", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add testdouble/han --skill han-feedback -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install testdouble/han han-feedback --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/testdouble/han.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/han-feedback/skills/han-feedback .cursor/skills/han-feedback && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "han-feedback" agent skill from https://github.com/testdouble/han/tree/main/han-feedback/skills/han-feedback into .cursor/skills/han-feedback/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "han-feedback", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/testdouble/han.git --path han-feedback/skills/han-feedback--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add testdouble/han --skill han-feedback -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install testdouble/han han-feedback --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/testdouble/han.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/han-feedback/skills/han-feedback .gemini/skills/han-feedback && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "han-feedback" agent skill from https://github.com/testdouble/han/tree/main/han-feedback/skills/han-feedback into .gemini/skills/han-feedback/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "han-feedback", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install testdouble/han han-feedbackInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add testdouble/han --skill han-feedback -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/testdouble/han.git skills-src && mkdir -p .github/skills && cp -r skills-src/han-feedback/skills/han-feedback .github/skills/han-feedback && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "han-feedback" agent skill from https://github.com/testdouble/han/tree/main/han-feedback/skills/han-feedback into .github/skills/han-feedback/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "han-feedback", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add testdouble/han --skill han-feedback -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install testdouble/han han-feedback --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/testdouble/han.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/han-feedback/skills/han-feedback .opencode/skills/han-feedback && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "han-feedback" agent skill from https://github.com/testdouble/han/tree/main/han-feedback/skills/han-feedback into .opencode/skills/han-feedback/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "han-feedback", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
han-feedbackCapture structured feedback on the Han skills and agents used in the current session and optionally post it as a GitHub issue to testdouble/han.
Han Feedback is an agent skill from testdouble/han. Capture 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.
Its SKILL.md is about 3.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Development, covering Code review. It works with GitHub. The repository describes itself as: Han: AI skills and agents for "Solo" product engineers and small teams. The licence is MIT.
10 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit abba73a. It shows what the files ask for, not the result of running them.
Pre-approves these tools, so the agent can use them without asking each time:
ReadWriteBash(ls *)Bash(mkdir *)Bash(gh *)Bash(date *)Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh")From allowed-tools in the SKILL.md frontmatter.
Shell commands in SKILL.md call:
ghbashFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Han Feedback loads about 3.9k tokens when it runs. Until then it costs about 126 tokens; SKILL.md has 2,093 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
The full file from testdouble/han at commit abba73a, republished under its MIT licence (© testdouble). 2,093 words, ~3,933 tokens.
.claude/skills/han-feedback/SKILL.md (or your agent's skills folder).date +%Y-%m-%dbash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"cat .han/config.md 2>/dev/null || echo ""As your first action, use the Read tool on .han/config.md inside the personal config directory path above. A read
that returns no file is no personal configuration: continue silently. When that file or the project .han/config.md
probe supplies content, apply it per config-rule.md, which governs precedence
between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.
han-core, han-planning,
han-coding, han-github, han-reporting, han-feedback, and any future han-* plugin). Skills and agents from
non-Han plugins are out of scope.Look back through the conversation for any use of a Han plugin component. A component counts as used if it was invoked, regardless of whether it completed or was cancelled.
Han skills. Look for invocations of skills namespaced to any han-* plugin. The namespace is the plugin name
followed by a colon: han-core:, han-planning:, han-coding:, han-github:, han-reporting:, han-feedback:, and
the same shape for any future han-* plugin (treat a bare han: prefix as Han too). Watch for slash-command
invocations (like /han-planning:plan-a-feature), messages showing a skill launching (like "Launching skill:
han-planning:plan-a-feature"), and any output that identifies a specific Han skill ran.
Han agents. Look for dispatches of agents from any han-* plugin. For example, an Agent tool call whose
subagent_type is han-core:adversarial-security-analyst, or skill output naming a Han agent it launched
(evidence-based-investigator, plan-synthesizer, risk-analyst, and so on). Record each distinct Han agent that ran,
whether a skill dispatched it or it was invoked directly.
Build one list of the Han skills used and one list of the Han agents used. Deduplicate each.
If no Han skill or agent invocations are visible in the current context window, ask the user before stopping: "No Han skill or agent invocations are visible in this context window. If you ran Han skills or agents earlier but the session was compacted, list what you used and I will generate feedback for them." If the user confirms none were used, stop without writing any file.
Check whether ~/.claude/han-feedback/ exists by running ls ~/.claude/han-feedback/ 2>/dev/null. If the command fails
(directory absent), run mkdir -p ~/.claude/han-feedback/ before proceeding.
Run ls ~/.claude/han-feedback/ 2>/dev/null and identify any files whose name begins with today's date (from Project
Context). A file already covering a component used this session is the file this run updates, not a reason to skip.
Read each matching file, then decide between two paths:
Nothing new has happened. Every component in this session is already covered, and the session produced nothing the existing file does not record: no further runs of those components, no new problems, no correction you have not already written down. Report the existing file paths, say plainly that nothing new happened since they were written, and stop.
Something new has happened. The session continued past that file, a covered component ran again, a new problem surfaced, or the user asked for a compiled report. Update the file in place. Add the new material and preserve everything already there; never overwrite it. Then state the update: name the file you updated and what you added to it, so the user is not left guessing whether their newer session was captured.
A run that continued past an existing file and then skipped is the failure this step exists to prevent. The default is to update.
When Step 3 found a file to update, that file's name is the filename. Keep it as it is, even when this run covers a component the name does not mention; renaming it would break the path already reported to the user.
Otherwise compute the filename as {TODAY}-{short-names}.md, where:
han-planning:plan-a-feature becomes plan-a-feature, han-github:post-code-review-to-pr becomes
post-code-review-to-pr, and the agent han-core:risk-analyst becomes risk-analyst.{TODAY} is today's date from Project Context.Example: a session with han-planning:plan-a-feature and han-coding:code-review on 2026-05-29 produces
2026-05-29-plan-a-feature-code-review.md.
Run ls -t ~/.claude/han-feedback/ 2>/dev/null | grep '\.md$' | head -1 to identify the feedback file with the most
recent modification time.
If a file is found, read it to confirm the current output structure before writing. If no .md files exist in the
directory, skip this step and use the embedded template in Step 7.
Think through the session for each qualifying skill and assess the following.
What worked well: Where did the skill do something noticeably better than doing it manually? Which dispatched Han agents added value, and how? Which findings or decisions from the skill or its agents changed the outcome?
What didn't work: Where did the skill or one of its agents ask a question the evidence could have answered? Where was the output disproportionately long for the decision at hand? Where did you redirect or correct the skill or an agent mid-run?
Overall: One paragraph summarizing the fit for this use case.
Rating: Score each dimension on a 1-to-5 scale. When the reference file from Step 5 exists, reuse its dimensions so ratings stay comparable across runs. When no reference file exists, use this default set, and add or drop a dimension only when the skill type clearly calls for it:
For a session that used Han agents directly (no skill), assess the agents the same way.
When Step 3 found a file to update, edit that file in place rather than rewriting it. Keep its existing structure and
every point already recorded, and fold the new material into the sections it belongs in: new points onto the existing
lists, any newly-used skill or agent onto the **Skills used:** and **Agents used:** lines, and a re-scored dimension
only where this session's evidence actually changed it. Add an ## Update {TIME} heading before the new material when
the session's story changed rather than merely lengthened, so a reader can see what arrived later. Then continue to Step 8.
Otherwise write the file to ~/.claude/han-feedback/{filename} using this structure:
# Han Feedback — {TODAY}
**Skills used:** `han-core:{skill-name}` **Agents used:** `han-core:{agent-name}` **Context:** {one sentence describing
what you were doing} **Outcome:** {one sentence describing what was produced}
---
## What worked well
- {point}
- {point}
---
## What didn't work
- {point}
- {point}
---
## Overall
{one paragraph}
---
## Rating
| Dimension | Score |
| -------------------------------- | ----- |
| Output accuracy | {N}/5 |
| Evidence discipline | {N}/5 |
| Finding signal-to-noise | {N}/5 |
| Output length vs. decision count | {N}/5 |
| Turn efficiency | {N}/5 |List every Han skill used on the **Skills used:** line and every Han agent used on the **Agents used:** line, each
with its full plugin namespace (for example han-github:update-pr-description, han-core:risk-analyst). If no Han
agents ran, write **Agents used:** none.
Keep it honest and specific. Generic praise or criticism is not useful. Cite concrete moments from the session.
If the write fails, tell the user: "The write failed. The file was being written to
$HOME/.claude/han-feedback/{filename}. Run ls ~/.claude/han-feedback/ and delete any file at that path before
retrying." Do not proceed to the checklist or posting steps.
When this run updated an existing file, say so in the same message that reports the path: name the file and name what you
added to it. "Updated 2026-07-29-plan-a-feature.md with the two escalation problems from this afternoon's run" tells
the user their newer session was captured. Reporting only the path leaves them unable to tell an update from a skip.
Check that the written file contains content beyond whitespace. If the file is empty or whitespace-only, notify the user and stop. Do not proceed to the sensitive-content checklist.
Display the full content of the written file. Then present this checklist and ask the user to confirm, in a single response, that the content contains none of the following:
A clear affirmative is "yes", "correct", "looks clean", or a similar unqualified confirmation. A response like "I think so", "probably", "seems fine", or any ambiguous answer is not a clear affirmative — treat it as sensitive content present.
If the response is a clear affirmative: proceed to Step 10.
If sensitive content is confirmed or the response is ambiguous: confirm the file is saved at
~/.claude/han-feedback/{filename}, provide the ready-to-run command below for manual use after editing, and stop.
gh issue create --repo testdouble/han --title "Han Feedback: {skill-name} ({TODAY})" --body-file $HOME/.claude/han-feedback/{filename}Ask: "Ready to post this as a GitHub issue to testdouble/han?"
A clear affirmative is "yes", "go ahead", "post it", or a similar unqualified instruction. Anything else — including "maybe", "not yet", silence, or an ambiguous response — is treated as no.
If yes:
Build {skill-name} for the title from the **Skills used:** field with each plugin namespace stripped (everything up
to and including the colon); join multiple short names with hyphens. When no Han skill ran, use the stripped names from
the **Agents used:** field instead. Extract {TODAY} from the feedback filename's date component (not the current
clock).
Run:
gh issue create --repo testdouble/han --title "Han Feedback: {skill-name} ({TODAY})" --body-file $HOME/.claude/han-feedback/{filename}If the environment refuses to run the command (the tool call is denied, a permission or sandbox layer blocks it, the command is not permitted in this environment, or the run has no network access): say plainly that the environment refused the publish. Do not describe it as the run declining, choosing not to post, or deciding to skip. Those are three different statements and only the environment's refusal is true, so a user told the run declined goes looking for a decision nobody made.
Do not retry the identical command. A refusal that came from a permission or sandbox layer returns the same answer every time, and a second attempt spends a turn to learn nothing.
Then hand over the command to run by hand, filled in rather than templated, so it can be pasted as it stands:
gh issue create --repo testdouble/han --title "Han Feedback: {skill-name} ({TODAY})" --body-file $HOME/.claude/han-feedback/{filename}Confirm the file is saved at ~/.claude/han-feedback/{filename} and stop.
If gh is not found (command not found or not installed): Report that the gh CLI is not installed. To post
manually, visit https://github.com/testdouble/han/issues/new and paste the file contents.
If the command exits with a non-zero code: Display the error message without modification. Confirm the file is saved
at ~/.claude/han-feedback/{filename}. Provide the posting command above. If the error contains "auth" or "login", add:
"Run gh auth login and retry."
If the command exits successfully but no URL is parseable in the output: Say "The issue was likely created. Check https://github.com/testdouble/han/issues to confirm. Do not retry — running the command again would create a duplicate issue."
If no: Confirm the file is saved at ~/.claude/han-feedback/{filename}. Provide the posting command above for later
use.
© testdouble, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Just SKILL.md in han-feedback/skills/han-feedback of testdouble/han.
Open the folder on GitHubat commit abba73a
Han Feedback next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Han Feedback this skilltestdouble/han | 279 | — | ~3.9k | Automated safety check: Pass | MIT | |
| PR Babysitteropeninterpreter/openinterpreter | 69k | 3 repos | ~4.2k | Automated safety check: Pass | Apache-2.0 | |
| GitHub Review Iterationprisma/orm | 48k | — | ~2.2k | Automated safety check: Pass | Apache-2.0 | |
| PR Finalize Reviewmicrosoft/garnet | 12k | — | ~3.1k | Automated safety check: Pass | MIT | |
| PR Review State Fetchprisma/orm | 48k | — | ~767 | Automated safety check: Pass | Apache-2.0 | |
| Fastlane Pull Request Reviewfastlane/fastlane | 42k | — | ~550 | Automated safety check: Pass | MIT |
openinterpreter/openinterpreter
Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.
prisma/orm
Runs a loop on a GitHub pull request: fetch review state, triage comments into actions, implement them and resolve threads, repeating until nothing actionable is left.
microsoft/garnet
Checks that a pull request's title and description match its implementation and reviews the code for Garnet best practices, reporting findings without posting them.
prisma/orm
Fetches a pull request's canonical review state as JSON, validates it, and renders markdown, a text summary and triage target files from it using bundled scripts.
fastlane/fastlane
Reviews a fastlane pull request against its linked issue and the project guides, separating blocking from non-blocking findings and handling vulnerabilities privately.
saadeghi/daisyui
Reviews open pull requests in the daisyUI repository using read-only GitHub data and isolated base-versus-PR checks, then writes a merge verdict report.
testdouble/han
Convert a stakeholder summary markdown file into a single self-contained HTML executive report — bottom line and decision asks up front, supporting detail later — styled with a Test Double-derived…
testdouble/han
Update Han plugin documentation so every skill, agent, guidance doc, index, and cross-reference is current and accurate.
testdouble/han
Authoritative guidance for building Claude Code skills, agents, and plugins, plus init and update steps that install and refresh the plugin-building skills in the current repository.
testdouble/han
Cut a Han release: update CHANGELOG.md with the changes since the last release, bump and tag every plugin that changed as {plugin-name}--v{version} so a version-constrained dependency can resolve…
testdouble/han
Builds a feature implementation plan from an existing feature specification (or equivalent context) through a facilitated team conversation.
testdouble/han
Restructure existing code without changing its behavior, through a test-gated refactoring loop: a named target, a green suite over that target before any edit, a planned sequence of small named…
Works with
Categories
Capture structured feedback on the Han skills and agents used in the current session and optionally post it as a GitHub issue to testdouble/han. Han Feedback is an agent skill from testdouble/han. Capture structured feedback on the Han skills and agents used in the current session and optionally post it as a GitHub issue to testdouble/han.
Han Feedback fits situations like: tasks that involve Code review.
Run `npx skills add testdouble/han --skill han-feedback -a claude-code`. Or copy the skill folder (han-feedback/skills/han-feedback in testdouble/han) into .claude/skills/han-feedback in your project. Claude Code loads it when a task matches its description.
Run `npx skills add testdouble/han --skill han-feedback -a codex`. Or copy the skill folder (han-feedback/skills/han-feedback in testdouble/han) into .agents/skills/han-feedback in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add testdouble/han --skill han-feedback -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/han-feedback, .gemini/skills/han-feedback, .github/skills/han-feedback and .opencode/skills/han-feedback in your project.
Going by SKILL.md and its folder, Han Feedback needs the command-line tools its instructions call (gh and bash). Its frontmatter pre-approves these tools: Read, Write, Bash(ls *), Bash(mkdir *), Bash(gh *), Bash(date *), Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh").
SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
Han Feedback is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 3.9k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with Han Feedback: PR Babysitter (openinterpreter/openinterpreter, 69k stars), GitHub Review Iteration (prisma/orm, 48k stars), PR Finalize Review (microsoft/garnet, 12k stars) and PR Review State Fetch (prisma/orm, 48k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
testdouble (a GitHub organization) maintains it in testdouble/han, which has 279 GitHub stars. The repository holds 54 skills in this directory. The repository was last updated on October 1, 2026.
Source: testdouble/han on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.