Aji nswlk
Wch yla glti rk kt9lb/bi ala chi date w ktbtoha b anglais z3ma rah chno .
W vhi wahdin ghi mt3dyin ala englais
W ghir bdarija b3da .
Wch yla glti rk kt9lb/bi ala chi date w ktbtoha b anglais z3ma rah chno .
W vhi wahdin ghi mt3dyin ala englais
W ghir bdarija b3da .
Hey. I'm Mustapha, one of the people behind AY Automate. We're an AI automation company — we build custom AI solutions, workflow automations, AI agents, and help businesses scale without growing headcount. We operate across Belgium, New York, Amsterdam, Paris, Casablanca, and Riyadh.
I started this community because most AI automation content online falls into two buckets: vendor marketing that sounds impressive but says nothing, or deeply technical content that only makes sense if you're already an expert. There's not much in between for people who are actually trying to implement this stuff.
So here's what I want this place to be. A spot where people share what's working, what's not, and what they're building. We'll be posting breakdowns from our blog and client work — real workflows, real numbers, real tools. Not theory.
Some of the topics you'll see here:
This isn't a support forum for AY Automate specifically. If you're building automations, deploying AI agents, or trying to figure out which tools are worth your time, this is for you whether you're a client or not.
A few resources to start with:
Post whatever's on your mind. A question, something you built, a tool you found, a problem you're stuck on. The more people contribute the more useful this gets.
Looking forward to seeing what everyone's working on.
Most Claude Code setups are built for one person. You have your CLAUDE.md, your skills, your hooks, and it works great until a second developer joins and none of that context transfers.
We've been running Claude Code across a small team for a while now and the stuff that actually made it work wasn't technical. It was organizational.
The biggest win was putting CLAUDE.md at the project level and version controlling it. Every developer who opens the project gets the same context, the same rules, the same guardrails. Before that, everyone had their own personal setup and Claude would behave differently depending on who was prompting it. Debugging the same codebase with inconsistent AI behavior is maddening.
Second thing: shared skills in .claude/skills/. We built a few internal ones (SEO auditing, browser automation, diagram generation) and now any dev on the team can use them without setup. Drop the folder in, Claude picks it up.
Third: hooks in .claude/settings.json at the project root. Pre-commit linting, security scanning, file protection. These run deterministically regardless of what anyone types. That matters more than prompting rules because Claude can ignore prompt instructions but it can't ignore a hook that returns exit code 2.
The CI/CD piece (claude-code-action for GitHub) came last but tied everything together. Claude reviews PRs, runs on issues tagged @claude, and posts findings directly.
We wrote up the full playbook: https://www.ayautomate.com/blog/claude-code-for-teams
How are other teams handling this? Especially curious about the CLAUDE.md situation. One file per project? Per repo? Something else?