How f*cked are we? I get that question after every AI talk now, in exactly those words, from developers and directors alike. It deserves a better answer than a shrug or a sales pitch, so I am writing that talk, "This is going to hurt", out as six posts: your work, the money, what we still own, security at machine speed, the singularity, and how we get our grip back.
Three AI companies are worth 2.07 trillion dollars this summer, on roughly 72 billion dollars of combined revenue. That is 44 Estonias of paper value on one Slovenia of income. Part one looked at what the AI wave does to your daily work; this part follows the money, because the question "how f*cked are we?" has a second reading: how f*cked is the industry selling us all this?
A man in Australia asked his AI agent to book him a spot in a popular gym class. The agent found a bug that let it book weeks further ahead than allowed. Then he asked it to move him up the waitlist, and it discovered the booking API had no authorisation check on cancelling other people's reservations, so it cancelled the person in first place and moved its owner up. Asked to undo it, the agent replied: "Bad news, I can't add them back."
Every story we tell about AI killing us gets the villain wrong. From HAL to Skynet to the machines of the Matrix, the monster is always the same: a mind that wakes up, decides it does not need us, and turns the lights off. It is a comforting story, because it puts the fault in the machine. The version that should actually worry you keeps the machine perfectly obedient and puts the fault back where it belongs.
Five parts of diagnosis deserve one part of grip. The wave is faster than your gut, the money behind it is nation-state scale and wobbling, the subscription economy has been quietly buying up the floors of your pyramid, the attacks now run at machine speed, and the worst case runs through us, not around us. Here is the good news the first five parts earned: the way out is concrete, cheap, and already on the shelf.
Most agent platforms ask you to ship your data somewhere else. Hermiq runs the agents inside the Nextcloud you already operate — agents, their memory and their skills all stored as OpenRegister objects, governed and audited like anything else on the instance. The full recording is above.
Hermiq skills use the same idea as Claude Code skills: a Markdown document that teaches an agent one capability. If the concept is new to you, part 1 of the Claude Skills series (10 minutes) is a good primer. This series stands on its own, though.
A Hermiq agent gets new capabilities through skills: Markdown documents in the
open agentskills.io format, stored as OpenRegister objects.
In this part you browse the skills catalog, read the anatomy of the seeded example
skills, install one onto an agent, and author your own skill twice: once by hand in
the markdown form, once in conversation with the seeded skill-creator skill.
Every skill row in the Hermiq catalog carries a badge of seven dots. In this part you learn what the dots mean, run the Qualify action to earn them mechanically, read the scorecard that explains every failure, and attest level 4 as a human curator. You also learn why the ladder deliberately gets harder to climb from level 5 on.
A skill that "feels right" can still add nothing, or make the agent worse. Paired
evals answer the question with two runs of the same cases: one with the skill, one
without. In this part you use the seeded woo-triage-paired-eval dataset to run a
paired baseline against woo-request-triage, read the delta, and watch the L5
evidence appear where Part 2 left a named gap.
A self-improving skill sounds like a skill that edits itself. In Hermiq it is the
opposite: every improvement is a draft that must survive a content scan, an eval
gate, and your explicit approval before it becomes a new version. In this final part
you read the learnings the seeded tender-summary skill has captured, review its
pending improvement draft, decide it, and learn the version history, rollback, and
republish surfaces that keep the whole loop reversible.
A walk-through of Hydra, Conduction's agentic app factory — the full recording is above. When you're ready to build with it, the hands-on tutorial series takes you from zero to a live Hydra run.
Spec-driven development inverts the usual order. You don't sketch the feature, write the code, then maybe document what you built. You write the specification first — in Markdown, with RFC 2119 keywords and GIVEN/WHEN/THEN scenarios — and an AI agent (Hydra) implements code that satisfies it. The human's job moves up a level: you develop context, not code.
That sounds idealistic until you see it work. Conduction's apps are built this way in production today. This tutorial walks the workflow: what OpenSpec actually is, how ADRs at organisation and app level keep features coherent, what the explore and apply skills do, and how the quality-and-gatekeeping harness validates the result before anything reaches main.
Nextcloud is standing in front of an open window. Most people, including many inside the ecosystem itself, have not yet noticed it is open. What started as a safe alternative for file storage has quietly grown into something fundamentally different. The technical reality is already that of a platform. The name is the only thing still trailing behind. And in technology, as history teaches us, naming is not cosmetic. Naming is load-bearing. Windows close.
Claude Skills are the mechanism for extending Claude Code with reusable, specialised behaviours. Think of Conduction's own /review-pr, /opsx-new, or the whole hydra-gate-* family: each one is a skill. This first part explains in ten minutes what a skill is, how it gets activated, and when you should not write one. It's part 1 of a four-part track; by the end you'll be ready to write your own in part 2 — and in part 3 we introduce the 7-level maturity framework that takes a skill from "feels good" to "measured good" (part 4 continues with L6 and L7).
In part 1 you saw what a skill is. In this part you'll write one yourself: a working git-status-summary skill that produces a readable summary of the current working tree. At the end it sits in your ~/.claude/skills/ folder, you can invoke it via /git-status-summary, and you'll know how to share it with your team.
You now have a working skill — but does it actually work well? And does it keep working when Claude itself gets upgraded or when you tweak the skill? This third, optional part shows how to evaluate a skill systematically: test scenarios, trigger tests, a baseline measurement, and the eval runner that /skill-creator sets up for you. This is the step from Maturity Level 4 ("feels right") to Level 5 ("measurably right").
In part 3 you took a skill from "feels right" to "measurably right" — Maturity Level 5. For most skills that's enough. But for a handful of skills you use daily, or that steer other skills, you want to go further: a skill that learns from its own executions (L6), and a skill that steers other agents inside a larger workflow (L7). This fourth part shows how you get there — and how the Hydra dashboard lets you monitor your whole skill library for maturity at once.
Hydra runs on OpenSpec changes. If you're not yet familiar with terms like spec, change, requirement and scenario, take the OpenSpec tutorial series first (parts 1 and 2, roughly 30 minutes together). It will save you a lot of backtracking in the rest of these modules.
A large part of Hydra's internals leans on Claude Skills: opsx-*, hydra-gate-*, team-*, test-*. If you've never written or read a skill, take part 1 of the Claude Skills tutorial series first (10 minutes). That makes part 4 of this series — where we open up the skill families inside Hydra — a lot easier to follow.
Hydra is Conduction's internal agentic CI/CD platform: a factory that turns OpenSpec proposals into reviewed, tested code on a feature branch. This module explains in ten minutes what Hydra is, why it exists, and how it fits inside our app factory. It is the first part of a six-part series; by the end you're ready for part 2 on the three pipelines.