Write a number into CLAUDE.md and it starts dating the moment it lands. Nothing tells you when it's wrong, and the agent reads it back as true.
CLAUDE.md is the onboarding doc every session reads (more on that in Every Session Is Day One), so a stale number in it doesn't get read once. It gets taught every time.
Documentation doesn't always mean hard-coded text.
On one product at work, rather than writing "100 users" in a text file, give the agent a small script that counts the AD users, or the GitHub users in the org. The best context isn't the fact. It's a way to find out.
True the day it was written. After that, nobody knows.
True whenever it runs.
The script
It doesn't need to be clever. Counting members of a GitHub org is one call to the gh CLI.
#!/bin/sh
# Prints how many people are in the GitHub org right now.
set -eu
ORG="${1:?usage: count-org-members.sh <org>}"
gh api --paginate "orgs/$ORG/members" --jq '.[].login' | wc -l | tr -d ' 'Then point at it from CLAUDE.md instead of writing the answer down.
## Numbers that change
Don't trust a user count written anywhere in this repo.
Run `scripts/count-org-members.sh our-org` for the current figure.Same idea: what's deployed where
On a Fabric project we deliberately increment our version every time, and keep a reference to the commit that created it. Then we have a skill in Claude that can go and fetch all the versions, look at the commit history, and know exactly what's deployed and where.
Nobody has to keep a "currently deployed" line up to date. The agent asks.
If your versions are git tags, the starting point for that kind of skill is one command.
# Every version, newest first, with the commit it points at.
git for-each-ref refs/tags --sort=-creatordate \
--format='%(refname:short) %(objectname:short) %(creatordate:short)'Making it standard
A script in one repo helps one repo. I'm hoping that we'll be able to make some of that standard: skills that find out things like how many sites there are or how many GitHub users, so any product that needs it can call them. Or later on, potentially as MCP servers, where we've got a bit more control of access.
Related: No Personal Skills, on where skills should live so the whole team gets them.