How I work · 2026

Rules, agents & verified sources.

An agentic AI workflow built on Claude Code and MCP. Specialised agents, a constitutional rule file, and hooks that enforce between sessions. Everything traces to a source on disk — nothing is invented.

Single Page Application (run locally)
CV Engine · Dashboard
+ New Variant

Role family 1

Primary target lane

Role family 2

Secondary target lane

Role family 3

Stretch lane

Role family 4

Exploratory lane

17 variants
CompanyTarget titleUpdatedStatus
summit reSenior Product Owner23.05 · 09:37DRAFT
alpine fintechBusiness Analyst Claims23.05 · 18:17DRAFT
centro cxProduct Owner Digital CX23.05 · 09:37APPLIED
neura consultingAI Domain Lead22.05 · 14:02DRAFT
25 rules 13 agents 8 PDFs per app ~4 min per pass 0 API tokens ATS-friendly

The approach

Constitution first. Agents second. Hooks enforce the rest.

A single rule file — twenty-five rules — loads at every session start. No agent can override it. Each agent is scoped to one concern and loads only the playbook and source files it needs. Hooks run between sessions to stamp state, trace sources, and surface drift.

The model runs locally via Claude Code on a Max plan. MCP extends the tool surface — file reads, script calls, renders, all within one session. No API tokens, no external calls, no data leaving the machine.

Rule 1 — loaded every session

Facts only. No invention. Ever.

Every claim must trace to a source. If a claim has no source, it does not appear. No exceptions.

Agentic architecture

Specialised agents, shared rules.

Each agent is scoped to one concern. It loads its own playbook, reads only the source files it needs, and hands off to the next agent via structured output. The rules constitution loads at every session start — no agent can override it. Hooks enforce by side-effect between sessions.

RULES.md — 25 rules · loaded every session · no agent can override Triage agent Scores JD against rubric → FIT / STRETCH / SKIP Copy agent Tailors CV + letter → structured JSON variant QA agent Validates against sources → pass / findings Translator agent Mirrors DE ↔ EN → bilingual variant + 9 more specialised agents (web, UX, translation, …) · each loads only its own playbook Hooks enforce between sessions — source-trace · date-delta · state-stamp · application-sync SOURCE FILES ON DISK cv-master.json Every CV field numbers · non-claims Verified metrics + explicit gaps letter-corpus · voice Reference letters + banned words

The pipeline

JD in, eight PDFs out.

A job description enters the system. The engine triages, tailors, validates, and renders. Every PDF is ATS-friendly — real embedded text, no flattened images, machine-readable section headers. The model only fills values the schema allows, with content the source corpus already contains.

Capture JD → jd.md Triage FIT / STRETCH / SKIP Tailor Claude · constraints Validate verify.js · 18 rules Render 8 PDFs FED BY VERIFIED SOURCES cv-master.json Single source of truth for every CV field numbers · non-claims Verified metrics and explicit gaps letter-corpus · voice Reference letters and banned-word list The model never invents — it only fills values the schema allows, with content the corpus already contains.

The interface — Triage

Every JD gets scored before anything else runs.

The triage step applies an HR rubric — location, salary floor, lane fit, applicant pool, disqualifiers — and emits a FIT, STRETCH, or SKIP verdict. Only FIT and STRETCH proceed to the tailoring pass. SKIPs auto-log with the verdict reasons.

CV Engine · Triages

Triages

7 decisions logged

EmployerRoleDateVerdict
Centro CXProduct Owner Digital CX (m/w/d)2026-05-23FIT
Alpine FintechBusiness Analyst Claims2026-05-23FIT
Solaris AGSenior Product Manager (100%)2026-05-22SKIP
Neura ConsultingAI Domain Lead2026-05-22STRETCH
Pragma EngineeringBusiness Solution Architect – AI & UX2026-05-21STRETCH
CV Engine · Variant detail

summit re

Senior Product Owner

DEEN DRAFT
Status
Draft Progress Applied Rejected
PDF ↓ Re-tailor

The interface — Variant

Language toggle. Status tracking. PDF on the fly.

Each variant shows the tailored content with a DE/EN toggle. Status moves from draft through applied. The PDF renders on download — page-count cap and ATS extraction enforced at render time. If either check fails, the build fails.

Enforcement

What happens when a claim can't be traced.

Every fact in the CV has to link back to a source file. Sometimes the model produces a line that doesn't. Two options: refuse to generate the PDF, or generate it but flag the ungrounded line.

The engine flags. The flagged line becomes a ticket the operator has to resolve before the next run. Over time this makes the system sharper — every near-miss is logged, not silently swallowed.

Block

Engine refuses. No output, no record of what went wrong. Strict, but silent.

Warn ✓

Engine ships, but flags the problem. The flag becomes a ticket that has to be fixed before the next CV goes out.

What this proves

Not a side project. A way of working.

The engine solved my problem. The method behind it is what I'd bring to a client engagement.

01

Business problem first, technology second.

The starting point was "applications take too long and drift" — not "let's use Claude." The tool choice followed the constraint analysis. That's how I'd scope a client's AI use case: identify where the pain is, then design the solution.

02

Rules first, system second.

The twenty-five-rule constitution existed before the first line of code. Constraints shaped the architecture — not the other way around. For a client, that means guardrails are designed in, not patched on after an incident.

03

Teachable, not bespoke.

The rules-constitution + hooks + agent pattern is a methodology, not a one-off. A client team can learn it, adapt it, and run it without me in the room. That's enablement — not dependency.

What comes out

An ATS-friendly, source-traced PDF.

hello@… +41 … LinkedIn

Let's talk.

Get in touch →