# Less Is More > Use before committing to any architecture, design, or non-trivial technical direction — when the user asks how to build or structure something, proposes a system or feature, or faces a hard-to-reverse structural decision. Not for localized code style or a single function's implementation. - Skill: `bahadirkisbet/less-is-more` (Agent Skill) - Install (CLI): `npx skillmds@latest add bahadirkisbet/less-is-more` - Raw SKILL.md: https://api.skillmd.com/api/skills/bahadirkisbet/less-is-more/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: bahadirkisbet (https://skillmd.com/u/bahadirkisbet) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/bahadirkisbet/less-is-more --- # Less Is More Architecture decisions are won or lost on understanding the *intent* and the *business* — not on cleverness. You are usually NOT fully aware of the business. This skill forces you to surface the real intent, lay out explicit paths, weigh tradeoffs against what you actually know of the business, and — every single time — record what you learn so the next decision is sharper. This skill operates at the architecture / design altitude. Code-level minimalism (shorter functions, fewer lines, stdlib over custom) is a separate concern handled by a code-simplicity reviewer; do not duplicate it here. **Announce at start:** "Using less-is-more to map paths and tradeoffs against business context." ## When to Use - "How should we build / structure X?", a new service / module / feature, a schema or data-flow decision, build-vs-buy, a structural refactor. - Any decision where picking wrong is expensive to reverse. - Not for: localized code style, a single function's implementation, mechanical edits. ## Step 1: Extract the Intent State the real goal in one or two sentences — the outcome the user wants, not the literal mechanism they named. Users often ask for a solution; find the problem underneath it. If the intent is ambiguous, ask ONE clarifying question before going further. A wrong intent makes every path below wrong. ## Step 2: Load Business Context Read the project's business-context note (default: `.claude/business-context.md`; create it if missing). It holds what you have learned about this project's domain, constraints, priorities, and past tradeoff decisions. You are not the domain expert. This note is how you borrow the expertise you have accumulated across past sessions. Use it to ground everything below. Where the note is silent on something that matters, treat that as a known blind spot for Step 4. ## Step 3: Lay Out Explicit Paths — BEFORE Tradeoffs Present 2–4 concrete, named paths. For each: what it is, what building it actually entails, what it assumes. Be specific — "Path A: extend the existing job runner with a new task type" not "we could reuse existing code." Do NOT jump to a recommendation yet. The user needs to see the real option space before any verdict narrows it. ## Step 4: Tradeoffs, Grounded in the Business Only now weigh the paths — against the business context, not abstract purity: - Cost to build, cost to reverse, cost to operate. - Fit to the known constraints and priorities from Step 2. - The simplicity lens: fewer moving parts wins when nothing in the business argues otherwise. **Flag your blind spots.** Wherever a tradeoff depends on business facts you do NOT have, say so plainly: "This hinges on X — I don't have that. If X, Path A; if not-X, Path B." Honesty about what you don't know is the point — it invites the user to fill the gap, which becomes Step 5's memory. Then give a recommendation, conditioned on the open questions. ## Step 5: Learn the Business — EVERY Time This is mandatory, not optional. The skill is worthless without it. After the decision (or the user's correction of it), append to `.claude/business-context.md` what you learned: ``` ## — - Domain fact / constraint / priority learned: - Decision made, and the *business* reason (not just the technical one): - Tradeoff the user weighted differently than you expected: ``` Over many uses this note turns "I don't know the business" into "I know this business." Each invocation must leave the note richer than it found it. ## Common Mistakes - Recommending before showing the explicit paths — the user can't see what you ruled out. - Weighing tradeoffs on engineering aesthetics instead of business reality. - Pretending to know the business — hiding blind spots instead of flagging them. - Skipping Step 5 — a session that taught you nothing persistent wasted the skill. - Reading "less" as "fewest lines." Here "less" means fewer moving parts and less you will regret, decided against the business. **Required next:** when the chosen path is significant and hard to reverse, record it with `bardak:adr` — its Context and Options sections draw on the paths and business context from this skill.