Conduction

By Part 6 your PetStore app is shipped and integrated. Along the way the manifest renderer mounted a handful of nc-vue components for you (CnAppRoot, CnPageRenderer, CnIndexPage, CnDetailPage, CnDashboardPage, CnObjectSidebar, CnMarkdownEditor) and Part 5b walked through the dashboard widget vocabulary. The lib ships ~70 Cn* components and a dozen composables. Part 7 is the capability tour: which component to reach for when, what the composable layer does for you, and how the whole library fits together so you stop guessing.

This is a tour, not a reference. The full prop tables live on nextcloud-vue.conduction.nl. Use Part 7 to build the mental map; use the lib docs to look up signatures.

A 45-minute tutorial that gives your PetStore app a documentation site. Hosted from your own Codeberg or GitHub repo via the central documentation workflow, illustrated with abstract screen mocks that compose from design tokens, and brought to life with real screenshots that Playwright captures from your running app. By the end, every push to development rebuilds and republishes.

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.

This is Part 5 of the nine-part app-building tutorial series. Parts 1–4 got you a working app: scaffold, schemas + manifest, schema-driven Calendar integration, and a custom Care tab. Part 5 is the "now what": the v2.7.0 manifest features Parts 1–4 deliberately skipped so the learning curve stayed gentle. You don't need any of them to ship PetStore, but the moment your app needs a public form, a wiki, an admin-only listing, or a markdown editor inside a form, they save you from another round of hand-rolled Vue.

Three principles run through every feature in this part: schema-driven (no per-page Vue), type-safe (the manifest schema validates every shape before runtime), and fleet-portable (the same JSON works in every Conduction app and gets lib upgrades for free).

This is Part 6 of the nine-part app-building tutorial series. Part 4 packaged the app and put it on the Conduction store; this part makes it talk to the rest of the workspace: three integration patterns layered from least to most invasive. By the end your orders know who their supplier is, every order shows the right care guide from xWiki, and a needs_followup order automatically opens a maintenance page in xWiki that flips the order back to delivered when the page is marked resolved.

The point isn't the specific integrations, it's the pattern. Cross-register reads are how Conduction apps share data without coupling. The OpenConnector source-and-synchronisation pattern is how you absorb data from anywhere into your own register. The webhook endpoint pattern is how external systems push state back. Once you've wired all three, you've covered the integration vocabulary the rest of the catalogue uses.

The OpenWoo community meets every second Tuesday of the month. Vendors (Conduction, Xxllnc, OpenGemeenten, SHIFT2, Acato, Notubiz, iO), municipalities in production or acceptance, and KOOP share progress, blockers, and the next slice of the roadmap. Below are all recorded sessions since late 2023.

Part 4 of the nine-part app-building tutorial series. Part 3 made orders appear in NC Calendar with one schema annotation. Part 4 brings external knowledge, category-specific care advice, husbandry notes, feeding tips, from xWiki into the pet detail sidebar via a care_guide OpenRegister schema. Then we package the app and ship it.

External knowledge integration is the canonical case for OpenConnector. Pull data from a system you don't own (xWiki here, but the same applies to Confluence, Notion, SharePoint, Decos, Mendix), surface it inside Nextcloud-native UI without making the user context-switch.

This is Part 3 of the nine-part app-building tutorial series. Part 2 wired the pet and order schemas. Part 3 makes those orders appear in every user's Nextcloud Calendar (without writing a controller, an event listener, or any per-app calendar glue).

The trick: OpenRegister already ships an ICalendarProvider (RegisterCalendarProvider) that exposes any schema with a calendarProvider block as a virtual calendar. You declare the block on the order schema. NC Calendar shows the events. That's the whole story.

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.

This is Part 2 of the nine-part app-building tutorial series. Part 1 left you with an empty app shell, a chassis, no data. Part 2 fills the chassis: three schemas (modelled on the OpenAPI Pet Store), a manifest, and the same five Cn* pages drive every list, every detail view, every dashboard with the schema as the single source of truth.

The shape we keep saying "this saves you code" finally has numbers behind it: ~200 lines of hand-rolled Vue collapse to three.

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.

In part 1 you saw that Hydra has four personas. In this part we look at the pipeline: how those personas work on one issue one after another, which labels mark the transitions, and when the pipeline diverts to needs-input. By the end you'll know Hydra's label state machine inside out and you'll be able to steer an issue back to the right phase if it gets stuck somewhere.

