Maison

Skill

Révision du code

code-simplify

paulrberg/agent-skills

Cette compétence doit être utilisée lorsque l'utilisateur demande de « simplifier le code », « nettoyer le code », « refactoriser pour plus de clarté », « réduire la complexité », « améliorer la lisibilité », « rendre cela plus facile à maintenir », ou lorsqu’il demande à simplifier un code récemment modifié.

...Développer tout

Heure mise à jour 2 juillet 2026

# code-review # git # code-maintenance # Code ReviewGit & Version Control # code-simplification # code-refactoring # readability

À propos code-simplify

La compétence « code-simplify » est conçue pour simplifier le code existant tout en préservant son comportement d’exécution, ses interfaces publiques, ses effets secondaires et son intention opérationnelle. Elle aide les développeurs à réduire la complexité, à améliorer la lisibilité et à faciliter la maintenance du code sans introduire de modifications fonctionnelles. Cette compétence se concentre sur une refactorisation sûre et ciblée plutôt que sur des réécritures à grande échelle, garantissant ainsi la stabilité des entrées, des sorties, du comportement en cas d’erreur et des contrats sur lesquels le code s’appuie en externe. Elle est destinée aux situations où le code est devenu difficile à comprendre, trop imbriqué, dupliqué ou inutilement complexe.

Cette compétence détermine une portée appropriée en fonction des cibles fournies par l’utilisateur, des fichiers récemment modifiés ou des changements apportés au référentiel. Elle analyse le contexte environnant afin d’établir une référence comportementale avant d’effectuer des modifications. La simplification s’effectue via un processus structuré qui comprend l’aplatissement du flux de contrôle, l’amélioration de la clarté des noms, la réduction des doublons, la restructuration des transformations de données denses en étapes plus claires, ainsi que l’amélioration de la clarté des types ou des contrats le cas échéant. Le workflow privilégie les modifications mineures et réversibles, et respecte les conventions existantes du projet, les linters, les formateurs et les tests. Des règles de sécurité empêchent les modifications altérant le comportement, telles que la conversion d’API synchrones en API asynchrones, la suppression de mesures de sécurité opérationnelles ou la modification d’interfaces externes sans instruction explicite.

Cette compétence est utile pour les développeurs, les responsables de la maintenance et les équipes travaillant sur des bases de code en évolution qui souhaitent améliorer la qualité du code sans en modifier les fonctionnalités. Parmi les cas d’utilisation courants, on peut citer le nettoyage de code récemment modifié, la refactorisation pour améliorer la lisibilité, la réduction de la charge cognitive dans les fonctions complexes, la simplification de la logique imbriquée et la préparation du code en vue d’une maintenance à long terme. Elle est particulièrement précieuse dans les workflows de développement basés sur des dépôts où la vérification et la stabilité comportementale constituent des exigences importantes.

FAQ

Quand dois-je utiliser cette compétence ?

Utilisez-la lorsque vous souhaitez simplifier le code, améliorer sa lisibilité, réduire sa complexité, nettoyer du code récemment modifié ou faciliter la maintenance du code sans en modifier le comportement.

Cette compétence modifie-t-elle le comportement de l’application ou les API publiques ?

Non. Cette compétence est conçue pour préserver le comportement d’exécution, les contrats publics, les effets secondaires, les entrées, les sorties et la sémantique des erreurs sur laquelle s’appuient des éléments externes.

Cette fonctionnalité nécessite-t-elle un dépôt Git ?

Oui. Le workflow commence par vérifier le contexte du dépôt. Si le répertoire actuel n’est pas un dépôt Git, le processus s’arrête et demande à être exécuté à partir d’un dépôt Git.

Comment la compétence détermine-t-elle les fichiers à modifier ?

Elle utilise les cibles fournies par l’utilisateur lorsqu’elles sont disponibles. Sinon, elle se concentre sur les fichiers modifiés pendant la session et peut se rabattre sur les fichiers suivis et non suivis non validés s’il n’existe aucun fichier modifié pendant la session.

Y a-t-il des restrictions concernant les types de refactorisation effectués ?

Oui. La compétence évite les modifications qui changent le comportement, les réécritures à grande échelle, les abstractions inutiles, les changements entre les API synchrones et asynchrones, ainsi que la suppression des journaux, de la télémétrie, des conditions de sécurité, des tentatives de réessai ou de tout autre code important sur le plan opérationnel.

Voir sur GitHub

Code Simplify

Objective

Simplify code while preserving behavior, public contracts, and side effects. Favor explicit code and local clarity over clever or compressed constructs.

Arguments

