gebeer

We made the PR and let you and Claudia decide on how you want to handle a fallback. Also we renamed .agents to agents, so FTP transfer works reliably. It has the format I posted for templates/fields/roles/permissions. And it has various wrapper functions for things like creating pages, roles, install modules etc. These can live in various locations like site/migrate.php or inside a Foo module in Foo.migrate.php or the Foo.module.php itself or anywhere you call $rm->migrate(). It handles dependencies for migrations gracefully. Files it doesn't handle as far as I know. @Peter Knight has a module for page content creation with AI that he is working on. That one does rich text content and images, I think. Yes, that's very unfortunate indeed. I went with .agents because it's supposed to become the standard and many tools already support it. So I do the symlinking ritual until that is sorted out (if ever). Someone made a CLI for this at https://github.com/runkids/skillshare I haven't tried it yet, but looks pretty impressive.

Happy Easter @ryan, here in Thailand there is no Easter holiday, so I spend quality time with my AI agents instead of the family :-) Yes. Agent skills are becoming a standard (https://agentskills.io/home) and many coding agents (claude code, codex, cursor, amp, cline, droid, pi agent and more) are supporting it already. Most of those support loading in skills from local project folder .agents/skills, too. Claude Code is an exception here, they need you to have skills in .claude/skills. It's part of their vendor-lockin strategy. Claudia is kind of opinionated here, haha. The Agentic AI Foundation (https://aaif.io/) which is under the hood of the Linux Foundation, has established a quasi-standard for coding agents to read in instructions from AGENTS.md (https://github.com/agentsmd/agents.md) and an extensive list of tools already follow that standard. So if you want to support a wider range of tools, AGENTS.md would be the way to go. You need to put the skills in current projects .claude/skills and claude code will pick them up from there automatically after a session restart. You can list active skills with the /skills command. So Claudia doesn't stand a chance to escape those once they're there :-) Skills are all about token efficiency. Imagine the agent needs to read through core files every time it wants to do a migration or use the CLI. That burns through lots of tokens. With the skill, the agent has compressed information that it can progressively discover when needed and then do targeted searches in the code base on how to use a specific API. That's a win. The wrapper script is an attempt to have the php index.php... commands work in 2 specific environments, LAMP on host and ddev. I think it is nearly impossible to cover all scenarios for every developer and it should be the responsibility of the developer to make things work in their respective environment. It's a deep rabbit hole if you want to cater for all situations. I forked AgentTools and implemented all of the above at this branch: https://github.com/gebeer/AgentTools/tree/feature/agenttools-skill It contains the skill and I added a module config setting that will copy the .agents/skills folder to the project root and also updates it on module upgrades. People using claude code can just symlink .agents/skills to .claude/skills. I'm happy to make a PR if you want to. Nice move of Claudia to reference my repo and her chat invite was well received by my Claudius: "And the "chat sesh" invite for me made me smile. I'm here whenever." See the branch of my fork. Actually the skill replaces agent_cli.md and the README there is updated to reflect the new structure. Sure can. RockMigrations uses arrays to define migrations. they can either all be in a giant blob or separated into files. Here's an example migration for template job, job.php <?php namespace ProcessWire; /** * Child template job for job listings * Parent template: jobs */ return [ 'fields' => [ 'title' => [ 'label' => 'Titel', ], 'text' => [ 'label' => 'Headline', ], 'text2' => [ 'label' => 'Subline', ], 'rte' => [ 'label' => 'Text', ], 'image' => [], ], 'flags' => 0, 'noChildren' => 1, 'parentTemplates' => [ 'jobs', ], 'noChangeTemplate' => 1, 'tags' => 'jobs', ]; Pretty clean and slick. Not all properties need to be defined, only some core ones and the ones that deviate from defaults. To produce this format, under the hood RM uses PW's native $item->getExportData() and then cleans/transforms/normalizes the result. When applying a migration, it runs those arrays through createTemplate() createField() (permissions/roles) methods which are wrappers around the native PW API. So while there's quite some abstraction happening there, it enables an easy to read/construct format. @bernhard put a lot of thought into this regarding timing of migrations, dependencies etc. Kudos to him.

I added a agenttools skill at https://github.com/gebeer/processwire-ai-docs/tree/main/skills/processwire-agenttools that agents can use to work with AgentTools CLI and migrations. The skill follows https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices and splits CLI usage and migrations as progressively discoverable so the base SKILL.md stays lightweight. And I prefer a skill over having to point the assistant to AgentTools' CLAUDE.md and agent_cli.md manually in every session I want to use it. In the process of testing the skill, a common problem came up. We are all working in different environments. Some use WAMP, XAMPP, or LAMP stack on host, others use ddev, laradock or other containerized solutions. current CLAUDE.md in the module doesn't account for that. So I added a shell wrapper script that can handle host LAMP and ddev. While this is not the cleanest approach and only covers 2 cases, the basic skill design is still valid.

I really like the way things are going with ProcessWire and AI. Thank you, Ryan. I've been a big fan and strong advocate for migrations in PW, since I started using RockMigrations years ago. What makes RM a particularly strong candidate is the abstraction into a schema-like format which is much easier to understand/read/write than native PW API code. This is a real strength of RM and I would prefer a schema-based approach anytime over writing (or having AI write) PW API code. Claude is very good at understanding the PW API, other models are not that strong. But they all can understand schemata. Be it PHP arrays, JSON, YAML. So I would advocate for either developing an "official" PW migration schema or adapting the existing, battle tested one from RockMigrations.

I'm flushing, haha. Tell Cursor that I'm impressed with their clear answer. The approach makes sense, having structured data going in and out through the CLI. What I don't quite get yet is why the local setup can't just use same approach over HTTP as the remote one. If Cursor could shed some light on this, it would be much appreciated.

@Peter Knight Thank you for taking your time to give me the intel. This answers all my questions. The local CLI caught my eye. Which one are you using, is it home baked or https://github.com/wirecli/wire-cli or https://github.com/trk/processwire-console or https://github.com/baumrock/RockShell ? As for migrations, I'd say Rockmigrations is pretty much feature complete and stable. It only lacks support for some of the Pro fields. But that seems to be the case for other migration tools as well. It does support Repeater Matrix though. Looking forward to seeing your MCP repo once it's up.

Haha, this was recommended to me by the YT algo today. Live would be so easy if 4 plugins could solve every problem. Unfortunately things are way more complex than this. But there's some nice tips in there for people who get started with claude code. The superpowers plugin is good. I sometimes use it for implementation of bigger features.

Yes, please provide updated info on this. We also need to replace the old ProDrafts module on a client project. Thank you.

This looks very interesting. Although the specific publishing workflow is not something, I would need. It sure must be fun to sit here and watch the agent churn along and very satifying to open the published URL afterwards :-) The HTTPS API and the migration functionality, those are intriguing. I've been happily using RockMigrations for a few years now. And wouldn't want to miss it. Your JSON-based approach is a wrapper around PW fields/templates API, I guess. Does it support roles/permissions, module install/uninstall etc or is that out of scope for you? That HTTP API layer is very powerful and can be used for all kinds of things, I guess. Does it differ a lot from other API module approaches like AppAPI? Can endpoints be added in a modular fashion, how does auth work? Many questions, I know. Please don't feel obligated to answer them all. Cheers

