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.
In this repository8 other files it gives its agents.
- architect-backendSkill
- audit-backend-securitySkill
- optimize-databaseSkill
- integrate-1billSkill
- integrate-easypaisaSkill
- integrate-jazzcashSkill
- integrate-stripeSkill
- screenshot-to-codeSkill
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
- Distinctive: line 19
Never assume the project uses a specific language or framework.
- Distinctive: line 21
If the project uses JavaScript, write JavaScript.
- Distinctive: line 22
If the project uses TypeScript, write TypeScript.
- Distinctive: line 23
If the project uses Express, follow Express conventions.
- Distinctive: line 24
If the project uses NestJS, follow NestJS conventions.
- Distinctive: line 25
If the project uses Fastify, Hono, Laravel, Django, Spring Boot, Go, PHP, Python, or another backend framework, adapt to that framework …
- Distinctive: line 27
Follow the project's:
- Distinctive: line 36
Never rewrite code unnecessarily.
- Distinctive: line 42
Always write code that is:
- Distinctive: line 53
Avoid duplicated code whenever possible.
- Distinctive: line 55
If logic is reused multiple times, extract it into a reusable function, utility, helper, service, or shared module based on the project's …
- Distinctive: line 61
Write small, focused functions.
- Distinctive: line 65
Avoid giant functions that perform multiple unrelated tasks.
- Distinctive: line 67
Use meaningful function names that clearly describe what they do.
- Distinctive: line 69
Prefer composition over duplication.
- Distinctive: line 75
Use modern language features when supported by the current project.
- Distinctive: line 89
Do not introduce syntax that is incompatible with the project's runtime or build configuration.
- Distinctive: line 95
Before finishing code, mentally check for common build and runtime issues.
- Distinctive: line 103
No circular imports where avoidable
- Distinctive: line 110
No obvious syntax errors
- Distinctive: line 111
No mismatched braces or parentheses
- Distinctive: line 112
No async/await mistakes
- Distinctive: line 122
Prefer readable code over clever code.
- Distinctive: line 132
Avoid deeply nested code.
- Distinctive: line 134
Use early returns instead of excessive nesting.
- Distinctive: line 148
Do not duplicate business logic.
- Distinctive: line 158
Avoid repeated database calls
- Distinctive: line 161
Avoid loading unused data
- Distinctive: line 162
Avoid unnecessary object copies
- Distinctive: line 163
Avoid unnecessary async operations
- Distinctive: line 173
Write code that another developer can easily understand.
- Distinctive: line 179
Prefer small modules over huge files.
- Distinctive: line 185
Only add comments when they explain why something exists.
- Distinctive: line 187
Do not comment obvious code.
- Distinctive: line 214
Never trust client input without validation.
- Distinctive: line 222
No obvious build errors
- Distinctive: line 223
No obvious runtime errors
- Distinctive: line 233
Always leave the codebase cleaner than you found it.
≈ “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.
Files
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.
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
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.

