standing
Skill0 starsChanged 2 months agoMITView on GitHub
Report where the user actually stands, from evidence. Reads the last N Claude Code session transcripts plus git, extracts the work that shipped and the invisible work that did not leave a diff, compares it against a trailing baseline from the user's own history (and an industry source only when a cited one exists in the repo), and states objective progress with every number tied to an instrument and a time window. Use when the user asks "how am I doing", "am I making progress", "where do I stand", "was this week worth it", or is comparing themselves to others in their field. Never invents a benchmark; says Unknown when it cannot measure.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- iskron-ai/skillstheir own version, first seen Oct 9, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- iskron-ai/skills★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 53
If the directory does not exist, say so, fall back to git only, and mark every transcript-derived field Unknown.
- Distinctive: line 57
Read the N transcripts inside the window and pull out, with a timestamp and session id for each:
- Distinctive: line 118
Keep it short. Show the evidence, place it next to the feeling, stop.
- Distinctive: line 122
Not from tone. From three moves the distortion skips:
- Distinctive: line 128
If the record is thin, the report is thin.
- Distinctive: line 136
Arguing with the feeling: Put the table next to it.
- Very specific: line 147
If a run of this skill emits a number with no instrument and window beside it, or names an industry figure that is not in …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Standing
Try It Now
At the end of a week, in any git repository you have been working in with Claude Code:
/standing how am I doing this week, honestly?
You get a read of the last week from your transcripts and git: what shipped, what was learned, how it compares to your own trailing month, and what is still open. Every number names where it came from and what window it covers.
mirror answers "did I do anything today?" from git alone. standing answers the bigger question, "am I getting anywhere?", which ADHD brains answer by comparison, usually against an imagined peer who ships every day. That comparison is where the distortion hides: the peer is invented, the window is cherry-picked, and the invisible work is left out. This skill replaces the imagined peer with two things that can be checked: your own trailing baseline, and, when one exists, an industry source you have written down with a citation.
The point is accurate positive reinforcement, not comfort. A number the user cannot trace gets discounted just like the feeling it was meant to counter. So the rule is simple: every claim points at an instrument, and every number names its window. If the instrument cannot answer, the answer is Unknown, not a guess.
When to fire
- "How am I doing?" / "Am I actually making progress?" / "Where do I stand?"
- "Everyone else is further along." / "People in my field ship X a week."
- "Was this week / month / sprint worth anything?"
- Any request to compare the user's output to others, a field, or their past self.
Skip when the user wants a code review, a plan, or today's mirror (that is mirror). Skip when the user is celebrating; do not audit a good mood.
Inputs
| Input | Where it comes from | Default |
| N sessions | Claude Code transcripts for this project | 5 sessions, or every session in the window if fewer |
| Window | User's words, else the transcript timestamps | 7 days ending now |
| Baseline | The user's own git history before the window | trailing 28 days before the window start |
| Industry source | docs/standing/benchmark.md in the repo, if present | none; report Unknown |
The protocol
1. Locate the transcripts (do not ask the user where they are)
Claude Code writes one JSONL file per session under ~/.claude/projects/<slug>/, where <slug> is the absolute working directory with every / replaced by -. Find them:
slug=$(pwd | sed 's#/#-#g')
ls -t ~/.claude/projects/$slug/*.jsonl | head -n 5Each line is a JSON object. The rows that matter have "type":"user" or "type":"assistant", a timestamp, a cwd, a gitBranch, and a message.content that is either a string or a list of blocks with text. Ignore rows with isSidechain: true (subagent chatter) and rows whose type is anything else (settings, mode, summaries).
If the directory does not exist, say so, fall back to git only, and mark every transcript-derived field Unknown. Do not reconstruct sessions from memory.
2. Extract the work, in four buckets
Read the N transcripts inside the window and pull out, with a timestamp and session id for each:
- Shipped. Commits, pushes, deploys, published posts, sent deliverables. Cross-check every one against git:
git log --since=<window start> --format='%h %ad %s' --date=iso. A commit named in a transcript but absent from git is not shipped; say which. - Written but uncommitted.
git status --porcelainandgit diff --statat the time of the run. Real work that tomorrow's git log will not show. - Invisible work. Decisions made, dead ends ruled out, bugs understood before they were fixed, things learned. These come from the transcripts only. Quote the line or tool result that proves each one; no quote, no entry.
- Open. Things the transcripts show were started and not finished, with the last state observed.
A number quoted from a transcript (a file size, a page count, a figure the user or a prior run stated) is evidence that the claim was made, not that it is true. Label it "quoted, not re-measured" unless you re-run the instrument this session. File and line counts in the report come from a command you ran now (wc -l, find ... | wc -l, git diff --stat), and the command is named beside the count.
Count only what is in the record. If a session was mostly the user thinking out loud and nothing landed, the record says that, and so does the report.
3. Build the baseline from the user's own history
The baseline is the user's own trailing period, not a made-up field average. Measure the same things over the 28 days before the window with the same instruments:
# Full ISO timestamps only. Relative dates ("7 days ago") reach back an extra
# evening, and a bare date ("2026-08-29") is filled in by git with the CURRENT
# time of day, so the same command gives a different count an hour later.
git log --no-merges --since=2026-08-01T00:00:00 --until=2026-08-29T00:00:00 \
--format='%cd' --date=short | sort | uniq -cState the exact --since and --until you passed, in the report, next to the window label. The label and the command must agree. Cut weeks on the same weekday as the window start and say so; a median moves with the cut.
Derived numbers (a percentage, a median, "best week") show their arithmetic inline: "55 vs median 40, so +38%". A derived number without its inputs is a number without an instrument.
Report window and baseline side by side, always with the instrument and dates:
| Measure | Window (dates) | Baseline (dates) | Instrument |
| Commits | 6 (2026-09-01 to 2026-09-07) | 4.5/wk median (2026-08-04 to 2026-08-31) | git log --format=%ad |
| Days with a commit | 4 of 7 | 3.2 of 7 median | same |
| Sessions | 5 | Unknown, transcripts pruned | transcript file count |
A window that beats the baseline is progress and gets said plainly. A window below the baseline gets located, not excused: fewer days worked, a bigger task, an interrupt-heavy week. The transcripts usually show which.
4. Bring in the industry source only if it is cited
Look for docs/standing/benchmark.md. If it exists, it must contain, per claim: the number, the source URL or document, the publication date, the population it measured, and the window. Use only claims that carry all five. Quote the claim with its citation, then place the user's window against it with the population difference stated ("their sample is funded teams of four; you are one person").
If the file is missing, or a claim lacks a citation, the industry comparison is Unknown. Say exactly that: "No cited industry source in this repo, so I am not comparing you to the field. Your own trailing month is the benchmark below." Do not fill the gap from training data. A recalled statistic about "average developers" is a hallucination in this context, and it is the failure mode this skill exists to prevent.
5. Report
Lead with the verdict in one sentence, then the evidence. Label every claim:
- Verified: a transcript quote, a commit hash, a file path, a command and its output.
- Inferred: a reading of the evidence, said as a reading.
- Unknown: the instrument could not answer.
Shape:
- Standing (one sentence, labeled).
- Shipped (Verified list, hash and date each).
- Invisible work (Verified list, one quote each).
- Window versus baseline (the table from step 3).
- Versus the field (cited claim, or the Unknown sentence).
- Open, right-sized (what is incomplete, with its last observed state; "incomplete" is not "failed").
- One next action, sized to fit in one session.
Keep it short. Show the evidence, place it next to the feeling, stop.
Where the "glass half full" comes from
Not from tone. From three moves the distortion skips:
- Counting the invisible. Ruling out a wrong approach is progress. Understanding a bug is progress. The transcript is the only place this work leaves a trace, which is why this skill reads transcripts and
mirrordoes not need to. - Choosing the honest window. A bad Tuesday against a good month is a bad Tuesday. The baseline makes the month visible.
- Replacing the imagined peer. Either there is a cited source, and the population difference is stated, or there is no peer in the report at all.
If the record is thin, the report is thin. An honest "one decision and one commit, on a two-hour week" holds up tomorrow. A padded one does not.
Anti-patterns
- Quoting a field average from memory. Any number without an instrument in this report is a defect, not a rounding.
- Widening the window to rescue the number. The window is what the user asked for or the default. Say what it is; do not move it.
- Reading a self-report as evidence. An assistant turn that says "done" is a claim. The commit, the push, the file is the evidence.
- Counting subagent chatter as sessions.
isSidechain: truerows are not the user's work. - Arguing with the feeling. Put the table next to it.
- Turning it into a plan. One next action, not a roadmap.
Known limits
- Transcripts are per machine and per project directory. Work done elsewhere is Unknown, and the report says so.
- Claude Code may prune old transcripts; the baseline session count is often Unknown for that reason. Git is the durable instrument.
- The industry comparison depends entirely on the user maintaining
docs/standing/benchmark.md. Without it the skill is a self-relative instrument, which is the honest default.
Kill criterion
If a run of this skill emits a number with no instrument and window beside it, or names an industry figure that is not in docs/standing/benchmark.md with a citation, the skill has failed at its one job. Fix the protocol before running it again.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