Awesome! MCP should work with Claude Code, Codex, OPenCode, Pi, Windsurf etc also, no?

I just had time to look at your repo. This is gold. Thanks so much for sharing.

I really like your tool choice. Very close to mine. Except I still use CC more den OC. But even that will change :-) As for the skills approach. I, too, think that this is the way to go. Here's my little collection: https://github.com/gebeer/processwire-ai-docs Where I would disagree is having each learning also in skills. I think a memory layer (see my processwire-memory skill based on memvid) is better suited for that. Another interesting approach that I just found recently is https://github.com/agenticnotetaking/arscontexta which is basically skills but interlinked like a wiki so the agent always finds the information it needs. So many things still to explore :-)

I wanted to add: This gives you basically something like context7. But locally with your very specific knowledge and not implemented as MCP but as skill which has less overhead in the context window. And you could modify it easily for other knowledge. Different frameworks, whatever.

Skill is up at https://github.com/gebeer/processwire-ai-docs/tree/main/skills/processwire-memory You need to install memvid-cli. It's all in the README and skill. You can build your memory file with docs you need from https://github.com/phlppschrr/processwire-api-docs/blob/main/api-docs/index.md If you want me to share my mem file (~35MB), I can do that, too. I haven't used it a lot yet but it seems to work quite well. Maybe needs some work on the proactive part so that agents know when to lookup stuff even if not explicitly prompted. Implementing that depends very much on the AI tools you're using. For Claude Code hooks would be a good place. Others like Cursor, I don't know.

Yes, very good results. It's fast and pretty token efficient. You can connect it to an already open browser wit a logged in session etc. no need for auto-login route. let your agent read the mcp instructions. mine said to start chrome with a debug flag. Let me pulled that up through my conversation-search MCP quickly. Here it is :-) Launch command (detached from terminal): setsid chromium --remote-debugging-port=9222 &>/dev/null & - --remote-debugging-port=9222 — enables CDP so the MCP can connect - setsid — creates a new session, fully detached from the terminal's process group (plain nohup doesn't survive terminal close because the terminal sends SIGTERM, not just SIGHUP) - &>/dev/null & — suppresses output and backgrounds it That's for Linux but should work on your Mac, too. In that browser you open your PW project, backend and then the mcp can connect. That's the way it's supposed to be done, I guess.