Ship discipline as skills, not documents — introducing the 165 skills of ELN workflow

The short version

• What we built: ELN workflow, our in-house plugin suite that implements development discipline, quality standards, and spec processes as Claude Code skills (procedure sheets plus enforcement gates that AI follows), distributed to every project. As of September 2026 there are 165 skills.
• Why we built it: development standards written in documents do not get followed. They get followed only when they are built into the workflow. If the gate refuses to let you proceed, the discipline executes even when humans forget and even when AI forgets.
• The key point: the more development you delegate to AI, the more "did the AI actually do it right" becomes the bottleneck — a check humans end up doing by hand, every time. This plugin mechanizes that verification itself and ships it to every project.

The full story (about a 13-minute read)

The authentication, notification, and billing platforms I introduced in this series all moved "features every product needs" into shared platforms. This article is different in kind. What we consolidated is not a feature — it is how we develop.

"Please follow the rules" doesn't work

We develop more than 20 products with one human and AI as the executing team. The biggest problem in this setup is not coding speed. It is quality variance.

"Say 'done' only after tests pass." "Record design decisions." "Estimate costs before changes that affect billing." All of it was written down. AI still said "done!" anyway, and humans still skipped steps under time pressure. Writing more documents did not solve this.

So we inverted the approach: implement discipline not as documents but as Claude Code skills. A skill loads automatically when its situation arises and blocks the operation on the spot when its conditions are not met. Not "please follow this" — "you cannot proceed unless you do." Only after this inversion did discipline start executing identically across all projects.

The 165 skills at a glance

There are 165 skills today, across three plugins: the quality-and-discipline core (139), project orchestration (12), and business/content production (14). Alongside the skills, the same plugins bundle 50 automated checks (hooks) and 14 specialized sub-agents.

You cannot tour all of them, so here are the categories with representative examples.

