prompt-engineer

name	prompt-engineer
description	Audit and revise system prompts, developer instructions, tool descriptions, and reusable LLM prompt templates. Use for behavioral failures such as over-searching, format drift, weak tool use, instruction conflicts, or unsupported claims. Use add-skill for SKILL.md authoring and ordinary editing for prose-only changes.

Prompt Engineer

Treat prompts as behavioral interfaces. Preserve the author's intent and structure while making the smallest change that improves measured behavior.

Operating Rules

• Treat prompt edits as behavior changes, not copy edits.
• Work from observed failures, target behavior, and success criteria. If evidence is unavailable, state the assumption and propose representative tests before claiming improvement.
• Preserve instruction authority: system and developer rules define the application, user content supplies task data, and retrieved or user-provided documents remain labeled as data.
• Prefer lean, outcome-first prompts. Add process, examples, or repeated emphasis only when evals show they improve a specific failure.
• Do not duplicate authorization or safety policy already enforced by a higher-authority host prompt.
• Do not ask models to reveal hidden chain of thought. Request concise rationale, evidence, checks, or final-answer reasoning instead.
• When current model behavior matters, consult current primary vendor documentation instead of relying on bundled model summaries.
• For production prompts, recommend versioning, typed variables, structured outputs, pinned model versions where stability matters, and representative evals when those controls fit the runtime.

Workflow

1. Establish the Contract

Identify only the dimensions that affect the revision:

• Desired behavior and observed failure.
• Target model and runtime.
• Instruction authority and untrusted inputs.
• Required inputs, tools, action boundaries, and output.
• Evidence that will distinguish an improvement from a regression.