programming-guidelines
Programming Guidelines
The following rules are universal coding standards. Apply all of them by default — but use proportional judgment for tasks that are simple, one-off, or not part of a larger engineering effort.
Tradeoff: These guidelines bias toward caution over speed. For trivial or one-off tasks, use judgment.
1. Think Before Coding
Don't assume. Don't hide confusion. Surface tradeoffs.
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
2. Simplicity First
Minimum code that solves the problem. Nothing speculative.
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
3. Surgical Changes
Touch only what you must. Clean up only your own mess.
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
4. Goal-Driven Execution
Define success criteria. Loop until verified.
Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
More from zenless-lab/skills
python-docstring-expert
Expert methodology for evaluating, formatting, and generating Python docstrings. Use when creating or updating documentation for Python code, determining if a docstring is necessary based on API exposure, or formatting docstrings for modules, classes, and functions. Load this skill when code changes affect existing docstrings to keep them synchronized.
16cloud-init-crafter
Expert assistant for creating, modifying, and debugging cloud-init scripts. Supports multiple formats (YAML, shell, MIME archives), Jinja templating with instance-data, and multi-platform validation.
9readme-crafter
Use this skill when you need to write, refactor, or improve a project's README.md file. Trigger this anytime the user wants to create documentation, project overviews, or profile pages following best practices and modern aesthetics.
8skill-expert
Comprehensive master guide for designing, creating, editing, updating, and refactoring Agent Skills according to the official agentskills.io specification. Use this when you need to build or modify capabilities for an AI agent.
8agents-md-crafter
Use this skill when you need to create, update, or improve AI agent instruction files like AGENTS.md, GEMINI.md, or copilot-instructions.md. Trigger this anytime the user wants to set up standard AI rules, document project context for LLMs, or add repository-wide guidelines for AI agents.
8skill-crafter
Use this skill when creating a new skill or when modifying, updating, refactoring, restructuring, or reviewing an existing skill. Trigger it for framework-specific and framework-agnostic skill work, including SKILL.md design, folder layout, scripts, references, assets, metadata, and description optimization, even if the user only says "make a skill", "improve this skill", or "refactor the skill".
7