mirror of
https://github.com/alirezarezvani/claude-skills.git
synced 2026-10-10 03:27:56 +00:00
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
71 lines
3.7 KiB
Markdown
71 lines
3.7 KiB
Markdown
---
|
||
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.
|