Paths, patterns, a commit/range, or a scope phrase: used in Scope Resolution step 2.
--no-report: Skip the full user-facing report and return terse working notes for the caller.
--no-verify: Skip verification because a parent orchestrator will verify the final result separately.
Default: verify touched behavior and present the full report.

Scope Resolution

Resolve scope once, then treat the result as fixed for the rest of the run.

Verify repository context: git rev-parse --git-dir. If this fails, stop and tell the user to run from a git repository.
If the request names targets — file paths/patterns, a commit/range, a natural-language subset (e.g. "the parser changes"), or a resolved-scope fenced block with one repo-relative path per line — scope is exactly those targets. Map natural-language subsets to concrete paths before continuing.
Otherwise, scope is only session-modified files: files created or edited earlier in this session. Do not include other uncommitted changes.
If there are no session-modified files, or earlier conversation history is not visible in this context, fall back to all uncommitted files, running each command once:
- tracked: git diff --name-only --diff-filter=ACMR
- untracked: git ls-files --others --exclude-standard
- combine both lists and de-duplicate.
Exclude generated/low-signal files unless explicitly requested: lockfiles, minified bundles, build outputs, vendored code.
If scope resolves to zero files, report that and stop.
Emit the scope as a fenced code block tagged resolved-scope, one repo-relative path per line. The block is authoritative: do not re-run scope commands or revisit exclusions afterward.

Operating Rules

Preserve runtime behavior exactly. Keep inputs, outputs, side effects, and error behavior stable.
Prefer project conventions over personal preferences. Infer conventions from existing code, linters, formatters, and tests.
Make small, reversible edits. Avoid broad rewrites when targeted simplifications solve the problem.
Call out uncertainty immediately when behavior may change.

Workflow

1) Determine Scope

Apply the Scope Resolution section.

2) Build a Behavior Baseline

Read surrounding context, not only changed lines.
Identify invariants that must not change:
- function signatures and exported APIs
- state transitions and side effects
- persistence/network behavior
- user-facing messages and error semantics where externally relied on
Note available verification commands (lint, tests, typecheck).

3) Apply Simplification Passes (in this order)

Control flow:
- Flatten deep nesting with guard clauses and early returns.
- Replace nested ternaries with clearer conditionals.
Naming and intent:
- Rename ambiguous identifiers when local context supports safe renaming.
- Separate mixed concerns into small helpers with intent-revealing names.
Duplication:
- Remove obvious duplication.
- Abstract only when at least two real call sites benefit and the abstraction reduces cognitive load.
Data shaping:
- Break dense transform chains into named intermediate steps when readability improves.
- Keep hot-path performance characteristics stable unless improvement is explicit and measured.
Type and contract clarity:
- Add or tighten type annotations when they improve readability and safety without forcing broad churn.
- Preserve external interfaces unless asked to change them.

4) Enforce Safety Constraints

Do not convert sync APIs to async (or reverse) unless explicitly requested.
Do not alter error propagation strategy unless behavior remains equivalent and verified.
Do not remove logging, telemetry, guards, or retries that encode operational intent.
Do not collapse domain-specific steps into generic helpers that hide intent.

5) Verify

Skip when --no-verify is set. Otherwise verify per the Verification section below.

6) Report

Produce the Report section below.

Simplification Heuristics

Prefer explicit local variables over nested inline expressions when it reduces cognitive load.
Prefer one clear branch per condition over compact but ambiguous condition trees.
Keep function length manageable, but do not split purely for line count.
Keep comments that explain intent, invariants, or non-obvious constraints.
Remove comments that restate obvious code behavior.
Optimize for the next maintainer's comprehension time, not minimum character count.

Anti-Patterns

Do not perform speculative architecture rewrites.
Do not introduce framework-wide patterns while simplifying a small local change.
Do not replace understandable duplication with opaque utility layers.
Do not bundle unrelated cleanups into one patch.

Verification

Run the narrowest checks that validate touched behavior:

formatter/lint on touched files
targeted tests for touched modules
typecheck when relevant

Run broader checks only when risk warrants it. Name every skipped check and why.

Report

Skip when --no-report is set; return terse working notes instead: touched scope, key simplifications, residual risks.

Use these section headings, in this order. Omit sections that do not apply — do not number them and do not leave gaps or placeholders.

Scope

Files and regions changed.

Simplifications

One sentence per meaningful change, focused on the readability or maintainability gain. Confirm behavior-preservation assumptions explicitly.

Verification

Commands run and outcomes, including skipped checks.

Residual Risks

One line per risk: Assumed <assumption>; if wrong, <what breaks>; check via <command or inspection>. Plain language — expand or gloss domain-specific terms. Include questions that need a user decision, phrased directly. Write None. when there are none.