agentleFS
ruverdruverd/bulma/skills/bulma-reviewer/SKILL.md

bulma-reviewer

Skill1 starsChanged 51 days agoMITView on GitHub

Graph: review a PR/branch via bulma-code-review, classify CI/test failures, optionally bus a REVIEW_RESULT. Use when /reviewer, /bulma-reviewer, $bulma-reviewer, or a REVIEW_REQUEST envelope arrives.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Every verdict body includes Model and Reasoning effort rows identifying the executing reviewer's actual settings, or unknown per …

    line 40
  2. Very specific:

    Do not defer solely because CI could not be read.

    line 51
  3. Distinctive:

    After posting the verdict, remove this job's clean review-only checkout via JOBS.md review cleanup.

    line 55
  4. Very specific:

    Does not spawn developer/qa unless the user asks after the report — then write REVIEW_REQUEST is inbound only.

    line 59
  5. Very specific:

    Not the fd node bulma-fd-reviewer.

    line 63

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Bulma Reviewer (graph)

Orchestrator. Never merge. Chat: bulma-memory. Apply Kevin for human-facing communication.

REQUIRED: GRAPH.md · STATE.schema.md · bus PROTOCOL.md · skill bulma-code-review · bulma-memory · DISK.md (.bulma-* is global, never git root)

Init .bulma-reviewer/STATE.md. Walk GRAPH (admit first). code_review is the engine: spec-first, patch bind, high-risk critic. Its preflight reads all review context before pass selection and again before publication, pins the reviewed head, and verifies CI execution. A sensitive-path list stays in the private job report and does not defer. An unresolved thread whose author approved this head is not an open concern, and neither is a dismissed change request. Another reviewer's open change request still gets a code review, then a DEFER review_pending when the diff is clean. Never dismiss another review or approve over a concern from someone who did not approve this head. Every review POST runs behind the engine's scripts/gate.py; an APPROVE it rejects is never sent. The engine dismisses its own approval only when a new head gets REQUEST_CHANGES for a code defect. Verdicts are APPROVE, REQUEST_CHANGES or DEFER; never a COMMENT review, even when another bot approved. CI that cannot be read is a DEFER ci_unknown (CI cell not verified (tooling)) unless the diff has a defect. Review preserves the user's checkout. Local checks use isolated checkouts; regression claims distinguish source inspection from executed tests. Changes that depend on another deployment include counterpart and rollout checks via the engine's evidence rules. Every verdict body includes Model and Reasoning effort rows identifying the executing reviewer's actual settings, or unknown per unavailable field. Second review while main is busy → worktree + general-purpose worker per PR. --force if CI red. Pending required CI allows pinned review, then waits with retained analysis (no PR comment) via wait_ci. CI is collected from GitHub Actions (gh run list -R <repo> --commit <head> and gh run view <id> -R <repo> --json jobs, plus --log-failed on a failed run) and cross-checked with statusCheckRollup { state } on the head commit. Never use gh pr checks or the check-runs / check-suites REST endpoints. If the Actions list and the rollup query both fail, including HTTP 403, continue the review and mark CI unverified. Do not defer solely because CI could not be read. Draft / conflict / CI-red DEFER is expected, and the draft gate is unchanged. Cursor and Claude invoke /bulma-reviewer. Codex invokes $bulma-reviewer. Worktree and branch rules: JOBS.md §Worktree. After posting the verdict, remove this job's clean review-only checkout via JOBS.md review cleanup. Pending CI or failed publication keeps it for resume.

Does not spawn developer/qa unless the user asks after the report — then write REVIEW_REQUEST is inbound only; outbound fix = tell the user or write PR_BUG_FIX only if authorized and the issue is the PR.

Not the fd node bulma-fd-reviewer.

Verified external concerns feed FEEDBACK.md: attribute actual stage gaps, save scoped prevention, and draft only actionable improvement tasks. A request for changes or LSTM invocation alone proves no miss. Issue publication requires authorized policy and an exact destination.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.