Add skills to update Drupal core to minor or major release

[shaundrong]

Add Drupal Core Update Skills

Summary

Adds two new skills for managing Drupal core updates in UCEAP projects:

• /uceap:upgrade-core - Patch and minor version updates
• /uceap:upgrade-core-major - Major version upgrades

These skills codify UCEAP's documented Drupal core update procedures and integrate with the existing UCEAP skill ecosystem.

New Skills

/uceap:upgrade-core (Patch/Minor Updates)

Purpose: Routine security and feature updates within the same major version (e.g., 10.2.7 → 10.3.1)

Key Features:

• 10-step procedure from prerequisites through commit
• Uses UCEAP's standard exact-version-targeting approach
• Follows documented composer commands (4 core packages + dev packages)
• CLI-only workflow (no browser-based checks)
• Optimized for devcontainer environment (no backup step, uses uceap devcontainer-reset-db)
• Updated to current Drupal best practices (composer audit vs deprecated drush pm:security)

User Intent Triggers:

• "upgrade drupal core"
• "update drupal core"
• "drupal security update"
• "update drupal to [version]"

/uceap:upgrade-core-major (Major Version Upgrades)

Purpose: Major version upgrades requiring extensive planning (e.g., Drupal 10.x → 11.x)

Key Features:

• Comprehensive 14-step procedure with team coordination requirements
• Upgrade Status module integration for deprecation scanning
• Custom code audit and remediation workflow
• Extended testing checklist
• 6-week timeline guidance
• Troubleshooting for common major upgrade issues

User Intent Triggers:

• "upgrade drupal major version"
• "upgrade to drupal 11"
• "major version upgrade"
• "drupal 10 to 11"

UCEAP-Specific Customizations

Both skills are tailored to UCEAP's infrastructure and workflow:

1. Exact Version Targeting: Uses UCEAP's documented procedure with specific version numbers (typically from Jira tickets based on security audit reports)

2. Four Core Packages: Includes all four packages per UCEAP documentation:

   drupal/core-recommended
   drupal/core-composer-scaffold
   drupal/core-project-message
   drupal/core-vendor-hardening

3. Devcontainer Optimization:

   • No SQL backup step (uses uceap devcontainer-reset-db)
   • No drush core:requirements checks (local environment false positives)

4. CLI-Only: All checks use drush/composer commands (no /admin/reports URLs)

5. Integration: References existing skills:

   • /uceap:upgrade-drupal-module for contrib modules
   • /uceap:load-db for database operations
   • /uceap:release-notes for release process

Technical Details

Composer Commands

Main packages:

composer require drupal/core-recommended:[VERSION] \
  drupal/core-composer-scaffold:[VERSION] \
  drupal/core-project-message:[VERSION] \
  drupal/core-vendor-hardening:[VERSION] \
  --update-with-all-dependencies

Dev packages:

composer require drupal/core-dev:[VERSION] --dev --update-with-all-dependencies

Updated Commands

• ✅ composer audit (replaced deprecated drush pm:security)
• ✅ composer show drupal/core (for PHP requirements check)
• ✅ composer outdated "drupal/core-*" (scoped to core only)
• ✅ drush watchdog:show (for error checking)

Removed Legacy Methods

• ❌ SQL backups (use devcontainer reset)
• ❌ drush core:requirements (local environment issues)
• ❌ /admin/reports/* URLs (browser-based)
• ❌ /update.php (browser-based)
• ❌ drush pm:security (deprecated)

Skill Routing

Skills automatically route based on version context:

• User: "Upgrade Drupal core to 10.3.1"
  Claude: Invokes /uceap:upgrade-core (minor version)

• User: "Upgrade Drupal core to 11.0.0"
  Claude: Invokes /uceap:upgrade-core-major (major version)

Manual invocation with wrong skill will prompt user to use the correct one via whenToUse guidance.

Documentation Sources

Based on official Drupal.org documentation:

• https://www.drupal.org/docs/updating-drupal/updating-drupal-core-via-composer
• https://www.drupal.org/docs/upgrading-drupal

Customized for UCEAP's documented procedures and infrastructure.

Testing

Recommended Validation

Before deploying to production marketplace:

1. Test patch update scenario:

   User: "Upgrade Drupal core to 10.3.1"
   Expected: Invokes /uceap:upgrade-core, follows 10-step procedure
   

2. Test major update scenario:

   User: "Upgrade to Drupal 11"
   Expected: Invokes /uceap:upgrade-core-major, shows team coordination requirements
   

3. Test version-specific targeting:

   • Verify [VERSION] placeholder is replaced with actual version
   • Verify all four core packages are updated
   • Verify dev packages updated separately

4. Test skill cross-references:

   • Verify references to /uceap:upgrade-drupal-module work
   • Verify uceap devcontainer-reset-db reference is correct

Integration Testing

After deployment:

• Test on a real upgrade scenario (suggest testing on a patch update first)
• Verify commands execute correctly in devcontainer
• Confirm no false positives from removed checks

Files Added

• upgrade-core/SKILL.md - Patch/minor version update skill (~240 lines)
• upgrade-core-major/SKILL.md - Major version upgrade skill (~330 lines)

Breaking Changes

None - these are new skills with no existing implementations to replace.

Follow-Up Items

• Test both skills on a real core update
• Consider adding to main CLAUDE.md skill reference list
• Update team wiki/documentation with skill availability
• Monitor for feedback on first uses
• Consider future enhancement: auto-fetch target version from Jira ticket

Related Issues

• Addresses need for standardized Drupal core update procedure
• Codifies existing team documentation in executable format
• Complements existing /uceap:upgrade-drupal-module skill

---

Ready to merge: ✅ Both skills are complete and follow UCEAP marketplace metadata format

[kurowski]

Looks good!

I wonder if it's worth adding some verbiage to the major upgrade skill stating "this skill has not been tested by UCEAP yet, so please proceed with caution and verify each step with the user before proceeding" or something like that. As well as "please update this skill to remove the warning after successful completion". Or maybe I'm being overly paranoid, at the end of the day we're just opening a PR after all.

In another vein, the timeline described doesn't match with how I typically think of using Claude Code sessions. Perhaps a note telling the bot that this is expected to take multiple sessions with the user, and that the bot should proactively remind the user they should /rename the session so they can easily find it again using --resume when they pick up the process again days/weeks later.

[shaundrong]

Looks good!

I wonder if it's worth adding some verbiage to the major upgrade skill stating "this skill has not been tested by UCEAP yet, so please proceed with caution and verify each step with the user before proceeding" or something like that. As well as "please update this skill to remove the warning after successful completion". Or maybe I'm being overly paranoid, at the end of the day we're just opening a PR after all.

In another vein, the timeline described doesn't match with how I typically think of using Claude Code sessions. Perhaps a note telling the bot that this is expected to take multiple sessions with the user, and that the bot should proactively remind the user they should /rename the session so they can easily find it again using --resume when they pick up the process again days/weeks later.

Those all sound like good enhancements, I was more codifying the Drupal core update process per our Software Engineering Playbook. I've already done a local test of /uceap:update-core in PR: https://github.com/UCEAP/myeap2/pull/3010, which well (san my mistake with basing the branch on my active branch vs qa, requiring a new branch/pr)
I'm not sure we have any specific documentation on doing major Drupal core updates, so we can certainly discuss how we want that to work here before landing this ticket.

[shaundrong]

It might also be worth having @helioha review these skills given all the work he has done on the security updates lately. When we returns on the 24th.