prompt-engineeringlisted

# Prompt Engineering Treat prompts as small behavioral specs. Improve them by naming the job, testing the behavior, changing one important thing at a time, and preserving the prompt's operating context. ## Activity And Authority - For review, return findings and evidence without rewriting files or changing a deployed prompt. A proposed revision may accompany findings when requested. - For drafting or implementation, change the requested prompt artifact within existing authority. Separate local evaluation from deployments, live tool actions, sensitive-data use, and metered runs that need additional authority. - Use the smallest useful output. A short rewrite need not produce a formal experiment report; a consequential behavior change needs explicit cases and honest evidence. ## Core Workflow 1. **Scope the prompt job.** Identify the target model or provider, audience, runtime surface, inputs, tools, output contract, constraints, and where the prompt will live. If the prompt belongs to a repo, inspect existing prompts, schemas, examples, tool definitions, evals, logs, and docs before asking avoidable questions. 2. **Define success before rewriting.** State the desired behavior, hard requirements, acceptable variation, known failure modes, and evidence that would prove the prompt improved. If success is vague, establish representative cases and meaningful failure criteria before editing. Preserve baseline cases and explain changed expectati