Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

review

Sterne4

Forks0

Aktualisiert25. Juni 2026 um 17:41

Reviews current branch changes: reads the actual diff, produces structured feedback (Blockers / Concerns / Nits), asks targeted questions, then applies fixes on approval. TRIGGER when: user says "/review", "review this PR", "review my changes", "code review", "review the diff", "PR review", "review branch", "what do you think of my code", "look at my changes", "give me feedback on this". DO NOT USE when: user wants to understand what changed without requesting feedback; user asks for explanation only; no commits exist on current branch beyond main.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

bsene

bsene/skills

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

Softwarequalitätssicherungsanalysten und -testerInformatik- und Mathematikberufe·SOC 15-1253

SKILL.md

readonly

name

review

description

/review

Workflow

Run git diff main...HEAD — get ACTUAL diff, never reconstruct
Produce structured review (severity tiers below)
Ask ≤5 grill-me questions (one per key design decision)
On approval: apply Blocker fixes → run tests → run lint → commit (conventional message)

Severity Tiers

Tier	Criterion	Required Action
Blocker	Bug, security hole, data loss, broken invariant	Fix before merge
Concern	Design flaw, missing test, perf issue	Discuss + likely fix
Nit	Style, naming, minor duplication	Optional

Output Format

## Blockers
- `src/auth.ts:42` — expiry check uses `<` not `<=`; off-by-one passes expired tokens

## Concerns
- No test for error path in `processPayment()`

## Nits
- `userData` → `user` (same meaning, shorter)

## Questions
1. Why is `retryCount` hardcoded to 3 — should this be config?

Integrated Example

Input: user says "/review my changes".

Step 1 — get the ACTUAL diff (never reconstruct from memory or from the chat history):

$ git diff main...HEAD
--- a/src/cart.ts
+++ b/src/cart.ts
@@ -8,7 +8,7 @@ export function total(items: Item[], coupon?: Coupon) {
-  const sum = items.reduce((a, i) => a + i.price, 0);
+  const sum = items.reduce((a, i) => a + i.price * i.qty, 0);
   if (coupon) return sum - coupon.amount;
   return sum;
 }

Step 2 — structured review against the real lines (note the coupon.amount guard the diff revealed — reconstructing would have missed it):

## Blockers
- `src/cart.ts:11` — coupon can drive total negative; clamp with `Math.max(0, sum - coupon.amount)`

## Concerns
- No test covers the new `qty` multiplication path

## Questions
1. Should a coupon larger than the cart be an error, or just clamp to 0?

Step 3 — on approval: apply the Blocker fix, run tests, run lint, then commit with a conventional message (fix(cart): clamp coupon discount at zero).

Guardrails

Never skip diff step — reconstructed diffs miss context and whitespace changes
Grill-me questions cover design intent only, not style
Commit only after approval + green tests + clean lint

Mehr aus diesem Repository

gleiches Repository

simple

bsene/skills

Use this skill whenever writing new code, proposing a bugfix, reviewing a PR/diff, or discussing whether to add an abstraction, config layer, plugin system, or generic mechanism. Also trigger for architecture/design discussions, is this too complex" questions, or any point where Claude is about to suggest introducing a new abstraction layer. The core stance — code is written for humans to read, not as an artwork to admire — optimize for affordance (like a road sign, instantly readable) rather than elegance or cleverness. Trigger even if the user doesn't name "simplicity" explicitly — e.g. "should I make this configurable", "quick fix for this bug", "review this PR", "should I abstract this into a helper", "this codebase feels messy".

2026-07-264

typescript

bsene/skills

TypeScript-specific best-practices and rule enforcement — type safety, runtime validation, error handling, and TS-only conventions. Routes to type-system and Zod sub-skills, the `javascript` skill for JS-foundation rules, and `oop-principles` for design patterns and SOLID. TRIGGER when: language (TypeScript, TS, .ts, .tsx, idiomatic TypeScript), type-system (discriminated unions, generics, utility types, make illegal states unrepresentable, type narrowing), safety (strict mode, any vs unknown, ts-expect-error, ts-ignore, type assertions), runtime (Zod, schema validation, runtime type checks, parse/safeParse), errors (error handling without throwing, union return errors, Result type), ts-conventions (readonly modifier, return type annotations, interface prefix, `as const`), contracts (domain vs DTO, monorepo types, API contract types). DO NOT USE when: user asks generic JS questions with no TS angle — use `javascript` instead.

2026-07-264

typescript-type-system

bsene/skills

