AI tools · skills · evidence
How I use AI tools without handing over judgement
The public engines on this site are the method around the tool. They help me decide what the work is, which capability is appropriate, what evidence is needed, what can fail, and when a person must review or approve the result.
Inspect the public work on GitHub ↗The short answer
I use AI tools as capable assistants inside a larger operating system. The AI tool may draft, code, classify, compare, summarise, or explore. The skills engine provides the context, route, constraints, evidence, quality gates, and handoff. A human must remain in the middle: reviewing the work, correcting it, approving or rejecting it, and owning the decision, release, and consequences.
The operating model
Six steps from a vague request to a defensible result
Frame the problem
State the outcome, audience, decision, constraints, data, time window, and consequence of getting the work wrong. A tool is not selected before the problem is understood.
Route to the right engine
Choose the smallest accurate skills engine. Research, software, design, finance, proposals, websites, marketing, Linux, and formal SDLC documentation have different quality rules.
Choose the AI tool
Use a language model, coding agent, research/browser workflow, local script, document tool, or analytics tool according to the task and the data it can safely handle.
Work with structured inputs
Give the tool the relevant skill instructions, source material, expected output, assumptions, boundaries, and failure conditions. Do not use an unbounded prompt when a workflow is needed.
Check the result
Verify sources, calculations, code, requirements, accessibility, security, privacy, financial logic, or operational behaviour. Test failure paths, not only the happy path.
Human review, explicit approval, and learning
A responsible person checks the work, then explicitly types approval when the workflow requires it before publishing, deploying, submitting, sending, changing, or taking another consequential action. The person can correct, escalate, reject, stop, or roll back the work, then capture learning for the next run.
Approval is an input
Some work must pause until the user says “I approve”
This is a feature, not a failure. In particular cases, an engine will prepare the next step but deliberately refuse to implement it until the user manually types a clear approval. The system must not infer permission from the original request, a previous conversation, a draft, or silence.
Typical approval pauses
Publishing or sending externally, changing production systems, handling sensitive data, making destructive changes, committing funds, submitting a proposal, or making a binding financial or operational decision.
What a good approval says
The user names the action, target, scope, and relevant conditions: “I approve publishing this reviewed post to the specified channel,” or “I approve applying this migration to the staging database only.”
How the engines cooperate
One primary route, specialist companions where needed
The engines are not a pile of unrelated prompts. Each one owns a domain, and the links between them make handoffs visible. I start with the engine that owns the main decision, then bring in a companion when the work crosses into another specialist area. At every handoff, a human remains accountable for checking that the output is fit for the next stage, and the workflow pauses for explicit typed approval whenever the next action is consequential.
Primary question
What decision or outcome is the work meant to support?
Primary engine
Which engine owns the main method and quality standard?
Companion engines
Which evidence, finance, design, software, or delivery boundary needs specialist support?
Human gate
Who reviews, corrects, approves, rejects, escalates, stops, releases, owns, and can roll back the result?
An AI website project
Website Skills owns the delivery route. Design System Skills owns the visual layer. Digital Research Skills verifies changing claims. Chwezi Dev Engine handles application or integration work. Social Media Skills handles the discovery and distribution system.
An AI-enabled business plan
Business Plan Skills owns the plan and model. Digital Research Skills verifies market and policy claims. Chwezi Accounting Doctrine governs finance and accounting logic. Proposal Skills helps when the final output is a tender, EOI, or funding response.
A WhatsApp AI assistant
Social Media Skills frames the customer journey and channel strategy. Chwezi Dev Engine handles the software and integration. SRS Skills documents requirements, evaluation, human handoff, and release. Digital Research Skills verifies external answers and policy claims.
A Linux-hosted AI service
Chwezi Dev Engine owns the application and AI system. Linux Skills owns the host, deployment, hardening, service, backup, and recovery route. Digital Research Skills verifies current platform or security claims. SRS Skills documents the operational handover.
What I expect from an AI tool
Capability is not enough
- It must have a clear job and a defined user, not just an impressive demo.
- The data it receives must be appropriate, permissioned, and handled according to the risk.
- The output must be inspectable: sources, tests, calculations, decisions, or traces should be visible where they matter.
- The workflow must have a fallback when the model is wrong, unavailable, too expensive, or unsuitable.
- The owner must know when to correct, stop, escalate, approve, or roll back the result.
The expert difference
I do not sell the tool as the solution
The expert work is deciding where AI belongs, where it does not belong, how to connect it to existing records and workflows, how to evaluate it, how to protect people and data, and how to make the result useful to the organisation after the pilot. It also means designing the human-in-the-middle control: who reviews the output, what they check, what evidence they need, and what happens when the answer is wrong.
That is why the public repositories matter: they make the method inspectable. You can see the routing, evidence expectations, boundaries, and quality gates instead of relying on a vague claim that AI will transform the work.
Discuss an AI workflow →Frequently asked
Questions about using the engines
What is the difference between an AI tool and an AI skills engine?
An AI tool performs a capability such as drafting, coding, classifying, comparing, summarising, or exploring. A skills engine supplies the professional method around that tool: the problem frame, routing decision, inputs, constraints, evidence requirements, quality gates, and handoff rules.
Do the skills engines work with one specific AI model?
No. They are portable instructions and operating methods that can be used by a human or an agent runner such as Codex, Claude Code, or another compatible workflow. The tool can change; the method, evidence, and approval controls remain explicit.
How do multiple skills engines work together?
Use one engine as the primary route and add companions only when the work crosses boundaries. For example, an AI website project can combine Website Skills for delivery, Design System Skills for visual quality, Digital Research Skills for changing claims, Chwezi Dev Engine for software, and Social Media Skills for distribution.
Does using AI remove the need for expert review?
No. The workflow is designed to make expert review clearer. Human authority remains responsible for scope, factual claims, financial judgement, security, approvals, release, client communication, and rollback.
Ready to discuss your project?
Every engagement begins with a conversation. Book a consultation to explore how Peter's experience can serve your organisation.