tegwick
c580bf63c9
The answer to the capability question was conditional: keep both fields if
they carry the required/observed distinction, fix the terminology if they do
not. They did not.
Section 9 opened with "records known requirements or observations", mixing
both in one field — `models` was observational ("known to be compatible or
evaluated") while `capabilities` was prescriptive ("expected from the
execution environment"). Section 10 then described dependencies as what a
prompt "expects". Both fields said expected, so the overlap was real
ambiguity rather than redundancy, and the fix is terminology.
`dependencies` now means **required**; `compatibility` means **observed**. A
consumer must not refuse to run a package because its environment is absent
from a compatibility list. The same capability name may legitimately appear in
both: required to run at all, and separately observed to work well on
particular models. `compatibility.aliases` records the same capability under
other names, so a consumer can recognize a requirement its environment labels
differently.
Dependencies now have three kinds, separated by what the format can do about
them: `prompts` it resolves by id and version; `context` names what it does
not package at all; `capabilities` are what the environment must be able to
do. Context entries use `name` rather than `id`, because nothing can look them
up, and `description` is required because nothing else can explain an
unpackaged dependency. A capability takes no version and no
`requirement: generate` — it is not an artifact and cannot be fetched, pinned
or generated. Capability names are free-form kebab-case, validated for shape
and not membership, exactly as tags are.
Section 10.1 also draws the line the format had never stated: an input is
content the caller passes for one use; a context dependency is a standing fact
about the environment.
Spec: 9 rewritten, 9.1 and 10.1 and 10.2 new, 10 reframed, 18 (rules 19-20),
4 updated. Former 10.1/10.2 renumbered to 10.3/10.4 with cross-references.
Reference CLI: validate_capabilities, validate_context_dependencies, and a
`resolve` section listing required capabilities and context under "this tool
cannot verify these" rather than implying it checked. Tests 51 -> 65.
Also drops an invented `session-review` capability from the example package in
favour of an honest `long-context` observation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjefh8NUiEiahN4JLwoSKM
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 388925@bnt-lap001
Assistant-Session: 3507023f-e0fd-4a1e-9d90-a0d4217d1502
53 lines
1.2 KiB
YAML
53 lines
1.2 KiB
YAML
format: canned-prompt/v0.1
|
|
id: practice/pqrst-estimate
|
|
name: PQRST Estimate
|
|
version: 0.2.0
|
|
summary: 'Produce a post-session estimate of effort distributed across the PQRST categories
|
|
for an agentic coding session.
|
|
|
|
'
|
|
type: template
|
|
template: prompt.md
|
|
dependencies:
|
|
prompts:
|
|
- id: practice/house-style
|
|
version: '>= 0.1.0'
|
|
requirement: required
|
|
inputs:
|
|
- name: house_style
|
|
type: content
|
|
required: false
|
|
description: 'Shared house-style block, composed from practice/house-style.
|
|
|
|
'
|
|
default:
|
|
include: practice/house-style
|
|
- name: session_summary
|
|
type: content
|
|
required: true
|
|
description: 'Session transcript, summary, or sufficiently detailed account of the
|
|
work performed during the coding session.
|
|
|
|
'
|
|
parameters:
|
|
include_rationale:
|
|
type: boolean
|
|
default: true
|
|
description: Explain the evidence behind the estimate.
|
|
output:
|
|
format: markdown
|
|
description: A 100% PQRST effort allocation with concise interpretation.
|
|
compatibility:
|
|
capabilities:
|
|
- long-context
|
|
tags:
|
|
- pqrst
|
|
- retrospective
|
|
- agentic-coding
|
|
- effort-estimation
|
|
provenance:
|
|
author: canned-prompts seed
|
|
examples:
|
|
- examples/basic.yaml
|
|
evals:
|
|
- evals/quality.yaml
|