Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

code-review

Étoiles25

Forks0

Mis à jour21 avril 2026 à 10:46

Guide for making code reviews. Use this when asked to make code reviews, or ask to use it before committing changes.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

maragudk

maragudk/fabrik

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name	code-review
description	Guide for making code reviews. Use this when asked to make code reviews, or ask to use it before committing changes.
license	MIT

Code review

Always start by inspecting the changes. If you're on the main git branch, typically the (staged) git diff. If you're on a different branch, the committed and uncommitted changes compared to the main branch.

Method

Please dispatch two subagents to carefully review the code changes. Tell them that they're competing with another agent. Make sure they look at both architecture and implementation. Tell them that whoever finds more issues wins honour and glory.

Surfacing issues

Signal-to-noise ratio matters more than completeness. When reporting back to the caller:

By default, only surface issues that both sub-agents independently found. Agreement between two reviewers is a strong signal that an issue is real.
Drop issues that only one sub-agent raised, unless the issue is serious -- e.g. a correctness bug, security flaw, data-loss risk, concurrency hazard, or significant architectural problem. Serious issues get surfaced even without corroboration.
Minor issues and nitpicks (style preferences, naming bikesheds, comment suggestions, micro-optimisations) should only be surfaced when both sub-agents flagged them.

State clearly in the report which issues had consensus and which are single-reviewer calls promoted for seriousness.

Plus depuis ce dépôt

même dépôt

maragudk/fabrik

ALWAYS invoke this skill as your FIRST action — before any Read, Write, Edit, or Bash — whenever a task involves Go in any way — creating or editing any `.go` file, `go.mod`, or `go test`; adding or changing handlers, structs, methods, interfaces, error handling, goroutines, channels, sqlc/database code, or gomponents views; or refactoring, reviewing, debugging, or testing Go. This is a hard requirement, not a suggestion — the user develops all Go through this skill, which encodes project-specific conventions (structure, error handling, testing, naming) that default Go habits violate. Do not start editing Go and consult it later — load it first. Skip only when no Go code is read or written (pure Python, shell, SQL, Dockerfiles, CI config, or conceptual Go questions with no code).

2026-06-2625

writing-clearly-and-concisely

maragudk/fabrik

Use when you write or revise a long-form document an audience will read—documentation, a README, a how-to or user guide, a spec, a design or decision doc, a blog post, a proposal, an announcement, or a standalone report or summary written for a person. Such writing should be clear, concrete, and tight, so draft it from the start by Strunk's Elements of Style (active voice; definite, specific, concrete words; omit needless words) instead of first-draft sprawl. Do NOT fire for short or code-adjacent text—commit messages, PR descriptions, release notes or changelogs, error messages, UI strings, code comments, config, version bumps, quick internal scratch notes, or the implementation diary. These exclusions win even when the text reaches an audience: a release note, changelog, or PR description is a working artifact, not a document drafted for readers.

2026-06-2525

git

maragudk/fabrik

Guide for using git with specific preferences -- branch names without `feat/`/`hotfix/` prefixes, backticks around code identifiers in commit messages, asking about GitHub issues to reference before committing. Use this whenever you branch, commit, or write a commit message -- not just when explicitly asked to "commit". These conventions aren't in your default knowledge and you'll get them wrong without consulting this skill.

2026-06-2225

one-at-a-time

maragudk/fabrik

Present output one unit at a time instead of dumping a list or wall of text. Use when the user says "one at a time", "/one-at-a-time", "one thing at a time", "go one at a time", asks you to slow down, to stop the wall of text, or to stop dumping everything at once -- either to redo output you just gave, or to pace the rest of a task.

2026-06-1825

observability

maragudk/fabrik

Guide for instrumenting and operating observable software systems. Use this skill whenever the user is adding or reviewing telemetry, instrumenting code with OpenTelemetry, working with traces/spans/metrics/logs/structured events, debugging production behavior, designing SLOs or alerts, setting up sampling or telemetry pipelines, choosing observability storage, or making code observable for humans or AI agents -- even if they don't say the word "observability". Triggers include "add tracing", "instrument this", "OTel/OpenTelemetry", "why is this slow in prod", "set up an SLO", "alert fatigue", "high cardinality", "structured logging", "wide events", and observability for LLM/agent applications.

2026-06-1825

gomponents

maragudk/fabrik

Building, rendering, or editing any HTML or UI in a Go application means using gomponents — ALWAYS invoke this skill as your FIRST action, before any Read, Write, Edit, or Bash. This fires for any view, page, layout, component, form, table, navbar, footer, or list that renders to HTML; any function returning a `Node`; anything in the `html` package; and converting HTML or templates into Go. It is a hard requirement — the user writes all HTML through gomponents, a pure-Go component library whose conventions (dot imports, `Node` composition, `Map`/`If`/`Iff`, `Group`, HTML5 documents) ordinary Go and HTML habits get wrong. Load it even when the Go skill also applies. Skip only when no HTML or view code is touched (pure database, handler, or business logic; plain `.css`/`.js`/`.html` files; conceptual questions with no code).

2026-06-1825

name	code-review
description	Guide for making code reviews. Use this when asked to make code reviews, or ask to use it before committing changes.
license	MIT

Code review

Method

Surfacing issues

Signal-to-noise ratio matters more than completeness. When reporting back to the caller:

By default, only surface issues that both sub-agents independently found. Agreement between two reviewers is a strong signal that an issue is real.
Drop issues that only one sub-agent raised, unless the issue is serious -- e.g. a correctness bug, security flaw, data-loss risk, concurrency hazard, or significant architectural problem. Serious issues get surfaced even without corroboration.
Minor issues and nitpicks (style preferences, naming bikesheds, comment suggestions, micro-optimisations) should only be surfaced when both sub-agents flagged them.

State clearly in the report which issues had consensus and which are single-reviewer calls promoted for seriousness.