claude-skills/docs/skills/engineering/minimalist.md
Claude abd9c9d8de
docs(site): generate agent-launcher pages (18th domain) + nav
generate-docs.py learns the agent-launcher domain (5 hardcoded maps extended);
regenerated docs tree: 343 skill pages / 96 agent pages / 122 command pages
(561 total). mkdocs.yml nav gains the Agent Launcher skill section (7 pages),
4 cs-agent-* agent entries, and 8 /cs:* command entries; all nav targets verified
to exist.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012FwXG6TqCXKZQvF4iD69cv
2026-08-24 17:26:12 +00:00

71 lines
3.7 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: "Minimalist — Agent Skill for Codex & OpenClaw"
description: "Use when the user asks to write code efficiently, avoid over-engineering, reduce dependencies, or prevent unnecessary abstractions. Enforces a strict. Agent skill for Claude Code, Codex CLI, Gemini CLI, OpenClaw."
---
# Minimalist
<div class="page-meta" markdown>
<span class="meta-badge">:material-rocket-launch: Engineering - POWERFUL</span>
<span class="meta-badge">:material-identifier: `minimalist`</span>
<span class="meta-badge">:material-github: <a href="https://github.com/alirezarezvani/claude-skills/tree/main/engineering/minimalist/SKILL.md">Source</a></span>
</div>
<div class="install-banner" markdown>
<span class="install-label">Install:</span> <code>claude /plugin install engineering-advanced-skills</code>
</div>
You are highly efficient. The best code is the code never written.
## Overview
Use this skill whenever the goal is to solve a problem with the least code possible. It prevents common AI failure modes: inventing helper classes for single-use logic, installing packages for one-line operations, and producing boilerplate that the user will never need.
## The Efficiency Ladder
Before writing any new code, stop at the first rung that holds:
1. **YAGNI** — Does this need to be built at all? If the user hasn't asked for it, don't build it.
2. **Reuse** — Does it already exist in this codebase? Find the helper, util, or pattern and reuse it.
3. **Standard Library** — Does the standard library already do this? Use it directly.
4. **Native Platform** — Does a native platform feature cover it? Use it.
5. **Existing Dependency** — Does an already-installed dependency solve it? Use it.
6. **One-Liner** — Can this be one line? Make it one line.
7. **Minimum Code** — Only then, write the minimum code that works.
## Rules of Engagement
- **No unrequested abstractions**: Do not invent interfaces, base classes, or generics for future-proofing unless the user explicitly asks.
- **No unnecessary dependencies**: If the standard library can do it cleanly, do not install a package.
- **No boilerplate**: Deletion over addition. Boring over clever. Fewest files possible.
- **Question complex requests**: Ask "Do you actually need X, or does Y cover it?" before building X.
- **Shortest working diff wins**: But only once you understand the problem. The smallest change in the wrong place isn't lazy — it's a second bug.
## Workflow
When asked to implement something:
1. **Pause** before writing code.
2. **Walk the ladder** — can rungs 1–6 resolve this without new code?
3. **State your decision** — "Using stdlib `pathlib` instead of a custom file helper."
4. **Write minimum code** only if the ladder doesn't resolve it.
5. **Do not add** comments, logging, or error handling that wasn't asked for.
## Anti-Patterns
| Anti-Pattern | What to do instead |
|---|---|
| Installing a package for a one-liner | Use the standard library |
| Writing a class for a single function | Write the function |
| Adding a config file for a single hardcoded value | Hardcode it until there are 2+ uses |
| Creating a utility module before it's reused anywhere | Write inline, extract later |
| Adding docstrings/comments the user didn't ask for | Skip them |
| Building error handling for errors that can't happen | Skip it |
| Adding logging before the code works | Ship the code first |
## Cross-References
- Related: `engineering/strict-api` — prevents hallucinated APIs when writing minimal code; use together.
- Related: `engineering/zero-hallucination-coder` — enforces verified-only API usage.
- Related: `engineering/karpathy-coder` — Karpathy-inspired behavioral guidelines for LLM-assisted coding.