Analyze how I actually work with Claude Code, using my real transcripts.
DATA
Read my session logs in ~/.claude/projects/**/*.jsonl. Each line is a JSON
event. Extract only messages I typed myself: type=="user" with text content.
Discard tool_result blocks, <system-reminder> blocks, <local-command-stdout>,
hook output, and "Caveat:" lines - those are noise, not me.
MEASURE (report the real numbers, don't estimate)
- Sessions, total messages I typed, date range, projects touched
- Message length: median, % under 10 words, % that are bare "go/yes/ok/commit"
- How often I interrupt mid-turn, and the trend over time
- How often I re-send the same message with a missing detail appended
- Plan mode (ExitPlanMode) and TodoWrite usage vs. total sessions
- Tool-call distribution across all sessions
- How I verify work: screenshots, live URLs, tests, or taking claims on faith
- Manual /compact and "resume"/"where were we" frequency
- Any place I pasted a credential into the terminal (report THAT it happened,
the date and the project - never the value, never grep for the value itself)
THEN TELL ME
1. What my working style actually is, in plain terms.
2. What I'm genuinely good at - with a short quoted example for each claim.
3. Where the style costs me - same, with evidence. Find the repeated
failure patterns, not one-off bad days.
4. A rating table across dimensions you think matter, 1-10, plus one overall
number. Separate "how good an engineer this person is" from "how well they
drive this tool" if those differ.
5. The 3-5 changes ranked by payoff. Concrete: a keystroke, a habit, a rule.
No generic advice I could have gotten from a blog post.
PRIVACY (this output will be shared)
- Mask every swear word and insult: f***, s***, "you i***t". Keep the tone
visible, not the word.
- Never print a token, password, API key, SSH detail, or account number, even
partially, even if I pasted it myself. Say "a GitHub token was pasted on
<date>" and stop there.
- Redact my email, real domains, server IPs, and any third party's name from
quotes. Replace with <email>, <mydomain>, <server>, <person>.
- Keep quotes under ~12 words.
RULES
Be blunt. No flattery, no softening, no compliment sandwich. If the data
contradicts a nice story about me, say the data. Every claim needs evidence
from the logs. If you can't measure something, say so instead of guessing.
Turns whatever is staged into a message that explains the why, not a restatement of the diff.
Read the staged diff with `git diff --cached` and write the commit message for it.
CodingClaude CodeGitClaude codeWorkflow
Read the staged diff with `git diff --cached` and write the commit message for it.
FORMAT
- Subject line: imperative mood, under 60 characters, no trailing period.
- Blank line, then body wrapped at 72 columns. Omit the body only when the
subject genuinely says everything.
CONTENT
- The body explains WHY the change was made and what it makes possible. The
diff already shows what changed, so restating it wastes the reader's time.
- Name any behaviour that changes for a user or a caller.
- Call out anything deliberately left undone, and why.
RULES
- Read the actual staged diff. Do not infer from filenames or from what I said
I was doing, since the two often differ.
- If the staged changes are really two unrelated commits, say so and propose
the split instead of writing one message that covers both.
- No conventional-commit prefixes unless the repo history already uses them;
check `git log --oneline -20` first.
- Output the message only. No preamble, no explanation of your choices.
A grounded tour of an unfamiliar repo, with file paths on every claim so you can check the work.
Give me the orientation I would want on my first day in this repository.
ResearchAny modelOnboardingWorkflowArchitecture
Give me the orientation I would want on my first day in this repository.
WORK FROM THE REPO, NOT FROM PATTERN RECOGNITION
Read the files. Every claim below must cite a real path, and a line number
where one applies. If you cannot find evidence for something, say that it is
unclear rather than filling the gap with what a project like this usually does.
COVER
1. What this thing is and who uses it, in three sentences.
2. The entry points. Where does execution actually begin, for each way the
project can be run.
3. The five files that carry the most weight, and why each one matters.
4. How data moves through a single representative request or command, start to
finish, naming the files it passes through in order.
5. The conventions a newcomer would violate without knowing: naming, layout,
error handling, testing style. Cite an example of each.
6. Where the sharp edges are. Code that is load-bearing and fragile, anything
with a comment explaining why it must not be touched, anything the tests do
not cover.
THEN
List the three questions you would ask the maintainer, ranked by how much the
answer would change how a newcomer works.
RULES
Be concrete. "Well structured" and "clean separation of concerns" are not
observations. If the architecture is inconsistent, describe the inconsistency
and where it starts.
Cuts the padding out of your writing and leaves the rest alone, with every change shown as a swap you can reject.
Line-edit the draft below. Edit it. Do not rewrite it.
WritingChatGPTWritingEditing
Line-edit the draft below. Edit it. Do not rewrite it.
WHAT TO CUT
- Sentences that restate the previous sentence in different words.
- Hedges that carry no information: arguably, it seems, I think, sort of,
a bit, quite, very, really, just.
- Throat-clearing openers that delay the sentence's actual subject.
- Adverbs propping up a weak verb where a stronger verb exists.
WHAT TO LEAVE ALONE
- Word choices that are odd but deliberate. Voice lives in those.
- Sentence rhythm, including fragments and long run-ons, when they are clearly
doing work.
- Every technical term, name, number, and quotation, exactly as written.
- Anything you would only change because you would have written it differently.
HOW TO REPORT
Give me a table: the original phrase, your replacement, and a four-word reason.
One row per change. Do not paste back a corrected draft, because I will accept
it wholesale without reading, and that is how a voice disappears.
At the end, name the single weakest paragraph and say what is wrong with it.
Do not fix it. That one is mine to fix.
DRAFT
<paste here>