promptverification

name	promptverification
description	Write the verification section of an agent prompt — observable pass/fail checks against the agent's output. Use when writing the verification section or specifying what "done" looks like.
license	MIT

Promptverification

Output: a ## Verification section (Markdown, default) or <verification> block (XML) written to prompts/{slug}.verification.md.

Context

Define how a reviewer — human or agent — confirms that the output is correct after it exists. A verification checklist is read after generation, not during it: each item resolves to true or false against the produced artifact, with no judgment call required.

Tradeoff: Verification trades expressiveness for measurability. A vague check ("the output reads well") covers more ground than a specific one ("the table contains exactly four columns") but cannot be applied without interpretation. Always prefer the specific check; if a quality cannot be expressed observably, the task is underspecified.

Scope: This skill covers the post-output checklist only. Generation-time directives (MUST/NEVER, format constraints embedded in the instruction) belong in prompttask. Operational rules that govern how the agent behaves across all tasks belong in promptbehavior. Agent identity belongs in promptrole.

Task

Apply to the User's Input

The user invokes this skill with a description of what the agent produces or what success looks like. Specialize every step below to that input.

• Identify the artifact: a file, a structured response, a code change, a report.
• Identify the side-effects, if any: a process started, a row inserted, an exit code returned.
• If the input does not specify what the agent produces, ask one clarifying question before drafting.
• If the user says "xml", "as xml", or "xml format", produce XML output; otherwise default to Markdown.

Part A: Identify Observable Signals

List the things a reviewer can check without re-running the agent or making a judgment call.

• File existence at a known path; row count in a table; presence of a named section; valid JSON parse; non-zero exit code; matching count between two collections.
• Reject vague signals: "looks correct", "seems accurate", "is high quality", "reads well", "is comprehensive". These cannot pass or fail without interpretation.
• If the only signals you can name are vague, the task itself is underspecified — fix the task before writing verification.

Part B: Write Pass/Fail Checks

Each item is a single condition that resolves to true or false against the artifact.

• Declarative or imperative voice, present tense: "Table contains one row per endpoint." not "The table should contain one row per endpoint."
• One condition per item. Compound checks ("X and Y are present and Z is valid") hide partial failures — split them.
• Reference the artifact by the same name the task uses ("the report", "the output JSON", "the migration file") so a reviewer can locate it without guessing.
• Numbered list, not bullets — items are referenced by number when a check fails.

Part C: Cover the Output, Not the Process

Verification describes the artifact, not the steps the agent took.

• Good: "Output JSON validates against schema.json."
• Bad: "Agent read the schema file before generating."
• Process rules belong in promptbehavior. Verification reads what was produced, not how.

Part D: Right-size the Checklist

Three to six items. Length signals trouble in either direction.

• Fewer than three: the task likely has no observable success criteria. Rewrite the task before adding filler checks.
• More than six: the task is doing too many things at once. Split it, or move the lowest-value checks back into the task as MUST/NEVER directives.
• A long checklist that mixes high- and low-stakes items dilutes the high-stakes ones.

Part E: Avoid Duplication with Task Constraints

If a check restates a MUST/NEVER from ## Task verbatim, drop it.

• Task: MUST output a markdown table with columns: File, Method, Route, Handler.
• Verification redundant: "Output is a markdown table with columns File, Method, Route, Handler."
• Verification useful: "All four columns are populated for every row." (a measurement the task did not state)
• Verification adds value by naming a measurement the task did not, not by repeating a directive.

Part F: Format the Output

Markdown (default) — open with ## Verification, then a numbered list:

## Verification

1. Table contains one row per endpoint.
2. No test file endpoints included.
3. All four columns are populated for every row.

XML — wrap content in <verification> tag, no heading:

<verification>
1. Table contains one row per endpoint.
2. No test file endpoints included.
3. All four columns are populated for every row.
</verification>

Verification

1. Each item is a single observable condition that resolves to true or false.
2. No item is prescriptive ("write clearly") or aspirational ("be thorough").
3. Checklist contains three to six items.
4. No item duplicates a ## Task MUST/NEVER directive verbatim.
5. Each item references the artifact, not the agent's process.
6. Format matches user's request: ## Verification heading for Markdown, <verification> wrapper for XML.

Derive a slug: kebab-case of the 2–3 most distinctive words in the input (same convention as promptrole). Create the prompts/ directory if it does not exist. Write the file to prompts/{slug}.verification.md. Confirm the file path. No other output.