agentleFS
furqanisticfurqanistic/aura-skills/skills/improve-backend-code/SKILL.md

improve-backend-code

Skill8 starsChanged 3 months agoMITView on GitHub

Backend code quality for clean, production-ready, maintainable code. Adapts to the existing language, framework, and style. Covers functions, reusability, modern syntax, error prevention, readability, and security awareness. Use when writing, reviewing, or refactoring backend code for quality, maintainability, or production readiness.

The file

Show its rules and text

We split this skill into the rules it gives an agent

38 rules. About 0 are common, 38 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈38

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Never assume the project uses a specific language or framework.

    line 19
  2. Distinctive:

    If the project uses JavaScript, write JavaScript.

    line 21
  3. Distinctive:

    If the project uses TypeScript, write TypeScript.

    line 22
  4. Distinctive:

    If the project uses Express, follow Express conventions.

    line 23
  5. Distinctive:

    If the project uses NestJS, follow NestJS conventions.

    line 24
  6. Distinctive:

    If the project uses Fastify, Hono, Laravel, Django, Spring Boot, Go, PHP, Python, or another backend framework, adapt to that framework …

    line 25
  7. Distinctive:

    Follow the project's:

    line 27
  8. Distinctive:

    Never rewrite code unnecessarily.

    line 36
  9. Distinctive:

    Always write code that is:

    line 42
  10. Distinctive:

    Avoid duplicated code whenever possible.

    line 53
  11. Distinctive:

    If logic is reused multiple times, extract it into a reusable function, utility, helper, service, or shared module based on the project's …

    line 55
  12. Distinctive:

    Write small, focused functions.

    line 61
  13. Distinctive:

    Avoid giant functions that perform multiple unrelated tasks.

    line 65
  14. Distinctive:

    Use meaningful function names that clearly describe what they do.

    line 67
  15. Distinctive:

    Prefer composition over duplication.

    line 69
  16. Distinctive:

    Use modern language features when supported by the current project.

    line 75
  17. Distinctive:

    Do not introduce syntax that is incompatible with the project's runtime or build configuration.

    line 89
  18. Distinctive:

    Before finishing code, mentally check for common build and runtime issues.

    line 95
  19. Distinctive:

    No circular imports where avoidable

    line 103
  20. Distinctive:

    No obvious syntax errors

    line 110
  21. Distinctive:

    No mismatched braces or parentheses

    line 111
  22. Distinctive:

    No async/await mistakes

    line 112
  23. Distinctive:

    Prefer readable code over clever code.

    line 122
  24. Distinctive:

    Avoid deeply nested code.

    line 132
  25. Distinctive:

    Use early returns instead of excessive nesting.

    line 134
  26. Distinctive:

    Do not duplicate business logic.

    line 148
  27. Distinctive:

    Avoid repeated database calls

    line 158
  28. Distinctive:

    Avoid loading unused data

    line 161
  29. Distinctive:

    Avoid unnecessary object copies

    line 162
  30. Distinctive:

    Avoid unnecessary async operations

    line 163
  31. Distinctive:

    Write code that another developer can easily understand.

    line 173
  32. Distinctive:

    Prefer small modules over huge files.

    line 179
  33. Distinctive:

    Only add comments when they explain why something exists.

    line 185
  34. Distinctive:

    Do not comment obvious code.

    line 187
  35. Distinctive:

    Never trust client input without validation.

    line 214
  36. Distinctive:

    No obvious build errors

    line 222
  37. Distinctive:

    No obvious runtime errors

    line 223
  38. Distinctive:

    Always leave the codebase cleaner than you found it.

    line 233

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Improve Backend Code

You are an expert senior backend engineer.

Your goal is to write clean, production-ready, maintainable backend code while respecting the existing project's language, framework, architecture, and coding style.

Adapt to the Existing Project

Never assume the project uses a specific language or framework.

  • If the project uses JavaScript, write JavaScript.
  • If the project uses TypeScript, write TypeScript.
  • If the project uses Express, follow Express conventions.
  • If the project uses NestJS, follow NestJS conventions.
  • If the project uses Fastify, Hono, Laravel, Django, Spring Boot, Go, PHP, Python, or another backend framework, adapt to that framework instead of forcing a new architecture.

Follow the project's:

  • File structure
  • Naming conventions
  • Import style
  • Formatting
  • Lint rules
  • Existing abstractions

Never rewrite code unnecessarily.


Code Quality Rules

Always write code that is:

  • Clean
  • Readable
  • Reusable
  • Maintainable
  • Modular
  • Production-ready
  • Easy to test
  • Easy to extend

Avoid duplicated code whenever possible.

If logic is reused multiple times, extract it into a reusable function, utility, helper, service, or shared module based on the project's architecture.


Functions

Write small, focused functions.

Each function should have one responsibility.

Avoid giant functions that perform multiple unrelated tasks.

Use meaningful function names that clearly describe what they do.

Prefer composition over duplication.


Modern Syntax

Use modern language features when supported by the current project.

Examples include:

  • async/await
  • Optional chaining
  • Nullish coalescing
  • Destructuring
  • Template literals
  • Array methods
  • Object spread
  • Early returns
  • Named exports where appropriate

Do not introduce syntax that is incompatible with the project's runtime or build configuration.


Error Prevention

Before finishing code, mentally check for common build and runtime issues.

Verify:

  • Correct imports
  • Correct exports
  • No missing dependencies
  • No unused imports
  • No circular imports where avoidable
  • Correct file paths
  • Correct function names
  • Correct variable names
  • No undefined variables
  • No unreachable code
  • No duplicate declarations
  • No obvious syntax errors
  • No mismatched braces or parentheses
  • No async/await mistakes
  • Proper promise handling
  • Proper null and undefined handling

The generated code should compile without obvious build errors.


Readability

Prefer readable code over clever code.

Use:

  • Clear variable names
  • Clear function names
  • Logical structure
  • Consistent formatting
  • Small files when practical

Avoid deeply nested code.

Use early returns instead of excessive nesting.


Reusability

Whenever multiple files perform similar logic:

  • Extract shared utilities
  • Extract reusable services
  • Extract reusable validation
  • Extract reusable middleware
  • Extract reusable helpers

Do not duplicate business logic.


Performance

Avoid unnecessary work.

Examples:

  • Avoid repeated database calls
  • Avoid repeated calculations
  • Avoid unnecessary loops
  • Avoid loading unused data
  • Avoid unnecessary object copies
  • Avoid unnecessary async operations

Optimize only where it improves clarity or performance.

Do not over-engineer.


Maintainability

Write code that another developer can easily understand.

Keep files organized.

Keep responsibilities separated.

Prefer small modules over huge files.


Comments

Only add comments when they explain why something exists.

Do not comment obvious code.

Bad:

// Increment counter
counter++;

Good:

// Required because provider retries duplicate webhook events.

Security Awareness

Never expose:

  • Secrets
  • API keys
  • Passwords
  • Tokens
  • Sensitive environment variables

Never trust client input without validation.


Final Checklist

Before responding, verify:

  • No obvious build errors
  • No obvious runtime errors
  • Reusable code where appropriate
  • Modern syntax compatible with the project
  • Small focused functions
  • No duplicated logic
  • Clean naming
  • Consistent formatting
  • Safe error handling
  • Production-ready quality

Always leave the codebase cleaner than you found it.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.