dev-code-style

Guides writing compact, readable code with justified abstractions and purposeful comments.

2|Updated May 16, 2026
One-click install
npx skills add https://github.com/avbel/ai-skills --skill dev-code-style-avbel
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dev-code-style
Source: https://github.com/avbel/ai-skills/tree/main/skills/dev-code-style
Command: npx skills add https://github.com/avbel/ai-skills --skill dev-code-style-avbel

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate overengineered abstractions, speculative configuration, and noisy comments that narrate obvious code, making reviews and maintenance harder. This Skill enforces a consistent style where every abstraction earns its place and every comment carries information the code cannot express. ## Core Features & Use Cases - Abstraction Discipline: Requires a current, concrete reason before adding helpers, wrappers, interfaces, or dependencies, and permits small local repetition over premature sharing. - Comment Hygiene: Keeps only comments explaining non-obvious constraints, invariants, and workarounds while removing narration, banners, TODO stubs, and commented-out code. - Readability-First Editing: Prefers domain names, explicit units, early returns, and named intermediates over dense expressions, with a self-check checklist before finishing any edit. - Use Case: When asked to simplify a tangled module or review a pull request, apply these rules to collapse speculative layers, delete filler comments, and keep behavior-preserving minimal diffs. ## Quick Start Ask the agent to review and simplify the current file using the dev-code-style rules, removing unjustified abstractions and comment noise.

Frequently Asked Questions about dev-code-style

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I simplify overengineered code without breaking behavior?▼

Read the affected flow and its callers first, then collapse speculative wrappers, factories, and configuration while preserving validation, error handling, and tests. Finish with the self-check: confirm each remaining abstraction earns its place and the diff still meets the full contract.

When should I extract a helper function versus keeping code inline?▼

Keep short, clear logic inline by default. Extract only when it centralizes a rule that must stay consistent, isolates a cohesive complex operation, or serves a current boundary like resource ownership or an existing test seam.

What comments should I keep when cleaning up code?▼

Keep comments explaining non-obvious reasons, external constraints, intentional surprises, and invariants a later edit could break, plus required API docs, license headers, and safety rationale. Remove narration of obvious statements, section banners, and commented-out code.

Does avoiding duplication always mean creating shared modules?▼

No. Reuse depends on shared meaning and change ownership, not similar syntax. A little local repetition can be clearer than coupling unrelated concepts, and a second occurrence alone does not justify a shared module.

When is this code style approach not appropriate?▼

Do not apply it as a license to strip required documentation, tooling directives, unsafe-code invariants, or behavior-establishing checks. Correctness and ecosystem documentation requirements take priority over brevity.