babysit-pr — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited babysit-pr (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
A bulleted imperative like {match} tells the agent to never reveal, disclose, or mention something to the user. Used adversarially it can instruct the agent to hide its tool calls or lie about what it did — stripping the transparency a user relies on to trust the agent.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Apply changes that genuinely improve the work. Respectfully decline those that do not. Every accept, reject, defer, or skip is backed by documented evidence: Context7 lookups, the project's architecture documentation, or an explicit logical argument grounded in the code. The goal is not to mark every comment resolved; the goal is to ship correct, maintainable work.
This skill carries the protocol. The project supplies the standards: coding conventions, verification commands, architectural invariants, tracker choice, and Context7 mechanics live in the project's context files (AGENTS.md, CLAUDE.md, CONTRIBUTING.md, README.md) and architecture documentation. This skill tells you how to reason; the project tells you what to reason about.
Project context (AGENTS.md, CLAUDE.md, architecture documentation) is reference material consulted while walking through this skill's steps - not a prerequisite to read end-to-end before starting. If a wrapper prompt that invoked this skill lists its own prerequisite reading, honor those reads first; the wrapper has authority to add such a gate. The "not a prerequisite" rule applies only to the project context files named here - it is not a blanket prohibition against preliminary reading the wrapper requires.
Script paths in this document (e.g. scripts/) are resolved relative to this SKILL.md file, not to your current working directory. If a relative command fails to resolve, prefix it with the path your platform loaded this SKILL.md from.
Fallback. If python3 cannot be located, analyze the script's purpose and logic and execute its intent with available tools, but warn the user that python is not available and the logic was executed with a fallback approach that may not be perfect.
Before executing any step, confirm:
resolve-library-id, then query-docs). This skill defines when to use it; the project context defines how.docs/architecture.md, ARCHITECTURE.md), an architecture section inside the primary context file (AGENTS.md/CLAUDE.md), a directory of design notes, or a set of accepted ADRs. If no dedicated doc exists, treat the most architecturally-detailed context file as the de facto record. Never guess what the architecture says - read it.Copy this checklist into your response and mark items as you complete them. Do not skip gates. Each gate exists to prevent a specific failure mode documented in the protocol's rules.
Do not pre-form an action plan from the reviewer's text. "I'll implement the missing tests and fixes mentioned in the review" - thinking like this is the failure mode this protocol exists to prevent. Steps 1 through 3 (ingest → Context7 audit → classify) MUST complete before any decision about which fixes to apply. The review is input; the decision is output.
Examine the input the user provided.
Source A - Inline input. The user pasted or typed review comments. Use them as-is. Do not fetch anything from a remote tracker.
Source B - GitHub PR. The user provided a PR number or URL, or the input is empty and a PR exists on the current branch. Run the fetch script to collect every kind of comment: python3 scripts/fetch_pr_comments.py [PR_NUMBER]. The script emits a single JSON object on stdout with pr, inline, reviews, and issue fields.
If python3 or the script is unavailable, run the three commands it wraps - missing any of them silently drops a class of comments:
PR=$(gh pr view --json number --jq '.number')
gh api "repos/{owner}/{repo}/pulls/${PR}/comments" --paginate
gh api "repos/{owner}/{repo}/pulls/${PR}/reviews" --paginate
gh pr view "$PR" --json comments --jq '.comments'Classify the feedback domain from what the comments reference:
| Signal | Domain | Role |
|---|---|---|
| Source files, function/class names, test failures, idiom or style | Code | Coder |
| Architecture documentation, design decisions, models, ADRs | Architecture | Architect |
| Both | Mixed | Split the comments into two groups; resolve each in its own domain |
MANDATORY. Complete every sub-step before assigning any classification to any comment. There are no exceptions.
A reviewer asserting that a library behaves a certain way is making a verifiable, falsifiable claim. Context7 is the verification mechanism. Accepting or rejecting on unchecked library assumptions is the proximate cause of both false approvals and false rejections. This step prevents both failure modes.
#### 2a. Triage - which comments require Context7
For each collected comment, answer: does this comment reference, either explicitly or implicitly, the behavior, API surface, correct usage pattern, or known limitations of an external library, framework, SDK, or third-party API?
If yes, mark the comment [C7-REQUIRED] in your internal analysis.
The tag is a working annotation for Steps 2b–2c and Step 3 reasoning only. It MUST NEVER appear in tracker-visible artifacts (PR replies, ticket bodies, the Step 6 summary, or any other output visible outside your own reasoning).
For the heuristic that decides what counts as a library claim, the categories of comments that do NOT require Context7, the cautious-default rule, and the failure-recovery procedure, read references/context7-triage.md.
The default posture is cautious: when in doubt, run Context7. A false positive (running it when not strictly necessary) costs one tool call. A false negative (skipping it when needed) costs a wrong classification and a defensible-looking mistake.
#### 2b. Execute the Context7 workflow
For every [C7-REQUIRED] comment, run the two-step Context7 workflow per the project's Context7 usage instructions. Follow those instructions for query phrasing, topic filtering, token budgets, and failure recovery.
When the library is not indexed and you fall back to an authoritative source (the library's official docs, its package-registry page, or its GitHub README at the version pinned in the project's manifest), record [FALLBACK: web] in the evidence table. The finding is still treated as authoritative; only the logistics differ.
#### 2c. Library Evidence Table
Build this table completely before proceeding to Step 3. Every [C7-REQUIRED] comment gets exactly one row. The table is evidence, not interpretation - classification comes in Step 3.
Use assets/evidence-table-template.md as the structural template. It contains a blank skeleton, filled example rows demonstrating each verdict type, and column-discipline notes.
#### 2d. Binding rules
These rules govern every classification in Step 3. They are not guidelines; they are gates. They exist to counteract the well-documented tendency of language models to drift toward agreeing with whoever spoke last - a drift that is the proximate cause of both sycophantic acceptance of wrong suggestions and sycophantic rejection of correct ones when the reviewer's tone becomes uncertain.
With the Library Evidence Table complete, classify every comment. Write the per-comment classification block verbatim before assigning a category. Forcing yourself through each field catches comments that seem clear but turn out to depend on an unverified library claim or an unstated architectural assumption.
Use assets/classification-block-template.md as the structural template. It contains the blank block, a filled example, and discipline notes.
The seven categories:
| Category | Action |
|---|---|
| Valid & Actionable | Apply the fix (Step 4a / 4c) |
| Valid - Deferred to Backlog | Tracker triage (Step 4b) |
| Valid but Already Addressed | Skip with explanation |
| Subjective / Stylistic | Skip with explanation |
| Incorrect or Counterproductive | Reject with rationale |
| Outdated / Stale | Skip with explanation |
| Needs Discussion | Flag for human decision |
For precise criteria, worked examples, the borderline-case decision rubric, and how Context7 verdicts map to each category, read references/classification-categories.md.
#### 4a. Code-domain comments (Valid & Actionable)
Follow declared commands verbatim. Do not substitute equivalents (e.g., do not invoke a tool directly when conventions specify a task runner). If conventions are silent on a category you touched, infer the default from the project's manifest and note the inference in the Step 6 summary so the human operator can confirm.
#### 4b. Deferred comments - tracker triage
A comment classified Valid - Deferred to Backlog in Step 3 is a real concern the agent has chosen not to fix in the current change. The Deferred classification is a promise that the concern will be tracked. The promise is only valid if backed by a ticket reference.
Hard rule. Deferred ↔ ticket. Every comment that ends Step 4b in the Deferred category MUST resolve to a ticket reference - either a newly created ticket or an existing ticket already covering the concern. A Deferred comment without a ticket reference is forbidden, regardless of which tracker the project uses: it is a memory leak in the review process. If the workflow below cannot produce a ticket reference, the comment was misclassified - return to Step 3 and pick a different category.
Step 4b begins with discovery, not action. Two discoveries happen before any ticket is created.
##### Discover the project's issue tracker
The project uses one of: GitHub Issues, Jira, GitLab Issues, Linear, or another tracker. Identify it from the strongest available signal:
.github/ directory and an authenticated gh CLI suggests GitHub Issues. Atlassian URLs (*.atlassian.net) in commit messages, PR descriptions, or branch names suggest Jira. GitLab CI configuration and gitlab.com remotes suggest GitLab Issues. Treat these as evidence only when context files do not name a tracker explicitly.##### Discover sibling skills that manage the chosen tracker
The current session loads a catalogue of skills. Inspect their descriptions for words that match the chosen tracker - typically descriptions naming the tracker, naming a ticket type, or describing operations like "create a ticket", "manage backlog", "triage issues", "manage roadmap", "manage epics". A matching skill is the correct tool because it carries project-specific conventions (label taxonomy, body templates, duplicate-detection logic, parent-epic resolution, custom-field handling) that hand-rolled CLI calls do not.
If a matching skill exists, load and apply it for the create operation. Pass the deferred concern with full context: the file:line being deferred, the reviewer attribution, and the gate verdicts below. Let the discovered skill handle the mechanics; this skill's job is to decide whether to create a ticket and what it should contain semantically, not to format ticket payloads.
If no matching skill exists, fall back to manual creation:
gh issue create with a clear title, a body that names the file:line and the reviewer, and labels inferred from the project's existing issue conventions (read a few existing open issues for examples).##### Apply the three triage gates in order
The gates validate the Deferred classification. They are not silent stops: if a gate trips, the comment was misclassified and Step 3's category was wrong. Reclassify and continue - never leave a Deferred comment without a ticket.
{existing ticket reference} (existing). Do not create a new ticket.##### Create the ticket and verify
If gates 1 and 3 pass, create the ticket via the discovered skill (preferred) or the manual fallback. Confirm the create operation returned a ticket identifier (the tracker echoed an ID, key, or URL) - a silent failure means no ticket exists, which means the comment cannot stay in Deferred.
Record the outcome in the Step 6 summary as {ticket reference} (created via discovered skill) or {ticket reference} (created via manual fallback). If creation failed and cannot be retried in this session, reclassify as Needs Discussion (Category 7) with the failure noted, and flag for the human operator to create the ticket manually.
#### 4c. Architecture-domain comments (Valid & Actionable)
Never modify accepted ADRs without explicit instruction from the user. Accepted ADRs preserve the context, alternatives, and consequences of prior decisions; rewriting them retroactively destroys the historical record.
You are FORBIDDEN from posting any comment, reply, or message to the reviewer under any circumstances.
This prohibition is absolute and has no exceptions:
Before producing the Step 6 summary, confirm you have not executed any of the forbidden operations. All reasoning, all evidence, all decisions belong in the summary for the human operator - not in the PR thread.
Output the summary directly in the chat response to the human operator, using assets/summary-template.md as the structural template. Do not save the summary to a file - the audience is the human reading the chat, not a persistent artifact. The template has one section per category plus the source header, the tracker header, and the Context7 evidence log.
Before sending the response, verify the draft against this checklist:
_(none)_ for empty bodies).[C7-REQUIRED] tags appear anywhere in the summary.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.