D. Reusable task-brief patterns

A reusable brief is a set of decision fields, not a spell that makes every answer correct. Keep the fields that affect the task and omit irrelevant ceremony. The downloadable brief template and examples below are original starting points; replace their context with the actual project state.

Inspection without edits

“From CP00, read the named source excerpt and technical note. Explain the input, output, and limits of what the code establishes. Make no edits or installation changes. Name the files actually used. Separate proposed commands from executed actions. Accept when each consequential claim is tied to code, a source, or an explicit unknown.”

Use this when understanding the current system is the task. It does not establish runtime access controls; inspect those separately. If the assistant proposes an implementation, keep it as a possible next task while completing the requested explanation.

One reporting change

“Starting from the clean CP01 baseline, change README's Report label: synthetic. to Report label: synthetic input. Preserve host source, firmware, fixed sample values, dependencies, and commands. Show the exact diff. Accept when the origin is clearer and only the intended README line changes. Report any check actually performed.”

This brief is intentionally narrow. A new dashboard or renamed output schema may be useful in another task but does not belong here. The small boundary lets the learner inspect the complete result before committing.

Diagnose before fixing

“The named fixture fails under the attached command. Expected behavior and actual diagnostic are included. Preserve the current failing input. Identify two plausible explanations and one small check that distinguishes them. Do not change policy merely to suppress the symptom. After evidence supports a cause, propose the smallest correction and rerun the original reproducer plus relevant regression checks.”

Attach the actual error, source version, and working directory. A hypothesis becomes useful when it predicts a distinguishing observation. Asking for several guesses without a test plan simply creates more possible edits.

Review a bounded diff

“Review the supplied diff against these requirements. Read nearby callers as needed. Report actionable findings with file/line, trigger, consequence, and source or test evidence. Distinguish observed behavior from prediction. Do not invent findings to fill a quota or rewrite unrelated code. If no material issue is supported, state that and identify only meaningful verification gaps.”

Use the resulting findings as review input. Check their evidence yourself before applying a correction. An assistant's agreement or disagreement is not a replacement for the requirement and actual program behavior.

Extract interface constraints

“Use the supplied exact board and component documents. Identify variant, revision, units, conditions, and relevant source locations. Return claim, value/unit, source, uncertainty, and design consequence. Separate chip limits from board connections and documented expectations from bench observations. Leave missing mappings explicit and do not infer physical wiring from a family name.”

This pattern asks for an artifact you can check row by row. It prevents a summary from hiding a missing unit or a mismatched board variant. The datasheet skill packages the same practiced procedure for repeated use.

Resume from repository context

“Use the current repository instructions, README, handoff, requirements, and relevant diff. Establish the actual state and identify the next bounded task. Preserve unrelated work. Run the documented applicable checks and report source identity, commands, results, and limitations. Do not treat an earlier handoff's pass statement as current evidence without its receipt or a relevant rerun.”

A good handoff makes this request possible without old chat history. If a referenced file is missing, report that gap and continue independent inspection. Do not invent a remembered decision to fill the space.

Write acceptance before the answer

For each pattern, include a normal case and a useful negative case. Specify the artifact and the evidence required to accept it. If you cannot decide whether a response meets the task, refine the requirement before requesting more implementation. The strongest prompt improvement is often a clearer expected behavior, not more emphatic language.