Page 99 - CyberSecurityEssentialsEnglish

Chapter Conclusion: From Writing a Request to Designing a Collaboration
A good prompt does not make a model infallible, but it reduces ambiguity and raises the
chance of an output that performs a defined function and can be reviewed. The process

begins with the purpose and the success criterion, then the task, the context, the material,
the audience, the format, the tone, and the constraints. Two lines may be enough for a
simple task, while precise tasks need examples, evaluation cases, and an output schema.

We have seen that PACFT is a recall tool prepared by the author, that asking, instructing, and

collaborating are teaching levels for choosing how much dialogue a task needs, and that
examples and follow-up prompts are means of improving a pattern rather than guarantees.
We have also seen that reasoning models do not necessarily need lengthy commands to

expose their internal thinking, and that a structured output still needs independent
verification of the content.

We have learned that self-critique is limited, that sycophancy can make a system confirm

our own view, that long context can lose some information, and that delimiters do not
prevent prompt injection. Sources, tests, appropriate tools, and human review therefore
remain part of quality. And when better wording is no longer enough, we must have the

courage to change the model, the tool, or the workflow.

The next chapter moves to the question that follows learning how to communicate: which
model, tool, or medium suits the task? A good prompt cannot turn an unsuitable tool into a
suitable one, just as a powerful tool cannot compensate for an ambiguous task.

98