Brevity is the amount of wording used to obtain the required output from a prompt. The goal is minimum effective length, not the shortest possible request. Routine tasks may need only essential parameters; specialized or high-stakes work may need more detail to prevent generic results and rework. section 3.3
Edit a prompt by separating useful specifications from expendable wording:
- Keep concrete requirements, constraints, and success criteria that affect the output. section 3.3
- Remove repeated politeness, restated instructions, and generic requests for polish. section 3.3 section 3.3.2
- Start brief, inspect what is missing, then add only specifications that close observed gaps. section 3.3.2
CI/CD architecture diagram
Instead of a polite request for a clean diagram with whichever services seem appropriate, specify the task and required elements: “Generate a clean CI/CD analytics architecture diagram. Include a source control webhook receiver, build orchestrator, test-results service, artifact registry, metrics pipeline, PostgreSQL for metadata, and object storage for build logs.” The extra words name components rather than repeating the request. section 3.0
Brevity works alongside precision and directness: length controls how much is said, precision controls how specifically requirements are stated, and directness controls whether instructions are implicit or explicit. A compact prompt can still be precise and direct. In a reusable template, compact instructions can also coexist with input parameters and a fixed output format. section 3.0 section 5.2.1
Judge an edit by the output it produces, not word count alone. For a telemetry diagram, a brief request can preserve the essential pipeline by naming components and labeling ingestion and backpressure flows. Add failure handling or review annotations only when those are needed. This avoids paying for filler while retaining detail that improves the deliverable. section 3.3.2 section 3.3
