TL;DRGiving full context is the official best practice people skip most often. This turns it into a pre-flight checklist: goal and acceptance criteria, named files, constraints and no-go zones, echo-back confirmation, plus an AGENTS.md write-back at the end of the session.
Sources SOURCES
Distilled from public community discussions. This page only breaks them down and verifies — it never reposts the original; opinions belong to their authors.
Facts FACTS
Check these claims against the listed sources. For allowance mechanics, first-party account displays outrank community summaries.
- Official best practices place giving full context alongside plan-first: stating goals, constraints, and the relevant files before work starts is called out as a foundational move. Skip it and the agent fills the gaps with guesses — which is exactly where the ten-round grind comes from.
- Community templates list project context as the first block of AGENTS.md, typically followed by architecture notes, dev commands, and coding conventions.
- Official guidance recommends persisting long-lived constraints into AGENTS.md to cut down the repeated briefing every session would otherwise need — a pure overhead tax: same content, new session, every time.
- AGENTS.md is a pure-Markdown standard file, distributed with the repo — humans and agents read the same copy, so the briefing doesn't fork into two versions.
Concepts CONCEPTS
Not everything said in a community thread is a fact — each concept carries its nature label. Read the label first.
Stating the goal, acceptance criteria, relevant files, and constraints before any work begins. Part of the official best practices; uncontroversial as fact. It's the difference between the agent reading your intent and reconstructing it from a filename.
Having the agent restate the task and its plan in its own words before starting — a cheap smoke test for shared understanding that surfaces misunderstandings early. A common community technique, not an official requirement.
Pointing at an existing module of the same kind in the repo and telling the agent to write against it — style and error handling come pre-answered. When a good example already lives in the repo, pointing at it beats describing the style. High-frequency community practice.
The worry from the other direction: stuffing too much irrelevant material into the prompt dilutes what matters — when everything is flagged important, nothing is. No public measurement of where "too much" starts; treat as a hypothesis for now.
Step-by-step SOP STEP BY STEP
- 01One-sentence goal
Open with "what I want + what done means": one sentence for the change, one sentence for the acceptance criteria. No vagueness, no buried asks. Two sentences here routinely save two clarification rounds later.
- 02Name the files to read
Call out the entry point, the module to change, and one similar implementation. Say it explicitly: "read these three files before you start." Named files also stop the agent from touring the whole tree first.
- 03State the constraints
Stack and versions, banned dependencies, runtime environment, compatibility to preserve — all in one message, not fed piecemeal across five replies. Constraints delivered late get discovered as surprises mid-task.
- 04Draw the no-go zones
State the untouchable scope: unrelated refactors, generated directories, lockfiles, environment configs — anything unlisted reads as fair game to the agent.
- 05Echo back before green light
Require it to restate the task and present a change plan; once you confirm the direction, let it write code. If the echo comes back wrong, you just found the bug before it was written.
- 06End-of-session write-back
New repo facts and pitfalls learned this session go back into AGENTS.md, so you never have to explain them twice. The verbal briefing you keep repeating becomes the repo's own documentation.
Keep reading NEXT
Want today's verdict? Back to the live radar.