Answering with an assistant

Most of the interesting questions on a scorecard ask about something the person answering would have to go and look up — how the deploy pipeline actually works, whether onboarding is really written down, what the churn number was last quarter. Asked to recall it, people guess, and self-assessments come back flattering.

Every published scorecard is also readable as plain text, so the person answering can hand it to their own assistant — one that can look at the repo, the documents, the dashboard — and get answers grounded in what is actually there.

There is nothing to install and nothing to connect.

The plain-text version

Any published scorecard is available at its own URL with .md on the end:

https://app.dimensionkit.com/scorecards/your-scorecard-slug.md

It opens as plain text in any browser. It lists every question with its options lettered A, B, C, and carries instructions written for an assistant rather than a person.

Option scores are deliberately left out. An assistant that can see which option is worth the most has been given a reason to pick it, and a scorecard answered that way is worth less than no scorecard at all.

How someone uses it

1. They open the .md link and copy the whole page.
2. They paste it into Claude, ChatGPT, or whatever they use, with whatever context that assistant has — their codebase, their drive, their analytics.
3. The assistant works through the questions and gives them back a single line of answers, plus a link.
4. They open the link, land on your scorecard with every answer already filled in, correct anything the assistant got wrong, and submit.

They see your scorecard, your branding, and your results page exactly as any other respondent does. Nothing is recorded until they press the button.

Answers a human still confirms

The link never submits anything. It opens a review screen: every question, the answer the assistant chose, and a way to change it.

That matters for what lands in your submissions. An assistant told to answer honestly will sometimes not be able to — it has no way of knowing how your client’s team handles disagreement. When that happens it is told to leave the question unanswered rather than guess, and those questions block the submit button until the person answers them themselves.

So a submission that arrives this way was drafted by an assistant and asserted by a person, question by question.

Seeing which submissions came in this way

Submissions carry a Channel column in the admin table, recording which of the three ways someone reached the scorecard:

Channel	What it means
Direct link	Answered on the scorecard’s own page
Embed	Answered inside an embed on someone’s site
Assistant	Drafted by an assistant, confirmed on the review screen
Unknown	Recorded before this was tracked

The column is hidden by default — turn it on from the column toggle above the table. The separate Source domain column tells you which site an embed ran on; Channel tells you how the person got there at all.

If the scorecard changes

The answer line is tied to the exact version of the scorecard it was generated against. Add a question, reword one, reorder a dimension, and every position in that line shifts.

Rather than quietly applying the answers to the wrong questions, a link generated against an older version is refused, and the person is told to get a fresh copy of the scorecard text. Nothing is half-filled.

This is worth knowing if you are editing a live scorecard while someone is partway through answering it — they will need a new .md copy.

What this is not

This is not a way for an assistant to submit on someone’s behalf without them. There is no API key, no connector, and no unattended path from an assistant to a recorded submission — the review screen is always in the way, and the usual spam protection still applies because the person submits from the normal form.

If you want an assistant to build and manage your scorecards rather than answer them, that is the MCP server.