Menu
Address review feedback on a PR (hv-managed or standalone) and update it — parallelizing across files with implementer subagents when the feedback spans 3+ independent files. Use after /hv:review-pr requests changes, or to act on human review comments and push the fixes back to the PR.
Autonomously drives ONE feature end-to-end — understand, implement, review-and-fix, and open a right-sized PR — inside its own worktree. Runs as the main loop of a background feature agent (launched by /hv:launch-agents, or directly via `claude --bg "/hv:build-feature ..."` for a single feature). Accepts a spec-file path, inline JSON, a plain-text task, or `<spec> <featurename>`.
Turn a GitHub issue, spec file, or free-text request into a design and the right-sized plan to build it. Judges the epic's total weight and decides whether to keep it as a single PR (small/cohesive work) or decompose it into independent, parallel-executable features for a fleet of agents (large work or separable risky cores) — it does not split by default. Use this first, before launching any work. Free to propose a better architecture than the current code; sizes by risk and independence. Outputs a feature manifest (one or more features) that /hv:launch-agents consumes.
Watch one feature's PR in the background and auto-clean its agent, worktree, and branch once it merges. Use after a feature's PR is open to wire hands-off cleanup on merge (typically called by /hv:build-feature as its final step). It polls GitHub with exponential backoff and only triggers cleanup — the actual removal is done by /hv:clean-agents.
Prepare a parallel launch from a /hv:plan-features manifest — validate it, write a self-contained spec file per feature, and emit ready-to-paste `claude --bg` commands grouped into dependency waves for the human to run. Use after design when you're ready to run features in parallel. Does not spawn sessions itself (a session launching sessions is unsupported); it produces the exact launch commands. Each launched agent auto-isolates in its own git worktree.
Code quality standards for reviewing code changes. Activated when reviewing PRs, implementing features, or discussing code quality. Triggers on requests to "review code", "check quality", "improve code", or "refactor".
Reviews PR changes against the broader codebase to find inconsistencies, missed propagation, and stale references beyond the diff. Replicates senior reviewer codebase knowledge. Activates when reviewing PRs, checking consistency, or when changes touch shared entities across multiple files.
| name | apply-feedback |
| description | Address review feedback on a PR (hv-managed or standalone) and update it — parallelizing across files with implementer subagents when the feedback spans 3+ independent files. Use after /hv:review-pr requests changes, or to act on human review comments and push the fixes back to the PR. |
| argument-hint | <pr-number> [feedback text, if not pulling from the PR] |
| model | opus |
| disable-model-invocation | true |
| effort | high |
| allowed-tools | Read, Edit, Write, Bash, Grep, Glob, Agent |
$ARGUMENTS
You turn review feedback into committed fixes on the PR's branch — correctly, without thrashing. Treat feedback as data to evaluate, not orders to obey blindly: if a comment is wrong or unclear, verify against the code before acting and say so rather than implementing something incorrect.
PR="<number>"
gh pr view "$PR" --json headRefName,reviews,comments
gh pr diff "$PR"
Combine PR review comments, the latest /hv:review-pr output, and any feedback
passed in the input. Check out the PR branch in this worktree:
gh pr checkout "$PR"
Group feedback into discrete fixes. For each: the file(s), what's wrong, and the intended change. Drop or flag items that are mistaken or already handled (explain why) — don't pad the diff with unnecessary churn.
implementer subagent per slice in parallel (one Agent message), then
integrate. Keep slices disjoint so parallel edits don't collide.The standards skills (code-quality, security-review, codebase-consistency)
apply here too — a fix must not introduce a new problem.
Run the relevant tests/lint/build and capture output. For anything that was a
correctness or security comment, re-review the fixed area using /hv:review-pr's
hybrid axis (generic checks in subagents to keep main clean; repo-specific /
context-critical judgment in main) plus adversarial-verification — the whole
point of feedback is that the original review missed something, so verify the fix
actually closes it rather than re-stating the same pass.
git add -A
git commit -m "fix: address review feedback on PR #$PR"
git push
gh pr comment "$PR" --body "Addressed review feedback:
- <fix> (<file>)
Verification: <result>"
result: PR # updated — fixes applied, checks <green/red>.