Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

change-review

Sterne2

Forks0

Aktualisiert28. Mai 2026 um 22:43

Review a set of changes (the staged diff, or a branch's diff) for correctness — before committing, pushing, or as a standalone pass

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

flying-dice

flying-dice/pseudoscript

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	change-review
description	Review a set of changes (the staged diff, or a branch's diff) for correctness — before committing, pushing, or as a standalone pass

Review the change on its own merits. No session context assumed — the diff has to stand by itself.

Process

See exactly what changed — the staged diff (git diff --staged), or a branch diff (git diff <base>...HEAD), plus git status for new files the change depends on. Review only what's in the change set.
Read the diff in context — what changed, why. Open the surrounding code the hunks touch; a hunk that reads fine alone can still break its caller.
Run the checks the change touches — build, lint, typecheck, and the relevant tests for the affected area. Scope to what the diff affects; don't rebuild the world. If a pipeline already ran these for this exact revision, trust its result — don't re-run.
Devise unhappy-path scenarios (given/when/then) and run the ones the tests don't cover. A failed scenario → a full given/when/then in the finding so the author can turn it into a test.
Test gap — behaviour added with no test is a finding (issue), not a pass.
Report findings (format below). bug/issue block; nit/question don't.

Checklist

Pass, fail, or N/A — <reason>. No blanks.

Builds + affected tests pass (run, or confirmed green in a pipeline — not assumed)
New behaviour has tests
Destructive/edge-case paths considered
No silent reverts
No unrelated changes, no debug/WIP leftovers (dbg!, stray println!, .only, commented-out code)
Change does what its message/intent says

Comment format

**[type]** summary

detail

bug — breaks at runtime. Blocks.
issue — wrong but won't crash (missing test, edge case, leak). Blocks.
nit — non-blocking.
question — answer before proceeding.

Focus

Weight unhappy paths. The happy path probably works — the author just wrote it. Find where it falls apart: regressions, edge cases, error paths, concurrency, rollback safety, interface changes without migration, silent reverts, debug/WIP code sneaking in.

Ignore

Style a formatter/linter already enforces. "I'd do it differently." Re-running a check a pipeline already passed for this revision. Anything outside the change under review.

Mehr aus diesem Repository

gleiches Repository

pseudoscript

flying-dice/pseudoscript

Author and maintain PseudoScript (.pds) — C4-level architecture-as-code that compiles to diagrams and a doc site — as the single source of truth for spec-driven development. Use this skill whenever the user wants to model an application in PseudoScript, reverse-map / capture an existing app or codebase into a .pds model, drive development from a model (write the spec first, implement from it), capture business rules as code while keeping infrastructure (repositories, HTTP/controllers, persistence, queues, external APIs) as black boxes, write Gherkin-style `feature` behaviour specs, or reconstitute / generate a real implementation from a model. Trigger it on mentions of PseudoScript, `.pds`, "architecture as code", "C4 as code", "model the system", "spec-driven", "turn this app/codebase into pseudocode", or "what does the model say it should do" — even if the user doesn't name the language explicitly.

2026-06-242

clean-code-review

flying-dice/pseudoscript

Multi-agent clean code audit — each principle gets its own agent

2026-06-072

chaos-monkey

flying-dice/pseudoscript

Find the unhappy paths an existing Cucumber/BDD suite doesn't cover and write them up as new Gherkin scenarios in the feature files. Use whenever the user wants to harden, stress, or find gaps in Cucumber tests, .feature files, or Gherkin scenarios, or mentions a "chaos monkey", negative testing, edge cases, failure modes, or unhappy paths. Trigger even on a casual "think of ways to break this" or "what are we not testing?" about a BDD codebase.

2026-05-302

idiomatic-rust

flying-dice/pseudoscript

Write idiomatic, ownership-clean Rust. ALWAYS use this skill when writing or editing Rust — any .rs file, anything under crates/, Cargo.toml/Cargo manifests, or when the user asks to add a function, type, trait, test, or module in Rust. Grounds the model in established Rust idioms: error handling, ownership/borrowing, iterators, the type system, API design, and the clippy/rustfmt baseline. Trigger even when the user doesn't say "idiomatic" — any Rust authoring task qualifies.

2026-05-282

pre-commit

flying-dice/pseudoscript

Use before every git push — mandatory quality gate, no exceptions

2026-05-282

refactor

flying-dice/pseudoscript

Pick highest-scored clean-code TODO, fix it, stop. Loop handles repetition.

2026-05-282

name	change-review
description	Review a set of changes (the staged diff, or a branch's diff) for correctness — before committing, pushing, or as a standalone pass

Review the change on its own merits. No session context assumed — the diff has to stand by itself.

Process

See exactly what changed — the staged diff (git diff --staged), or a branch diff (git diff <base>...HEAD), plus git status for new files the change depends on. Review only what's in the change set.
Read the diff in context — what changed, why. Open the surrounding code the hunks touch; a hunk that reads fine alone can still break its caller.
Run the checks the change touches — build, lint, typecheck, and the relevant tests for the affected area. Scope to what the diff affects; don't rebuild the world. If a pipeline already ran these for this exact revision, trust its result — don't re-run.
Devise unhappy-path scenarios (given/when/then) and run the ones the tests don't cover. A failed scenario → a full given/when/then in the finding so the author can turn it into a test.
Test gap — behaviour added with no test is a finding (issue), not a pass.
Report findings (format below). bug/issue block; nit/question don't.

Checklist

Pass, fail, or N/A — <reason>. No blanks.

Builds + affected tests pass (run, or confirmed green in a pipeline — not assumed)
New behaviour has tests
Destructive/edge-case paths considered
No silent reverts
No unrelated changes, no debug/WIP leftovers (dbg!, stray println!, .only, commented-out code)
Change does what its message/intent says

Comment format

**[type]** summary

detail

bug — breaks at runtime. Blocks.
issue — wrong but won't crash (missing test, edge case, leak). Blocks.
nit — non-blocking.
question — answer before proceeding.

Focus

Ignore

Style a formatter/linter already enforces. "I'd do it differently." Re-running a check a pipeline already passed for this revision. Anything outside the change under review.