How do I install the Simplicity First skill?

Run npx skillmds@latest add nvidia-nemo/simplicity-first in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Simplicity First safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Simplicity First?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Simplicity First free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Simplicity First?

NVIDIA NeMo (@nvidia-nemo) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Simplicity First by nvidia-nemo — Agent Skill

Name: Simplicity First
Author: NVIDIA NeMo

Simplicity First

Simplicity gate for ALL code written, fixed, or reviewed in this repo. Invoke BEFORE writing any code change and when reviewing any diff. Treats over-complex or oversized code as a correctness bug, not a style issue.

NVIDIA NeMo f5f680b 2.7 KB Updated Sep 17, 2026

File contents

Simplicity is the first principle

Human readability comes first; coding-agent traceability is the minimum gate. A human should understand the code in one pass. An agent must at least be able to trace a feature from CLI flag to executed branch, tensor/record, metric, and test without reconstructing hidden control flow. Every rule below is an instance of that ordering. These are hard correctness rules, not style preferences. A violation is a bug and must be fixed before the change ships.

Code a human can't follow at a glance is a bug. If a reviewer can't read a function top-to-bottom in one pass, restructure or delete it. Nesting, indirection, and clever constructs count against correctness — cleverness that costs comprehension is a defect, whatever it saves.
Too much / redundant code is a bug. Solve the problem in the fewest lines that stay readable. Prefer deleting code over adding it. A fix that adds more than ~20 lines for a problem statable in one sentence is suspect — find the smaller fix first.
Simplicity is the core engineering metric. When two designs both work, ship the one with less code, fewer concepts, fewer files. Never add config, record types, or return-shape changes "for the future".
No over-encapsulation. No new class / dataclass / helper / module for a single call site. A helper needs 3+ real call sites AND nontrivial logic — otherwise inline it. Never wrap trivial code. Never change a function signature or return shape to thread data that only one caller needs.
Simplicity is not deletion of capability. Features, performance knobs, and observability are intentional — do not remove them in the name of simplicity. Knobs default ON stay ON. Simplify the implementation, keep the behavior surface.

Checklist before finishing any change

Would a human reading this cold understand it in one pass? That is the gate.
Could this diff be half the size? If unsure, make it smaller.
Any new class or file? Justify each with 3+ call sites, or delete it.
Any signature / return-shape change? Verify every caller genuinely needs it.
Comments: concise "why" only, 2-4 lines max, written for an external reader — no job ids, commit hashes, single-run metrics, or internal paths; keep upstream issue/PR links.
One problem = one minimal diff. Do not batch unrelated "improvements".
A "bug" that cannot trigger under the real recipes is not worth fixing.

---name: simplicity-firstdescription: Simplicity gate for ALL code written, fixed, or reviewed in this repo. Invoke BEFORE writing any code change and when reviewing any diff. Treats over-complex or oversized code as a correctness bug, not a style issue.---# Simplicity is the first principle**Human readability comes first; coding-agent traceability is the minimumgate.** A human should understand the code in one pass. An agent must at leastbe able to trace a feature from CLI flag to executed branch, tensor/record,metric, and test without reconstructing hidden control flow. Every rule belowis an instance of that ordering. These are hard correctness rules, not stylepreferences. A violation is a bug and must be fixed before the change ships.1. **Code a human can't follow at a glance is a bug.** If a reviewer can't read a function top-to-bottom in one pass, restructure or delete it. Nesting, indirection, and clever constructs count against correctness — cleverness that costs comprehension is a defect, whatever it saves.2. **Too much / redundant code is a bug.** Solve the problem in the fewest lines that stay readable. Prefer deleting code over adding it. A fix that adds more than ~20 lines for a problem statable in one sentence is suspect — find the smaller fix first.3. **Simplicity is the core engineering metric.** When two designs both work, ship the one with less code, fewer concepts, fewer files. Never add config, record types, or return-shape changes "for the future".4. **No over-encapsulation.** No new class / dataclass / helper / module for a single call site. A helper needs 3+ real call sites AND nontrivial logic — otherwise inline it. Never wrap trivial code. Never change a function signature or return shape to thread data that only one caller needs.5. **Simplicity is not deletion of capability.** Features, performance knobs, and observability are intentional — do not remove them in the name of simplicity. Knobs default ON stay ON. Simplify the implementation, keep the behavior surface.## Checklist before finishing any change- Would a human reading this cold understand it in one pass? That is the gate.- Could this diff be half the size? If unsure, make it smaller.- Any new class or file? Justify each with 3+ call sites, or delete it.- Any signature / return-shape change? Verify every caller genuinely needs it.- Comments: concise "why" only, 2-4 lines max, written for an external reader — no job ids, commit hashes, single-run metrics, or internal paths; keep upstream issue/PR links.- One problem = one minimal diff. Do not batch unrelated "improvements".- A "bug" that cannot trigger under the real recipes is not worth fixing.

Frequently asked questions