The conversation at DrupalCon Rotterdam 2026 won't just be about what Drupal CMS 2.x can do - it will be about how teams are actually getting there. Migration is the real-world bridge between the platform you have today and the Recipe-driven, Canvas-powered experience covered in Post #1 of this series.
This post is a hands-on guide covering the three migration paths developers are navigating in 2026, the tools that power each one, and the common pitfalls that derail projects weeks or months into execution. We'll go deep on the Migrate API, look at real YAML definitions, and document the failure modes you're most likely to hit - along with their fixes.
Understanding What You're Actually Migrating
"Migrating to Drupal CMS" covers three structurally different problems. The tools, timeline, and risk profile are different for each:
Your Current Platform
Migration Type
Primary Tooling
Drupal 7
Data + platform upgrade
Migrate API + Migrate Drupal
Drupal 9 / 10 / 11 (classic)
Layer adoption, no data move
Recipes + Canvas adoption
WordPress / Joomla / AEM / Sitecore
Full platform replacement
Migrate API + custom source plugins
Knowing which one you're doing early - before scoping or quoting - is the single biggest factor in accurate estimation.
The Migrate API: Your Foundation
Regardless of source platform, Drupal's Migrate API is the ETL (Extract-Transform-Load) engine underneath every non-trivial migration. It lives in Drupal core and is composed of three module layers:
migrate- the core framework: source plugins, process plugins, destination plugins
migrate_plus (contrib)- adds source types (JSON, XML, SOAP, HTTP), process plugin extras, and migration groups
migrate_tools (contrib)- adds the Drush commands you'll use day-to-day
Install the contrib layer before anything else:
Image
A source plugin reads rows from legacy data. Process plugins transform field values one by one. The destination plugin writes to Drupal entities. Understanding this pipeline is what separates developers who debug migrations quickly from those who spend days chasing phantom errors.
Path 1: Drupal 7 → Drupal CMS 2.x
Drupal 7's end-of-community-life has passed, and commercial extended support windows are closing. If you're still running D7 in 2026, this migration is urgent - not optional.
Setup: Point the Migrate API at Your D7 Database
Add the legacy database as a second connection in settings.php:
Image
Image
Inspecting the Generated Migrations
The upgrade command generates a full set of migration YAML definitions tailored to your D7 module footprint. Before running anything, inspect what was created:
Image
Writing a Custom Content Type Migration
Auto-generated migrations handle standard field types well. Custom CCK fields, computed values, or non-standard formatters need explicit YAML definitions. Here's a realistic example - a D7 Event content type with a date range field:
Image
Image
Path 2: Classic Drupal 9/10/11 → Drupal CMS 2.x
This is the most common scenario at agencies right now: modern Drupal running well, but built before Recipes and Canvas existed. There is no data migration here - your content stays exactly where it is. What you're adopting is a new site-building layer.
Step 1: Inventory Your Current Setup
Image
Step 2: Add Drupal CMS Packages to Composer
Image
Step 3: Apply Recipes Selectively
Image
Because recipe config actions use createIfNotExists, this is safe on a live codebase - it will not overwrite your existing SEO or media configuration; it only fills in missing pieces.
Step 4: Making the Canvas Decision
This is where teams stall. If your current site uses Layout Builder or Paragraphs for page composition, official tooling to migrate into Drupal Canvas does not yet exist as of mid-2026. Your real options today:
Option A - Hybrid adoption (most common): Keep existing Layout Builder/Paragraphs pages untouched. Use Canvas only for new pages, landing pages, and templates going forward.
Option B - Manual high-value rebuild: Identify your top 10-20 highest-traffic pages. Rebuild those in Canvas using Mercury components. Leave the rest.
Option C - Wait: If your site has thousands of Paragraphs-based pages, holding for official migration tooling may be the most pragmatic decision - a visible discussion at DrupalCon Rotterdam.
Path 3: WordPress / Other CMS → Drupal CMS 2.x
This is the highest-complexity path but increasingly common as organizations exit proprietary platforms for digital sovereignty and cost reasons.
The Contrib Stack
Image
A Real WordPress-to-Drupal Migration YAML
This example extracts WordPress posts from a side-by-side MySQL database and loads them into Drupal CMS article nodes:
Image
Image
Handling Media: The Hardest Part
Media is where CMS migrations to Drupal quietly break - broken image paths and dead embedded media are among the most common post-launch complaints.
The problem: body content migrated as raw HTML still contains <img src="/wp-content/uploads/..."> paths referencing the old platform. Two strategies fix this:
Strategy A - Migrate files first, rewrite src attributes after
Image
Strategy B - Use the file_import process plugin
Image
Always run a dedicated media migration pass before your content migration, so file entities exist before nodes try to reference them.
The Six Most Common Migration Pitfalls (and How to Fix Them)
⚠ Pitfall 1 Migration is busy with another operation: Importing
The most frequently encountered Migrate API error. It happens when a migration process is killed mid-run (Ctrl+C, server timeout, PHP fatal) and the status lock isn't cleared.
The fix:
Image
⚠ Pitfall 2 Skipping the Content Audit Phase
A reliable migration follows six stages: audit, content mapping, environment setup, content migration, media migration, and SEO preservation. Skipping a stage tends to resurface later as a launch-day fire drill.
A full pre-migration audit must cover:
Total row counts per content type and per file type
Fields with data in fewer than 5% of records (candidates for dropping)
Taxonomy terms with zero content references (clean up before migrating)
Broken internal links in body content (fix at source before migrating, not after)
User accounts with no content (migrate only active users)
⚠ Pitfall 3 Not Planning for Delta Migrations
Initial migration runs are never the final run. Between your first migration pass and go-live, editors will keep publishing on the old platform. You need a delta migration strategy - re-running migrations to pick up records created or updated after the initial pass.
Image
⚠ Pitfall 4 Incorrect URL Alias Handling
After migration, old URLs may lead to 404 errors if not redirected correctly. Set up 301 redirects for old URLs to preserve SEO and user experience.
The pathauto module will regenerate URL aliases on save - which is exactly what you don't want post-migration if your old URLs had a different pattern. Disable Pathauto auto-generation on migrated content by setting path/pathauto to 0 in your migration YAML (as shown in the WordPress example above).
Image
⚠ Pitfall 5 Migrating Roles and Permissions Too Early
If you migrate users before your Drupal CMS roles and permissions are fully configured, user role assignments land in the system referencing role IDs that either don't exist or have different permission sets than intended.
The correct order:
1. Configure roles and permissions on the destination site first
2. Export config with drush cex
3. Then run upgrade_d7_user or equivalent user migration
4. Verify a sample of migrated users have the expected roles before migrating content
⚠ Pitfall 6 Not Rolling Back Cleanly Between Test Runs
During development and testing, you'll run migrations many times. Not rolling back cleanly between runs leads to duplicate content, inconsistent map tables, and cascading lookup failures.
Image
Migration Strategy: Choosing Your Cutover Approach
Beyond the technical tooling, the cutover strategy matters as much as the code. Three patterns dominate real-world projects:
Strategy
Best For
Key Characteristic
Big Bang
Smaller sites (<300 pages)
Single cutover, maintenance window required
Progressive
Large content libraries
Reverse-proxy routing, sections migrate gradually
Hybrid (API Gateway)
Regulated industries, complex integrations
Drupal CMS as content hub, legacy systems via API
Realistic timelines from field experience: small projects 6-12 weeks, medium-complexity 3-6 months, large enterprise migrations 6-12 months or more. These aren't conservative padding - they reflect what competent, well-resourced teams actually take when they don't skip the audit and planning phases.
After the Data Lands: Apply Recipes
This is the step migration guides most often omit. Migrate moves your content - it does not configure Drupal CMS's site-building layer. After your data migration validates cleanly, apply the relevant recipes:
Image
What to Watch at DrupalCon Rotterdam 2026
Layout Builder & Paragraphs → Canvas migration tooling - the single most-requested missing piece; community proposals are expected in the Drupal CMS track
The Migrate Drupal deprecation path - what officially replaces D6/D7 upgrade tooling in Drupal 12.x and beyond
Delta migration patterns for headless and API-sourced content - increasingly relevant as organizations move off SaaS headless platforms
Case studies from the Digital Sovereignty track - real migration stories from organizations exiting proprietary CMSs, with full technical detail
Summary
Migration to Drupal CMS 2.x is three different problems depending on where you start:
Drupal 7 sites use the core Migrate API + Migrate Drupal, with urgent deadline pressure and the 11.4+ deprecation on the horizon
Classic Drupal 9/10/11 sites need no data migration - selective Recipe adoption and a deliberate Canvas strategy is the whole project
Other CMS platforms need custom Migrate API source plugins, a full content audit, delta migration planning, and a clear cutover strategy
In every case, the six pitfalls covered in this post - stuck migration locks, skipped audits, missing delta runs, broken URL aliases, wrong sequencing of users and roles, and unclean rollbacks - account for the majority of timeline blowouts. Most of them are avoidable with upfront discipline.
← Post #1: Getting Started with Drupal CMS 2.x: Site Building with Recipes
→ Post #3: AI-Powered Drupal: Integrating LLMs and Agentic Architecture
References
Migrate API Overview - drupal.org/docs/drupal-apis/migrate-api/migrate-api-overview
We toured the resort, planned events, sampled food and drinks (strictly for quality assurance, of course), floated around the pools, and spent way too much time talking about all the fun stuff we're putting together.
After seeing everything in person, I'm convinced this is going to be the best DrupalCon ever!
This DrupalCon is going to feel different (and I think that's a good thing)
If you've been to previous DrupalCons, one thing you'll notice right away is that this one is going to have a different vibe. Normally we're in a downtown convention center where you can walk to bars, restaurants, coffee shops, and whatever else you stumble across.
This isn't that. The Grand Cypress sits in the middle of Orlando's resort area near Disney. If you want to leave the property, you'll probably grab an Uber or Lyft. Disney Springs is only about 10 minutes away, and the parks are just beyond that.
But honestly... I don't think most people are going to want to leave. This resort is awesome.
Instead of everyone scattering around downtown after the sessions end, I think we're going to end up hanging out together around the resort having poolside cocktails, or smores by the fire pits. And after spending the weekend there, I think that's going to make for an even better conference.
The pools are ridiculous
Seriously. The pool area is unlike anything we've ever had at a DrupalCon.
The pools wind around faux limestone cliffs with waterfalls pouring down into them. There's a cave that connects two sections of the pool, a grotto, a waterslide, two hot tubs, and tons of places to spread out.
Then you've got a poolside bar serving frozen drinks, beer, and food just a few steps away. I can already picture dozens of Drupal people hanging out there after sessions.
Florida in March is basically cheating
If you're coming from somewhere that's still cold in late March... congratulations. This is probably the nicest time of year to be in Florida.
Expect highs around 80°F (27°C), cool evenings, blue skies, and weather that's pretty much perfect for sitting outside all day. It's warm enough to swim without feeling like you're melting.
One of the nicest surprises is the hotel rate that we have. The Drupal Association was able to lock in an incredible rate of just $259/night, and that includes no resort fee. Considering this is one of the best times of year to visit Florida (and a resort like this!) it's an amazing deal. If you're planning to attend, book sooner rather than later:https://www.hyatt.com/events/en-US/group-booking/VISTA/G-DC27.
Everything is actually close together
This might sound boring compared to waterfalls and waterslides, but trust me, it matters. One thing I loved about the venue is how compact the conference space is. No hiking across giant hotel lobbies or speed-walking half a mile to your next session. No wondering which section your talk is actually in.
Everything is clustered together, which means less walking and more time talking to people in the hallways, which is the best part of every DrupalCon anyway.
Drupal's Got Talent is finally happening!
I've been trying to make this happen for years. Every DrupalCon I'd pitch the idea of a talent show, and every year something got in the way. Well... this is the year! It's happening!
We'll be looking for pretty much anything entertaining:
Musicians
Bands
Stand-up comedy
Magic
Singing
Dancing
Juggling
Puppet shows
Weird talents you didn't think anyone wanted to see (we do)
We're not taking sign-ups just yet, but keep an eye out!
What should you pack?
Besides your laptop?
👙 A swimsuit (trust me)
🩴 Flip-flops or sandals
😎 Sunglasses
🧴 Sunscreen
👕 Clothes for warm afternoons and cooler evenings
🎤 Your hidden talent
This venue is a little different than what we're used to, but after spending the weekend there, I know it's going to create a totally different kind, and super memorable, DrupalCon.
Instead of everyone disappearing into the city after the sessions end, I think people are going to stick around. Hanging out by the pool. Sitting around the fire pits. Grabbing a drink. Talking Drupal late into the night.
Drupal teams can govern the context supplied to AI agents, but they cannot make model behaviour deterministic. Kristen Pol explains why that distinction matters when evaluating CCC for policy-sensitive and production-facing workflows.
AI-powered internal linking in Drupal uses vector search and LLMs to surface relevant links as you write. Read this blog to learn how it works and which modules to use.
A portable SKILL.md file does not guarantee portable installation. Drupal now has Composer-aware skill aggregation, while its maintainers are debating how much distribution logic belongs in Drupal rather than the wider Agent Skills ecosystem.
Single Directory Components (SDC) are the biggest change to Drupal theming in a decade, and one of the quietest. There was no page-builder launch, no new screen to learn, just a simple answer to a question Drupal front-end developers had been asking for years: why are all the pieces that make up one part of a page scattered across five different folders?
I am doing some maintenance work on the Entity Pager module, which has been fixing bugs, improving the tests, and so on. And because Computed Field is also a module I maintain, and because I have at the back of my mind the idea of finding more use cases for it, I had the thought that I could add support for Computed Fields to Entity Pager.
Specifically, this would mean that Entity Pager would allow you to add computed fields to your entity type, which would be computed entity reference fields to the previous and next entities in the pager. As well as allowing you to output the previous and next links with more flexibility, and within the rendered entity rather than in a block, it would open up having these links in JSON:API (though there's a bug to fix still).
So, then, quite a good use case!
It does, however, require a bit of re-plumbing inside the EntityPager class. Currently, EntityPager, expects to be instantiated within the theming for an executed view. Our computed field needs a new API which it would call with the basic data (the view ID, display ID, and current entity), and that would take care of executing the view, extracting the data from the result, and returning it.
I suppose I could make a whole new pathway, but a lot of the code that would need is in EntityPager so it makes more sense to me to change that to allow both cases. This means adding a new way of constructing it from the factory service, and then executing the view if necessary.
So then we'd have an API for getting the previous and next entities. And that's where the big idea suggests itself: what if we used this API for everything?
Currently, the rendered entity pager is a specially-themed view. We define a custom Views style plugin, and that uses our theme template 'entity_pager' for its theming. We use the Views block system to show the pager. By the time our code is involved, the view has already been executed, and all of our code is taking place within the Views theming. This makes it tricky to do things like hiding the pager completely.
But... once we have an API, we could totally invert this. We could define a custom render element which outputs the pager. This would take the view ID and display ID as properties, and the current entity if you have it (and continue to detect it from the current route if you don't). Like this:
This render element would then be in charge of executing the view, and getting the data it needs from the view's result. You'd still store settings for the pager on the view's style plugin, but we'd no longer rely on the theming of that - the view would just be used as a data source. The render element would have similar theming to the Views style - it could pretty much use the same Twig template. The block we provide would change to being a completely custom block plugin, which would output the pager element.
To me, this seems like a cleaner structure. Our pager is a separate render element, and our code no longer runs inside Views rendering, which feels a little bit convoluted and fragile.
If you use Entity Pager, what do you think? Would this make your use of Entity Pager simpler, more complex, or not affect you at all? It would be a big change to the module, so I'd love to hear opinions on the issue for this, as I'm still undecided about it.
Do you need help with updating a contrib module, refactoring it, or expanding its capabilities? I'm available for hire - contact me!
Beta 4 release of Drupal AI Context Beta 4 of Drupal AI Context , also known as Context Control Center (CCC), is now available. CCC helps Drupal sites provide governed, reusable context for AI workflows and agents, from brand voice and editorial standards to organisational knowledge and governance rules. This gives AI systems access to more structured and relevant information while allowing teams to manage that information centrally. Following the beta 3 release , beta 4 has been shaped by extensive community testing and an expanded scope. The community testing revealed refinements for a more intuitive user experience, and several features earmarked for 1.1 have been brought forward into 1.0. The result is a more capable, usable and reliable context management system.
There is a catch in calling all of this "open AI." Downloadable weights under an open-source licence do not by themselves establish that an entire AI system is open source. Under the Open Source Initiative's Open Source AI Definition, the preferred form for modification also requires sufficiently detailed information about the data used to train the system, the complete source code used to train and run it, and the model parameters. Even so, downloadable weights can expand practical deployment choices by allowing organisations to run and adapt models on infrastructure they control rather than relying solely on a vendor-hosted service.
Drupal is relevant here not because a content management system and an AI model are equivalent, but because the project has spent 25 years working within open-source principles. Drupal marked its 25th anniversary on 15 January 2026, and the Drupal Association's Open Web Manifesto describes the open web through principles including freedom, decentralisation, participation, choice, privacy and security. The comparison should remain limited: a content management system, model weights, training data, source code and computing infrastructure are different layers with different licensing and governance problems. The shared principle is practical: leave organisations room to choose infrastructure, modify systems, and avoid unnecessary dependence on a single provider.
The larger question is whether those principles are becoming easier to recognise beyond software-development communities. AI is forcing organisations to consider what happens when a technology provider changes terms, raises prices, closes a service or simply stops fitting their needs. Drupal cannot answer AI's licensing, computing, data-governance or portability questions, and open source does not guarantee independence. What Drupal can offer is a 25-year example of why choice, modification and exit matter when digital infrastructure becomes important enough to depend on.
As AI becomes another dependency inside websites and digital services, that old open-web argument has a new place to land. The question is no longer only what an AI model can do, but how much control remains with the people and organisations that build on it.
If AI can generate an application from a description, is software still worth anything?
I have lived with a version of that question longer than most.
I released Drupal for free more than twenty-five years ago, and later co-founded Acquia, which has grown into a large enterprise software company built around Drupal.
Granted, Drupal is free in a different way than AI-generated applications are free, but I'm not sure that changes the basic question of how to build a successful business around either one.
Open Source made code abundant by giving people broad rights to use, modify, and redistribute it. AI is lowering the cost of producing code. One lets you copy the software; the other makes it cheaper to recreate software.
Free code changes what customers pay for
Because anyone could use Drupal for free, Acquia could never build a durable business around access to the code. From the start, we had to make money another way.
We built that business around helping enterprises build, run, and manage Drupal applications throughout their lifecycle. That includes hosting, but goes well beyond it: the tools and services needed to develop, deploy, secure, scale, monitor, and improve applications in production.
Proprietary SaaS typically bundles access to the application with the hosting and operations required to run it. With Open Source, organizations can run the software themselves or choose who hosts and operates it.
As AI makes applications cheaper to recreate, the traditional SaaS bundle of software and operations comes under pressure. Customers may become less willing to pay for access to application functionality without becoming any less willing to pay to run and manage applications in production. For Open Source businesses those economics are not new.
Dependability becomes the product
Software can be free, or nearly free, without becoming cheap to depend on. The more people and organizations depend on a system, the more of its value comes from operating it securely, reliably, and at scale.
Once people depend on an application, the cost of its failure has little to do with how much it cost to build. An application that costs $1,000 to build can still cause a $10 million failure.
As AI makes enterprise applications easier to create, adapt, and integrate, they still have to be deployed, secured, scaled, monitored, and run reliably over time. As software cost comes down, dependability becomes a differentiator.
Linux is abundant; dependable cloud infrastructure is a service worth paying for. Drupal is abundant; dependable digital experience infrastructure is a service worth paying for.
Acquia has lived with those economics for nearly 20 years. Drupal made the code abundant, so we built our business around helping organizations build, run, and improve what they created with it. As AI makes code cheaper to generate, that business model may start to look a lot less unusual.
Either way, more software companies will have to answer the same question: if the code is abundant, what are customers really paying you for?
In the last article I mentioned something about the Jadu API that caused me a lot of headaches. The API contains most of the information for a page, but critically, the Jadu API contains no information about the path of a page. There is basically no way to get the URL of a page in Jadu from the XML API.
I'm quire sure that this makes creating anything useful in the API a real pain since referring back to the site needs to be done with manually placed links, but it's clearly like this by design. I couldn't find any documentation on why it is like this, but it almost feels like vendor lock-in. Please correct me if I'm wrong here.
If you migrate a page from one system to another then it is highly important that you maintain the URL structure of the site. If you change the URL of a page then you need to add in a step that adds a redirect from the old system to the new so that all of your search engine results, the existing links from other sites, and any user bookmarks that have been created work correctly. This is critical to get right for a public facing council site like this.
Since I was migrating into a LGD site, it made sense to use the Drupal path auto system and LGD path management plugins to manage the paths on the Drupal site. We therefore needed to know the existing Jadu URLs so that we could create these redirects.
To get the URLs during the migration caused quite a bit of experimentation, but I did solve the issue with a solution that had a high success rate.
Webform is the most popular module for building forms in Drupal. You can use it for a simple contact form or for a long form with conditional logic, file uploads, and email alerts. Either way, you build the whole thing from the admin interface without writing code.
In the video above, you will learn how to build a form with Webform in Drupal CMS. You will create a Customer form, add conditional logic, send a confirmation email, split the form into pages, view submissions, and embed the form on a Drupal Canvas page.
A man who runs an insurance agency showed me software he built himself, after paying a development company for months and getting nothing. I sat there listing everything that could go wrong with it, and then realized nobody had asked me to. If building is no longer the hard part, I don't know what the rest of us still bring, and I'd rather work that out in the open than pretend I already have.
Thirty years ago last month, between my sophomore and junior years of college, I started a company called Palantir Internet Services, later known as Palantir.net. I had been building personal websites for nearly two years at that point and was captivated by this revolutionary new medium that allowed anyone, anywhere, to publish something that anyone else in the world could read.
While the internet touches nearly every part of our lives today, in the summer of 1996 it was still seen by many as a novelty. There were only about 250,000 websites on the web, and while Amazon and eBay had already launched, Google, Facebook, and Wikipedia were still years away.
That fall, I met Tiffany Farriss, and together we built Palantir into a company that developed websites for clients of all shapes and sizes. As college students, we were featured in a news story on CNN and profiled in a front-page Chicago Sun-Times article. Our first paying clients were colleges and universities, and then for several years we partnered with Chicago design firms who were making the transition from print to the web.
During that time, we built and deployed several versions of our own in-house content management platform, eventually deprecating it in 2007 in favor of the newly released Drupal 5. Putting our energy into contributing to an open source project not only brought us new business opportunities but also introduced us to a community we are proud to still be part of today.
Along the way we grew into a full-service digital consultancy, bringing our strategy, design, build, and support services to public sector agencies, higher education institutions, nonprofits, and healthcare organizations whose needs are genuinely complex and whose work has a profound impact on others.
Only a handful of companies in our industry have been around as long as we have. Over the years, we've watched it go through several transformations: the dot-com bubble of the late 1990s, the rise of "Web 2.0" and social media in the mid-2000s, and the emergence of smartphones and the mobile web in the late 2000s.
Today, we are in the middle of one of the web's biggest transformations yet, as generative AI has fundamentally disrupted the traditional ways that online content is both created and consumed. The business models that built the web are no longer sufficient for an environment increasingly dominated by bot traffic and bot-created content. As more money has flowed into generative AI, we've seen less of it invested in other forms of online infrastructure, and that shift has affected us and many others in our industry.
At the same time, these tools have already demonstrated their usefulness for automating manual and labor-intensive work, from code review to content audits. We believe that when used thoughtfully, generative AI can improve the online experience and make vital information more accessible to more people.
And that's why, in an era of slop and enshittification, we feel it's more important than ever to recommit to our mission and vision. Palantir exists to help others discover, create, and share knowledge, and to strengthen humanity through the work that we do and the way that we do it.
We may not be able to predict the future, but 30 years of experience gives us a lot of perspective on where things have been and where they might go next. Technology keeps changing, but it's people who decide where to put their time and attention. That's the choice we've made so far, and it's the one we will continue to make.
I know this blog post's title implies losing my (programming) skills, and I will gladly address my feelings about how agentic coding has caused my problem-solving and coding to atrophy from lack of use. The main focus of this post is about losing, specifically deleting, my overly verbose and complicated skills and AGENTS.md files.
I was inspired to write this post after recently switching to the latest OpenAI GPT 5.6 models with Codex and OpenCode as my harnesses for Drupal development. In a previous post, I discussed that one approach to working with AI is to accept that every beginning and end of a session is like onboarding and offboarding a new team member. To help onboard an AI, we need to provide documentation, guidance, and workflows, typically implemented as AGENTS.md and agent skills.
AGENTS.md and agent skills are instructions added to your context to nudge the AI in the right direction. After switching to a more intelligent frontier model, I began to suspect I needed to rethink my assumptions about what the AI was capable of and how much initial context was required for the AI to succeed at a task. So I removed all my assumptions, deleted my AGENTS.md and skills directory, and started fresh.
Losing my agent skills
I had a hunch that some of my installed agent skills were costing me extra tokens and not adding enough value when I read a Reddit thread about "are you guys still using the superpowers skill?" Superpowers nudges coding agents to adopt a pragmatic workflow that includes brainstorming, specs, plans, tests, and review....Read More
Beta 4 release of Drupal AI Context Beta 4 of Drupal AI Context , also known as Context Control Center (CCC), is now available. CCC helps Drupal sites provide governed, reusable context for AI workflows and agents, from brand voice and editorial standards to organisational knowledge and governance rules. This gives AI systems access to more structured and relevant information while allowing teams to manage that information centrally. Following the beta 3 release , beta 4 has been shaped by extensive community testing and an expanded scope. The community testing revealed refinements for a more intuitive user experience, and several features earmarked for 1.1 have been brought forward into 1.0. The result is a more capable, usable and reliable context management system.
