Prompting 101
By now, you know the shape of the system: the model completes the context it receives, and the harness turns some completions into tool calls, file reads, edits, commands, and observations. Prompting is where you draw the beginning of the pattern you want the agent to continue.
A prompt is not a conversation starter. It is context design: selecting the task, inputs, constraints, examples, vocabulary, and output shape that make the intended continuation the most likely one. Good prompting narrows the completion space before the agent starts spending tool calls and editing code.
Start With the Task and Output Target
Skip pleasantries. AI models don't need "please" or "thank you"—those tokens dilute signal without adding clarity. Start with the decision or artifact you want and the standard it must satisfy.
Thanks!
Audience: engineering lead and product manager deciding whether this is ready for build planning.
Cover: billing model changes, customer migration, entitlement logic, data backfill, support impact, rollout risk.
Return sections: summary, affected systems, open decisions, migration plan, rollout plan, validation checklist.
The technique is to name the desired artifact before supplying details. That first phrase biases the completion toward a plan, decision record, review, or spec instead of an open-ended discussion.
Ask Questions to Load Context
Ask questions to load context. In an agent harness, a question can trigger an action sequence: search the repository, read files, query docs, inspect tool output, and synthesize the relevant findings. This is Agentic Search. The question causes the agent to load useful context before you ask it to plan or edit.
How does the onboarding flow currently handle teammate invites before dashboard preview?
That question is enough. The agent must find the flow, inspect the relevant files, and summarize the current behavior before you ask for the change: "Make teammate invites optional before dashboard preview." Use this before planning or editing when the missing information is discoverable.
Choose the Output Structure Early
Structure organizes information and directs attention. Markdown, JSON, and XML work well because they're information-dense formats heavily represented in training data. Pick the shape before details compete for attention.
The structure makes the decision reviewable: why this matters, what cannot break, which options were considered, and how success will be verified.
Add Constraints as Guardrails
Without constraints, the model fills gaps with assumptions. Define boundaries explicitly.
Constraints:
- Preserve the current API response contract during rollout.
- No user-visible regression for upload progress or error recovery.
- Preserve audit logs and idempotency guarantees.
- No schema change without a backfill and rollback plan.
Return affected systems, migration phases, risks, evidence needed, and decisions that require human approval.
The unconstrained version invites the agent to jump into implementation. The constrained version defines the operational envelope before code exists.
Use Examples When Rules Are Hard to Describe
Few-shot prompting gives the model input/output examples before the real task. Instead of describing every rule, you show the pattern you want completed.
"I wanted to try the dashboard, but it asked me to invite teammates before I knew what the product did."
Examples:
Input: "I don't understand what a workspace is."
Output: Copy — terminology blocks comprehension.
Input: "It asks me to invite teammates before I see value."
Output: Flow — sequence creates premature commitment.
Input: "I can't connect the billing data source without admin access."
Output: Permissions — access boundary blocks activation.
Now classify:
Input: "I wanted to try the dashboard, but it asked me to invite teammates before I knew what the product did."
Output:
Start with one example when the pattern is simple. Add more only when the output stays inconsistent, and prefer diverse examples that cover real boundary cases.
Reverse Prompt From an Ideal Output
When you already have an ideal output, don't guess the prompt from scratch. Give that output to the model and ask it to infer the instructions, constraints, structure, and validation criteria that would reproduce it.
architecture decision record I want from an AI coding assistant:[Paste one complete decision record whose structure and quality you want to reuse.]
Reverse-engineer the prompt that would produce this kind of decision record.
Infer:
- intended audience and decision scope
- required sections
- evidence requirements
- expected trade-off language
- constraints the reviewer must preserve
Return:
1. A reusable prompt template
2. The variables I should fill in for each decision
3. A validation checklist for testing whether the prompt reproduces this decision quality
Use multiple examples when the target output is complex. A single example helps you move fast, but several examples make the shared structure clearer and reduce invented constraints.
Add Persona When Vocabulary Matters
Use personas when domain-specific terminology matters: security, performance, accessibility, reliability. Skip personas when the task is straightforward and adding persona context wastes tokens without adding value.
You are a staff-level reliability engineer reviewing a proposed multi-region failover design.Review for:
blast radius, failover trigger ambiguity, data consistency risk, observability gaps, runbook gaps, rollback assumptions.
Assume partial regional outages, degraded dependencies, and an on-call engineer executing under time pressure.
The persona doesn't add knowledge. It changes which knowledge gets retrieved by shifting vocabulary. The same control interface applies to code search, web research, vector databases, and sub-agent delegation: "multi-region failover risks" retrieves different context than "deployment issues."
Define the Reasoning Path for Multi-Step Work
When tasks require multiple steps, define the execution path. You are not asking for hidden reasoning; you are dictating the route so the agent cannot skip diagnosis, evidence, or validation.
1. Identify the affected funnel stages and the before/after metric deltas.
2. Compare the old and new onboarding sequence at the product-experience level.
3. List hypotheses across copy, flow, permissions, data readiness, and reliability.
4. Mark each hypothesis as supported, unsupported, or needs data.
5. Propose experiments or fixes with expected signal.
Provide evidence for every claim and call out assumptions separately.
Use this whenever the path must be enforced: diagnosis before recommendation, evidence before conclusion, validation before implementation. It does not make the agent deterministic; it just makes skipped steps and premature claims easier to detect.
Require Evidence for Claims
Evidence requirements control what the model can claim. When the agent explains a plan, discrepancy, or bug, require file paths, line numbers, concrete values, exact error messages, cited sources, metric names, timestamps, or customer quotes.
workspace_invite_shown → first_dashboard_view: 62% to 41% in activation_funnel_enterprise for May 14–21. Three support tickets quote confusion about mandatory invites, and the redesign spec lists teammate invitation before dashboard preview.The second claim is verifiable. If the metric, date range, quote, or spec reference is wrong, you spot the drift immediately. Evidence requirements do not make the model deterministic; they make unsupported claims visible.
Replace Negation With Positive Instructions
Negation is a weak control surface because the model is not applying symbolic rules. It predicts continuations from the whole context, and the forbidden concept is still part of that context. Use "do not" to mark the boundary, then immediately specify the desired behavior in positive, concrete terms.
Do NOT make the flow confusing.Do NOT introduce steps that make activation feel blocked.Instead, keep the first-run path linear and value-first.Ask for workspace name before teammate invites; show optional setup after dashboard preview; label optional steps as skippable.
The safer pattern states the forbidden outcome, immediately supplies the desired experience, then names the sequencing mechanism. It gives the model a concrete continuation to follow instead of leaving the forbidden concept as the strongest signal.
Delegate Math to Executable Code
Math needs exact execution, not plausible continuation. Because LLMs generate probable next tokens rather than verified results, they can produce arithmetic-shaped answers that look coherent but are wrong. Ask them to write executable code for arithmetic, measurement, parsing, and validation.
Inputs:
- current MRR by account
- monthly event volume by account
- proposed unit price, included volume, caps, and discounts
- account segment and contract tier
Return cohort revenue deltas, accounts with >20% increase, and a sensitivity table.
Include tests for pricing formulas, caps, discounts, and missing data handling.
The model may generate plausible-sounding business impact because probability can imitate correctness without guaranteeing it. It is far better at writing code that computes the result, tests the formulas, and exposes the assumptions behind the estimate.
From Prompt Controls to Workflow
These controls make one prompt reviewable: target artifact, separated inputs, constraints, examples, evidence, positive instructions, and executable validation. They are the smallest unit of agent operation.
For production work, the next problem is orchestration. A large change is not one perfect prompt; it is a sequence of prompts that research the system, produce a plan, execute within constraints, and validate the result.
Next: Chapter 4: Four-Phase Workflow shows how to compose these prompt-level controls into a repeatable operating loop.