• Completion gates (stopping the AI's "it's done") — flagship: eln-verify-before-claim. Blocks completion claims that lack measured logs, test output, or live verification. A passing build is not "done."
• Evidence-based debugging — flagship: evidence-based-debugging. In production bug hunts, demands observation of logs, DB, and real requests before any guess-based code edits.
• Review and cross-checking — flagship: eln-adversarial-review. Requires an adversarial, multi-perspective review before substantive changes merge to main. A merge without the review record is mechanically refused.
• Cost and billing safeguards — flagship: eln-cost-watch. Demands a monthly cost estimate before billing-affecting changes, and forbids claiming "costs went down" until real measurements converge.
• Spec and design documents — flagship: eln-new-adr. Templates and indexes for filing and updating design-decision records.
• Progress records and handoffs — flagship: progress-record. Keeps investigation state in git-tracked logs so a new session can resume where the last one stopped.
• Code conventions — flagships: use-ts-pattern / no-else-no-default. Down to how TypeScript branches are written — unified by skills, not review comments.

Other categories cover infrastructure/AWS/environments, observability, security, internationalization, parallel git work, and team notifications.

A few skills up close

Names and roles below are the real ones.

Skills for not trusting AI reports

• eln-verify-before-claim — machine-checks claims against evidence (measured logs, test output) the moment before "done" is declared. No evidence, no claim.
• eln-report-guard — stops completion reports backed only by weak proxies ("build passed," "unit tests passed") and escalates them to live observation.
• answer-the-question-first — makes "is it finished?" get answered in the first sentence, not after a recap.
• eln-execute-dont-defer — stops the AI from bouncing CLI-executable work back to humans as "please do this manually."
• no-tracked-leftovers-at-goal — blocks "done" while tracked tasks remain. Zero leftovers is the definition of done.

Investigation and debugging discipline

• evidence-based-debugging — no guess-based fixes before logs, DB, and live requests are observed.
• zero-result-query-check — zero search results may not be concluded as "does not exist" until the query itself is validated.
• classify-failure-before-rerun — classify why CI failed before rerunning. No blind "let's just retry."
• read-current-state-before-implementing — read the current state from primary sources before implementing; prevents duplicate implementations of existing features.

Skills that protect money and production

• eln-cost-watch — cost estimates before, measured convergence after. Until then, "it's cheaper now" is unsayable.
• dynamodb-best-practices — database designs must show monthly cost as a number before code is written.
• billing-safety — a dedicated discipline for touching payment code; blocks changes that could double-charge or misbill.
• verify-after-deploy — deploying is not finishing. Live verification in production is part of the deployment.
• eln-deploy-target-checklist — enumerates every deployment target a change should reach; blocks "done" with only some targets updated.

Skills for working as a team

• eln-adversarial-review — adversarial multi-perspective review as a merge precondition, mechanically enforced.
• eln-codex-cross-check — has a different AI (Codex) review read-only, so one AI's blind spots get probed by another.
• eln-acceptance-ledger — captures mid-conversation "oh, also do this" requests into a ledger; no checkmark without evidence.
• progress-record / progress-recall — git-tracked state for resuming across sessions.
• prioritize-users-restated-goal-over-current-thread — when the human restates the goal, replanning outranks the current thread.

What each one does in depth, and the incidents they have actually prevented, will be their own articles in this series.

The gates, concretely — naming the bad completion report

One more level of detail on the completion gates. Suspicious AI reports become machine-detectable once you name the patterns. A few of the real detection classes:

• FALSE_SUCCESS — "done" without evidence
• WEAK_PROXY — claiming "works in production" from builds or unit tests alone
• MOCK_THEATER — using an all-mocked green test suite as evidence that the real thing works
• NARROW_PROBE — declaring "that feature doesn't exist" after reading one file
• FALSE_DEFERRAL — handing CLI-executable work back to the human as manual steps
• RESIDUAL_COMPLETION — listing leftover tasks and still closing with "done"

Evidence has a defined strength ladder too: static checks < unit tests < integration tests < live end-to-end < production observation. Claims about external boundaries (payments, webhooks, deployments) do not pass below live verification.

There is a gatekeeper at the end of the conversation as well. The moment a reply tries to end while declaring "done," it is checked against git's actual state, not prose: any changes not merged to main? any open PRs? any uncommitted files? If anything remains, the declaration bounces back with the unfinished items listed by name.

We do not build clever gates — a principle decided by measurement

By now you might think "just make the gates smarter." We learned the opposite.

We once considered having the completion gate judge whether evidence was genuine via pattern matching. Tested against 191 lines of real records, it wrongly rejected 76% of genuine evidence. That measurement froze the policy: mechanical gates check structure only (does a record exist, are leftovers zero, is the format satisfied); judging whether content is real is delegated to an independent reviewer — another AI or a human. The temptation to make gates clever was rejected by data.

New gates follow a fixed introduction path, too. They start in observe mode — logging warnings without blocking — and are promoted to blocking only after the false-positive rate is measured. One guard analyzed 30 days and 400 sessions of history to confirm "about nine operations a month would be blocked, nearly all correctly" before it was allowed to block. Even a rule that looks right does not get to stop humans until its false alarms are measured. That is the responsibility that comes with adding gates.

One more principle: gates never lock people in. If the checking tooling itself is broken, gates fail open; unblocking is reserved for the human's explicit action; and there is deliberately no environment variable that lets the AI unblock itself.

The moment a gate is born — three failures on record

Most skills carry the actual failure that created them. Three examples.

The zero-results misdiagnosis (April). Searching database logs by a field named timestamp returned zero rows, and we concluded "the logging pipeline is broken." The real field name was createdAt, and 7,406 log rows existed. Since then, a skill forbids "it doesn't exist" until field names, types, and time ranges are validated and an unfiltered probe proves data is present at all.

The $43-a-day bill (September 3). A recurring read over a growing table, added without estimation: 300 million read units a day. Plugging the numbers into the formula afterward matched the bill almost exactly — one line of arithmetic beforehand would have prevented it. Now, database designs cannot proceed without a monthly figure from "reads × unit price."

The prose that got walked past (September 6). Three days after we canonicalized the cost discipline as skill prose, a billing-affecting configuration change executed with zero estimation anyway. Documents — and skill prose — do not work unless they are read at the moment of execution. That failure promoted the cost rules into a gate that interrupts at the moment the command runs: billing-affecting commands are now refused outright unless an estimation ledger exists.

Every failure becomes a mechanism that makes the same failure impossible. 165 skills is also a record of how many times we have failed.

The catalog guards itself too

At 165, even the author cannot remember every skill's purpose and invocation. The count was 90 on July 2, 121 by July 20, 154 in August, 165 now. A hand-maintained list of a growing set will drift from reality, guaranteed.

So the catalog is auto-generated. Every skill's registration requires four fields — category, purpose, when-to-use, invocation — and the catalog is generated from those alone, in 16 categories. Invocation styles are classified three ways: 69 skills trigger automatically, 68 are called explicitly by name, 28 are use-when-you-like. The guidance for humans is simple: "if in doubt, remember only the 68 explicit ones."

The mechanism is doubly enforced: generation halts if required fields are missing, and CI fails if the stored catalog is stale. We once had a hand-written list quietly coexisting with reality — four numbers diverged — and that story is written up separately.

Scale — 289 releases in four and a half months

This plugin is developed under its own discipline (using it on itself daily is where the quality comes from). First commit April 28, 2026; since then 547 commits and 289 version bumps. 139 architecture decision records. Over 26,000 lines of skill procedure text.

There is a second layer besides skills: 134 "instincts" — behavioral lessons from past sessions compressed into one line each, auto-injected at the start of every session in confidence order. Skills are the procedures to follow; instincts are the situational reflexes from past failures. Ship the rules, and ship the experience too. With AI teammates, cross-project learning needs both layers.

What this means for your team

The plugin itself is internal, but the approach transfers.

• Pick one rule your team keeps breaking and move it from a document into a gate inside the workflow: a pre-commit hook, a required CI check, a template's required field. The location matters less than the property "you cannot proceed without it."
• If AI writes your code, start with a gate that demands evidence (measured logs, test output) for AI completion reports. That is where our 165 began.

Lessons you can take with you

• Development standards are not followed as documents. They are followed when they are built into the flow and block progress otherwise.
• With AI development, "gates that verify AI claims" become the core of quality. Start at four spots: completion reports, debugging, review, and cost.
• Keep mechanical gates structural; delegate meaning-judgment to an independent reviewer. Measure false positives before you let a gate block anyone.
• If your rules multiply, auto-generate the rule catalog. Hand-written lists always drift.
• Concentrate discipline in one place (a plugin), and every new project starts day one with the same quality bar.