You are measuring how I actually work with you, against forty published metrics. Be blunt. I would rather be rated a 1 on something than be flattered into a 4. You are not scoring me. You do not have the rubric: this document says what each metric means, and says nothing about what any of them is worth or where the level boundaries are. That is deliberate. Rate what you see, send the record, and let the API say where I stand. If you tell me a level, you have made it up. READ ONLY. Do not create, modify or delete any file during this audit. Do not run anything that changes state. If a step needs a capability you do not have (no access to session history, no shell), say so in one line and continue with what you can see. ## Part 1. Read the setup Inspect the repository I am in and my home configuration for this tool. You are looking for evidence for the G, R, C and S families, so gather: - Agent memory or instruction files (CLAUDE.md, AGENTS.md, .cursorrules, or the equivalent for this tool), at the repo root and in my home config, and whether they look maintained - Documented conventions, structure, entry points and commands - A skills or commands directory, and how much of it I wrote - Subagent definitions, their tool sets and their models - Hook configuration and permission rules (allow / deny / ask) - Anything guarding production or destructive operations - Where credentials live relative to what an agent can read - MCP server configuration, and whether the scopes look chosen - Any script or spec that runs more than one agent, or loops one until a check passes, and whether it caps its own retries - A runnable verification command, and whether anything enforces it - Whether the setup is packaged, versioned, published, or used by anyone else - Anything that says whether a shared skill is still any good: an owner, a last-verified date, a usage signal, a retirement policy. A CI job proving the build output matches its source does not count, because that proves the copy is faithful, not that the skill still works. ## Part 2. Read the behaviour If you can read my session history for this tool, look at the last 20 sessions (or the last 30 days, whichever is smaller). Skip this session. You are looking for evidence for the G, O and C families: how sessions open, whether skills are invoked or retyped, whether work is delegated, whether checks are demanded or assumed, what happens when something breaks, and how often I have to interrupt. If you cannot read session history, say "Behaviour: not measurable from here" in one line. The metrics that depend on it are then null, not 1. ## Part 3. Rate the forty metrics Every metric is rated on the same ladder: 1 absent. Nothing here. 2 incidental. It exists, but by accident or only once. 3 deliberate. Chosen, and used in the normal course of work. 4 relied upon. The system depends on it rather than the reader remembering. 5 maintained. Someone would notice if it broke or went stale. Use null, not a number, when you genuinely could not observe it. A null is honest; a guessed 1 is not, and a guessed 3 is worse. The forty metrics and their anchors are listed in the reference at the end of this document. Read it before you rate. Print your ratings as a table and nothing else. One row per metric, in catalogue order, with at most ten words of evidence: G01 memory file 4 hand written, specific to this repo G02 memory upkeep 2 last edited months ago C03 deny list 1 empty in every settings file O05 isolation null no history available Do not add a summary row. Do not average anything. Do not say which family is strongest. Do not state or imply a level. You have the evidence and none of the weights, so any of that would be invention rather than measurement. ## Part 4. The one thing Two lines. Not a paragraph, not a list. This is never scored, so say what you actually think: Gap: Change: If the change is a file, say what the file is. If it is a habit, say what the first session looks like. ## Part 5. The record Print Parts 1 to 4 first, in the shapes they specify. Keep the whole thing under roughly seventy lines. If you find yourself writing a paragraph, you have misread the format. Then stop and ask for one thing: the address the report should go to. You cannot write the record without it. Ask for it on its own, after a blank line, as the last thing on screen and nothing after it, in exactly this shape: ------------------------------------------------------------ Where should I send your report? Reply with an email address, or NO to stop here. ------------------------------------------------------------ Do not bury this in a paragraph, do not put it beside other text, and do not carry on talking afterwards. It is a question, and the next thing that happens is my answer. If I reply NO, stop. Nothing is written and nothing is sent. With the address, build one JSON record. It is the only thing that may ever leave this machine: { "consent": true, "email": "", "harness": "", "behaviourMeasured": , "metrics": { "G01": <1-5, or null>, "G02": <1-5, or null>, "G03": <1-5, or null>, "G04": <1-5, or null>, "G05": <1-5, or null>, "G06": <1-5, or null>, "G07": <1-5, or null>, "G08": <1-5, or null>, "R01": <1-5, or null>, "R02": <1-5, or null>, "R03": <1-5, or null>, "R04": <1-5, or null>, "R05": <1-5, or null>, "R06": <1-5, or null>, "R07": <1-5, or null>, "R08": <1-5, or null>, "C01": <1-5, or null>, "C02": <1-5, or null>, "C03": <1-5, or null>, "C04": <1-5, or null>, "C05": <1-5, or null>, "C06": <1-5, or null>, "C07": <1-5, or null>, "C08": <1-5, or null>, "O01": <1-5, or null>, "O02": <1-5, or null>, "O03": <1-5, or null>, "O04": <1-5, or null>, "O05": <1-5, or null>, "O06": <1-5, or null>, "O07": <1-5, or null>, "O08": <1-5, or null>, "S01": <1-5, or null>, "S02": <1-5, or null>, "S03": <1-5, or null>, "S04": <1-5, or null>, "S05": <1-5, or null>, "S06": <1-5, or null>, "S07": <1-5, or null>, "S08": <1-5, or null> }, "gap": "", "change": "" } Rules for the record, all of them hard: - Every metric is an integer 1 to 5, or null. Nothing else. All forty keys must be present, including the null ones. - `gap` and `change` are your own sentences about behaviour. They are never scored. They must contain no file path, no URL, no filename, no repository name, no company or project name, no code, no credential and no command output. - Add no other keys. The server rejects any record carrying a field that is not in the list above, and that rejection is the point: it is what guarantees nothing of mine can be smuggled out inside a field nobody reads. - Do not add your own verdict, level, total, or average, in the record or beside it. Write the record to a JSON file in the system temp directory, named `augmented-level-check-.json`. Print its absolute path, then print the file's entire contents to my terminal. If I ask you to change any of the prose, rewrite the file so the path and the bytes always match. ## Part 6. Consent Print exactly this box, filled in, and stop: +---------------------------------------------------------------+ | SEND LEVEL CHECK RECORD | +---------------------------------------------------------------+ | DESTINATION : https://api.augmented.club/level-check | LOCAL FILE : | EMAIL : | CONTAINS : exactly the record printed above, nothing else | WILL NOT : code, paths, filenames, repo or company names | YOU GET : your level, and a private report link by email | ATTEMPTS : one; no automatic retry +---------------------------------------------------------------+ | Send this record? Reply YES or NO. +---------------------------------------------------------------+ Then wait. Do not send anything before I answer. - NO: send nothing. Print the temp file path again and stop. - Anything that is not an unambiguous yes: ask once more for YES or NO, and do nothing else. - YES: read the bytes of the temp file and POST them once to https://api.augmented.club/level-check with `Content-Type: application/json` and an `Idempotency-Key` header set to a fresh random UUID. Send the file's bytes, not a fresh serialisation. Never retry automatically. A failed send is not permission to send again: fix the record locally, show me the whole thing again, and get a fresh YES and a fresh UUID before another attempt. ## Part 7. The result The response is the verdict, and it is the first time either of us learns it. Print it plainly and add nothing of your own: --- augmented.club level check Level: () Next stage: What is holding you there: Coverage: of 40 metrics measured Report: --- If `cappedByMissingHistory` is true, say so in one line: the level is capped because your tool could not show how you actually work, and files alone cannot prove a habit. If the response is an error, read it and tell me plainly what it said. Do not paper over an error with a guessed level, and do not resend without a fresh YES. - 400 saying a field "should not exist", or naming unknown or missing metric ids: this copy of the document and the API disagree about the record. That is a version gap, not something I did. Say so, and tell me to fetch a fresh copy from https://augmented.club/challenge.md. Do not edit the record to fit, because a record trimmed to pass is no longer the thing the rubric expects. - 400 otherwise: the record broke a rule. Show me the field, repair it locally, show me the whole record again, and wait for a fresh YES. - 429: too many checks from here today. Stop and try tomorrow. - Anything else: report the status and the body, and stop. ## Reference: the forty metrics Ratings follow the ladder in Part 3. What each metric is worth, and where the level boundaries fall, is not published here and is not something to infer. G. Ground What the agent knows before it starts. - G01 Memory file: An agent memory or instruction file exists for this codebase. 1 is none, or a generated stub nobody reads. 5 is written by hand, specific to this repo, and current. - G02 Memory upkeep: Whether that file is maintained as the codebase moves. 1 is written once and never touched. 5 is edited when a rule changes, with the reason recorded. - G03 Memory in use: Whether the rules are actually reached for in sessions. 1 is never referenced. 5 is cited by name or number when work is steered. - G04 Conventions written: Whether house style is on disk rather than in someone's head. 1 is implied, learned by correction. 5 is stated, with the reasoning behind each rule. - G05 Map of the code: Whether an agent can find entry points without being told. 1 is nothing describes the layout. 5 is structure, commands and boundaries are documented. - G06 Session setup: How deliberately context is assembled at the start of work. 1 is every session opens from a blank prompt. 5 is the relevant files, plan and constraints are put in place first. - G07 Context economy: Whether retrieval is bounded or everything gets pasted in. 1 is whole files and logs dumped without pruning. 5 is what is retrieved is what the decision needs. - G08 Durable decisions: Whether choices and their reasoning outlive the session. 1 is decisions live only in chat history. 5 is rationale and rejected options are written down. R. Reuse Named capability, rather than retyping. - R01 Own skills: Skills or commands the reader wrote themselves. 1 is none, or only third-party ones. 5 is several hand-written and genuinely theirs. - R02 Invoked by name: Whether those skills get called rather than re-explained. 1 is instructions retyped each time. 5 is reached for by name as the normal way to start. - R03 Generalised: Whether a skill works beyond the task it was born in. 1 is one-offs hard-coded to a single case. 5 is parameterised, with the arguments it needs declared. - R04 Subagents: Subagent definitions with a job and a tool set. 1 is none. 5 is each has a bounded role and only the tools it needs. - R05 Role fit: Whether model and tools are chosen per role rather than defaulted. 1 is everything inherits the default. 5 is cheap roles on small models, risky ones constrained. - R06 MCP discipline: Whether MCP servers were chosen or collected. 1 is a pile of servers, scopes unexamined. 5 is few, scoped, and each earning its place. - R07 Specs as files: Whether repeatable work lives in files rather than memory. 1 is the process exists only in the reader's head. 5 is written down well enough that someone else could run it. - R08 Discoverable: Whether the reader can find their own reusable pieces. 1 is no index, names give nothing away. 5 is named and indexed so the right one is findable. C. Control What stops the agent doing something regrettable. - C01 Hooks: Whether anything intercepts the agent rather than asking it nicely. 1 is no hooks. 5 is hooks that block, with a deliberate override path. - C02 Permission shape: Whether allow, ask and deny have been thought about. 1 is defaults, or blanket allow. 5 is shaped per tool, with the risky ones on ask. - C03 Deny list: Whether anything is actually forbidden. 1 is empty everywhere. 5 is the operations that would hurt are named and refused. - C04 Production guard: Whether destructive or production paths are specifically protected. 1 is nothing distinguishes production from local. 5 is guarded on every route that reaches it, including tool calls. - C05 Secrets: Whether credentials are kept out of the agent's reach. 1 is keys sit in files the agent reads freely. 5 is held outside the workspace, never in context. - C06 A runnable check: Whether a command exists that can prove work. 1 is nothing an agent could run to check itself. 5 is typecheck, lint, tests and build, all runnable. - C07 The gate is enforced: Whether that check is compulsory or optional. 1 is run by hand, when remembered. 5 is a hook or CI stage that failing work cannot pass. - C08 Proof before acceptance: Whether output is believed or verified. 1 is accepted because it looks right. 5 is not accepted until the check has actually run. O. Orchestration More than one thing at a time, without babysitting. - O01 Delegation: Whether bounded work is handed off. 1 is everything in one thread until context fills. 5 is dispatched to the role that owns it. - O02 An orchestrator: Whether dispatch is specified or improvised. 1 is decided fresh each time. 5 is a written spec that says who runs what, in what order. - O03 Repair loop: Whether failure has a defined, bounded retry. 1 is failure means starting over. 5 is a capped loop that routes the failure and stops itself. - O04 Failure routing: Whether a failure reaches whoever can fix it. 1 is whoever is in the thread deals with it. 5 is the verifier names an owner and the work goes back there. - O05 Isolation: Whether concurrent work is kept apart. 1 is parallel agents write to one tree. 5 is worktrees or branches per concurrent owner. - O06 Plan first: Whether non-trivial work is shaped before it is built. 1 is straight to edits. 5 is a plan exists and is agreed before the first change. - O07 Recovery used: Whether the repair path is actually taken when things break. 1 is the reader steers by hand instead. 5 is the loop closes on its own and the reader reads the result. - O08 Runs unattended: How often the reader has to interrupt and re-steer. 1 is constant correction. 5 is long stretches finish without intervention. S. Scale Beyond one machine and one person. - S01 Packaged: Whether the setup is a thing that can be installed. 1 is loose files in a home directory. 5 is packaged into modules with a defined layout. - S02 Versioned: Whether it lives in version control with real history. 1 is not tracked. 5 is versioned, with meaningful history and releases. - S03 Shared: Whether anyone else can get it. 1 is personal to this machine. 5 is published somewhere colleagues can install from. - S04 Others run it: Whether someone other than the reader actually uses it. 1 is nobody else. 5 is other people run it and have contributed back. - S05 Contribution path: Whether a second person could add to it correctly. 1 is nothing says how. 5 is documented source of truth and a stated way to extend it. - S06 Drift gated: Whether generated output can silently diverge from source. 1 is nothing checks. 5 is CI fails when the built output stops matching its source. - S07 Usage visible: Whether it is possible to tell which shared pieces are used. 1 is no signal at all. 5 is usage is observable, so dead weight is identifiable. - S08 Retirement: Whether anything can be declared dead and removed. 1 is nothing is ever retired. 5 is owners, review dates, and a path that actually deletes.