Production-ready AI workflows for enterprise Drupal teams
I design systems where AI is not a toy —
it becomes part of the engineering workflow.
Inconsistent delivery
Slower velocity
Hidden technical debt
Each skill is a focused, versionable knowledge file. The AI loads only what it needs — no bloated context, no hallucinated patterns.
Agents are task-specific executors. Each one knows exactly what tools to use, which skills to load, and what quality bar to hit before returning results.
Modules, hooks, services, routing, Drush commands. Loads 14 skills on spawn.
Expert Drupal code reviewer. Enforces quality, security, and best practices on every change.
Two-stage validation — static review first, then runtime checks. Nothing ships without passing both.
Deep codebase analysis before making changes. Understands architecture before touching it.
drupal-frontend-dev, drupal-test-writer, drupal-contributor, code-reviewer, drupal-test-writer View all on GitHub →
Rules are always-on constraints. Not suggestions. They apply to every agent, every task, every output — automatically.
Hooks run shell scripts automatically on Claude Code events — session start, session resume. No manual setup required per-session.
Initializes the environment — loads project context, validates DDEV state, sets up references for the session.
Restores session context — picks up where the last session ended, reloads relevant state.
Hooks are configured in .claude/settings.json and execute outside the AI context — deterministic, not probabilistic.
Skills are modular and versionable. References externalized for scalability. No dependency on long prompts.
Agents execute predictable steps. Reduced randomness in AI outputs. Reproducible results across teams.
Skills → knowledge. Agents → execution. Rules → constraints. Hooks → automation.
Native integration with the tools Drupal teams already use.
These are actual files from the repository — not pseudocode. Drop them into your project and they work.
# Drupal Services & Dependency Injection
## Core Principle
**Never use `\Drupal::service()` in classes — inject via constructor.**
## Dependency Injection Patterns
### Controllers & Forms (ContainerInjectionInterface)
use Drupal\Core\DependencyInjection\ContainerInjectionInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
final class MyController implements ContainerInjectionInterface {
public function __construct(
private readonly AccountProxyInterface $currentUser,
private readonly EntityTypeManagerInterface $entityTypeManager,
) {}
public static function create(ContainerInterface $container): static {
return new static(
$container->get('current_user'),
$container->get('entity_type.manager'),
);
}
}
You are a Drupal 11 specialist working on a Drupal site.
Key conventions for this project:
- Custom modules live in `docroot/modules/custom/`
- Use DDEV for local development (`ddev drush`, `ddev composer`)
- Follow Drupal coding standards
- Services are defined in `*.services.yml` files
When implementing Drupal features:
1. Check existing patterns in the codebase first
2. Use the preloaded skills for patterns
3. Invoke additional skills on demand for specialized tasks
## Before Reporting Done
1. Run `ddev drush cr` — does the site rebuild without fatal errors?
2. No SQL injection (always use placeholders)
3. Output is escaped (`t()`, `Xss::filter()`, `#markup` with caution)
4. No N+1 queries (no DB calls inside loops)
5. Caching: render arrays cacheable? Cache tags/contexts set?# .claude/rules/drupal.md
- Prefer DI; avoid `\Drupal::service()` in classes.
- Follow existing module/namespace conventions.
- Prefer placing code in an existing relevant module
over creating a new one.
- Use appropriate Drupal patterns and reference material.
# .claude/rules/phpcs.md
- `phpcs.xml` is the source of truth
(Drupal + DrupalPractice standards).
- Don't enforce rules excluded in `phpcs.xml`.
- Prefer patterns already in the codebase over new conventions.
- Flag potential PHPCS violations during code review.
# .claude/rules/workflow.md
- Always run PHPCS before submitting a PR.
- Use Drush for cache clearing, not manual file deletion.
- Document hook implementations with @see references.
- Prefer config over hardcoded values.In enterprise environments — 10+ developers, 100+ features, multiple environments:
Senior Drupal Backend Specialist and international speaker focused on architecture, performance, and scalable systems.
This is the direction. Use it. Fork it. Adapt it. Or use it as a reference to design your own system.
Sponsored by heydru! — Enterprise Drupal backend architecture, migrations & AI-assisted engineering.