A number is not an instruction
An engineer told their specificity is 6.4 has learned nothing they can act on. An engineer handed the rewritten request has.
Better prompting, measurably better output.
Most tools that look at prompts will tell you a score and stop, which leaves a leader holding a dashboard and no decision. This scores the work six ways, names the specific thing that went wrong, hands back the version that would have worked, and turns the patterns that keep winning into your organisation's default.
Prompt quality
Overall
7.4/10
Reworked
31%
Wasted tokens
18%
Clarity8.2
Specificity7.1
Context6.4
Six dimensions, scored per session and rolled up per engineer
What changes in how work is asked for.
Today
- A score with no instruction attached, which nobody can act on
- Prompt skill spreads by sitting near someone who already has it
- The same weak pattern is repeated across teams for months
With Tetriz
- The specific issue named, with the fix written out
- Coaching drawn from an engineer's own work in your codebase
- Winning patterns promoted into the standard everyone starts from
From a score nobody can act on, to a standard everyone starts from.
Scoring is the easy part and it already exists. The four steps below are what turn it into something that changes output.
Score the work six ways
A single quality number tells you something is wrong without telling you which part.
What Tetriz does here
- Clarity, specificity, context, actionability, completeness, efficiency
Plus an overall, per session, rolled up per engineer and per team.
- So the weak dimension is obvious
A request that was perfectly clear and missing all its context is a different problem from a vague one.
Prompt quality by dimension
Clarity8.2
Specificity7.1
Context6.4
Actionability7.8
Name the issue, not the symptom
Knowing specificity scored low is still not a thing anyone can do on Monday morning.
What Tetriz does here
- A typed issue with a severity
An ambiguous directive, a missing acceptance criterion, internal context the agent could not have seen.
- Pointed at the exact text
So the conversation is about the work rather than about the number.
Prompt issues by severity
| Issue | Severity | Sessions |
|---|---|---|
| Ambiguous directive | Medium | 61 |
| No acceptance criteria | High | 44 |
| Missing internal context | High | 38 |
Hand back the version that works
This is where most tools stop. A diagnosis without a prescription leaves the engineer exactly where they were.
What Tetriz does here
- The rewritten request, in full
Not a principle to apply — the actual improved version, specific to that task and that codebase.
- With the cost of the original attached
The tokens the weaker version burned, so improvement is visible in spend as well as quality.
Impact of recommended rewrites
First-pass
+22pts
Tokens saved
24%
Accepted
81%
Promote what keeps winning
A fix that helps one engineer once is worth very little. The same fix as an org default is worth it every week.
What Tetriz does here
- Patterns become skills and rules
Requests that consistently produce shipped code are codified into your org's prompt library and rules files.
- New engineers inherit it
Someone joining starts from your best-performing pattern instead of assembling one over a year.
Prompt library adoption
In library
23
Engineers
11 of 11
Repos updated
6
Why a score alone changes nothing.
The gap between measuring prompt quality and improving it is the whole of this page.
The fix has to come from your codebase
Generic prompting advice is freely available and does not work, because what makes a request answerable depends on your architecture, your conventions and your naming.
And it only compounds if it leaves the person
Individual improvement plateaus and walks out of the door. A pattern promoted into the org's standard applies to every engineer who arrives after it.
Questions leaders ask about Prompt Engineering.
Clarity, specificity, context provision, actionability, completeness and efficiency, plus an overall score. Each is reported per session and rolled up per engineer and team.
The engineer sees their own scores first. Their manager and organisation leadership see them after that, because a score is something to coach on rather than to rank by, and it should never reach a manager before the person whose work it describes.
You get the improved version alongside the original. Nothing intercepts or edits what an engineer types, and adopting a recommendation is their choice or an admin's.
No. Length is not a dimension. What is scored is whether the request was described well enough to come back usable, which a longer one does not achieve on its own.
Detected, and handled as a security finding rather than a quality one. That surface is Session Security, under Governance.