babysit-prs

Files (4)

• SKILL.md
• github-actions.md
• repos.md
• routine.md

SKILL.md (first lines)

# babysit-prs

## Input

Treat text accompanying the skill invocation as the input:

- **Empty** → process **all** open PRs authored by the current GitHub user across **all default
  repos** (see Targets).
- **One or more PR numbers** (e.g. `1768 1765`) → process only those PRs. PR numbers are
  ambiguous across repos, so they resolve against the **first** default repo (`Atllas-Inc/codebase`)
  unless a `--repo` is also given. Process a numbered PR only when the current user authored it
  (Scope guardrail).
- `--repo <owner/name>` → restrict this run to one repo (one of the defaults, or any other repo you
  own PRs in). Can be combined with PR numbers.

### Targets (default repos)

**Read [../shared/repos.md](../shared/repos.md).** It owns the repo set, the clone paths, the
default branches, and each repo's stack. Process every repo there unless `--repo` narrows the run.
**Never assume `master`.** Read the PR's own base ref.

Each repo needs a clone to make fixes in. Resolve `CLONE` per repo, in this order, and take the
first hit:

```bash
for candidate in "./$NAME" "$HOME/$NAME" "$HOME/Git/$NAME"; do
  [ -d "$candidate/.git" ] && CLONE="$candidate" && break
done
```

`./$NAME` is the Routine cloud checkout. `$HOME/Git/$NAME` is the local host. Confirm the `origin`
remote matches `$REPO` before you use a hit, because a name can collide.

**Default author:** the authenticated login.

## Core safety model (do not weaken these)

Three invariants:

1. **Scope, your PRs only. Never act on a PR you did not author.** Confirm `author == $ME`
   for every PR before touching it. Skip a PR number passed in the invocation input that you do
   not own, and log a note.
2. **Evidence before resolution.** Auto-resolve a thread **only** after you pushed a real fix,
   the affected typecheck/lint/tests are green, and you posted a reply linking the fixing commit.
   **Never** resolve silently. **Never** resolve a thread you only replied to.
   Exception: resolve a thread already fixed by an earlier commit on this branch when it is
   bot-authored, verified by reading the current code at that `path` and identified via
   `git log --oneline -3 -- <path>` (Phase 3, outdated pre-step).
3. **When unsure, answer and leave open.** Reply with your reasoning or question and **leave the
   thread unresolved** for the human when a thread is a question, a judgment call, an
   architectural disagreement, security-sensitive, or the fix cannot be made green.

"Safe to auto-resolve" = **mechanical, local, obviously-correct, test-covered.** Everything else
is a reply-and-leave-open.

---

## Writing style

Copied verbatim from `~/.claude/CLAUDE.md`, which a headless run never loads.
Binding on every thread reply this skill posts and on the Phase 7 report.

When you write technical text (documentation, READMEs, runbooks, procedures, error messages, release notes, reports), write plain English in the spirit of ASD-STE100 Simplified Technical English, so that a smart reader outside the field understands it on one read. Obey these rules:

CLASSIFY FIRST. Procedural text tells the reader what to do: imperative mood, maximum 20 words per sentence, one instruction per sentence. Descriptive text explains: simple tenses, maximum 25 words per sentence, one topic per paragraph, maximum six sentences per paragraph. Never mix the two in one passage.

PLAIN WORDS, for replies and for explanations written for readers outside the field. Use the common word when one exists ("use", not "utilize"). Define a concept term at its first use, in under ten words, at most one per sentence: "idempotent (safe to run twice)". Do not define product names, standard names (Postgres, S3, HTTP), or the tool the document is about. Address the reader as "you". Lead with the point. Procedures and reference documents follow the rules above alone.

VERBS. Use only: infinitive, imperative, simple present, simple past, simple future, past participle as adjective. No present perfect ("has completed" → "completed"). No "-ing" verb forms ("making it easy" → new sentence). Active voice; passive only in descriptions when the agent is unknown. Approved modals: can, will, must. Banned: should, would, may, might, could. For "should": write "must" if required, delete if optional.

SENTENCES. Keep complete grammar: no contractions, keep articles, keep "that" ("make sure that the file exists"). Put conditions before commands, with a comma: "If the test fails, read the log." No semicolons: write two sentences. No em-dashes: an em-dash hides the logic between two statements. Name the relation ("because", "but", "for example", "that is") or write two sentences. Use a vertical list for more than two items or steps.

