Prompting

Say what good looks like.

The best prompt is not the longest prompt. It gives the AI enough context to understand the job, enough constraints to avoid a wrong kind of success, and enough evidence rules to know when to stop.

The six-part prompt

1Outcome

2Context

3Constraints

4Evidence

5 · Output shape

Say what you want back: changed files, a decision memo, a table, a short explanation, or a list of blockers.

6 · Stopping rule

Define when to finish and when to ask. For example: continue through safe checks; ask only if the choice changes scope or risk.

Reusable templates

Small change

Implement [change] in the existing [area].

Success means:
- [observable behavior]
- [important edge case]
- [relevant test or check]

Preserve: [existing behavior, API, style, or constraint].
Do not change: [explicit non-goals].
Before finishing, run the narrowest relevant checks and report what passed or could not be verified.

Debugging

Investigate [symptom] in [project or workflow]. Do not guess from the first plausible file.

Reproduce or trace the behavior, identify the invariant that is failing, and make the smallest safe fix.
Check: valid input, boundary/empty input, invalid or unrelated input, permission behavior, and refresh/retry state when relevant.

Report the root cause, changed files, regression coverage, and any baseline or environment failure separately.

Research

Research [question] using current authoritative sources.

Separate:
- verified facts and their sources
- reasonable inference
- uncertainty or conflicting evidence

Give me the practical answer first, then the assumptions, tradeoffs, and links. Stop when the core question is answered with sufficient evidence.

Long-running project

Take this project to a verified, reviewable result: [goal].

Context: [repository, users, existing work, relevant links]
Constraints: [permissions, privacy, compatibility, budget, style]
Non-goals: [what is deliberately out of scope]

Create or update a roadmap. Work through safe, bounded increments. Keep me informed at meaningful transitions. Continue when the path is clear; ask one focused question only when the answer would materially change the outcome.

Completion requires: [acceptance criteria] plus evidence from [tests/runtime/artifact/source review].

A useful correction when the result is almost right

Do not say only “make it better.” Point to the mismatch: “The layout is clean, but the primary action is not discoverable on a narrow viewport,” or “The generated character is attractive, but it does not match the existing project reference.” Specific correction turns taste into a checkable next move.

Prompt habits that age well

Put stable instructions before changing task data when building API prompts.
Use a real output schema or structured-output mechanism when machine parsing matters, rather than describing a fragile format in prose.
Use strong words such as “must” and “never” for real invariants, safety, or required fields; use decision rules for judgment calls.
Include representative examples when the distinction is subtle.
Keep personality and collaboration style separate from task goals and tool rules.
When a prompt changes, compare it against representative cases instead of trusting one lucky answer.