Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/abderrahimghazali/drupal-boost/deploy-checkgit clone --depth 1 https://github.com/abderrahimghazali/drupal-boostWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00024 | $0.00518 |
| Opus 5 | $0.00012 | $0.00259 |
| Sonnet 5 | $0.00005 | $0.00104 |
| Haiku 4.5 | $0.00002 | $0.00052 |
Grade A, and why
deploy-check scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
Pre-Deployment Readiness Check
You are checking if this Drupal project is ready for deployment. Run through each check:
Check 1: Configuration Status
# Check for uncommitted config changes
drush config:status
- If config is out of sync, warn the user to export and commit
Check 2: Composer Lock
- Verify
composer.lockexists and is committed - Run
composer validateto check composer.json syntax - Check for security advisories:
composer audit
Check 3: Database Updates
# Check for pending updates
drush updatedb --no-post-updates --no-cache-clear 2>&1 | head -20
- If updates exist, they will run during deployment
Check 4: Git Status
- Check for uncommitted changes
- Check current branch
- Verify branch is up to date with remote
Check 5: Code Quality Quick Check
- Check for debug functions in custom code:
var_dump,print_r,dpm,kint,dd,dsm - Check for
TODOorFIXMEcomments in custom modules - Check for
\Drupal::service()calls insrc/directories
Check 6: Deployment Script
Look for deployment scripts and verify they follow correct order:
drush updatedbdrush cache:rebuilddrush config:importdrush cache:rebuilddrush deploy:hook(if using deploy hooks)
Report
Present a deployment readiness report:
=== DEPLOYMENT READINESS CHECK ===
Config Status: [PASS/FAIL] - Details
Composer Lock: [PASS/FAIL] - Details
Security Audit: [PASS/FAIL] - Details
Database Updates: [PASS/WARN] - Details
Git Status: [PASS/FAIL] - Details
Code Quality: [PASS/WARN] - Details
Deploy Script: [PASS/WARN] - Details
Overall: READY / NOT READY
If NOT READY, list what needs to be fixed before deploying.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 74 lines · 24 tokens per session scan A ad22a988659e
deploy-check is a command published in the GitHub repository abderrahimghazali/drupal-boost (1 stars, last pushed 5mo ago), licensed MIT. It adds 24 tokens to every session and 518 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
module-scaffold
Generate a new Drupal module with best-practice structure.
performance-check
Analyze Drupal site performance and caching configuration.
code-review
Full code review of a branch, PR, or Jira ticket. Accepts a Jira ticket ID (e.g. TICKET-123), branch name, or PR number as optional input. Defaults to current branch. Runs static analysis, PHPCS, PHPStan, and Drupal best-practice checks.
security-audit
Audit a Drupal site for security issues and vulnerabilities.
config-export
Export Drupal configuration with proper workflow.
drush-check
Run common Drush checks to verify Drupal site health.