When a prompt should become a team procedure

A prompt becomes a team procedure when the same request is repeated often enough that people need shared expectations, not just a clever instruction. The sign is not that the prompt is long. The sign is that mistakes repeat when the steps are not written down.

## Repeated use
If several people use the same prompt to review releases, summarize user feedback, triage bugs, or prepare support replies, the work deserves a stable checklist and examples.

## Risk of inconsistent output
A procedure is useful when different wording changes the result too much. It should name required inputs, output shape, review criteria, and what to do when information is missing.

## Review ownership
Someone should own the procedure. Without ownership, prompt notes become stale quickly. The owner does not need to approve every use, but they should update examples when failures appear.

## Keep it small
A good procedure is shorter than a manual. Include the purpose, inputs, steps, examples, and stop conditions. If it grows too large, split the work instead of hiding complexity in one prompt.

When a prompt should become a team procedure

// COMMENTS

ON THIS PAGE