Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

code-review-burntsushi

Estrelas1

Forks0

Atualizado28 de junho de 2026 às 03:58

Review code through BurntSushi's "honest machinery" lens — asking whether APIs, invariants, error contracts, performance boundaries, and defaults accurately represent reality. Use when reviewing library APIs, patches that change complexity or cost, dependency additions, or when the user asks "is this API honest?", "will this panic?", "is the cost visible?", "does this scale?", or "are the defaults right?". Works across languages; see REFERENCE.md for Rust-specific elaborations. Do NOT use for deletion/anti-bloat review (use code-review-russ-cox) or product-vs-library tradeoffs (use code-review-mitsuhiko).

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

wilbeibi

wilbeibi/wilbeibi-skills

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

Explorador de arquivos

2 arquivos

SKILL.md

readonly

name

code-review-burntsushi

description

code-review-burntsushi

"Is there a reasonable expectation that the code will behave as advertised?" — BurntSushi

A code review should ask: is this code honest about its invariants, failure modes, costs, and semantics? Not just: does it work?

Quick start

Paste a diff or file and say "burntsushi review" or "honest review". Walk the ten general axes in REFERENCE.md, add the two Rust-specific axes if the code is Rust, then emit findings.

Steps

State the change — what is this patch doing in one sentence? If unclear, ask first.
Walk all ten general axes from REFERENCE.md in order. Flag every axis with a finding.
If Rust: also apply the two Rust-specific axes (encoding invariants, ownership/allocation).
Emit findings first using the output contract below.

Output Contract

Lead with findings, ordered by severity. Use Must fix, then Consider, then Open questions; omit empty sections.
Prefix findings with [Axis N | file:line].
Each finding names the invariant, cost, or failure mode and gives one concrete alternative.
Add a brief Summary after findings. Do not add praise unless the user asks.

Tone rules

Name the invariant, failure mode, or hidden cost precisely.
Suggest one practical alternative per finding.
Do not nitpick style, naming, or formatting unless it obscures correctness or cost.
Do not complain about unwrap/assertions on static programmer invariants — only flag panics when the failure source is runtime/user/environment.

Reference

REFERENCE.md — all axes with examples, model comments, and skill rules.

Mais deste repositório

mesmo repositório

grok-repo

wilbeibi/wilbeibi-skills

Understand an unfamiliar codebase — either a full briefing (purpose, architecture, seams, design taste, commit-history rationale, standout code) or a scoped dataflow trace of one subsystem. Use when asked to "understand this repo", "explain this codebase", "give me a tour", "how does X work here", "trace how data flows", "where does this value come from", or "why is it designed this way". Do NOT use to assess repo health/popularity (use repo-eval) or to review a diff (use a code-review skill).

2026-07-101

code-review-russ-cox

wilbeibi/wilbeibi-skills

Review a change or audit existing code through the Russ Cox lens — necessity, layering, minimal seams, error/logging/testing discipline, and anti-bloat. Use when reviewing diffs, new features, or dependency additions, or when asked to "audit this package", "refactor/polish this code", "find design, implementation, or style problems", "do we need this?", or "is this too complex?". Do NOT use for public API shape or product-vs-library tradeoffs (use code-review-mitsuhiko) or invariant/cost honesty (use code-review-burntsushi).

2026-07-101

obsidian-capture

wilbeibi/wilbeibi-skills

Append quick captures — todos with due dates, log lines, learnings, reflections — to the right section of Obsidian daily (DailyPlan/) and weekly (Weekly/) notes. Use when asked to "add a todo", "note this down", "log this", "capture an idea", "due Friday", or to record something fun or a weekly reflection. Do NOT use for searching notes (use obsidian-vault-search) or for creating standalone long-form notes.

2026-07-091

obsidian-vault-search

wilbeibi/wilbeibi-skills

Search an Obsidian vault three ways — Meilisearch for topic and fuzzy queries, ripgrep for exact strings/tags/task glyphs, and a date-aware helper for natural-language dates and overdue math. Use when finding notes about a topic, half-remembered ideas, recent writing, tagged content, or due/overdue/high-priority tasks in a local Markdown vault. Do NOT use to add or edit notes (use obsidian-capture).

2026-07-091

write-readme

wilbeibi/wilbeibi-skills

Write or critique a README for an open-source project (library, CLI tool, or agent tool) with an impatient-reader lens: concrete value first, shortest path to use, no duplicated claims, and reference material only when it earns space. Use when the user asks to "write a README", "draft a README", "review my README", "improve my README", or starts a new lib/tool and needs documentation. Do NOT use for internal service docs, monorepo root READMEs, or non-public projects.

2026-07-091

write-cli

wilbeibi/wilbeibi-skills

Design or review command-line interface shape — flags, subcommands, help, errors, and output contracts — against established CLI conventions (clig.dev, POSIX, GNU). Use when the agent is about to write a CLI tool, add a subcommand, design flag names, review --help output, or evaluate CLI UX. Do NOT use for TUI/full-screen terminal apps, GUI design, or web API design.

2026-06-281

name

code-review-burntsushi

description

code-review-burntsushi

"Is there a reasonable expectation that the code will behave as advertised?" — BurntSushi

A code review should ask: is this code honest about its invariants, failure modes, costs, and semantics? Not just: does it work?

Quick start

Paste a diff or file and say "burntsushi review" or "honest review". Walk the ten general axes in REFERENCE.md, add the two Rust-specific axes if the code is Rust, then emit findings.

Steps

State the change — what is this patch doing in one sentence? If unclear, ask first.
Walk all ten general axes from REFERENCE.md in order. Flag every axis with a finding.
If Rust: also apply the two Rust-specific axes (encoding invariants, ownership/allocation).
Emit findings first using the output contract below.

Output Contract

Lead with findings, ordered by severity. Use Must fix, then Consider, then Open questions; omit empty sections.
Prefix findings with [Axis N | file:line].
Each finding names the invariant, cost, or failure mode and gives one concrete alternative.
Add a brief Summary after findings. Do not add praise unless the user asks.

Tone rules

Name the invariant, failure mode, or hidden cost precisely.
Suggest one practical alternative per finding.
Do not nitpick style, naming, or formatting unless it obscures correctness or cost.
Do not complain about unwrap/assertions on static programmer invariants — only flag panics when the failure source is runtime/user/environment.

Reference

REFERENCE.md — all axes with examples, model comments, and skill rules.