How to Write a Task Brief for an AI Agent
A five-part brief structure that keeps an AI agent from confidently doing the wrong thing, plus the one line most people forget to include.
Read article →Topic
19 articles tagged Documentation. For the wider topic, see Productivity & Operations.
A five-part brief structure that keeps an AI agent from confidently doing the wrong thing, plus the one line most people forget to include.
Read article →Write internal docs and SOPs that an AI agent can execute, not just a person: explicit steps, stated preconditions, unambiguous names.
Read article →A QBR summary that leads with the miss earns more trust than one that buries it. How to structure the document so it informs instead of impresses.
Read article →Going on leave without leaving chaos behind takes a handover that answers questions before they are asked. What to include so nobody has to message you on holiday.
Read article →Turn a finished project into lessons the next one uses. What to include, what to leave out, and how to stay blameless without going soft on the facts.
Read article →A repeatable review gate so agent output is never sent unread: a short checklist plus a word-level diff pass, and exactly what belongs on the list.
Read article →Numbered steps are the easy part. Where to put prerequisites, how to handle the branch, and why the failure cases belong in the article rather than the comments.
Read article →A 40-page style guide gets read once. What belongs in a one-page version, what to leave to judgement, and how to make the rules enforceable.
Read article →Alt text is written for someone who cannot see the image, not for a crawler. The decision tree, the cases where empty is correct, and the keyword mistake.
Read article →A one-page record that answers the questions an auditor, client, or regulator actually asks. What to write down, and why doing it now costs an hour instead of a week.
Read article →Steps, expected, actual, environment. Why most bug reports get bounced back, and how to write one that gets fixed instead of triaged into a question.
Read article →Reviewers need to know what changed, why, and what you want them to look at. A structure that gets faster, better reviews on the same code.
Read article →The first three lines decide whether someone keeps reading or closes the tab. What belongs at the top of a README, and what belongs much further down.
Read article →What is going away, when, what to use instead, and what breaks if you ignore it. How to deprecate without losing the developers who depend on you.
Read article →A subject line that finishes the sentence, a body that explains why, and the habits that make git log useful two years later.
Read article →Capture meeting notes that preserve decisions, actions, owners, deadlines, open questions, and useful context without transcribing everything.
Read article →Record a project decision so future readers can see what was chosen, why, who approved it, and when it should be reviewed.
Read article →Release notes are a product story, not a changelog dump. How to lead with value, group by user, and turn updates into something people finish reading.
Read article →Explore how software engineers are using inline, local AI to effortlessly improve code documentation and technical writing without leaving their IDE.
Read article →