AI Generalist
Prompt and context engineering · Agent design and evaluation · Systems analysis
Written communication is my core skill, and in applied AI it turns out to be the load-bearing one. Prompt and context engineering is largely technical writing for a reader that takes every word literally, where the real work is finding the ambiguity in your own instructions before the system finds it for you.
Four years in the Singapore Armed Forces as a Military Intelligence Expert, working high-volume signal data where the task was separating meaning from noise, quickly and correctly. That grounding in pattern recognition and disciplined classification underpins everything since, including recent technical field work commissioning airflow control systems in laboratory cleanrooms, where a misread instrument carries real safety consequences.
I am most interested in work at the boundary between people and systems: prompt and context engineering, agent design and evaluation, systems analysis, and translating between technical implementation and the people who have to use or approve it. I am comfortable working alongside engineers and reading code, but I am not looking for a role where shipping production software is the main deliverable.
What follows is not a software portfolio, and I am not a software engineer. It is an account of the tooling I run, the things I have built by directing it, and what I have learned from doing so. Where a model did the implementation work, I say so, and where my involvement was shallow I say that too. I would rather be trusted on the small claims than doubted on all of them.
An honest accounting of that list: perhaps four or five I use with any regularity. The rest I installed, ran against a real task, formed a view on, and left in place. I am not going to claim depth in sixteen tools. What the breadth has bought me is a sense of what varies between them and what does not, which is harder to acquire from any single one. The models converge; the differences that bite in daily use are how each tool manages context, how it asks permission before doing something irreversible, and how it wants its standing instructions written.
The problem. Agent skills are shared as GitHub repositories. Finding good ones, reading them, and copying them into the right directory was a manual process I was repeating every few weeks, and I kept losing track of where a given skill had come from.
What I decided. Rather than install everything I found, keep an offline library separate from the directory the agent actually reads, so skills sit on the shelf costing nothing until deliberately activated. Record where each one came from, including the source commit, so the library stays auditable as upstream repositories change.
What exists now. 110 skills imported from 10 public repositories, indexed in machine-readable and human-browsable form, with four PowerShell tools covering import, offline search, registry search and installation. Installing a skill leaves a provenance record naming its repository and commit.
Honest attribution. The curation is mine: which repositories to draw from, which skills to keep, and the decision to separate cold storage from active context. The PowerShell was written by Claude to my specification. I read it, ran it, and fixed what broke.
Having done the import once, I wanted it repeatable without re-explaining it each time, so I wrote the process up as a skill of its own. This turned out to be the more interesting piece of work, because specifying a process precisely enough for an agent to repeat it reliably is considerably harder than performing it once by hand. The written specification is the artefact. Three things it had to get right:
A question I kept returning to was whether useful local inference is possible on hardware I already own, rather than on rented GPUs. I approached it from two directions, both resting on the same idea of splitting a model by its layers.
On one machine. A small lab testing AirLLM's layer-splitting, benchmarked against a compact Qwen model first to confirm the plumbing before scaling up. Modest work, but it produced a concrete tokens-per-second figure on my own hardware rather than a number I had to take on trust.
Across several machines. A written proof-of-concept for a distributed cluster of low-cost single-board computers, using the RPC features in llama.cpp so a master node can draw on the memory of workers. It covers the architecture, the network layout, the build steps and the reasons for the choices, including why the interconnect must be wired rather than wireless. It is a design document rather than a running cluster; I have not bought the hardware.
A long-running mail export was tying up the machine overnight. Rather than sit and wait for it, I had a PowerShell watcher built that tracks the process by name and shuts the machine down when it exits, or when its IO counters have not moved for twenty minutes. The idle heuristic exists because the process sometimes finishes without terminating, and the shutdown call routes through cmd because shutdown.exe returns error 203 when invoked directly from PowerShell on this machine. That workaround is recorded in a comment, which I mention because undocumented workarounds are how systems quietly become unmaintainable.
I direct these tools well and I understand what they are doing. I read Python and PowerShell, modify them, and run them. I do not write production software unaided, and I am not applying for roles that require it. What I offer is the layer above: working out what a system should do, specifying it precisely enough to be built, and noticing when the output is subtly wrong.
Based in Singapore. Open to remote, hybrid and onsite roles, and to international relocation. English and Mandarin.