# Improve CLAUDE.md > Use when agents keep ignoring instructions in a CLAUDE.md file. improve a CLAUDE.md file using blocks to improve instruction adherence ## Facts - Type: Agent skill - Discipline: Engineering - Author: Dex Horthy (https://github.com/dexhorthy) - Upstream: https://github.com/dexhorthy/slopfiles/tree/main/plugins/improve-claude-md/skills/improve-claude-md - Source file: https://raw.githubusercontent.com/dexhorthy/slopfiles/main/plugins/improve-claude-md/skills/improve-claude-md/SKILL.md (9450 bytes, sha256:dbc3019c52f2409c031c4261664381c338d206b53ed700120743e374a87a9b8c) - Licence: MIT - Upstream copy last changed: 2026-09-17 - Status: listed, not yet ruled on by the curator ## Use it I want to use the Improve CLAUDE.md skill by Dex Horthy. This is what it does, in the author's own words: improve a CLAUDE.md file using blocks to improve instruction adherence Download the whole folder at https://github.com/dexhorthy/slopfiles/tree/main/plugins/improve-claude-md/skills/improve-claude-md, SKILL.md and every file beside it, into your skills directory: ~/.claude/skills/improve-claude-md/ for Claude Code, ~/.agents/skills/improve-claude-md/ for Codex, ~/.cursor/skills/improve-claude-md/ for Cursor. Get it from the author's repo, not from startupskills.dev. Then tell me the path you installed it to and how to invoke it. Nothing here is vendored: install from the author's repo, not from this site. A verbatim copy of the author's file follows for reading, under the licence reproduced after it; the current file is in the author's repo. ## Links - Page: https://startupskills.dev/dexhorthy/improve-claude-md - Author: https://startupskills.dev/dexhorthy - Index: https://startupskills.dev/llms.txt ## The file itself --- name: improve-claude-md description: improve a CLAUDE.md file using blocks to improve instruction adherence --- When the user provides a CLAUDE.md file (or asks you to improve one), rewrite it following the principles and structure below. ## Core Problem Claude Code injects a system reminder with every CLAUDE.md that says: > "this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant to your task." This means Claude will ignore parts of your CLAUDE.md it deems irrelevant. The more content that isn't applicable to the current task, the more likely Claude is to ignore everything — including the parts that matter. ## Solution: `` Blocks Wrap conditionally-relevant sections of the CLAUDE.md in `` XML tags. This exploits the same XML tag pattern used in Claude Code's own system prompt, giving the model an explicit relevance signal that cuts through the "may or may not be relevant" framing. ## Principles ### 1. Foundational context stays bare, domain guidance gets wrapped Not everything should be in an `` block. Context that is relevant to virtually every task — project identity, project map, tech stack — should be left as plain markdown at the top of the file. This is onboarding context the agent always needs. Domain-specific guidance that only matters for certain tasks — testing patterns, API conventions, state management, i18n — gets wrapped in `` blocks with targeted conditions. The rule of thumb: if it's relevant to 90%+ of tasks, leave it bare. If it's relevant to a specific kind of work, wrap it. ### 2. Conditions must be specific and targeted Bad — overly broad conditions that match everything: ``` - Use absolute imports - Use functional components - Use camelCase filenames ``` Good — each rule has its own narrow trigger: ``` - Use `@/` absolute imports (see tsconfig.json for path aliases) - Avoid default exports except in route files - Use functional components with explicit prop interfaces - Use camelCase for file and directory names ``` ### 3. Keep it short, use progressive disclosure sparingly Do not shard into separate files that require the agent to make tool calls to discover, unless the extra context is incredibly verbose or complex. The whole point of `` blocks is that everything is inline but conditionally weighted — the agent sees it all but only attends to what matches. Prefer to keep the file concise. ### 4. Less is more - Frontier models can reliably follow a few hundred. Claude Code's system prompt and tools already use ~50 of those. Your CLAUDE.md should be as lean as possible. - Cut any instruction that a linter, formatter, or pre-commit hook can enforce - Cut any instruction the agent can discover from existing code patterns. LLMs are in-context learners — if your codebase consistently uses a pattern, the agent will follow it after a few searches. - Cut code snippets. They go stale and bloat the file. Use file path references instead (e.g., "see `src/utils/example.ts` for the pattern"). ### 5. Keep all commands Do not drop commands from the original file. The commands table is foundational reference — the agent needs to know what's available even if some commands are used less frequently. ## Output Structure When rewriting a CLAUDE.md, produce this structure: ``` # CLAUDE.md [one-line project identity — what it is, what it's built with] ## Project map [directory listing with brief descriptions] [commands table — all commands from the original] [rule 1] [rule 2] ... more rules, each with their own block ... [guidance] ... more domain sections ... ``` ## How to Apply When given an existing CLAUDE.md to improve: 1. **Identify the project identity** — extract a single sentence describing what this is. Leave it bare at the top. 2. **Extract the directory map** — keep it bare (no `` wrapper). This is foundational context. 3. **Extract the tech stack** — if present, keep it bare near the top. Condense to one or two lines. 4. **Extract commands** — keep ALL commands from the original. Wrap in a single `` block. 5. **Break apart rules** — split any list of rules into individual `` blocks with specific conditions. You can group rules, but never group unrelated rules under one broad condition. 6. **Wrap domain sections** — testing, API patterns, state management, i18n, etc. each get their own block with a condition describing when that knowledge matters. 7. **Delete linter territory** — remove style guidelines, formatting rules, and anything enforceable by tooling. Suggest replacing with pre-push or pre-commit hooks. 8. **Delete code snippets** — replace with file path references. 9. **Delete vague instructions** — remove anything like "leverage the X agent" or "follow best practices" that isn't concrete and actionable. ## Example Input: ```markdown # CLAUDE.md This is an Express API with a React frontend in a Turborepo monorepo. ## Commands | Command | Description | |---|---| | `turbo build` | Build all packages | | `turbo test` | Run all tests | | `turbo lint` | Lint all packages | | `turbo dev` | Start dev server | | `turbo storybook` | Start Storybook | | `turbo db:generate` | Generate Prisma client | | `turbo db:migrate` | Run database migrations | | `turbo analyze` | Bundle analyzer | ## Project Structure - `apps/api/` - Express REST API - `apps/web/` - React SPA - `packages/db/` - Prisma schema and client - `packages/ui/` - Shared component library - `packages/config/` - Shared configuration ## Coding Standards - Use named exports - Use functional components with TypeScript interfaces for props - Use camelCase for variables, PascalCase for components - Prefer `const` over `let` - Always use strict equality (`===`) - Use template literals instead of string concatenation - Write JSDoc comments for all public functions - Use barrel exports in index.ts files ## API Development - All routes go in `apps/api/src/routes/` - Use Zod for request validation - Use Prisma for database access - Error responses follow RFC 7807 format - Authentication via JWT middleware ## Testing - Jest + Supertest for API tests - Vitest + Testing Library for frontend - Test fixtures in `__fixtures__/` directories - Use `createTestClient()` helper for API integration tests - Mock database with `prismaMock` from `packages/db/test` ## State Management - Zustand for global client state - React Query for server state - URL state via `nuqs` ``` Output: ```markdown # CLAUDE.md Express API + React frontend in a Turborepo monorepo. ## Project map - `apps/api/` - Express REST API - `apps/web/` - React SPA - `packages/db/` - Prisma schema and client - `packages/ui/` - Shared component library - `packages/config/` - Shared configuration Run with `turbo` from the repo root. | Command | What it does | |---|---| | `turbo build` | Build all packages | | `turbo test` | Run all tests | | `turbo lint` | Lint all packages | | `turbo dev` | Start dev server | | `turbo storybook` | Start Storybook | | `turbo db:generate` | Regenerate Prisma client after schema changes | | `turbo db:migrate` | Run database migrations | | `turbo analyze` | Bundle analyzer | - Use named exports (no default exports) - Use functional components with TypeScript interfaces for props - All routes go in `apps/api/src/routes/` - Use Zod for request validation - Use Prisma for database access - Error responses follow RFC 7807 format - Authentication via JWT middleware - API: Jest + Supertest - Frontend: Vitest + Testing Library - Test fixtures in `__fixtures__/` directories - Use `createTestClient()` helper for API integration tests - Mock database with `prismaMock` from `packages/db/test` - Zustand for global client state - React Query for server state - URL state via `nuqs` ``` What was removed and why: - camelCase/PascalCase, const vs let, strict equality, template literals, JSDoc, barrel exports — linter and formatter territory, or discoverable from existing code patterns - Coding Standards as a grouped section — split into targeted blocks by trigger condition What was NOT removed: - All commands kept (including dev, storybook, analyze) - Project map left bare (foundational context, relevant to every task) ## Licence of the file above The file above is https://raw.githubusercontent.com/dexhorthy/slopfiles/main/plugins/improve-claude-md/skills/improve-claude-md/SKILL.md, by Dex Horthy, reproduced without changes. - Source: https://github.com/dexhorthy/slopfiles/tree/main/plugins/improve-claude-md/skills/improve-claude-md - Copyright: Copyright (c) 2026 Dex - Licence: MIT, https://raw.githubusercontent.com/dexhorthy/slopfiles/main/LICENSE The repo's licence file, verbatim from https://raw.githubusercontent.com/dexhorthy/slopfiles/main/LICENSE: MIT License Copyright (c) 2026 Dex Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.