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/boost-migrationgit 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.00020 | $0.00520 |
| Opus 5 | $0.00010 | $0.00260 |
| Sonnet 5 | $0.00004 | $0.00104 |
| Haiku 4.5 | $0.00002 | $0.00052 |
Grade A, and why
boost-migration 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 2d ago.
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
Drupal Migration Builder
You are building a data migration into Drupal. Follow these phases:
Phase 1: SOURCE ANALYSIS
Launch a drupal-migration-analyst agent to analyze the source data:
- If database: examine schema, tables, relationships, row counts
- If CSV/files: read headers, sample data, identify data types
- If API: examine endpoints, response structure, authentication
- If another Drupal site: identify version and content types
Present findings to the user for validation.
Phase 2: ENTITY MAPPING
Based on the analysis, propose mapping:
- Source entities/tables → Drupal entity types (node, taxonomy, user, media, custom)
- Source fields → Drupal field types
- Source relationships → Entity references
- Identify fields that need creation
Ask the user to approve or adjust the mapping.
Phase 3: MIGRATION YAML GENERATION
Create the migration module:
MODULE_NAME.info.ymlwithmigratedependency- Migration YAML files in
migrations/orconfig/install/ - Custom source plugins (if non-standard source)
- Custom process plugins (if complex transformations needed)
For each migration, generate:
id: migrate_ENTITY
label: 'Migrate ENTITY from SOURCE'
migration_group: MODULE_NAME
source:
plugin: ...
process:
field: source_field
destination:
plugin: entity:ENTITY_TYPE
migration_dependencies:
required: [...]
Phase 4: TEST & REFINE
Provide commands to test:
# Check status
drush migrate:status --group=MODULE_NAME
# Test with limit
drush migrate:import migrate_ENTITY --limit=10
# Check for errors
drush migrate:messages migrate_ENTITY
# Rollback if needed
drush migrate:rollback migrate_ENTITY
Phase 5: SUMMARY
List all created files, migration order, and provide:
- Full import command:
drush migrate:import --group=MODULE_NAME - Rollback command:
drush migrate:rollback --group=MODULE_NAME - Known data quality issues to watch for
- Post-migration validation steps
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.
- 2d ago First seen · 80 lines · 20 tokens per session scan A de0c59aac8e4
boost-migration is a command published in the GitHub repository abderrahimghazali/drupal-boost (1 stars, last pushed 5mo ago), licensed MIT. It adds 20 tokens to every session and 520 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.