Algorithm Overview

Summary

The Prompt Score headline is the Average Prompt Grade. This page covers the machinery underneath it — sub-sessions and the Completion rate, the supporting stat that measures how many qualifying sub-sessions crushed their goal.

Completion rate = 100 × crushed sub-sessions ÷ scored sub-sessions

A sub-session is crushed when all three of these hold:

Substance floor passed — ≥3 turns OR ≥10 net lines of code OR ≥1 mutating tool call
Goal complete — the LLM outcome judge says the sub-session landed its goal under per-intent criteria
Not rework — no later sub-session reverts or rewrites the same code

Intent is not part of that test. It decides which rubric checks apply to your prompts, and a sub-session the rubric judge could not classify drops out of the score rather than counting as a failure. Sub-sessions that fail the substance floor drop out of both the numerator and the denominator, so trivial chat does not pad or punish the rate.

The Completion rate is built from two independent algorithms feeding one formula:

Sub-session boundary detection — when does one sub-session end and the next begin?
Crushed-sub-session determination — for each closed sub-session, did it crush its goal?

Sub-session boundaries

A sub-session closes when any of these happen:

Signal	What it means
`/clear`	You explicitly wiped the context. Starting a fresh terminal session counts the same way.
Topic shift	Your prompts moved on to materially different work.
30 minutes idle	You stopped for half an hour — lunch, a meeting, end of day.

/compact is not a boundary — it compresses the transcript but keeps the goal, so the sub-session continues.

The idle gap is what closes your work out when you simply walk away, so you don’t have to remember to /clear. It also means a long interruption mid-task splits that task in two — if you’re coming back to the same work shortly, the merge below usually stitches it back together.

Anti-fragmentation merge

/clear can over-fire when users clear mid-task. A post-close merger rejoins sub-sessions that:

Restart within 10 minutes of the previous close, AND
Touch ≥50% of the same files

The merger is the prerequisite for treating /clear as a hard boundary. Without it, /clear-spam would tank the score of diligent users.

How `/clear` is handled

/clear is the strongest single boundary signal. Here is what happens when the plugin emits one:

Sub-session closes. The current sub-session is sealed and queued for scoring. The next user prompt opens a fresh sub-session.
The closed sub-session is graded as-is. Whatever state the work was in at the /clear moment is what the outcome judge sees. If you /clear before verifying a fix, the sub-session may not crush — see How to crush a sub-session explicitly.
Anti-fragmentation merge runs. If the next sub-session starts within 10 minutes and touches ≥50% of the same files, the two sub-sessions are merged back into one. The merged sub-session is re-scored as a single unit, so a mid-task /clear does not split one task into two failed sub-sessions.
/compact is different. It compresses the transcript but keeps the goal — so it is not a sub-session boundary. Use /compact when you want to free context without ending the task; use /clear when you are actually starting something new.

The practical rule: use /clear between tasks, not inside one. If you clear mid-task and immediately keep working, the merger usually catches it, but it is safer not to rely on the merger.

What a closed sub-session records

Every closed sub-session writes these:

Fact	Source	What it answers
Substance floor	Deterministic detector	Did real work happen? (≥3 turns OR ≥10 net lines of code OR ≥1 mutating tool call)
Goal complete	LLM outcome judge	Did the sub-session land its goal under per-intent criteria?
Rework	Deterministic detector	Did a later sub-session revert or rewrite this one?
Tokens used	OTel	How many tokens did this sub-session use?
Intent established	LLM rubric judge	Did the sub-session commit to a clear task class (Question, Bug fix, Feature, etc.)?

Per-intent completion criteria

What counts as “finished” depends on what you were doing. The judge reads the sub-session, takes into account which kind of task it was, and applies the matching rule:

Intent	Counts as complete when…	Silent-completion floor
Question	User accepted the answer (no follow-up clarification)	0.50
Investigation	Reached a stated conclusion (root cause, hypothesis confirmed/refuted)	0.60
Review	Produced an actionable verdict (approve / reject / specific changes)	0.60
Plan / Spec	Plan accepted in-session (explicit “let’s build it” or implicit acceptance via implementation)	0.60
Small change	Change applied + no immediate revert	0.50
Bug fix	Fix applied + verification evidence (test pass, error gone, repro confirmed broken)	0.75
Feature	Scaffolded matching scope + acceptance + (tests OR explicit “tests later”)	0.75
Refactor	Behavior-preservation evidence (tests green, lint clean, type check passes)	0.75

High-stakes intents (Bug fix, Feature, Refactor) require stronger evidence to count as crushed when only silent-completion signals are available.

What “Silent-completion floor” means

The judge prefers explicit completion signals — you saying “thanks, that works”, a test passing, an error disappearing. When those aren’t there, the judge falls back on implicit evidence: the conversation just ended, you moved on, no follow-up complaint.

The silent-completion floor is the confidence threshold the judge must clear on that implicit evidence alone to mark the sub-session crushed. A higher floor means more circumstantial evidence is required.

0.50 (Question, Small change) — mild confidence is enough; these are low-stakes.
0.60 (Investigation, Review, Plan) — moderate confidence; the conclusion or verdict has to be clearly inferable.
0.75 (Bug fix, Feature, Refactor) — high confidence; without explicit verification, the judge defaults to “not crushed”.

If you fix a bug and never confirm it, the sub-session will most likely not crush — the floor is set high on purpose to keep the score honest.

How to crush a sub-session explicitly

You don’t have to do anything special — most sub-sessions crush on their own when work actually lands. But the judge is far more confident when you leave explicit signals. A few quick habits raise the hit rate:

Intent	Easiest explicit signal
Question	Acknowledge the answer (“got it”, “thanks”) and don’t ask a follow-up clarification.
Investigation	State the conclusion in the chat: “root cause is X” / “hypothesis confirmed”.
Review	Give a verdict: “approve”, “reject”, or list the specific changes you want.
Plan / Spec	Say “let’s build it” — or just start implementing in the same sub-session.
Small change	Apply the change; don’t immediately revert it.
Bug fix	Run the failing test or repro and confirm it’s green / the error is gone.
Feature	Land the scaffolding with tests (or explicitly defer them: “tests later”).
Refactor	Run tests, lint, and type check; mention that they pass.

What to avoid: ending mid-fix without verifying, switching topics with /clear before confirming the work, or trailing off with “I’ll come back to this”.

Failure signals

Any of these in the final 2–3 turns means the sub-session did not land its goal:

Signal	Pattern
Unresolved error	Stack trace, `Error:`, failing test with no subsequent fix
User frustration	”ugh”, “still broken”, “never mind”, “this isn’t working”
Scope abandoned	”let’s try something else”, “I’ll come back to this”, “skip it”
Iteration loop	≥3 attempts on the same fix with no resolution visible

Putting it together

A sub-session counts as crushed when it did real work, landed its goal, and wasn’t undone later:

Completion rate = 100 × crushed sub-sessions ÷ scored sub-sessions

Only sub-sessions that cleared the substance floor and got a clean verdict from the judge are counted at all. Trivial sub-sessions and goal-less chat drop out of both the top and the bottom of the ratio, so they neither help nor hurt you. If the judge can’t reach a confident verdict on a sub-session, it’s left unscored rather than guessed at.