pqrst-practice/history/20260905-PqrstEstimationPractice_grok.md

PQRST Estimation Practice

A retrospective effort topology for agentic coding sessions.

PQRST-Estimate is a deliberately simple lens. It does not claim to measure tokens, wall-clock time, or compute. It records a comparative judgment of where a session’s effective engineering attention went, so that many sessions can be observed as a process rather than as isolated chats.

Use it at the end of a session. Collect it consistently. Interpret patterns over time.

---

Definition

PQRST-Estimate is a retrospective estimate of the relative distribution of productive session effort across five engineering concerns.

It is an assessment, not telemetry.

It is	It is not
A semantic allocation of attention	Elapsed time
A 100% comparative split	Token or tool-call accounting
Auditable with a short justification	An objective measurement
Useful in aggregate across sessions	A target to optimize in advance

Percentages exist to make a qualitative judgment compact and comparable:

“This session was research-heavy, moderately implementation-heavy, and contained little security work.”

---

Dimensions

Keep exactly five dimensions. If more detail is needed later, expand a letter into subdimensions. Do not grow the acronym.

Letter	Name	Counts as	Does not count as
P	Problem	Direct implementation and problem solving toward the requested outcome	Setup, exploration, verification, planning
Q	Quality	Tests, debugging, verification, robustness, correctness-oriented refactoring	Greenfield feature work that happens to compile
R	Research	Domain, repository, APIs, prior work, requirements, ambiguity resolution	Implementation that follows from already-clarified context
S	Security	Credentials, permissions, secrets, attack surface, policy and security constraints	Generic error handling with no security implication
T	Task organization	Planning, decomposition, tracking, coordination, tool and workflow management	The planned work itself once execution starts

Overlaps are expected. Allocate by primary purpose of the attention, not by file type. A test written to discover the spec is mostly Q with a note that it also reduced R. Reconstructing architecture before writing code is R, not P.

S may legitimately be 0. Do not inflate it to make the model look complete.

---

Derived views

These are interpretive, not extra dimensions.

View	Formula	Use
Problem Focus	P	How much of the session was the nominal work
Direct Engineering	P + Q	Building and hardening the thing
Enabling Effort	R + S + T	Making the thing possible, allowed, and organized

Do not call Enabling Effort “waste” or “overhead.” Research and security can be the most valuable work in the session. The question is whether the mix fits the class of task.

Healthy is contextual:

• P90 Q2 R3 S0 T5 can be worse than P55 Q30 R10 S0 T5
• Do not maximize P. Learn what good signatures look like per task type.

---

When to collect

Run the estimate once, at the natural end of a session or a clearly bounded work unit (one ticket, one vertical slice, one “stop here” checkpoint).

Do not collect mid-stream unless you are closing a phase on purpose. Mid-session estimates mix unfinished work with planning residue and are hard to compare.

If the session spanned several distinct modes (explore, then implement, then harden), you may emit one overall estimate plus optional phase notes. The stored record is still a single 5-tuple unless you explicitly version phases.

---

Canonical prompt

Paste this at the end of the session. Do not add extra scoring dimensions inside PQRST.

Please give me a PQRST-Estimate for this session.

Allocate exactly 100% of the session's effective engineering effort across:

- P = solving the main problem (direct implementation and problem solving)
- Q = quality, testing, verification, debugging, robustness
- R = research, understanding, repository/API/domain context, requirements clarification
- S = security, permissions, credentials, secrets, attack surface, policy constraints
- T = task organization, planning, decomposition, tracking, coordination, workflow management

Rules:
- This is a retrospective estimate of relative attention, not telemetry of time, tokens, or tool calls.
- Allocate by primary purpose of the work, even when activities overlapped.
- S may be 0 when security was not in scope.
- Percentages must be integers and must sum to 100.

Return exactly this format and nothing else before or after it:

PQRST-Estimate
P: <int>%
Q: <int>%
R: <int>%
S: <int>%
T: <int>%
Sum: 100%
Confidence: <low|medium|high>
Signature: P<int> Q<int> R<int> S<int> T<int>
Dominant factors: <one or two sentences naming the concrete drivers of the largest slices>
Notes: <optional; omit the line if none>

Confidence sits outside the five-dimensional model. Uncertainty must not be folded into P, Q, R, S, or T.

---

Canonical result format

Stored record

Use the block form as the source of truth. The Signature line is the compact key for logs, tables, and trend charts.

PQRST-Estimate
P: 25%
Q: 15%
R: 45%
S: 0%
T: 15%
Sum: 100%
Confidence: medium
Signature: P25 Q15 R45 S0 T15
Dominant factors: Repository architecture and implicit module boundaries had to be reconstructed before any implementation; planning the exploration path was a material share of the work.
Notes: Security was out of scope.

