Writing Production Code
Markdown--- name: writing-production-code description: Writes, edits, debugs, optimizes, and explains code in any language or framework (HTML, CSS, JavaScript, TypeScript, Python, C#, C++, Java, PHP, SQL, Lua, Roblox Luau, Node.js, React, Next.js, APIs, bots, automation scripts, websites, applications). Use when the user asks for code to be written, fixed, refactored, reviewed, or generated as a complete project, or shares existing code for debugging/improvement. --- Writes complete, production-quality, human-style code in any language. No placeholders, no omissions, no AI-sounding filler.
When asked for code, produce the full working file(s) immediately. No "here's an outline" or "...rest of code here" — every function is fully implemented.
Python# Bad (never do this) def load_users(): # ... existing logic ... pass # Good def load_users(): with open("users.json") as f: return json.load(f)
Progress checklist for any non-trivial request:
- Understand the actual goal (language, framework, platform, constraints)
- Make reasonable assumptions for missing details instead of asking
- Write the full implementation — every file, every function
- Re-read for syntax errors, missing imports, undefined variables
- Check logic: edge cases, off-by-ones, null/undefined handling
- Verify naming is natural and consistent across all files
- If UI involved, confirm layout is modern, spaced, and not empty-looking
- Add error handling for anything that can realistically fail
- Strip unnecessary comments and dead code
- Final pass against the Quality Standard checklist below
For debugging requests:
- Reproduce the bug mentally by tracing execution
- Identify the root cause, not just the symptom
- Scan for related bugs nearby (same pattern elsewhere)
- Rewrite the full corrected file
- State the root cause in 1-3 sentences, no more
Function/variable names should read like a competent human wrote them under time pressure — clear, short, no corporate verbosity.
| Good | Bad |
|---|---|
loadUsers() | click_bot_python_function() |
clickBot() | advanced_user_management_system_v2() |
downloadVideo() | perform_complex_asynchronous_network_operation() |
Rules:
- No helper-function sprawl for simple logic — inline it if it's only used once and is short.
- Classes only when they genuinely model something (state + behavior), not for single-function wrappers.
- Comments explain why, never what. Delete comments that restate the code.
- No TODOs, no "implement later", no placeholder stubs.
Python: PEP 8, standard library first, flat over nested, type hints when they add clarity.
JS/TS: ES6+, async/await over .then() chains, no var, avoid globals, prefer const.
HTML/CSS/JS: Semantic HTML, organized CSS (logical grouping, not alphabetical), responsive by default (flexbox/grid, not fixed pixel layouts), vanilla JS unless a framework is requested or clearly necessary.
UI/GUI (any stack): Modern look by default —
- Generous, consistent padding/spacing (no cramped or empty-feeling layouts)
- Rounded corners on cards/buttons/inputs where it fits the design
- Modern system font stack (e.g.
Inter,-apple-system,Segoe UI) unless told otherwise - Balanced button sizing — not oversized, not tiny tap targets
- Consistent color palette (2-3 accent colors max, defined once as variables/tokens)
- Never ship the "default browser form" look unless explicitly asked
Example 1:
Input: "Write a Node.js Express endpoint that returns a user by ID from a Postgres DB."
Output: Full server.js (or route file) with express app setup, pg pool connection, parameterized query (WHERE id = $1), 404 handling for missing user, 500 handling for DB errors, and .env usage for credentials — no hardcoded secrets.
Example 2:
Input: "This React component re-renders too much, fix it." + pasted code
Output: Root cause stated briefly ("new object literal passed as prop on every render, plus missing memo on child") then the complete rewritten component file using useMemo/useCallback/React.memo as appropriate — not a diff, not a snippet.
Example 3: Input: "Make a login page" Output: Full HTML/CSS/JS (or framework equivalent), centered card layout, labeled inputs with proper sizing, client-side validation, accessible markup, responsive on mobile, polished visual style — not a bare unstyled form.
- Rewrite the entire file when editing, unless the user explicitly asks for a snippet/diff.
- Validate all external/user input; escape output where injection is possible (HTML, SQL, shell).
- Handle expected failure modes (network errors, missing files, bad input) with useful messages — never swallow exceptions silently.
- Use secure defaults: parameterized queries, no secrets in source, no
eval/innerHTML-with-user-input style shortcuts. - Optimize only where it matters (hot loops, large datasets); don't sacrifice readability for micro-optimizations.
- When a complete project is requested, generate a sensible file/folder structure and every file needed to run it (no "and you'll need to add X yourself").
- Don't use placeholder comments like
// ... existing code ...— ever. - Don't leave functions unimplemented or returning dummy values.
- Don't over-engineer simple requests with unnecessary classes, patterns, or abstraction layers.
- Don't write AI-sounding variable/function names or explain obvious lines with comments.
- Don't ask clarifying questions when a reasonable default assumption is possible — just build it.
- Don't ship UI with default browser styling, misaligned spacing, or oversized/undersized controls.
- Don't forget to double check imports and dependency names actually exist before finishing.
✓ No syntax errors ✓ No missing imports ✓ No undefined variables ✓ No placeholder code ✓ No unfinished functions ✓ Consistent naming ✓ Clean formatting ✓ Production-ready quality ✓ UI looks polished if applicable