agentsclimarketplace

Reply to code review

Skill aictrl-dev/skills/skills/reply-to-code-review

Eleven free, vendor-neutral AI engineering skills for common SDLC workflows.

Install
npx -y skills add aictrl-dev/skills --skill reply-to-code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Judge current-head review findings, fix accepted defects, run verification, post evidence-backed replies, and request bounded re-review. Use when the user says "address review comments", "reply to code review", "fix accepted findings", or "get this PR through review".

SKILL.md

3.2 KB, as published. Nobody here has run it

Reply to Code Review

Turn review feedback into verified remediation and concise, evidence-backed responses without creating an unbounded fix/review loop.

Workflow

  1. Resolve the repository, request identifier, and exact current head SHA. Preserve unrelated worktree changes and load repository guidance.
  2. Gather unresolved findings for the current head. Mark older-head findings stale and revalidate any concern that may still apply.
  3. Apply the judge-review-findings procedure: assign TRUE/FALSE/UNCERTAIN and FIX/DEFER/IGNORE with evidence. If that skill is available, invoke it rather than duplicating stored judgments.
  4. Present the remediation set when it contains a material scope, behavior, security, or compatibility decision. Never use “fix all” to bypass required user choices.
  5. For each accepted FIX:
    • make the smallest complete change that resolves the root cause;
    • add or update a test that would fail without the fix;
    • avoid drive-by refactors and unrelated cleanup.
  6. Run focused checks after each cluster, then broader tests, lint, type checks, build, and required CI in proportion to risk.
  7. Re-read the changed diff and verify every accepted finding against the current head. If the head changed externally, refresh and rejudge before replying.
  8. Commit and push only when authorized. Post one concise response per finding or a structured summary supported by exact code/test evidence.
  9. Request re-review once per remediation round. Bound the loop by the user's time/cost limit or a default of two rounds. Escalate unresolved, contradictory, or newly expanding feedback.
  10. Stop at addressed findings and green required checks. Do not merge or deploy unless separately authorized.

Response format

| Finding | Verdict / action | Resolution | Verification |
|---|---|---|---|
| <id> | TRUE · FIX | <path and behavior changed> | `<command>` — PASS |
| <id> | FALSE · IGNORE | <evidence-backed rationale> | <code/test evidence> |
| <id> | TRUE · DEFER | <reason and follow-up URL> | <risk boundary> |

Boundaries

  • Do not fix findings from a stale head without revalidation.
  • Do not mark tests or CI green unless observed.
  • Do not dismiss true findings without a documented defer decision.
  • Do not expose secrets, private source, or sensitive logs in public replies.
  • Do not create endless automated reviewer loops.

Built by aictrl.dev. This skill teaches the workflow; aictrl operationalizes it — grounded in your backlog, team standards, and codebase knowledge graph. See how →

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.