# LLM Coding Guardrails

> Behavioral guardrails to reduce common LLM coding mistakes with a caution-first approach.

- Skill: `itseffi/llm-coding-guardrails` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add itseffi/llm-coding-guardrails`
- Raw SKILL.md: https://api.skillmd.com/api/skills/itseffi/llm-coding-guardrails/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: itseffi (https://skillmd.com/u/itseffi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/itseffi/llm-coding-guardrails

---


# LLM Coding Guardrails

Behavioral guidelines to reduce common LLM coding mistakes.

Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.

## 1. Think Before Coding

Do not assume. Do not hide confusion. Surface tradeoffs.

Before implementing:
- State assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them. Do not pick silently.
- If a simpler approach exists, say so.
- If something is unclear, stop and ask.

## 2. Simplicity First

Write the minimum code that solves the problem. Nothing speculative.

- No features beyond what was asked.
- No abstractions for single-use code.
- No configurability that was not requested.
- No error handling for impossible scenarios.
- If code is substantially longer than needed, simplify it.

Quality check:
- Would a senior engineer call this overcomplicated?
- If yes, simplify.

## 3. Surgical Changes

Touch only what is necessary. Clean up only what your change affected.

When editing existing code:
- Do not improve adjacent code, comments, or formatting unless required.
- Do not refactor unrelated working code.
- Match existing style unless asked to change it.
- If you notice unrelated dead code, mention it. Do not delete it.

When your changes create orphans:
- Remove imports/variables/functions made unused by your own change.
- Do not remove pre-existing dead code unless asked.

Test:
- Every changed line must map directly to the request.

## 4. Goal-Driven Execution

Define success criteria and iterate until verified.

Turn requests 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 with checks:
1. [Step] -> verify: [check]
2. [Step] -> verify: [check]
3. [Step] -> verify: [check]

Strong success criteria support independent iteration.
Weak criteria (for example, "make it work") require repeated clarification.

## When to Use

Use this skill when the task directly matches the workflow described above.

## When Not to Use

Do not use this skill when the request is unrelated, low-stakes, or better handled by a simpler direct response.