An agent preparing a tender response needs to understand your method and the limits of its role. “Write a good response” specifies neither the documents to review nor the commitments it may make or the person who must approve the result.
Skills and hooks address two different needs: explaining how to work and triggering checks. Understanding this distinction helps separate a written instruction from a rule that is actually enforced.
A skill: a reusable procedure
The Agent Skills format organises instructions and resources around a SKILL.md file. A skill can include examples and scripts. It does not guarantee a correct result on its own.
Consider a fictional tender response. We would propose a method specifying the input documents, assessment grid, approved internal references, output format and situations requiring review. The agent should distinguish a buyer’s requirement, a demonstrated capability and a point that still needs confirmation.
The deliverable could be a table of requirements, evidence, gaps and responsible people. Pricing, delivery commitments and contractual exclusions would explicitly require approval. A business owner would maintain the method, its version and its change history.
A hook: a trigger at a defined stage
In Claude Code, a hook can run a check when an event occurs, including before certain tool calls. Its capabilities depend on the event and hook type. A programmed check can be deterministic; a model-based check involves judgment.
For this example, we would recommend a pre-publication check covering approval, authorised recipient, required attachments and output format. Checking after sending can help trace an error, but cannot prevent a message that has already been sent.
Define three responsibilities
- Method: what the agent should produce and how it should approach the work.
- Trigger: when a check must run.
- Control: what condition to verify, which result is acceptable and what happens on failure.
An “approved” field is insufficient by itself. The system should verify who approved the work and which version they approved. Permissions in the business tool must also restrict possible actions. A sentence in a prompt does not replace that restriction.
Test failures as well as the demonstration
We suggest testing an incomplete response, outdated evidence, a change after approval and an incorrect recipient. The design should also cover a check becoming unavailable: suspend the sensitive action, report the issue and define how to resume. The operating team needs to understand the record of attempts and decisions.
Information retrieved from a document must not redefine the execution rules. Retrieved knowledge supplies content; instructions and permissions come from the agent configuration and the agreed business process. This separation should be part of the review before connecting write-capable tools.
What Mintera proposes to build
The engagement can deliver a documented procedure, a control matrix, an approval workflow and a test set. Measures include output quality before review, total time to approval, justified blocks and corrections required.
We also recommend agreeing who can change the method and how those changes will be retested. A useful agent needs to remain understandable when a procedure, product or responsibility changes. The objective is a transferable method and controllable execution that your teams can maintain.