Skip to content
Back to skills

No Lazy Implementation

ASecurity

Prevents "lazy" coding habits by enforcing full implementation and banning placeholders.

  • 207 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added February 7, 2026
development

Security analysis

A100/100

Pro scans all 9 files and shows the line behind each finding

Scanned February 12, 2026

npx -y skills add NeverSight/skills_feed --skill no_lazy_implementation --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of No Lazy Implementation?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for No Lazy Implementation
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/neversight-no-lazy-implementation/badge)](https://www.skillsdirectory.com/skills/neversight-no-lazy-implementation)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: no_lazy_implementation
description: Prevents "lazy" coding habits by enforcing full implementation and banning placeholders.
allowed-tools: Read, Edit, Write
---

# No Lazy Implementation Protocol

## 1. Zero Placeholder Policy
**Strictly Prohibited:**
- `// ... rest of code`
- `// ... implement logic here`
- `// ... same as above`
- Leaving TODOs for critical business logic that was requested.

**Requirement:**
- You must generate **COMPLETE, WORKING CODE**.
- If a file is too large for one turn, explicitly state: "This is Part 1 of X. I will implement the rest in the next step." and **immediately** proceed to generate the rest.

## 2. Full Method Implementation
- When modifying a file, **never** replace existing working logic with a comment to save output space, unless you are absolutely certain that part of the file is untouched and you are using a diff-friendly tool.
- Even then, prefer context-aware editing that ensures the final file is complete and compilable.

## 3. "It Just Works" Standard
- The code you write must be ready to run.
- Imports must be real.
- Types must be defined (no `any` without strict justification).
- Variable names must be descriptive (no `data1`, `temp`).

## 4. Verification Checklist
Before calling `Edit` or `Write`:
- [ ] Did I simply comment out complex logic to save tokens? (If yes, STOP and write it out).
- [ ] Did I leave a "TODO" for something the user explicitly asked for? (If yes, implement it).
- [ ] Is the code compilable immediately after this edit?

Files in this skill

  • SKILL.md1.5 KB
  • description_cn.txt76 B
  • description_de.txt130 B
  • description_en.txt89 B
  • description_es.txt127 B
  • description_fr.txt136 B
  • description_ja.txt142 B
  • description_ko.txt109 B
  • description_tw.txt76 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.