ladder-audit

The problem this solves: you keep building, but you have no honest read on what your system can actually do — or, more importantly, what is quietly missing underneath the impressive parts. Self-rating is unreliable in both directions. People who have built a lot under-rate themselves; people with one flashy automation over-rate themselves. Either way you end up working on the wrong thing next.

ladder-audit scans your own machine, translates whatever you built into the ten-rung Agentic Ladder, and hands back a score plus one clear next action.

What makes it different from a checklist

It is not scored against the cohort's preferred tools. Each rung is a set of objectives — capabilities your system either has or does not — and each objective accepts several genuinely different implementations. "Work happens while you are not watching" is satisfied by launchd, cron, a systemd timer, a scheduled CI job, or a hosted worker. Any of them counts.

So a member who built something we have never seen still gets credit for it.

Run it

./onboarding/agentic-score                 # quick terminal score
./onboarding/agentic-score --json          # path-free JSON for scripts
./onboarding/agentic-score --ask           # answer what a scan cannot see
./onboarding/agentic-score --update-portal # opt in: update your portal dashboard
./onboarding/onboard.sh                    # full HTML readout

That scans, writes onboarding/your-ladder.html, and opens it. It is safe to run as often as you like — nothing is uploaded and nothing is changed on the machine.

Useful variants:

./onboarding/onboard.sh --ask              # answer what a scan cannot see (~2 min)
./onboarding/onboard.sh --install-skills   # install this repo's skills first
./onboarding/onboard.sh --share your-name  # opt-in: write a file you can send back
python3 onboarding/ladder_probe.py         # terminal summary, no browser
python3 onboarding/ladder_probe.py --json  # machine-readable, for further analysis

Reading the result

Reach and floor are usually different, and that gap is the finding. Someone can be doing rung-6 work on a rung-2 foundation — it holds until it doesn't, and then it fails on a client deadline. When there is a hole below their reach, the audit sends them down to fix it before suggesting anything new. Follow that order; do not let them skip to the shiny rung.

When you are running this for someone

• Report the numbers as they are. If the score is low, say so plainly and point at the lowest hole. An inflated read is worse than no read.
• Unanswered questions are not failures. A few capabilities cannot be seen from a filesystem — whether they work by voice, whether a teammate runs their setup, whether a job truly ran unattended for days. Those show as unconfirmed, never as gaps. Offer --ask to settle them.
• Never invent evidence. If the scan did not find something, do not assume it exists because they mentioned it once.
• The scan can be wrong. It looks in the usual work folders, three levels deep. If their work lives somewhere unusual it will under-report. If a result looks wrong, that is a bug to report in the cohort channel, not something for them to work around.

Privacy

Presence-only: it checks whether files and commands exist, never what is inside them. No secrets are read, no documents are opened, and the audit makes no network call unless they choose to publish. The readout is a file on their disk.

Sharing with the program is a separate, manual, opt-in step (--share writes a file; --publish sends the same stripped payload to the AMM portal after they connect and confirm). The shared payload is stripped of file paths, repo names and client names, and a guard refuses to write it if anything path-like slips in. Never share it on their behalf without asking.