Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

Loslegen

clean-code-review

Sterne2

Forks0

Aktualisiert7. Juni 2026 um 20:45

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

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	clean-code-review
description	Multi-agent clean code audit — each principle gets its own agent

Proportionality gate

Check diff size first:

> 50 lines changed OR > 3 files touched → full sub-agent audit below.
Otherwise → self-scan inline. One pass, same principles, no sub-agents. Tag violations you find.

Agents (full audit only)

Launch parallel sub-agents, each scanning files touched by the current change + immediate surroundings.

SRP — functions doing two jobs, classes with multiple reasons to change, mixed I/O and logic.
DRY — copy-pasted blocks, duplicated constants, near-identical functions, repeated conditionals.
Naming — unclear/misleading names, generic names (manager/handler/processor), no intent revealed.
Coupling — concrete deps constructed inline, shared mutable state.
Dead code — unused functions, unreachable branches, commented-out code, stale imports.
KISS — unnecessary complexity, over-engineered abstractions, premature generalisation. 5-whys each finding. Can't justify it → violation.
BOUNDARY — contract-not-implementation coupling across module/system seams.
- Consumer imports a concrete type from another module's internals instead of its published face (client, facade, package root, all).
- Signatures, return types, or DI wiring name a concrete impl where the published contract belongs — so swapping the impl forces edits in the consumer.
- Remote/service dep constructed against a specific node/version/impl rather than routed through its gateway/client abstraction.
- Foreign bounded-context model used raw across the seam, no translation (missing ACL).
- Dependency points toward the more-volatile side (stable code depending on volatile concretes).

BOUNDARY gate (inverse of KISS)

Fire ONLY where a real seam exists: a cross-system or cross-context call, a trust/security perimeter, or a swap that is actual or credibly imminent. Each finding must name the decision the boundary lets change independently. Can't name one → don't flag — and flagging it anyway is itself a KISS violation.

Each agent

Reports: file, line range, description, severity (0–1).
Ignores: test boilerplate, framework-mandated patterns, pre-existing issues outside the diff.

Consolidation

For each violation scoring > 0.5:

// TODO: clean-code - <0-1 score> - <SRP|DRY|NAMING|COUPLING|DEAD|KISS|BOUNDARY>: <description>

Add at the violation site. Violations you introduced this session scoring > 0.5 → fix immediately.

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

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

change-review

flying-dice/pseudoscript

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

2026-05-282

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	clean-code-review
description	Multi-agent clean code audit — each principle gets its own agent

Proportionality gate

Check diff size first:

> 50 lines changed OR > 3 files touched → full sub-agent audit below.
Otherwise → self-scan inline. One pass, same principles, no sub-agents. Tag violations you find.

Agents (full audit only)

Launch parallel sub-agents, each scanning files touched by the current change + immediate surroundings.

SRP — functions doing two jobs, classes with multiple reasons to change, mixed I/O and logic.
DRY — copy-pasted blocks, duplicated constants, near-identical functions, repeated conditionals.
Naming — unclear/misleading names, generic names (manager/handler/processor), no intent revealed.
Coupling — concrete deps constructed inline, shared mutable state.
Dead code — unused functions, unreachable branches, commented-out code, stale imports.
KISS — unnecessary complexity, over-engineered abstractions, premature generalisation. 5-whys each finding. Can't justify it → violation.
BOUNDARY — contract-not-implementation coupling across module/system seams.
- Consumer imports a concrete type from another module's internals instead of its published face (client, facade, package root, all).
- Signatures, return types, or DI wiring name a concrete impl where the published contract belongs — so swapping the impl forces edits in the consumer.
- Remote/service dep constructed against a specific node/version/impl rather than routed through its gateway/client abstraction.
- Foreign bounded-context model used raw across the seam, no translation (missing ACL).
- Dependency points toward the more-volatile side (stable code depending on volatile concretes).

BOUNDARY gate (inverse of KISS)

Each agent

Reports: file, line range, description, severity (0–1).
Ignores: test boilerplate, framework-mandated patterns, pre-existing issues outside the diff.

Consolidation

For each violation scoring > 0.5:

// TODO: clean-code - <0-1 score> - <SRP|DRY|NAMING|COUPLING|DEAD|KISS|BOUNDARY>: <description>

Add at the violation site. Violations you introduced this session scoring > 0.5 → fix immediately.