Brooklyn skills

Brooklyn skills: 25 portable agent skills for pull requests, triage, cleanup, UI checks and research

  • 215 ★ on the repository
  • Last commit
  • MIT
Skill

Extended access

Why this level

  • The skills run git, gh and tests, and `free-disk-space` deletes files on disk
  • The `triage` fix path can enable auto-merge on pull requests
All reasons and checks

outthislife/brooklyn-skills

Install

In your terminal, with SkillFoxx CLI

npx skillfoxx add skills/brooklyn-skills

Detects the agents on your machine, shows the access level and pins the version.

Other ways to install

Access and checks

How we review

Extended accessThe tool runs code or makes network calls and only reads external data.

  • The skills run git, gh and tests, and `free-disk-space` deletes files on disk
  • The `triage` fix path can enable auto-merge on pull requests

This is third-party code. Review the repository files before installing.

What it does

The repository holds 25 `skills/<name>` folders with a `SKILL.md` file and no hooks, adapters or setup scripts. You give the agent the repository link and ask it to install the skills you need. In Hermes Agent you can point `skills.external_dirs` at the folder and `git pull` becomes the update path. Most skills serve the edit and pull request loop: `work`, `clean`, `cpr`, `pr-update`, `pr-ready`, `pr-triage`, `stacked-pr`, `ticket-ship`, `babysit` for watching CI and `list-open-work` for a list of open MRs. The `triage` skill checks an incoming report against the main branch, removes duplicates and gives a verdict. For interfaces there are `ui-only`, `ui-system`, `visual-verify` and `modern-web-guidance`. The rest cover `audit-only`, `perf`, `runtime-debug`, `research`, `no-tropes` for prose, `engraved-figures` for monochrome scientific plates, `notarize-mac`, `free-disk-space`, `shop-board` and `draft-tweet`. The `defaults.md` file sets which skills run in pairs without being asked.

Who it is for. Developers who hand pull request chores, CI watching and issue triage to an agent and want one set for Claude Code, Codex and Hermes Agent.

Good fit when

  • A pull request is red with three Copilot comments and `pr-ready` should bring it to green
  • An issue arrives and has to be checked on the main branch and deduplicated through `triage`
  • A UI gets fixed in pieces and `ui-only` and `visual-verify` check the result
  • A developer machine needs disk space freed with the `free-disk-space` skill

Not a fit when

  • The project needs only CI watching or only triage: a set of 25 skills is too much
  • You need supported skills with guarantees: the author builds the set around his own workflows
  • The team forbids auto-merging pull requests: `triage` turns it on for low-impact changes

Example request

Install the pr-triage and pr-ready skills from this repository and bring my pull request to green CI

Limitations

  • The skills are shaped around the author's workflow: branches, MRs, tickets and CI. In your repository read and adjust them first.
  • The README `triage` fix path turns on auto-merge for low-impact PRs when authorized. Changes to the UI and core stay manual.
  • `shop-board` gathers store pages into one picking board and `free-disk-space` deletes files. Run these only on explicit request.
  • The `triage` skill needs `work`, `cpr`, `clean`, `pr-update`, `pr-ready`, `no-tropes`, `ui-only` and `ui-system` installed beside it.

How to disable. Delete the `skills/<name>` folders from the agent skills directory. If you connected through `skills.external_dirs` in Hermes Agent, remove the line from `~/.hermes/config.yaml`.

FAQ

How do I install Brooklyn skills?

Give the agent the repository link and ask for the skills you need, for example `pr-triage` and `pr-ready`. The agent copies each `skills/<name>` folder whole so the `references` files stay in place.

Do I need slash commands?

No. The leading slash is shorthand, and the agent matches a skill by the description in `SKILL.md`, so `/clean`, `clean` and "clean it up" reach the same skill.

How do I use the set in Hermes Agent?

Clone the repository and add the `skills/` path to `skills.external_dirs` in `~/.hermes/config.yaml`. Updating then means `git pull`, and each skill shows up as a slash command.

What does `triage` do?

It checks an incoming report against the main branch, merges duplicates and gives a verdict. With the "fix and ship" note it gathers related fixes into one maintainer PR.

Are the skills linked?

Some are: `clean` runs before a PR handoff, `no-tropes` on prose and `triage` leans on `work`, `cpr` and others. The pairing rules sit in `defaults.md`.

Discussion

No questions or reviews yet.

Skills

A library of 30-plus instruction skills for coding agents: planning, building, testing, hallucination guards and shipping

SkillMinimal access217Repository stars

Builder Skills

Skills for agents

A set of small skills from Builder.io for agent work habits: visual plans and diff recaps, docs-first checks, cross-agent review and clean status updates

