canned-prompts/examples/pqrst-estimate/prompt.md

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>
{{ add_ons }}