tegwick
4986a87773
Merge the two independent 2026-09-05 drafts under history/ into a single normative specification at spec/PqrstEstimationPractice.md (v0.1). Where the sources diverged on the canonical result format, the block/ signature record is adopted as the source of truth and the per-dimension table is retained as an optional presentation form; recorded in the spec's version history. Two rules the sources implied but did not state are added: confidence stays outside the 5-tuple (R9), and no sixth dimension may be introduced (R10). Add PqrstPrompt.md in the root as the canonical end-of-session prompt, pairing the fuller rule list with the strict fixed output block. Add INTENT.md and SCOPE.md framing the repo as the means of closing agentic coding sessions: why the practice exists, its anti-goals, and the boundary that this is a specification-and-prompt repo only — no tooling, storage, harness integration, scoring, or empirical validation. Source drafts under history/ are retained unmodified and are append-only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SQ6oF1DtVDKcD1FCpvRVLx Assistant: claude-code Assistant-Model: opus Assistant-Process: 272883@bnt-lap001 Assistant-Session: f40c8f53-fb65-4980-9d29-bcdb3dd946f7
83 lines
4.4 KiB
Markdown
83 lines
4.4 KiB
Markdown
# 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`](spec/PqrstEstimationPractice.md) (v0.1).
|
|
|
|
Do not add scoring dimensions inside PQRST. Do not run this prompt mid-session unless deliberately closing a phase.
|
|
|
|
---
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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.
|