WORDS. One word, one meaning, for the whole document: use "make sure that" for check/verify/confirm, and "configuration" for config/settings. Noun chains of maximum three words. Break longer ones with prepositions ("the timeout value for the connection pool"). Delete words that carry no fact: simply, seamlessly, robust, powerful, comprehensive, leverage, delve, pivotal, "in order to", "it is worth noting". Do not open or close with chat filler: "in conclusion", "in summary", "let's dive in", "that being said", "I hope this helps".

AVOID THE AI DRIFTS. Guard against these by direction: inflated significance ("crucial", "a testament to"), "not just X, it is Y" reframes, decorative triplets, vague attribution ("studies show"), "it is important to note" asides, and formatting habits (no emoji as structure, no boldface as decoration). State the fact. The fact carries itself. Replace: utilize → use, prior to → before, in the event that → if, e.g. → for example. American spelling.

WARNINGS. Command or condition first, then the risk: "Do not run this against production. The command deletes rows."

NEVER TOUCH. Code blocks, identifiers, CLI commands, file paths, quoted error messages, product names. Each counts as one word toward sentence limits. Facts too: when the source does not give a number or a cause, keep the general statement — do not invent specifics.

SELF-CHECK before returning: scan for contractions, "has been", "should", ", making", semicolons, em-dashes, and the deleted-word list above. Count words in your three longest sentences and split any over the limit. Collapse synonym rotation.

REPLIES TO THE USER. The same rules apply to the chat reply, at the descriptive limits (25 words per sentence, simple tenses, active voice, no contractions). Start with the answer or the result. If a concept term is necessary, define it in a few words. Do not restate the request. Keep the whole reply to 5 sentences or fewer, code and lists excluded. Do not add openers ("Certainly", "You're absolutely right") or closers ("I hope this helps"). Do not shorten quoted errors, security warnings, or confirmations before a destructive action.

STRICT MODE. If the user names STE, ASD-STE100, or compliance, also apply the STE dictionary to the document: "make sure that" for check/verify/confirm, "operate" for run, "do" for execute, "show" for display, "but" for however, "because" for since. Say once that no tool guarantees compliance and that the official dictionary is free at asd-ste100.org.

Do not apply these rules to marketing copy or brand writing.

In any markdown that will be rendered (chat responses, PR/issue bodies, reports, docs),
escape delimiter characters used literally, since two of them in one paragraph silently
corrupt everything between: `\~` for "approximately" tildes (`~...~` is strikethrough in
GFM) and `\$` for dollar amounts (`$...$` is inline LaTeX math in GitHub and VSCode
preview). Literal `~`/`$` in code stay inside backticks instead.

---

## Preflight (runs first)

**Stop and say so when a required check fails.**

- Resolve the **target repo set**: if the invocation input has `--repo`, resolve to that single
  repo. Otherwise, resolve to both rows in **Targets**. For each, split `OWNER=${REPO%/*}` /
  `NAME=${REPO#*/}` and resolve `CLONE` with the search order in **Targets**.
- **Set `GH_TRANSPORT` before any other GitHub call. Read
  [../shared/github-transport.md](../shared/github-transport.md) first.** It owns the probe, the
  per-repo rule, the `cli` to `mcp` operation mapping, and the GraphQL fallback. Probe per repo:

  ```bash
  # `gh auth status` and `gh api user` both pass on a sandbox where every repo call 403s.
  gh api "repos/$OWNER/$NAME" --jq .id >/dev/null 2>&1 && GH_TRANSPORT=cli || GH_TRANSPORT=mcp
  ```

  A failed `gh` probe in a Routine run is normal, not a defect. **Stop only when neither transport
  works.** Capture the login through the transport: `ME` is the authenticated user.
- Commit each repo's fixes in its **local clone**. Per clone, confirm it exists and its `origin`
  matches the repo. A clone is required to *fix*. Without one, **triage and reply** for that repo
  and say fixes were skipped. Resolve and check each clone **independently**: one missing clone
  disables fixes for that repo only, not the whole run.
- Each clone's working tree must be **clean** (`git status --porcelain`) before you check out PR

From ptrandev/agent-skills, MIT.

More from ptrandev/agent-skills