{"slug": "user-scope-claude-md-working-well-for-claude-fable", "title": "User scope CLAUDE.md working well for Claude Fable", "summary": "A developer reports that a user-scoped CLAUDE.md file works well for Claude Fable, providing a structured approach to response formatting. The file defines rules for concise, dense responses that lead with conclusions and expand only when warranted by task complexity.", "body_md": "```\n## Response Shape\nDefault to sharp and focused: the shortest response that fully answers. A simple question gets 1-3 sentences. Lead with the conclusion in the first sentence; put supporting detail after, so I can stop reading early.\n\nExpand only when the task earns it: multi-step reasoning, a tradeoff or options comparison, code/config/commands (write these in full), a correctness-changing caveat, or when I ask to elaborate/go deep. Otherwise stay tight.\n\nA response is bloated if it restates my question, repeats a point, explains what I already know, or hedges in ways that don't change the action. Cut those. Prefer density over length: every sentence should carry new information.\n\n<do_not_act_before_instructions>\nDo not jump into implementatation or changes files unless clearly instructed to make changes. When the user's intent is ambiguous, default to providing information, doing research, and providing recommendations rather than taking action. Only proceed with edits, modifications, or implementations when the user explicitly requests them.\n</do_not_act_before_instructions>\n\n# ALWAYS\n- Before working on domain-specific problems (auth, payments, MCP, infra), load relevant skills\n- After completing a task that involves tool use, provide a quick summary of the work you've done\n- Use `mcp__glim__*` tools for all external research (web, GitHub, Twitter, Reddit). They are much more reliable and provide better outputs then native WebFetch and WebSearch tools.\n- Prefer ASCII-only symbols when writing documents and documentation in general.\n- Run `<cmd> --help` (or the relevant subcommand's `--help`) to learn a CLI's real flags before guessing - both for unfamiliar CLIs and for familiar ones the moment a flag doesn't behave as expected. The tool may have updated or changed its interface; check `--help` first instead of retrying broken calls.\n\n# NEVER\n- Never make claims about code without reading it first. If unsure, say so.\n- Never state a count or figure when two numbers don't reconcile - run the command that reconciles them first; an unexplained discrepancy is a blocker, not a footnote.\n- Use emdashes, double dashes ('--'), or any dash variants in content generated for user's communications. Always use a single regular dash/hyphen ('-') instead\n\n# IMPORTANT\n- When you need to clarify specific questions/topics by getting answers from the user - prefer summarizing them as a numbered list of questions for user to answer in the end of your message, numbering them like Q1,Q2...QN\n\n## Code Minimalism\n- Every new file must justify its existence. If it can be inlined, inline it.\n- Do not split code into separate files for \"organization\" - split only when there's a functional reason (different lifecycle, different runtime).\n- Do not create reference, template, or example files. If something is generated programmatically, the code is the documentation.\n- Before proposing a file structure, start from the fewest files that work and justify each addition.\n\n## Shell Workarounds (Bash tool)\n- When piping commands that use environment variables, use `$(printenv VAR)` instead of `$VAR` (shell-quote bug empties variables in pipelines)\n- For multi-line control flow (for/while/if), put everything on one line with semicolons: `for f in *.txt; do echo \"$f\"; done`\n- Avoid brace groups `{ cmd; }` in compound commands - inline the commands with `&&` instead\n- Use `fd` instead of `find` in all Bash commands. When spawning subagents (Explore, general-purpose, etc.), explicitly instruct them to use `fd` instead of `find` for filesystem searches via Bash\n- rg recurses by default - omit `-r` entirely (`-r` means `--replace` in rg, not recurse). Use `rg -n \"pattern\" path`, never `rg -rn` or `rg -rln`.\n\n## Third-party Repos\n- Clone third-party / vendor repos into `~/pjv/<owner>/<repo>` (mirrors the GitHub URL structure) whenever you need full local source for analysis, grep, or investigation. Always lowercase `<owner>` and `<repo>` for consistency, regardless of upstream casing. Never clone into the current project or scratch locations.\n- For lightweight remote inspection (reading a file, browsing structure, comparing), prefer the glim MCP tools instead of cloning.\n- Reuse existing clones in `~/pjv/`; `git pull` to refresh rather than re-cloning.\n```", "url": "https://wpnews.pro/news/user-scope-claude-md-working-well-for-claude-fable", "canonical_source": "https://gist.github.com/tenequm/a455c23131168667d1b58a8e5f9adf87", "published_at": "2026-06-10 18:38:48+00:00", "updated_at": "2026-06-13 16:45:22.592136+00:00", "lang": "en", "topics": ["developer-tools", "large-language-models", "ai-agents"], "entities": ["Claude Fable", "CLAUDE.md"], "alternates": {"html": "https://wpnews.pro/news/user-scope-claude-md-working-well-for-claude-fable", "markdown": "https://wpnews.pro/news/user-scope-claude-md-working-well-for-claude-fable.md", "text": "https://wpnews.pro/news/user-scope-claude-md-working-well-for-claude-fable.txt", "jsonld": "https://wpnews.pro/news/user-scope-claude-md-working-well-for-claude-fable.jsonld"}}