In part 2 you saw that the three personas are backed up by mechanical quality gates — checks that pass or fail deterministically, without AI in the loop. This part explains which gates we have, why they are mechanical, and how to handle the exception: the false positive.

The previous parts were about what Hydra does. This part is about how: the skills that let the personas do their job. By the end you'll know which skills the automated pipeline (the "Hydra factory") runs and which ones you call yourself as a human, you'll know the five families, and you'll be able to judge when a new skill is worth writing.

The first four parts were about concept, pipelines, gates and skills. Time to actually run. In this part you start a full Hydra run on a target app, paying attention to the practical pitfalls: tokens, images, and — if you work with multiple devs against the same repos — the HYDRA_LABEL_PREFIX trick.

In part 5 the pipeline was running. Now the final part: what do you do when it doesn't go green? This part gives you the decision tree — ordered from cheapest intervention to most expensive — and the patterns that get needs-input issues moving again.

OpenSpec is a lightweight framework for spec-driven development: first write down what a feature should do, only then write the code. In this twelve-minute module you'll learn what OpenSpec is, which concepts it builds on, and why we use it underneath almost every Conduction project. By the end you're ready for Part 2, where you'll actually write your first change.

Time to see OpenSpec in action. In this part you'll create your first real change inside a Conduction project — from empty folder, through a spec-delta with a requirement and scenario, to a validated proposal ready for implementation. We do that with the Claude Code skills /opsx-new and /opsx-ff.

This is Part 1 of the app-building tutorial series, the hands-on chassis lap. If you haven't read Part 0: Three paths, one curriculum yet, that's the orientation that explains why we build on this stack rather than raw Nextcloud, and how the manifest and @conduction/nextcloud-vue work as two intertwined surfaces. Part 1 picks up after that decision is made.

You'll build PetStore, a Nextcloud app on top of the OpenAPI Pet Store domain (pets, orders, categories, tags) on the full Conduction Nextcloud stack. The end product: add pets to the store, place orders, see order ship-dates in your Nextcloud Calendar, and surface category-specific care guides from xWiki right next to each pet. Every piece reuses what @conduction/nextcloud-vue and OpenRegister already give you for free.

In Part 1 you scaffold the app, rename it, build it, and see the canonical app chassis on screen. No data, no integrations yet. We get the bones right first.

Every other tutorial in this academy needs a working Nextcloud. This is the fastest route: a few commands and you run the official Nextcloud locally on your laptop, identical to production. You do not need to be a programmer — if you can install an app and copy and paste text, you will get through this. After that you install the Conduction apps from the Nextcloud app store, the same path as production.

A Woo publication without files is metadata without evidence. In this tutorial you attach documents to a Woo publication through four upload modes: one file, multiple files at once, and large files in chunks. Plus publish, unpublish, and clean up.

The Dutch Open Government Act (Woo) requires government bodies to publish documents in eleven information categories. OpenRegister provides the storage model for that. In this tutorial you import the canonical Woo register, with all TOOI categories, in a few minutes.

This is Part 0 of the nine-part app-building tutorial series, the orientation lap. Before scaffolds, schemas, or manifests, the most useful thing we can hand a new developer is an honest map of the three ways Conduction apps actually get built, what each one costs, and what each one gives back. The rest of the series picks one path and shows the receipts. Part 0 explains why.

A second thing matters from minute one: the manifest system and the @conduction/nextcloud-vue component library are two different surfaces. The manifest is the declarative what, a single manifest.json that describes navigation, pages, configuration. nextcloud-vue is the rendering how, the Cn* components the manifest dispatches to (CnAppRoot, CnPageRenderer, CnIndexPage, CnDetailPage, CnDashboardPage, and the rest). They are technically separable. They are also so intertwined in practice that the rest of this series teaches them together, and every lesson names which surface it is touching.

The series uses the OpenAPI Pet Store as the running example: pets, orders, categories, the same entities every API developer has met before. It's the canonical sample domain across the Conduction academy. By the end of the series you have a working PetStore app on the Conduction stack and the mental model to build your own real app on the same patterns.

A short note on a single OpenTelemetry collector processor that disproportionately moved the needle for us. This post is a placeholder while we draft the full version.

This is the first post on the new Conduction site. We are in active development; the brand book at connext.conduction.nl/identity will be re-homed here once the OpenCatalogi content plugin lands.

A short walk-through of the Model Context Protocol server we ship for OpenRegister. Placeholder while we draft the full version.

A short summary of the migration. Placeholder while we draft the full version with the customer's permission.

Recording and Q&A from the webinar. Placeholder while the video is uploaded and the transcript is prepared.