# 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. ```text 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: % Q: % R: % S: % T: % Sum: 100% Confidence: Signature: P Q R S T Dominant factors: Notes: ``` 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. ```text 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: ```text 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. ```text P70 Q20 R5 S0 T5 ``` Well-understood implementation in a familiar area. Little discovery, some verification. ```text P25 Q15 R45 S0 T15 ``` Exploratory work in an unfamiliar system. Context reconstruction dominated. ```text P20 Q20 R10 S35 T15 ``` Access control, credentials, or security policy dominated the work. ```text P20 Q15 R20 S0 T45 ``` More energy managing the work than doing the work. Inspect agent workflow, task grain, and tool orchestration. ```text P55 Q30 R10 S0 T5 ``` Creation plus real verification. Often healthier than a very high-P session with almost no Q. ```text 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: ```text P: 57% Q: 14% R: 19% S: 2% T: 8% Dominant factors: Mixed work across several areas. ``` Strong: ```text 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.