# here are some tips by the creator of claude code. Will anyt of them be useful fo ## Retrieval Notes - Session id: `0b1e839b-a989-470f-b430-3c0a94ffc05d` - Last activity: `2026-02-02T09:32:31.776Z` ## My Notes <!-- Add your notes here. This section is preserved across syncs. --> ## Conversation ### User here are some tips by the creator of claude code. Will anyt of them be useful for me? I am not a coder but I am wondering if i could use them for philosophy problems. would they were work do you think? Please give me a long, deep, and detailed answer, with lots of options/ideas: as we are in the 'kicking ideas around' stage, I want as much feedback as you can give me so that i have a lot to consider. TEXT: To view keyboard shortcuts, press question mark View keyboard shortcuts Post See new posts Conversation Boris Cherny @bcherny I'm Boris and I created Claude Code. I wanted to quickly share a few tips for using Claude Code, sourced directly from the Claude Code team. The way the team uses Claude is different than how I use it. Remember: there is no one right way to use Claude Code -- everyones' setup is different. You should experiment to see what works for you! 12:32 AM · Feb 1, 2026 · 5.7M Views Boris Cherny @bcherny · Feb 1 1. Do more in parallel Spin up 3–5 git worktrees at once, each running its own Claude session in parallel. It's the single biggest productivity unlock, and the top tip from the team. Personally, I use multiple git checkouts, but most of the Claude Code team prefers worktrees -- it's the reason @amorriscode built native support for them into the Claude Desktop app! Some people also name their worktrees and set up shell aliases (za, zb, zc) so they can hop between them in one keystroke. Others have a dedicated "analysis" worktree that's only for reading logs and running BigQuery See https://code.claude.com/docs/en/common-workflows#run-parallel-claude-code-sessions-with-git-worktrees Boris Cherny @bcherny · Feb 1 2. Start every complex task in plan mode. Pour your energy into the plan so Claude can 1-shot the implementation. One person has one Claude write the plan, then they spin up a second Claude to review it as a staff engineer. Another says the moment something goes sideways, they Show more Boris Cherny @bcherny · Feb 1 3. Invest in your http://CLAUDE.md. After every correction, end with: "Update your http://CLAUDE.md so you don't make that mistake again." Claude is eerily good at writing rules for itself. Ruthlessly edit your http://CLAUDE.md over time. Keep iterating Show more Boris Cherny @bcherny · Feb 1 4. Create your own skills and commit them to git. Reuse across every project. Tips from the team: - If you do something more than once a day, turn it into a skill or command - Build a /techdebt slash command and run it at the end of every session to find and kill duplicated code Show more From code.claude.com Boris Cherny @bcherny · Feb 1 5. Claude fixes most bugs by itself. Here's how we do it: Enable the Slack MCP, then paste a Slack bug thread into Claude and just say "fix." Zero context switching required. Or, just say "Go fix the failing CI tests." Don't micromanage how. Point Claude at docker logs to Show more Boris Cherny @bcherny · Feb 1 6. Level up your prompting a. Challenge Claude. Say "Grill me on these changes and don't make a PR until I pass your test." Make Claude be your reviewer. Or, say "Prove to me this works" and have Claude diff behavior between main and your feature branch b. After a mediocre Show more Boris Cherny @bcherny · Feb 1 7. Terminal & Environment Setup The team loves Ghostty! Multiple people like its synchronized rendering, 24-bit color, and proper unicode support. For easier Claude-juggling, use /statusline to customize your status bar to always show context usage and current git branch. Many Show more Boris Cherny @bcherny · Feb 1 8. Use subagents a. Append "use subagents" to any request where you want Claude to throw more compute at the problem b. Offload individual tasks to subagents to keep your main agent's context window clean and focused c. Route permission requests to Opus 4.5 via a hook — let it scan for attacks and auto-approve the safe ones (see https://code.claude.com/docs/en/hooks#permissionrequest) Relevant people Boris Cherny @bcherny Claude Code @anthropicai Trending now What’s happening Business & finance · Trending #GOLD Sports · Trending #CremoneseInter Sports · Trending Diaz Trending $ETH Show more Terms of Service | Privacy Policy | Cookie Policy | Accessibility | Ads info | More © 2026 X Corp. ### Assistant This is a great question, and I think the answer is: *most of these translate surprisingly well to philosophy work, though the metaphors need adjustment*. Let me go through each systematically, then explore some synthesis ideas. --- ## 1. Parallel Worktrees → Parallel Inquiry Streams **The coding concept**: Multiple isolated copies of a codebase, each tackling a different feature, running simultaneously. **Philosophy translation**: This maps onto several things you might do: **a) Competing interpretations of a text** When reading a difficult source (say, a Heidegger passage or a Merleau-Ponty section), you could spin up 2-3 parallel sessions, each pursuing a different interpretive hypothesis. One reads the passage as making an epistemic point, another as ontological, another as phenomenological-methodological. Each develops its interpretation as far as it can go. Then you compare: which one makes sense of more of the text? Which introduces fewer awkward readings? **b) Thesis vs antithesis** For argumentative work: one session develops the strongest positive case for your view, another session (playing adversary) develops the strongest objection. They don't see each other's work. Then you synthesize. This avoids the problem where the objections you consider are conveniently weak. **c) Parallel project threads** You already have multiple research projects (Generating Philosophy, Typography Aesthetics). Rather than context-switching in one session, you could maintain 2-3 simultaneous sessions, each with its own project context loaded. Pop between them as ideas strike. **d) "Analysis worktree" equivalent** The tip mentions "a dedicated analysis worktree that's only for reading logs." For philosophy: a dedicated session that's only for *reviewing and reflecting on* your other work—reading through past sessions, finding patterns, noticing tensions between projects, without the pressure to *produce* anything. **What you'd need to try this**: Nothing special, really. Just discipline to open multiple terminal windows and keep them focused. The mental shift is treating these as genuinely parallel inquiries rather than "I'll do this later." --- ## 2. Plan Mode for Complex Tasks **The coding concept**: Before implementing, force yourself to specify *what* you're building in enough detail that implementation becomes execution rather than improvisation. **Philosophy translation**: This is directly applicable, maybe even more so than in coding. Philosophy problems are often hard precisely because we dive in before understanding the terrain. **a) Dialectical mapping before drafting** Before writing an argument, use plan mode to: - Identify the target audience's likely starting commitments - Map the logical dependencies (what needs to be established before what) - Anticipate the main objections and where they'd land in the argument - Decide what's in scope and what gets bracketed **b) Reading plans for difficult texts** Before tackling a difficult book or paper: - What questions are you bringing to it? - What do you already think you know about the position? - What would change your mind about the text's significance? - What specific passages are most crucial? **c) The "second Claude as staff engineer" trick** > One person has one Claude write the plan, then they spin up a second Claude to review it as a staff engineer. Philosophy version: Have one session develop a reading of a text or an argument structure. Then spin up a *fresh* session (no prior context) and prompt it as a hostile reviewer: "Here's a proposed argument structure. Find every weakness, every gap, every place where a reviewer would object." The fresh context means it has no investment in the plan—it approaches it cold. **d) "The moment something goes sideways, restart with planning"** When an argument keeps running into the same problem, or an interpretation keeps not quite working: stop. Back up to plan mode. The impulse is to push harder on execution. Often the problem is a flawed plan. **What you'd need**: You already use planning implicitly. The explicit move would be to *always* start complex work with a planning phase, resisting the temptation to dive into drafting. --- ## 3. Invest in CLAUDE.md → "Update so you don't make that mistake again" **The coding concept**: After any correction, have Claude encode the lesson so it doesn't repeat the error. **Philosophy translation**: You already have an elaborate CLAUDE.md! But the specific practice of *after every correction, encoding the lesson* could add: **a) Terminological preferences** Every time you correct me on usage ("don't say 'central' about my ideas") or I conflate concepts you keep distinct, I should offer to encode that. Over time you'd build a thick layer of interpretive corrections. **b) Philosophical commitments register** Not just "don't do X" but "Nick holds Y." If you commit to a methodological principle (e.g., "I think conceptual analysis should be continuous with empirical inquiry") and I violate it, encoding that would prevent future violations. **c) Mistake glossary for specific sources** If we work through a text and I misread it in a particular way, encoding "when reading [Author], don't assume X; they actually mean Y" builds up interpretive guidance. **d) Prompting lessons** When you prompt me poorly and I produce something useless, the tip suggests asking "how could I have prompted you better?" and then encoding *that*. Philosophy prompting is different from code prompting—the lessons would be specific to argumentative and interpretive work. **What you'd need**: The habit of ending corrections with "add this to the knowledge base" or having me offer to do so. The `/evolve` skill already does this, but the trigger would become more frequent. --- ## 4. Skills and Commands → Philosophy Toolbox **The coding concept**: If you do something repeatedly, automate it into a reusable command. **Philosophy translation**: You already have many skills! But there might be gaps. Ideas for new ones: **a) /steelman** Input: a position you disagree with. Output: the strongest, most charitable version of that position. Useful before writing objections—you want to object to the strong version, not a strawman. **b) /objection-scan** Input: a draft argument. Output: the 3-5 most serious objections a referee might raise, ranked by severity. **c) /dialectical-map** Input: a philosophical problem. Output: a structured map of positions, relationships (refutes, builds on, presupposes), key figures, and open questions. **d) /conceptual-debt** (equivalent to /techdebt) Scans a manuscript or session history for: - Terms used inconsistently - Distinctions drawn but never deployed - Promissory notes ("I'll address this later") never redeemed - Arguments that assume premises never established **e) /citation-check** Input: claims you've made about a source. Output: finds and quotes the actual passages, flags any discrepancies. **f) /formalize** Input: an informal argument. Output: a semi-formal rendering (not full logic, but explicit premises and inference steps). Forces clarity about what's being assumed. **g) /analogize** Input: an abstract philosophical point. Output: 3-5 concrete analogies that might illuminate it for readers. **h) /counterexample-hunt** Input: a proposed universal claim or principle. Output: attempts to find counterexamples (real or imagined). **What you'd need**: Write the skill files and commit them to `~/.claude/skills/`. The infrastructure is already there. --- ## 5. Bug Fixing → Finding and Fixing Philosophical Errors **The coding concept**: Point Claude at error logs, say "fix," minimal hand-holding. **Philosophy translation**: "Bugs" in philosophy are: - Internal contradictions - Invalid inferences - Unargued premises - Unaddressed objections - Textual misreadings - Unclear terms **a) Referee report → fix** When you get a referee report: paste it in, say "fix these issues," let me work through them. Similar to pasting a Slack bug thread. **b) Self-review as bug-finding** Before submitting, prompt: "Read this as a hostile reviewer. Find every error, gap, or weakness. Then fix them." Two-phase: identify bugs, then fix. **c) Consistency check across drafts** Point me at multiple documents (e.g., different sections of a book manuscript) and say: "Find any places where these contradict each other or assume inconsistent things." Cross-file bug hunting. **d) "Go fix the failing CI tests" → "Make this survive the objections"** Instead of specifying how to address each objection, say: "Here's the argument, here are the standard objections in the literature. Make the argument survive them." --- ## 6. Level Up Your Prompting **The coding concept**: Challenge Claude, make Claude be your reviewer, explore "how could I have prompted better?" **Philosophy translation**: **a) "Grill me on this argument"** Roleplay as: - A referee at your target journal - A scholar from a different tradition (continental vs analytic) - A specific philosopher whose objection would matter (e.g., "What would Merleau-Ponty say to this argument about perception?") - A skeptical graduate student in the seminar **b) "Prove to me this works"** - "Prove to me this interpretation fits the text"—force me to quote passages that support each move - "Prove to me this objection lands"—force me to spell out exactly where the argument fails - "Prove to me these two claims are consistent"—force me to show how they can both be true **c) Post-mortem on mediocre output** When I produce something flat or unhelpful: "That wasn't useful. How could I have prompted you differently to get something better?" I can often diagnose what went wrong—maybe the prompt was too open, or assumed knowledge I didn't have, or asked for the wrong genre. **d) Roleplay different traditions** Philosophy isn't monolithic. A prompt could specify: "Respond to this as an analytic philosopher focused on logical structure" vs "Respond as a phenomenologist focused on lived experience" vs "Respond as a pragmatist focused on consequences." Different frames surface different issues. **e) "Don't make a PR until I pass your test" → "Don't finalize this draft until I can defend it"** Have me generate objections, then you have to respond. I push back. Only when you've survived the grilling does the draft count as ready. This inverts the usual flow where you generate and I assist. --- ## 7. Terminal and Environment Setup **The coding concept**: Statusline, context visibility, easy session-switching. **Philosophy translation**: Less directly relevant, but: **a) Project context visibility** The statusline could show which project context is loaded (e.g., "typography-aesthetics" vs "generating-philosophy"). Avoids confusion about which frame I'm operating in. **b) Context usage awareness** Knowing how much context window is used matters for philosophy conversations because they accumulate a lot of text. If you're at 90% context and about to paste a long source passage, you'd want to know. **c) Session organization** Dedicated windows/tabs for different inquiry streams (see #1). Clear visual markers so you know which is which. --- ## 8. Subagents **The coding concept**: Spawn separate processes to handle specific tasks, keeping main context clean. **Philosophy translation**: This is underused for philosophy, but powerful: **a) Literature search subagent** Main thread: developing the argument. Subagent: "Find vault notes relevant to [concept]. Report back with quotes and links." Result: main thread gets targeted information without getting distracted by search process. **b) Tangent exploration subagent** Mid-argument, an interesting tangent appears. Instead of following it (and losing the thread), spawn a subagent: "Explore this tangent, report back if it's important." Main thread continues; subagent returns with a summary. **c) Objection development subagent** Main thread: positive case. Subagent: "Develop the strongest version of [objection X]. Don't pull punches." Result: main thread gets a steelmanned objection without having to context-switch to adversarial mode. **d) Consistency check subagent** "Go through my last 5 session notes on this project. Flag anything that contradicts what I'm saying now." Runs in background, returns with concerns. **e) "Throw more compute at the problem"** Complex interpretive questions benefit from multiple passes. "Use subagents" tells me to spawn parallel interpreters, each reading the passage independently, then synthesize. --- ## Synthesis: Novel Combinations for Philosophy Let me suggest a few *novel workflows* that combine multiple tips: ### Dialectical Stress-Test Protocol 1. **Plan mode**: Map the argument structure, identify load-bearing premises 2. **Parallel sessions**: Spawn 3 subagents, each trying to break a different premise 3. **Main thread**: Synthesizes the attacks, strengthens the argument 4. **CLAUDE.md update**: Encode which attack patterns proved most effective for future use ### Interpretation Race 1. **Parallel sessions**: 3 sessions, each assigned a different interpretive hypothesis for a text 2. Each session develops its reading, quotes supporting passages, explains away difficulties 3. **Merge phase**: Compare results. Which interpretation: - Accounts for more of the text? - Requires fewer ad-hoc moves? - Fits better with the author's broader project? 4. **Winner** becomes the working interpretation (with acknowledged weaknesses from the losers) ### Referee Simulation 1. **Plan mode**: Identify which journal you're targeting, its typical reviewer concerns 2. **Subagent as Referee 1**: Hostile reading focused on [X concern] 3. **Subagent as Referee 2**: Different concern [Y] 4. **Main thread**: Revises to satisfy both before actual submission 5. **Skill creation**: If a particular objection pattern recurs, encode it as a `/check-for-X` skill ### Conceptual Deep Cleaning (Weekly) Run `/conceptual-debt` on recent session notes and draft material: - Find terminology drift - Flag unresolved tensions - Identify premises that need argumentative support - Surface abandoned threads that might be worth resuming This would be like the `/techdebt` command but for philosophical hygiene. --- ## What Translates Less Well To be honest about the limits: **Git worktrees specifically**: The technical mechanism doesn't apply. But the *concept* of isolated parallel workspaces translates fine. **CI tests / automated testing**: Philosophy doesn't have automated validity checkers. The nearest equivalent is referee review, which is slow and expensive. We'd have to create manual or prompted approximations. **Slack MCP / paste-bug-and-fix**: Relies on having structured, machine-readable error information. Philosophy "bugs" (bad arguments) don't come in structured form. More interpretation needed. **Docker logs**: No equivalent unless we treat session transcripts as "logs" of intellectual process. --- ## Where To Start If you want to experiment, I'd suggest: 1. **Try plan mode explicitly** for your next complex task (maybe the next Typography Aesthetics session). Force yourself to produce a structured plan before any drafting. 2. **Spin up a parallel adversary session** when you're developing an argument. Don't let it see your positive case—just describe the view and ask it to attack. 3. **Create one new skill** that addresses a frequent pain point. Maybe `/steelman` or `/objection-scan`. 4. **Adopt the "update CLAUDE.md after every correction" habit** for a week and see how the instructions layer up. These are low-commitment experiments. If they help, iterate. If they don't, drop them. --- *È interessante come i pattern del lavoro tecnico si traducano sorprendentemente bene nella filosofia—forse perché entrambi richiedono la gestione di complessità strutturata.* ### User you got cut off, please continue from where you left off. ### Assistant I think my response actually completed—it ended with the "Where To Start" section suggesting four experiments to try, followed by the Italian sentence about how technical work patterns translate to philosophy. But perhaps it got truncated on your end? Here's what the final section was: --- ## Where To Start If you want to experiment, I'd suggest: 1. **Try plan mode explicitly** for your next complex task (maybe the next Typography Aesthetics session). Force yourself to produce a structured plan before any drafting. 2. **Spin up a parallel adversary session** when you're developing an argument. Don't let it see your positive case—just describe the view and ask it to attack. 3. **Create one new skill** that addresses a frequent pain point. Maybe `/steelman` or `/objection-scan`. 4. **Adopt the "update CLAUDE.md after every correction" habit** for a week and see how the instructions layer up. These are low-commitment experiments. If they help, iterate. If they don't, drop them. --- If you *did* see all that and wanted me to go deeper on something specific—a particular tip that seems promising, or a workflow you'd like fleshed out more—just say which and I'll expand. *Dimmi quale idea ti incuriosisce di più e possiamo approfondirla insieme.*