菜单
Harden a pull request by fixing blocking review findings, strengthening regression tests, validating locally, pushing to the PR branch, and updating AgentJido review-state labels. Use only when explicitly asked to fix a PR.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Guide human-in-the-loop Hex package releases for AgentJido repositories. Use when preparing, validating, dry-running, publishing, tagging, or dispatching a Hex release workflow.
Build and maintain composable Jido actions with validated inputs, explicit outputs, predictable errors, and AI-tool compatibility. Use when defining actions, schemas, action chains, or action execution behavior.
Build and maintain Jido agent modules, schemas, command handling, plugins, directives, and runtime wiring. Use when creating agents, changing agent behavior, or working with AgentServer-style runtime integration.
Integrate AI and LLM behavior into Jido systems using local jido_ai and req_llm conventions. Use when adding providers, model aliases, AI agents, tool calling, streaming, structured output, or skill prompt composition.
Provide Jido ecosystem context, package roles, conventions, and foundational patterns. Use before Jido agent, action, AI, testing, docs, or package work when the local repo needs shared Jido guidance.
Test Jido agents, actions, plugins, signals, directives, and AI integrations with focused unit and runtime coverage. Use when adding tests, fixing test gaps, or validating Jido behavior.
| name | pr-harden |
| description | Harden a pull request by fixing blocking review findings, strengthening regression tests, validating locally, pushing to the PR branch, and updating AgentJido review-state labels. Use only when explicitly asked to fix a PR. |
| metadata | {"author":"agentjido","version":"0.2.0"} |
| license | Apache-2.0 |
Turn a needs_work pull request into a merge-ready PR by editing the PR branch
directly.
Use this skill only when:
needs_workUse pr-review instead for read-only PR review.
gitgh CLI with permission to push to the PR branchRun:
git status --short --branch
git fetch --prune origin
Stop if the worktree is dirty unless the dirty files are known to be yours and part of this hardening task.
Fetch PR metadata, checks, labels, reviews, comments, and changed files:
gh pr view <number> --json title,body,labels,reviewDecision,mergeable,statusCheckRollup,headRefName,baseRefName
gh pr checks <number>
gh pr diff <number> --name-only
Identify blocking issues first:
Use:
gh pr checkout <number>
Confirm the checkout is writable before editing. If the PR comes from a fork and is not writable, stop and report the limitation.
Keep changes scoped to the PR goal. For each blocking issue:
Run the focused tests that prove each fix. Then run repo-standard validation. If no alias is documented, run at least:
mix test
mix compile --warnings-as-errors
If GitHub CI was failing, make sure local validation covers the failing area before pushing.
Commit with a conventional commit message and push to the PR branch only.
Never push to main.
After push, update labels:
gh pr edit <number> --add-label needs_work --remove-label ready_to_merge
gh pr edit <number> --add-label ready_to_merge --remove-label needs_work
Apply ready_to_merge only when all blockers are resolved, focused validation
passes, required CI is green, and the PR is merge-clean. If CI is pending after
the push, keep or apply needs_work and report that the PR should be relabeled
after CI passes.
Report:
main.ready_to_merge with known failing CI, unresolved blockers, or
conflicts.