원클릭으로 Manus에서 모든 스킬 실행

code-review-burntsushi

스타1

포크0

업데이트2026년 6월 28일 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).

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

wilbeibi

wilbeibi/wilbeibi-skills

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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.

이 저장소의 다른 Skills

같은 저장소

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.