claude-code-tips: fifty numbered habits and the files that ship beside them

The table of contents runs to Tip 49, and the tree holds the files the tips argue for

The repository is written as a numbered list rather than a tool, with entries running from Tip 0 through Tip 49, each one anchored in a table of contents you can jump through. What makes it more than a link dump is the top level of the default branch: `CLAUDE.md`, `GLOBAL-CLAUDE.md`, `TESTING.md`, a `skills/` directory, a `.claude-plugin/` directory, `content/`, `scripts/` and `assets/`. Now line that up with two of the tips themselves. Tip 23 exists to sort out the difference between CLAUDE.md, Skills, slash commands and plugins, and Tip 48 asks you to review code through a TESTING.md document. Both files are present here, alongside a plugin directory and a skills directory. The consequence for a reader is that the four mechanisms are not competing advice, they are four places to put instructions, and a repository can demonstrate all four at once because it has all four.

The status line spends two lines on model, branch and token pressure

Tip 0 is a good one to start with because it attacks the failure everyone hits: losing track of what the session was about and how much room is left. The status line shows the model, the current directory, the git branch when there is one, a count of uncommitted files, sync status with origin, and a visual progress bar for token usage. A second line echoes your last message, truncated, so you can read back what you asked for. The script behind it is `scripts/context-bar.sh`, with setup notes in `scripts/README.md`, and it carries 10 colour themes: orange, blue, teal, green, lavender, rose, gold, slate, cyan and grey. The practical value is that the token bar turns compaction from a surprise into a scheduled event, which is exactly what the later tip about compacting your context proactively assumes you can see coming.

/usage reports the weekly budget per model, and prints every reset in one timezone

Tip 1 covers the built-in slash commands, and typing `/` lists all of them. The one worth knowing first is `/usage`, which renders your rate limit consumption like this:

 Current session
 █████████▌                                         19% used
 Resets 5:39pm (America/Vancouver)

 Current week (all models)
 ██▌                                                5% used
 Resets Sep 6 at 9:59am (America/Vancouver)

 Current week (Fable)
 █████                                              10% used
 Resets Sep 6 at 9:59am (America/Vancouver)

Three things fall out of that layout. The session bar and the weekly bars are tracked separately, so a single long session is not the same budget as a week of small ones. The week is split into an all models bucket and a second bucket labelled Fable, which means weekly consumption is accounted per model rather than as one total, and routing part of your work to a different model spends from a different meter. And in the README sample every reset time is shown in America/Vancouver, the timezone of the author's machine.

Context is treated as a perishable supply, so durable instructions belong in files

The organising metaphor is blunt: Tip 5 compares AI context to milk and says it is best served fresh and condensed. Around it sit the mechanics, namely breaking large problems into smaller ones in Tip 3, compacting the context proactively in Tip 8, and searching through your conversation history in Tip 12 when the record no longer holds what you need. Forking and half-cloning conversations, Tip 21, is the other recovery path. The consequence runs straight through the rest of the repository: if compaction can drop detail you assumed was still there, then anything that must survive a session belongs in a file on disk, which is precisely why `CLAUDE.md` and `TESTING.md` are top level entries rather than blog posts about keeping notes. Tip 28 keeps that file simple and asks you to review it periodically.

Parallel work is carried by git worktrees, terminal tabs and background processes

Several tips attack the same limitation: one conversation, one working directory, one stream of output. Tip 14 introduces git worktrees for parallel branch work, so two tasks can hold two checkouts of the same repository at once without stashing between them. Tip 13 covers multitasking with terminal tabs, and Tip 36 covers running bash commands and subagents in the background so a slow step does not block the prompt. Tip 4 is the supporting habit, using git and the GitHub CLI properly, and Tip 6 covers getting output out of your terminal. The consequence is a bookkeeping cost that the tips do not remove for you: every worktree is another branch and another copy of the working tree, background runs produce output you have to collect yourself.

The write-test cycle is what makes an unattended run survivable

Several tips concern verification and autonomy. Tip 9 asks you to complete the write-test cycle for autonomous tasks, meaning the run has to leave behind something a machine can check. Tip 34 backs it with lots of tests and test driven development, Tip 26 covers mastering different ways of verifying the output, and Tip 48 turns that into a document you review code against. Tip 19 supplies the blast radius, isolated environments for long-running risky tasks, and Tip 15 handles jobs that outlive your attention with manual exponential backoff. The consequence is blunt for anyone tempted to skip the setup: an autonomous run with no tests in the repository has nothing to fail against, so it cannot tell you it broke, and the backoff is manual, which means the operator decides when to retry rather than the tool.

The three most mechanical tips print no command in the README

Near the end of the list sit the tips you would most want to copy and paste: Tip 44 installs the dx plugin, described in the introduction as skills for everyday dev workflows, Tip 45 is a quick setup script, and Tip 49 turns on the concise output style. Tip 46 switches between multiple Claude accounts and Tip 47 turns GitHub into a knowledge base. The repository's `scripts/`, `.claude-plugin/` and `skills/` directories hold the files these tips refer to, and there is also a demo video linked for the multi-Claude workflow with voice input.

Tags trail the branch, and the recorded licence resolves to nothing

Two facts about how this project is packaged matter if you plan to reuse any of it. The recorded licence identifier resolves to no assertion even though a `LICENSE` file sits at the top level of the repository, so automated licence checks and corporate policy scans will not tell you what terms you are accepting when you copy the status line script, the `CLAUDE.md` text, or the skills. And the release tags do not track the branch: v0.26.37 was published on 2026-08-25, v0.26.38 and v0.26.39 both on 2026-08-30, while the last push to the default branch is dated 2026-09-25, and the project is not archived. The consequence is that the newest tag is not the newest content, so if you pin to a release you pin to text from late August, and if you vendor any of it you have to read the licence text yourself rather than trusting the metadata.

Editorial conclusion

Read this repository as a checklist for your own setup rather than as software to install: the two tips that matter most are the ones about verification and about keeping durable instructions in files instead of in a conversation. Do not copy the status line script or the plugin content into a work setup until you have read the LICENSE file yourself, since the recorded licence identifier resolves to no assertion, and fetch the setup instructions from scripts/README.md rather than guessing at the commands.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. ykdojo/claude-code-tips on GitHub