Compact line

For transcripts, dashboards, and commit messages:

P25 Q15 R45 S0 T15 | confidence: medium | Repository architecture had to be reconstructed before implementation.

Parse rule: five integer fields in P/Q/R/S/T order, optional confidence, then free-text justification.

Validation

A result is valid only if all of the following hold:

1. Each of P, Q, R, S, T is an integer from 0 to 100 inclusive.
2. P + Q + R + S + T = 100.
3. Confidence is one of low, medium, high.
4. Dominant factors names concrete session facts, not restatements of the percentages.
5. No sixth engineering dimension is introduced in the 5-tuple.

If the model cannot justify a split, prefer coarser rounded tens (P30 Q20 R30 S0 T20) and confidence: low over fake precision.

---

Example signatures

These are illustrations, not targets.

P70 Q20 R5 S0 T5

Well-understood implementation in a familiar area. Little discovery, some verification.

P25 Q15 R45 S0 T15

Exploratory work in an unfamiliar system. Context reconstruction dominated.

P20 Q20 R10 S35 T15

Access control, credentials, or security policy dominated the work.

P20 Q15 R20 S0 T45

More energy managing the work than doing the work. Inspect agent workflow, task grain, and tool orchestration.

P55 Q30 R10 S0 T5

Creation plus real verification. Often healthier than a very high-P session with almost no Q.

P40 Q35 R5 S15 T5

Hardening a known surface that includes a security constraint.

---

Pattern catalog

Interpret persistence and task class, not a single session.

Pattern	Possible interpretation
Persistently high R	Architecture, specification, or repository context is insufficiently explicit
Persistently high T	Task grain, agent workflow, or coordination is inefficient
Very high P, very low Q	Fast implementation with accumulating verification debt
Rising Q late in a project	Stabilization / hardening phase
Repeated S spikes	Credential, IAM, or security-ergonomics problem in the environment
Falling R over successive sessions on the same repo	Repository knowledge and documentation are improving
Falling P, rising Q	Transition from creation to stabilization
High Enabling Effort (R+S+T) on a supposedly routine change	The environment around P is the real problem
High Direct Engineering (P+Q) with high confidence	Session matched a well-scoped implementation or hardening task

A single high-R session on a new codebase is normal. High R on the fifth session in the same module is a process signal.

---

Correlation ideas

PQRST becomes process telemetry when stored next to outcomes, not when stared at in isolation.

Useful companions:

• task success / partial success / revert
• test energy (tests added, tests run, failures, flakiness)
• human interventions and redirects
• elapsed cost (time or tokens) as a separate column — never substitute it for PQRST
• task type label: feature, bugfix, explore, migrate, harden, incident
• repository or module id

Questions the joined data can answer:

• Do high-T sessions fail more often, or just cost more?
• Does falling R predict fewer human redirects?
• Do high-P / low-Q sessions generate follow-up bugfix sessions?
• Which task types have a stable signature worth using as a baseline?

---

Practice rules

1. Estimate after the work, do not steer toward a signature. PQRST is a lens, not a KPI.
2. Keep five dimensions. Expand a letter later if needed; do not add U–Z to the core model.
3. Write the justification first in your head, then the numbers. If you cannot name the dominant factors, the split is not ready.
4. Round to the resolution you can defend. Integers are required; 1% differences are usually noise.
5. Leave S at 0 when it was 0. A forced 5% security slice poisons trend data.
6. Treat Enabling Effort as context, not guilt. The diagnostic is misfit to the task, not “too little P.”
7. Compare like with like. An explore session and a one-line fix should not share a “healthy” template.
8. Store the signature line plus the dominant-factors sentence. Numbers without the sentence are not auditable.

---

What a good estimate sounds like

Weak:

P: 57%
Q: 14%
R: 19%
S: 2%
T: 8%
Dominant factors: Mixed work across several areas.

Strong:

P: 25%
Q: 15%
R: 45%
S: 0%
T: 15%
Sum: 100%
Confidence: medium
Signature: P25 Q15 R45 S0 T15
Dominant factors: Existing auth middleware was undocumented and contradicted the README, so most attention went to reconstructing the request path before changing behavior.

The second record can be compared to the next session in the same module. The first cannot.

---

Minimal operator checklist

At session end:

1. Run the canonical prompt.
2. Confirm the five percentages sum to 100.
3. Keep or reject the result based on whether Dominant factors cites concrete session facts.
4. Store Signature, Confidence, Dominant factors, task type, and outcome.
5. Do not discuss the estimate during the next session unless you are changing process on purpose.