drupal-critic
A Drupal-specific harsh-review orchestrator for Claude Code. Coordinates 24 external specialist skills to deliver evidence-backed critique of Drupal plans, code, and operational workflows.
Overview
drupal-critic runs a structured, multi-phase review against any Drupal artifact: module code, deployment plans, config workflows, contrib patch decisions, cache strategies, migration scripts, or Composer/Drush/DDEV operations.
It ships as both a Claude Code skill (invoked via /drupal-critic) and a read-only agent (Opus model, no Write/Edit tools). The skill orchestrates up to 3 external specialist skills per review, selected by context from a catalog of 24 community-maintained Drupal skills.
Three audience perspectives always run (Security, New-hire, Ops). Three more activate when the review context demands them. Every CRITICAL and MAJOR finding must include concrete evidence — file:line references or artifact quotes. Anything speculative gets moved to Open Questions.
Review Workflow
Confirm Scope
Identify the review target: module code, deployment plan, config change, migration, etc. Narrow by component/feature/path if too broad.
Pre-commitment Predictions
Make 3–5 predictions about likely failure points before the deep review begins. Anchors the investigation against confirmation bias.
Protocol Phases
Run verification, multi-perspective analysis, explicit gap analysis, and synthesis — in order.
Plan-Specific Checks
For plans/specs only: key assumptions extraction, pre-mortem, dependency audit, ambiguity scan, feasibility check, rollback analysis, devil's-advocate challenge.
Self-Audit
Move LOW-confidence or easily-refutable claims to Open Questions. Downgrade or remove preference/style-only points from scored sections.
Realist Check
Every surviving CRITICAL/MAJOR finding gets reality-tested with 4 questions. Severity can be downgraded — except for data loss, security breach, or financial impact. Every downgrade requires a "Mitigated by:" statement.
Apply Drupal Rubric
Score against 9 dimensions: security, architecture, contrib lens, site builder lens, editor lens, ops safety, caching, testing, review confidence.
Activate Audience Perspectives
3 always-on (Security, New-hire, Ops) + up to 3 context-driven (Open Source Contributor, Site Builder, Content Editor/Marketer).
Load External Skills
Select max 2–3 specialist skills from the 24-skill catalog via routing map. Default: one core review skill + one specialist skill.
Structured Verdict
Return the complete output contract: VERDICT, findings, perspective notes, justification, and open questions.
External Skills Catalog — 24 Skills
Core Review
Always Eligible
Highest Priority
Open Source / Issue Queue
Context-Driven
Cache & Rendering
Context-Driven
Canvas / Components
Context-Driven
Tooling & Environment
Context-Driven
Routing Rules
2–3
Max Skills Per Run
Never loads more than 3 external skills in a single review. Keeps focus tight and avoids conflicting guidance.
1+1
Default Pattern
One core review skill (priority 70–100) plus one specialist skill matched to the review context.
P100
Priority Wins
When two skills overlap, the higher-priority active entry in the manifest wins. Avoids loading overlapping core skills unless scope is broad.
Audience Perspectives
Always On
Security
Routes, permissions, entity queries, token checks, render safety, SQL injection vectors.
Always On
New-hire
Can a new developer understand this code? Are conventions followed? Is the intent clear?
Always On
Ops
Deployment safety, rollback paths, logging, failure handling, blast radius, monitoring hooks.
Context-Driven
Open Source Contributor
Activates when contrib/core behavior is overridden, a bugfix targets third-party code, or change introduces patch maintenance burden.
Context-Driven
Site Builder
Activates when changes touch content types, views, display modes, workflows, moderation, permissions, menus, media, or admin config.
Context-Driven
Content Editor / Marketer
Activates when changes affect editorial workflow, content authoring UX, content model, metadata/SEO, campaign pages, or publishing cadence.
9-Dimension Review Rubric
01
Security
Route permissions, accessCheck(TRUE), input validation, safe rendering, SQL via query builder
02
Architecture & Drupal Fit
Contrib-first, DI patterns, hooks vs subscribers vs plugins, config schema conventions
03
Open Source Contributor
Upstream patch viability, issue queue research, contribution path, patch maintenance burden
04
Site Builder (Admin UI)
Config UX, permissions/workflows practical, no hidden coupling, drush/config sync alignment
05
Content Editor / Marketer
Editorial workflow clarity, content model, metadata/SEO fields, editorial friction minimized
06
Operational Safety
Rollback path, Composer constraint safety, Drush DB/config/cache ordering, actionable error logs
07
Caching & Performance
Tags/contexts/max-age correct, no broad cache busting, BigPipe/lazy builders used correctly
08
Testing & Verification
Proportional test strategy, risky paths validated, acceptance includes critical user journeys
09
Review Confidence
High-confidence findings have evidence, medium/low concerns labeled and moved to open questions
Output Contract
Every drupal-critic review returns this exact structure. No section is omitted — empty sections say "None."
VERDICT
→
Overall Assessment
→
Pre-commitment Predictions
→
Critical Findings
→
Major Findings
→
Minor Findings
→
What's Missing
→
Ambiguity Risks
→
Multi-Perspective Notes
→
Verdict Justification
→
Open Questions (unscored)
Verdict options: REJECT · REVISE · ACCEPT-WITH-RESERVATIONS · ACCEPT. Dashed sections are conditional (Ambiguity Risks = plan reviews only; Open Questions = speculative/low-confidence items).
Severity Calibration + Realist Check
Critical
Exploit, security bypass, data loss, or deploy-blocking flaw. Cannot ship.
Major
Likely regression or significant rework required before safe deployment.
Minor
Non-blocking correctness or maintainability issue. Style-only points excluded.
The Realist Check
Every surviving CRITICAL and MAJOR finding must answer four questions. This prevents severity inflation from investigation momentum.
Q1
"If we shipped this as-is today, what is the realistic worst-case outcome?" Not theoretical — the likely worst case given actual usage, traffic, and environment.
Q2
"Is there a mitigating factor that limits the blast radius?" Feature flag, low traffic path, existing monitoring, downstream validation, limited user exposure.
Q3
"How quickly could this be detected and fixed in production?" Minutes (monitoring) vs days (silent corruption) vs never (subtle logic error).
Q4
"Is the severity proportional to actual risk, or was it inflated by investigation momentum?"
Downgrade rules: Minor inconvenience + easy rollback = CRITICAL→MAJOR. Mitigating factors contain blast radius = downgrade one level. Fast detection + straightforward fix = keep but note context. Survives all four = correctly rated. Never downgrade data loss, security breach, or financial impact. Every downgrade must include a
Mitigated by: ... statement.
No-Copy Policy
drupal-critic
manifest.yaml
manifest.yaml
⟶
External Skill
ID + pinned SHA
ID + pinned SHA
External skills are referenced, never copied. The manifest stores each skill's
id, skills_url, repo_url, and a pinned_commit (40-char SHA). CI validates that no upstream SKILL.md content has been copied into this repo. If a referenced skill is unavailable at runtime, drupal-critic falls back to its local rubric and states the limitation.