# Prompt Engineer > Guide for writing or refining prompts for Claude or GPT-5.6 Sol, distilled from each vendor's official best practices. Use for new prompts, debugging an existing prompt, or "prompt engineering", "system prompt", "Claude/GPT/OpenAI prompt". Accepts arg: "claude" or "gpt". - Skill: `chrisliu298/prompt-engineer` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds@latest add chrisliu298/prompt-engineer` - Raw SKILL.md: https://api.skillmd.com/api/skills/chrisliu298/prompt-engineer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: chrisliu298 (https://skillmd.com/u/chrisliu298) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/chrisliu298/prompt-engineer --- # Prompt Engineer Help users write effective prompts — from scratch or by refining existing ones — using vendor-specific best practices. ## Usage Covers two model families; the user specifies which: - **`prompt-engineer claude`** — Anthropic Claude prompting best practices - **`prompt-engineer gpt`** — OpenAI `gpt-5.6-sol` prompting best practices If unspecified, ask which model family the prompt targets. If obvious from context (e.g., they mention "Claude", "Anthropic", "GPT", "OpenAI"), use that. ## Workflow The process is the same regardless of model family: ### Writing a prompt from scratch **Step 1: Clarify the task** — ask the user: - What should the model do? (core task) - Which exact model, and at what reasoning effort? Guidance now diverges enough between versions (verbosity, thinking defaults, verification, delegation) that the target model changes the draft. - What does good output look like? (format, length, tone/structure) - What context will be available at runtime? (documents, user input, tool results) - Will the model have tools? (search, file editing, code execution, etc.) **Step 2: Draft the prompt** — read the appropriate reference file for model-specific patterns and blocks, then draft applying the relevant techniques. **Step 3: Pre-flight quality pass** — before presenting, read the draft back and design out the failure modes that most often degrade a one-shot prompt. Without an eval loop you can't *measure* these traps, so anticipate them — they're the design flaws an eval would flag, caught without running one. Check: - **Structure** — can a stranger tell role from policy from guidelines from data from examples at a glance? If you can't tell them apart when reading the prompt, the model can't either. If not, split them into clearly labeled sections (XML tags for Claude; headings or explicit blocks for GPT). - **Capability vs. instruction** — does any instruction ask the model to *do* something it can't reliably do (exact arithmetic, external/current lookups, deterministic transforms where exactness matters)? Give it a tool, ask for the missing input, or narrow the task — don't escalate the adjectives. Instructions don't add capability. - **Tradeoffs** — is any rule stated one-sided (a cost with no counterweight, e.g. "avoid X, it's expensive")? State both sides so the model weighs them, instead of hard-coding the conclusion and causing it to overfit. - **Over-constraint** — would any blunt `NEVER`/`ALWAYS` rule make the model *withhold information it actually has* or refuse a valid action? Replace the prohibition with a source of truth ("the provided context is authoritative — answer from it; redirect only when the value is genuinely absent"). - **Instruction strength** — are `CRITICAL`/`MUST`/`NEVER` earning their place, or papering over missing structure or a missing tool? Dial back to plain phrasing where they aren't. For a higher-quality result, have the model critique its own draft against these checks in the same turn, then revise — an inline version of the generate → review → refine pattern. This is a review pass over a draft artifact, not an answer-verification loop; don't add standing "double-check your work" instructions to the prompt you're writing, which several current models already do unprompted. **Step 4: Present the draft** — show the complete prompt and explain design choices. ### Refining an existing prompt **Step 1: Diagnose** — read the prompt and ask what's going wrong, then read the reference file and consult its model-specific diagnostic table. **Step 2: Apply targeted fixes** — add what's missing, remove what's counterproductive, explain the why. **Step 3: Present the revision** — show a before/after diff explaining each change. ## Model-specific references Read the corresponding reference file for the full set of patterns, XML blocks, and diagnostic tables: - **Claude** → `references/claude-prompting.md` — clarity, roles, XML structure, examples, output format, effort and thinking guidance, safety controls, agentic patterns, and a per-model section (Opus 5, Sonnet 5, Fable 5/Mythos 5, earlier models) covering the behaviors that differ enough to change the prompt. - **GPT-5.6 Sol** → `references/gpt.md` — outcome-first prompting, output contracts, follow-through policies, tool routing and persistence, completeness verification, citation/grounding, reasoning effort, verbosity, and GPT-specific failure modes. The Claude and GPT references contain ready-to-paste XML blocks.