Engineering Prompts

Deliverable is always a prompt artifact — a ready-to-copy prompt the user takes elsewhere. Never execute what the prompt describes.

User: "Write a prompt that has Claude review pull requests for security issues."

Output: a complete, copy-ready system/user prompt using XML structure,
chain-of-thought guidance, and explicit success criteria — not an actual
code review.

Progress:

• Step 1: Determine content type (traditional prompt vs. LLM-targeted content) and route accordingly
• Step 2: If refinement of prior prompt in conversation — ask only "what specifically should change?" and skip to Step 5
• Step 3: Scope the prompt (traditional only) — goal, audience, success criteria, target platform, target model
• Step 4: Select techniques based on task complexity
• Step 5: Apply model-specific adaptations if GLM 4.7 or Gemini 3 requested
• Step 6: Deliver in the correct output format
• Step 7: Run quality checklist before final delivery

Step 3: Scoping (traditional prompts only)

Clarify at the prompt level, not the subject-matter level:

• What should the user accomplish with this prompt?
• Who uses it (technical level, domain)?
• What defines success (format, completeness, quality)?
• Target platform: Web/Desktop (default) or API?
• Target model: Claude 4 (default) — only ask about GLM/Gemini if user mentions them.

Use AskUserQuestion only when: use case is ambiguous, multiple valid approaches exist, format is unclear, or variations would help. Otherwise proceed with sensible defaults.

Step 4: Technique Selection

Simple tasks: clear direct instructions, explicit output format, examples only if format is critical.

Complex tasks: combine as needed:

• Chain of thought — <thinking>/<answer> tags, or "think step-by-step" for lighter cases
• Multishot examples — 3-5 diverse examples in <examples><example> tags, covering edge cases
• XML structure — separate <instructions>, <context>, <examples>; nest for hierarchy; consistent tag names
• Role prompting — specific expertise + tone, more specific = better
• Prefilling (API only) — start assistant turn to force format (e.g., prefill { for JSON)
• Prompt chaining — break multi-step workflows into sequential prompts with explicit handoffs

Claude 4 specifics:

• Request thoroughness explicitly ("include as many relevant features as possible")
• Give reasons for instructions ("...since this will be read by a TTS engine, never use ellipses")
• Anti-reward-hacking for code: "Do not hard-code test cases. Tell me if the task is unreasonable rather than creating a workaround."
• For agentic/tool use: "After receiving tool results, reflect on their quality before proceeding."

Step 5: Model Adaptation

GLM 4.7 (only when explicitly requested):

1. Front-load all mandatory rules in the first 200 words
2. Convert soft language to directives: "please consider" → "You MUST"; "try to avoid" → "NEVER"
3. Add explicit output templates with concrete format examples
4. Add a FORBIDDEN section listing generic response patterns to avoid
5. Add self-verification block ("Does your response name the specific file/function?")
6. Add language control line if relevant ("ALWAYS respond in English")
7. If API: thinking={"type": "enabled"}, temperature 0.6-0.7, stop tokens ["<|endoftext|>", "<|user|>", "<|observation|>"]

Gemini 3 (only when explicitly requested):

1. Keep temperature at 1.0 always — never adjust
2. For long context: place instructions AFTER the data block, not before
3. Explicitly request verbosity ("Provide a detailed, comprehensive response... do not summarize briefly")
4. Always include 2-3 few-shot examples
5. Use response-prefix strings for format control instead of prefilling
6. Place constraints at the END of the prompt
7. Add a verification block before response
8. If API: response_mime_type="application/json" + schema for JSON, system_instruction param for system prompts

Step 6: Output Format

Default target is Claude Web/Desktop — single copy-ready markdown block, no API params unless requested.

Step 7: Quality Checklist

• Instructions unambiguous and complete
• XML tags used consistently where structure matters
• Examples included if format/consistency is critical
• Explicit success criteria stated
• Edge cases addressed
• Tells the model what TO do, not just what to avoid

Example 1 — Traditional prompt: Input: "I need a prompt for summarizing customer support tickets into 3 bullet points." Output:

You are a customer support analyst. Summarize the ticket below into exactly 3 bullet points:
1. Core issue reported
2. Customer sentiment (frustrated/neutral/satisfied)
3. Recommended next action

<ticket>
{ticket_text}
</ticket>

Output only the 3 bullets. No preamble.

Example 2 — Refinement: Input: "The prompt from before gives responses that are too long." Output: (asks "what specifically should change — length limit, or less explanatory detail?" then) delivers the full revised prompt with a CONSTRAINTS: Maximum 100 words, no explanations line added, plus a "Changes Made" note.

Example 3 — GLM 4.7 adaptation: Input: "Adapt this Claude prompt for GLM 4.7: 'Please try to follow our style guide when writing docs.'" Output: Before/After comparison showing conversion to "You MUST follow the style guide in <style_guide> below. NEVER deviate from its formatting rules." plus a FORBIDDEN section and self-verification block.