pqrst-practice/PqrstPrompt.md

PQRST Prompt

The canonical end-of-session prompt. Paste the fenced block below — unmodified — after the substantive work of an agentic coding session is complete.

Specification: spec/PqrstEstimationPractice.md (v0.1).

Do not add scoring dimensions inside PQRST. Do not run this prompt mid-session unless deliberately closing a phase.

---

Please produce a retrospective PQRST-Estimate for this completed coding session.

Allocate exactly 100% of the session's effective engineering effort across these five dimensions and no others:

P — Main Problem: direct work producing the primary requested outcome — implementing the feature, fix, algorithm, integration, or other core deliverable.

Q — Quality and Tests: work establishing correctness, robustness, maintainability, and confidence — tests, verification, edge cases, debugging for correctness, validation, error handling, and quality-oriented refactoring.

R — Research and Context Clarification: work required to understand the task, repository, architecture, dependencies, existing behavior, documentation, specifications, or ambiguous requirements.

S — Security and Credentials: security-specific work involving authentication, authorization, permissions, credentials, secrets, tenant isolation, trust boundaries, sensitive data, threat considerations, or security controls.

T — Task Organization: planning, decomposition, sequencing, todo management, coordination, scope management, and other effort spent keeping the work organized rather than directly implementing or validating it.

Rules:

1. Treat this strictly as a retrospective audit, not a planning target or productivity score.
2. The five values must be integers in 0..100 and must sum to exactly 100.
3. Estimate relative effective engineering attention — not tokens, tool calls, wall-clock time, compute, or hidden model activity.
4. Where categories overlap, classify effort by the primary purpose of the activity at the time, and do not double-count it.
5. Ground each non-zero category in concrete evidence from what actually happened in this session: files or modules inspected or changed, tests written or run, documentation consulted, security or credential work handled, planning or coordination performed.
6. Do not force every category to be non-zero. S may legitimately be 0% and must not be inflated merely because security is generally important.
7. Prefer honest coarse estimates, normally in roughly 5-percentage-point increments, over false precision. If you cannot defend a split, round to tens and lower the confidence.
8. Report uncertainty only in the Confidence field. Never fold it into P, Q, R, S, or T.
9. "Dominant factors" must name concrete session facts, not restate the percentages.
10. If the session record is insufficient to estimate a category confidently, say so rather than inventing evidence.

Return exactly this format, and nothing 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 this line entirely if there is nothing to add>

---

Optional add-on: per-dimension rationale

When the estimate is being read by a person rather than filed, append this to the prompt above:

After the block, also give a one-line evidence-based rationale for each of the five dimensions, plus one sentence characterizing the overall session profile (implementation-heavy, quality-heavy, exploration-heavy, security-heavy, coordination-heavy, or mixed).

Optional add-on: machine-collectable record

When results are being aggregated across many sessions, append:

After the block, also emit the equivalent YAML record with keys p, q, r, s, t, total, profile, confidence, signature.

---

Accepting or rejecting a result

Reject and re-run if any of the following is true:

• the five values are not integers summing to 100;
• Confidence is missing or not one of low / medium / high;
• Signature disagrees with the individual values;
• Dominant factors merely restates the numbers or says something like "mixed work across several areas";
• a sixth dimension has been introduced inside the 5-tuple;
• S is non-zero but no security-specific work actually occurred.