tftio

What I build

I'm a forward-deployed engineer at a small software company. I also build my own tools around agents and guardrails. My goal is to reduce the attentional load on humans: offload mechanically checkable work to tooling, and use that tooling to establish a narrow scope for agents.

I favour focused sessions rather than long-running conversations. Context needs to survive the session, not depend on keeping one agent running.

Agents & harnesses

• Claude Code (current): One of my three primary coding harnesses, using my shared tooling and instructions.
• Codex (current): Another primary coding harness, with the same operator-directed boundaries.
• OpenCode (current): A primary harness that also gives me access to open-weight models through OpenRouter.
• Clanker (current): My launcher selects context, domain, model and composed instructions; an unresolved context is an error rather than a guess.

Models & apps

• Opus and Sol (current preferences): I tend toward these models, alongside open-weight models accessed through OpenCode.
• ChatGPT, Claude, LM Studio and supacode (current): Other parts of my AI toolkit; the coding workflow centres on the harnesses above.

Skills, commands & context

• Agent-content / agent-toolkit (current): My shared source for prompt fragments, skills, workflow agents, commands and hooks, compiled into packages for Claude Code, Codex and OpenCode.
• Specialised skills (available): Planning, code and PR review, language and infrastructure audits, and documentation playbooks provide task-specific guidance rather than one oversized standing prompt.
• Planner (current): My authoritative plan format, validator and lifecycle tooling keep task state and completion evidence in an artifact that another session can pick up.
• kb (current): My knowledge base preserves retrievable material beyond the current conversation.
• mnene (current): A separate agent-to-agent memory store carries deliberately selected facts and decisions into later project or task sessions; retrieval is keyword-based, not another model.
• MCP and CLI connections (available): These expose tools to the harnesses; mnene has both interfaces, while kb and planner have agent-facing CLI workflows.

Guardrails I build

• Repository invariants: REPO_INVARIANTS.md names the constraints and their enforcement. In the repositories inspected for this page, checks cover formatting, linting, types, tests and dependency policy; rules requiring judgment remain explicitly assigned to review.
• Shared check commands: Repository-owned mise tasks let local hooks and CI invoke the same checks instead of maintaining separate definitions of correctness.
• Planner's role boundary: Its worker-plan type cannot contain hidden criteria. Plan mutations are validated and stale writes rejected, rather than leaving these checks to an agent's recollection.
• Silent Critic (project): My plan-supervision tooling uses an execution ledger and sealed acceptance artifact; it is another way of putting acceptance state outside the worker's conversation.

How I work

• I define an outcome and narrow scope, then launch a harness through Clanker with the relevant context. The agent reads the affected artifacts and repository invariants before proposing changes.
• For substantive work, I use a plan to carry decisions and task state across focused sessions. kb supplies retained knowledge; mnene supplies selected agent-to-agent memories. They serve different purposes rather than becoming duplicate transcripts.
• A bounded implementation goes through the repository's checks, with evidence recorded against the task. For example, planner can record task completion with the result of mise run ci; the next session can inspect that state instead of reconstructing it from chat.
• I review the result and verification evidence. Mechanically passing checks does not confer authority to publish, deploy or take irreversible action: those remain explicit approval gates.