Deep dive into TypeScript's type system — narrowing, discriminated unions, mapped types, conditional types, type guards, branding, and escape hatches. TRIGGER when: user asks about unknown vs any, type narrowing, discriminated unions, exhaustiveness checking, mapped types, conditional types, infer keyword, user-defined type guards, type branding, companion object pattern, as const, escape hatches, type assertion, how do I narrow a type, how do I write a type predicate, how to create nominal types, how to prevent structural aliasing, make illegal states unrepresentable, illegal states, state machine types, entity lifecycle types, optional field anti-pattern, discriminated union state modeling, interface vs type alias, when to use interface vs type, enum best practices, typescript enum, const enum, readonly property, ReadonlyArray, lazy object initialization, barrel exports, when to use generics, generic naming conventions, no interface prefix. DO NOT USE when: runtime/schema validation at boundaries (parsing e

2026-07-264

typescript-zod

bsene/skills

Zod v4 best practices — schema design, error handling, transforms, coercion, branded types, and boundary validation. TRIGGER when: user mentions zod, zod validation, zod schema, zod v4, zod parse, zod transform, zod coerce, zod branded types, zod error handling, runtime validation, validate API response, schema composition, zod object, zod mini, zod infer, zod v3 to v4, migrate from zod v3, upgrade zod, zod breaking changes. DO NOT USE when: the question is pure compile-time typing with no runtime validation (discriminated unions, generics, narrowing, `as const`) → use `typescript-type-system`.

2026-07-264

git-hero-git-guru

bsene/skills

Expert Git assistant that answers questions about Git concepts, commands, workflows, and best practices — both in French and English. Use this skill whenever the user mentions Git, version control, commits, branches, merges, rebases, conflicts, stash, push/pull, remotes, history rewriting, or anything related to source code versioning. Also trigger when users say things like 'comment faire un rebase', 'I messed up my history', 'explain branching strategies', 'how do I undo a commit', 'what is the difference between merge and rebase', 'git tips', 'commit message best practices', or any git-related question — even phrased casually or in French. DO NOT USE when: choosing a commit-message emoji → use git-hero-gitmoji; designing/optimizing GitLab CI pipelines → use git-hero-gitlab-dag; non-Git version control (SVN, Mercurial, Perforce).

2026-07-264

git-hero

bsene/skills

Git best practices — commit discipline, branching/history hygiene, safety, and CI/CD pipelines. Routes to `git-guru` (expert Q&A), `gitmoji`, and `gitlab-dag` sub-skills. TRIGGER when: commits (Conventional Commits, atomic commits, commit message format, commit hygiene), history (branch naming, rebase vs merge, clean git history, interactive rebase, history management), safety (force push safety, recover lost commits, reflog, reset), CI/CD (GitLab CI, pipeline optimization, DAG, .gitlab-ci.yml), emoji (gitmoji, commit emoji, "quel emoji pour ce commit"), setup (git configuration, "bonnes pratiques git", "comment faire un rebase", "configure git properly"). DO NOT USE when: user needs a single one-shot git command answer — let Claude answer directly.

2026-07-264

name

review

description

/review

Workflow

Run git diff main...HEAD — get ACTUAL diff, never reconstruct
Produce structured review (severity tiers below)
Ask ≤5 grill-me questions (one per key design decision)
On approval: apply Blocker fixes → run tests → run lint → commit (conventional message)

Severity Tiers

Tier	Criterion	Required Action
Blocker	Bug, security hole, data loss, broken invariant	Fix before merge
Concern	Design flaw, missing test, perf issue	Discuss + likely fix
Nit	Style, naming, minor duplication	Optional

Output Format

## Blockers
- `src/auth.ts:42` — expiry check uses `<` not `<=`; off-by-one passes expired tokens

## Concerns
- No test for error path in `processPayment()`

## Nits
- `userData` → `user` (same meaning, shorter)

## Questions
1. Why is `retryCount` hardcoded to 3 — should this be config?

Integrated Example

Input: user says "/review my changes".

Step 1 — get the ACTUAL diff (never reconstruct from memory or from the chat history):

$ git diff main...HEAD
--- a/src/cart.ts
+++ b/src/cart.ts
@@ -8,7 +8,7 @@ export function total(items: Item[], coupon?: Coupon) {
-  const sum = items.reduce((a, i) => a + i.price, 0);
+  const sum = items.reduce((a, i) => a + i.price * i.qty, 0);
   if (coupon) return sum - coupon.amount;
   return sum;
 }

Step 2 — structured review against the real lines (note the coupon.amount guard the diff revealed — reconstructing would have missed it):

## Blockers
- `src/cart.ts:11` — coupon can drive total negative; clamp with `Math.max(0, sum - coupon.amount)`

## Concerns
- No test covers the new `qty` multiplication path

## Questions
1. Should a coupon larger than the cart be an error, or just clamp to 0?

Step 3 — on approval: apply the Blocker fix, run tests, run lint, then commit with a conventional message (fix(cart): clamp coupon discount at zero).

Guardrails

Never skip diff step — reconstructed diffs miss context and whitespace changes
Grill-me questions cover design intent only, not style
Commit only after approval + green tests + clean lint