Essential guidelines
Good and weak instructions
The same job, written two ways. The difference is almost never length. It is whether a second person could check the result.
Name one artifact and one completion event
| Weak | Better |
|---|---|
| Improve our operations | Reconcile the April invoice export against the ledger, explain every mismatch, and return a corrected workbook for approval |
| Look into the pipeline | Flag deals with no next step, a close date in the past, or a departed owner, and post the list to #revops with record links |
| Research this market | Return a cited brief on the freight TMS mid-market, with an unresolved-claims section for anything a source cannot carry |
| Fix the failing tests | Diagnose the webhook suite failure, apply a fix, run the suite plus a 1,000-request soak, and open a PR with the diff summarized |
The failures that produce weak runs
| Failure | Better operating choice |
|---|---|
| The request describes a broad goal | Name one artifact and one completion event |
| The source of truth is unclear | Identify the authoritative system or file |
| The agent is asked to make it better | Define the quality checks and give examples |
| Too many agents edit the same surface | Recut the work around independent outputs |
| A run returns a confident summary without proof | Require citations, checks, receipts, or a recording |
| Every correction is pasted into the next prompt | Store stable facts in Knowledge and procedures in Skills |
| The automation runs too often | Add conditions, limits, and a failure owner |
| Review becomes a rubber stamp | Route exceptions and consequential decisions explicitly |
Length is not the variable
A long prompt that never says how the work will be checked is weaker than three sentences that do. If your prompt keeps growing run over run, that is a signal that some of it is reusable operating context in the wrong place. Move the stable parts into Knowledge or a Skill and let the prompt describe today's job.