SkillExtended access4.7KRepository stars

A set of independent skills against drift in large codebases: hard-cut, root-cause tracing, lean testing and CI right-sizing.

SkillMinimal access140Repository stars

The author's personal set: shared agent rules and dozens of skills for GitHub, the browser, macOS, messaging and releases, plus a sync script

SkillBroad access7.5KRepository stars

A skills library for Claude Code, Cursor and Codex: team code review, TDD, stacked PRs and repository readiness scoring

PluginExtended access72Repository stars

skills-npm links agent skills shipped in your dependencies in node_modules and listed in the skills field of package.json

CLIExtended access582Repository stars

README in short

The README explains that the set is made of portable `SKILL.md` files with no agent binding and shows how to hand the repository to an agent or wire it into Hermes Agent. It follows with example phrases for each skill and a note on chaining skills.

README badge

Original SKILL.md

---
name: pr-ready
description: >-
  Clear everything blocking an existing PR/MR from merging — rebase onto the
  default branch, get CI green, and resolve review threads (Copilot and human).
  Use for "rebase on main", "make CI green", "fix CI/CD", "address the reviews",
  "address Copilot", "review-loop", or "get this mergeable".
---

# PR Ready

An open PR/MR isn't mergeable. Two things block it — a **stale base or red CI**,
and **open review threads**. Same loop for both: fix, push, re-query the forge,
repeat. Handle whichever is blocking; usually that's both.

No feature work. No drive-bys.

## Rebase + CI

1. Find the worktree for this PR (or create one per repo convention). Prefer an
   existing worktree the user already has.
2. `git fetch origin <default>` (usually `main`).
3. Honor repository history rules before choosing an update strategy. Where force pushes are forbidden or the user requires a merge, merge `origin/<default>` into the existing branch without rewriting commits. Otherwise rebase onto `origin/<default>`. Resolve conflicts by reading both sides' intent and regression tests; shared callback code must preserve newer callback-once behavior as well as the PR's guards.
4. Push (`--force-with-lease` if the rebase rewrote history).
5. Watch CI. Fix **failures caused by the rebase or existing breakage on this
   branch** — nothing else.
6. Flaky upstream on the default branch → say so. Don't paper over it with
   unrelated test deletes.
7. Verify `process.execPath` in the same execution mode as MR tests, using the repository's package manager. Background login shells can replace an earlier PATH export, so select the project's declared Node version inside the launched command. A newer runtime can shadow happy-dom localStorage or remove util.isDate; rerun unchanged failing tests under the supported runtime before editing application code.
8. For merge commits, old lint-staged hooks can autoformat every upstream file in the index. Run lint on the PR delta and the repository precommit checks explicitly, preserve upstream files, and document any one-command hook bypass used solely to prevent unrelated formatting. Never call that bypass a substitute for verification. Do not assume `HUSKY_SKIP_HOOKS=1` is honored: inspect the hook output. Legacy hook `git add` can also include unstaged edits to already-staged files. Reconcile the resulting commit against the pre-merge PR file set plus intended fixes, and restore unrelated suppression-file pruning rather than publishing incidental changes.

- Unset `npm_config_prefix` on MR commit processes as well as test processes so Husky’s nvm hook can select Node 18. If legacy lint-staged concurrently runs `git add` for JS and Vue groups and races on index.lock, first verify the lock has disappeared and review the staged diff. Split the staged extension groups into additive commits if needed; do not delete a live lock, rewrite published history, or bypass the hooks to hide the race.

## CI-only failures

- Distinguish a V8 heap-limit abort from a container OOM before changing CI resources. Measure the failing typecheck with the supported runtime and extended diagnostics, then verify a bounded heap override scoped to that job; keep the typecheck enabled.
- Reproduce repository-wide duplicate scans against a tracked `git archive` snapshot, not a working tree full of local build output. Attribute clones before changing configuration. Machine-generated API artifacts should be regenerated and drift-checked, not manually deduplicated; preserve the authored-code threshold when excluding those artifacts.
- Verify the package script's actual scope before calling a run the full backend suite. A package's `test` script may run unit tests only, while `exec jest --runInBand` exercises every configured Jest project. Require the completed project/suite summary, not a partial log.

## Interrupted repairs

- Reconcile the current remote head, worktree diff, and saved test evidence before resuming an interrupted repair. Preserve an existing merge and relevant uncommitted fixes; do not repeat a repair already pushed by another worker. A partial test log without a completed runner summary is not a pass.
- When a merge exposes tests for deliberately deleted files, verify the deletion commit and remaining production references before retiring those assertions. Keep active replacement coverage and record the before/after failure evidence; do not restore retired application code or delete unrelated tests merely to turn CI green.

## Review threads

Report a problem