11 Claude Tips from the Viral Thread — Tested Live
A post appeared on r/ClaudeAI with the title “11 things I wish someone had told me 12 months ago.” It climbed to nearly 1,300 upvotes with 121 comments. The author has 18 months of daily Claude use, including six months in Claude Code. That’s a signal worth paying attention to — but upvotes don’t prove anything works.
So I tested every tip live. Here’s what actually held up, what needed a caveat, and the patterns worth stealing right now.
What you need
A Claude.ai account with access to Projects, Claude Code installed locally, and an API key if you want to replicate the Artifacts tip. Familiarity with basic prompting helps but isn’t required — the techniques here range from UI settings to Claude Code subagents.
Tips 1–3: Projects, Custom Styles, and Memory
Projects as persistent context. The author says they wasted roughly 100 hours re-pasting context before discovering Projects. That tracks. Drop your codebase overview, stack decisions, and key constraints into a Project once, and every chat in that project inherits it. No more “here’s what we’re building” at the top of every session.
Custom Styles — the “skeptical senior eng” style. The author calls this the single biggest output quality jump they got, and it took three minutes to set up. Build it in the Custom Styles UI: instruct Claude to push back on design decisions, ask about edge cases, and flag anything that looks like it was copied from a tutorial. Run a real code review with it. The difference from the default style is immediate — responses get sharper and more confrontational in exactly the way a good code review should be.
Memory is on by default. Worth checking. Claude.ai’s memory settings toggle lives in preferences and is easy to miss entirely. Toggle it off, run a session, toggle it back on, and compare what Claude surfaces. The behavioral difference is real enough to be worth knowing which state you’re in.
Tips 4–6: Search, Model Selection, and Haiku for Batch Work
Searching past chats. The author describes querying by natural language — something like “what was the final auth setup we decided on?” — and getting accurate retrieval. This works, but the quality depends heavily on how much context was in the original conversation. Dense, well-structured chats retrieve cleanly. Meandering sessions with lots of topic-switching are harder to query.
Model selection by task type. The author recommends Claude Sonnet for most things and Claude Opus for gnarly architectural work. Running both on the same hard design problem confirms the pattern: Sonnet is faster and handles 80% of tasks without a noticeable quality drop. Opus earns its place when you’re making decisions that ramify — system boundaries, data models, anything you’ll live with for months.
Claude Haiku for batch work. If you’re generating multiple short outputs (drafting five variations of a function docstring, producing a batch of test cases), Haiku is noticeably faster and the quality gap for structured, constrained tasks is small. The tradeoff breaks down for anything that requires judgment or nuance — don’t use it for architectural review.
Tips 7–9: Voice Mode, CLAUDE.md, and Skills
Mobile voice mode for thinking out loud. Narrate a technical problem while walking, let Claude summarize the key decisions at the end. The transcript is rarely perfect but it’s a surprisingly useful thinking tool. The author’s framing — “thinking out loud” rather than “dictating instructions” — is the right mental model.
CLAUDE.md doing more work than the prompts. The author’s phrasing: “write 80 lines of project context once, stop re-explaining your stack every session.” This is the tip with the highest leverage. Here’s a starter block:
# Project Context
## Stack
- Runtime: Node.js 22, TypeScript strict mode
- Database: PostgreSQL via Prisma
- Auth: JWT with refresh tokens (see /src/auth/README.md)
- Testing: Vitest, coverage threshold 80%
## Conventions
- All API routes return { data, error } — never throw from a route handler
- Prefer explicit error types over generic Error
- No any types without a comment explaining why
## Current focus
- Migrating from REST to tRPC — new endpoints go in /src/trpc, old ones stay until migration complete
- Do not suggest changes to /src/legacy unless I ask
## Reviewer persona
Act as a skeptical senior engineer. Push back on complexity. Ask about edge cases.
Flag anything that looks over-engineered for our scale (10k users).Without this file, Claude treats every session as a blank slate. With it, the first response in any new session already reflects your architecture, your conventions, and your current priorities.
Skills for repetitive workflows. The author describes a skill that detects which file type is open and loads the relevant documentation automatically. This requires more setup than the other tips, but if you have a workflow you run ten times a day, the investment pays back quickly.
Tips 10–11: Subagents and Artifacts Calling the API
Subagents in Claude Code for parallel work. Spin off a subagent to run your test suite while you keep coding. The author’s description is accurate: Claude Code can fork a subprocess, hand it a task, and let it run while the main session continues. The practical caveat is that subagent output can get noisy — pipe it to a log file if you don’t want it interrupting your flow.
Artifacts calling the Claude API — “Claudeception.” The author describes an HTML artifact that calls the Claude API from inside itself. This works. A minimal example: an HTML page with a <textarea> for input, a <script> block that calls the API via fetch, and a <div> to render the response. The artifact becomes a self-contained tool — the author built a client brief generator this way. Here’s the skeleton:
<!DOCTYPE html>
<html>
<body>
<textarea id="input" placeholder="Describe the client..."></textarea>
<button onclick="generate()">Generate Brief</button>
<div id="output"></div>
<script>
async function generate() {
const response = await fetch("https://api.anthropic.com/v1/messages", {
method: "POST",
headers: {
"x-api-key": "<your_api_key>",
"anthropic-version": "2023-06-01",
"content-type": "application/json"
},
body: JSON.stringify({
model: "<claude-model-id>",
max_tokens: 1024,
messages: [{
role: "user",
content: `Write a client brief for: ${document.getElementById("input").value}`
}]
})
});
const data = await response.json();
document.getElementById("output").innerText = data.content[0].text;
}
</script>
</body>
</html>Note: don’t hardcode your API key in a shared artifact. Use this pattern for local tools only.
Where this breaks
A few tips from the thread didn’t hold up cleanly. Past-chat search is inconsistent on older, messier sessions — don’t rely on it for anything critical. Subagents get unwieldy if you spawn more than two or three simultaneously; the output coordination overhead starts to eat the time savings. And the “Claudeception” pattern requires your API key to be present in the artifact, which is fine for local experiments and a security problem the moment you share it.
The 121-comment thread surfaced one tension worth noting: the author’s strong recommendation for Claude Sonnet by default frustrated users on plans that don’t expose model selection in the same way. If you’re on a team plan with locked model settings, tips 4–6 are informational rather than immediately actionable.
Next steps
The meta-lesson from the original post is the sharpest thing in it: if your Claude output feels generic, your prompt was generic. The CLAUDE.md template above is the fastest way to fix that. Drop it into a real project, fill in your actual stack and conventions, and add the reviewer persona that matches the feedback you actually want. One concrete exercise: open your most recent Claude Code session, look at the first message you sent, and ask whether it contains enough context for a new engineer to understand what you’re building. If not, that context belongs in CLAUDE.md.
What’s the tip that took you longest to figure out on your own?
← Back to blog