Prompts are specs: role, constraints, examples, output shape — not magic words.
In my daily workflow
- I write the success criteria first (what a good answer contains).
- I add 1–2 few-shot examples from real failures, not toy cases.
- Structured outputs use JSON schema or tool definitions, not 'reply in JSON'.
- I version prompts in code and note which eval set they must pass.
How it makes me work smarter
Clear prompts reduce model hopping and retries. When the copilot must return registry-safe JSON, the prompt and schema align — the model is not guessing format. I change prompts in small diffs tied to eval results, not vibes.
My setup
- System prompts colocated with graph nodes
- Zod schemas for runtime validation
- Prompt comments explaining non-obvious constraints
- Eval fixtures capturing prior failure modes
On this portfolio
Copilot nodes, assistant system instructions, and job-fit classification all use explicit output contracts validated after generation. Admin-facing copy is separate from model instructions — no accidental leakage of internal tone.
