babysit-pr — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited babysit-pr (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 2 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 3 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.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, CONTRIBUTING.md, README.md) and architecture documentation. This skill tells you how to reason; the project tells you what to reason about.
Project context is reference material consulted while walking the steps, not a prerequisite to read end-to-end first; the exception for a wrapper prompt that declares its own reading gate is in references/protocol-rationale.md.
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:
An authenticated gh CLI for Source B, Context7 and its two-call workflow, the project's documented verification commands, the project's architecture documentation, and no assumption about which issue tracker the project uses. What each one means and where to look for it is in references/setup-and-ingest.md.
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, plus the review_digest and totals it derives from them.
A review body is a container of findings, not one finding. Read all three places: the inline comments, the body's own prose, and every collapsed ### Suppressed comments (N) block inside that body, where each **path:line** entry is a separate finding. Compare what you extracted against the N the reviewer declares in its own heading; counts_agree: false on a review_digest[].suppressed_blocks[] entry, or totals.suppressed_counts_agree: false across every block, means the format moved and you must read the body by hand.
Take each review's verdict from the first line of its body, never from `state`. A bot submits every review as COMMENTED and puts the verdict in the body's opening heading (### 🟢 Approval recommended, ### 🟡 Changes recommended, ### 🔵 Needs a closer look); review_digest[].verdict carries it.
If python3 or the script is unavailable, run the three gh commands it wraps and do the same three-place reading yourself; both are in references/setup-and-ingest.md. Missing any of them silently drops a class of 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.
Why this audit is mandatory, why the binding rules below are gates rather than guidelines, and the cautious default that governs a borderline call are in references/context7-triage.md.
#### 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.
#### 2b. Execute the Context7 workflow
Run the two-call workflow for every [C7-REQUIRED] comment. The query mechanics, the not-indexed fallback, and the [FALLBACK: web] convention are in references/context7-triage.md.
#### 2c. Library Evidence Table
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
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)
The five-step apply procedure is in references/applying-and-reporting.md. It carries the rule to run Context7 for the implementation and not only for the classification, and how to pick the verification subset the project's context files declare.
#### 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.
The tracker and sibling-skill discovery, the fix-versus-ticket proportionality test that runs before the gates, the three triage gates in order, and the creation-and-verification procedure are in references/tracker-triage.md.
#### 4c. Architecture-domain comments (Valid & Actionable)
The revision procedure, and the internal-consistency and downstream-implication checks that travel with it, are in references/applying-and-reporting.md.
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.
Scope first: this step restricts what reaches the reviewer, and nothing else. Committing, pushing, and branch lifecycle reach no reviewer and are not restricted here. Read the prohibition below as being about review surfaces only. Widening it into "touch nothing outward" is a known failure: it ends the run with verified changes stranded in the working tree and the operator asked to authorise a push nobody forbade.
You are FORBIDDEN from posting any comment, reply, or message to the reviewer under any circumstances.
This prohibition is absolute and has no exceptions:
Merging, closing, reopening, marking ready and updating the branch are lifecycle operations: this protocol never performs one on its own initiative, and when the operator explicitly instructs one, carry it out - Step 5 is not a reason to refuse a direct instruction.
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 the ten-item checklist in references/applying-and-reporting.md. It covers the required headers, the evidence log, the empty-section rule, the [C7-REQUIRED] tag prohibition, and the evidence each populated entry owes.
The protocol ends here with the applied changes in the working tree. It does not decide whether they are committed: that belongs to whoever invoked it, and the summary is a report rather than a finish line.
Nine principles stand behind these rules: library claims are falsifiable, quality beats harmony, architecture beats library capability, spec before code, maintainer over people-pleaser, thorough but surgical, evidence for every decision, defer only with a ticket, and a ticket is never free. Each is stated in full in references/protocol-rationale.md. Read it when a rule above and the situation in front of you seem to disagree.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.