Contribution Issue

Contribution Issue (worker skill)

Works the Drupal issue lifecycle so the contribution is meaningful, not duplicate.

Backs /drupal-ai-contrib:issue. Load the knowledge layer via dev-guides-navigator: drupal/contributing/drupal-issue-lifecycle, drupal/contributing/issue-forks-merge-requests, drupal/contributing/contribution-etiquette-rtbc-credit, drupal/contributing-with-ai/issue-creation.

Procedure

1. Review prior work FIRST — before anything else

For an existing issue, review what has already happened:

• Read existing comments, the issue status, and any open merge requests.
• Determine whether the contribution would duplicate work in progress.
• If someone is actively on it, surface that — coordinate, do not compete.

A contribution that re-does existing work wastes maintainer review time. This review is mandatory; it is not optional context-gathering.

2. Detect the issue system

drupal.org classic queue vs. GitLab — detect by following the project's Issues link. The status taxonomy differs (classic statuses vs. GitLab state::* scoped labels); handle dual-mode per the issue-lifecycle dev-guide.

3. Act — create, comment, or claim

• Create an issue — drupalorg-cli has no issue:create command. A new issue is filed through the web UI: the project's Drupal.org issue queue, or its GitLab issues page if the project has migrated. Draft the issue for the contributor — title, summary, steps to reproduce, proposed resolution, the component, and the affected version — then guide them to file it in the web UI and resume with the new issue ID. Cite drupal/contributing-with-ai/issue-creation. Do not attempt a CLI creation command.
• Comment on an issue — shape: thank → what works → feedback → next step.
• Claim an issue — set the appropriate status; then proceed to fork checkout (§4).

4. Fork checkout — three-way handling

When claiming an issue, handle the issue-fork state in three ways — never clobber existing work:

On a migrated (GitLab) project, delegate fork provisioning, remote setup, and push to the drupal-gitlab skill (its references/merge-requests.md) — it owns the /do:fork / /do:access flow and the two-host rule: SSH push → git.drupal.org; HTTPS / glab → git.drupalcode.org (the CDN has no SSH listener). On a legacy-queue project glab cannot see the issue — use drupalorg / the web UI. Branch naming must include the issue number (per the issue-forks dev-guide). Target the most recent development branch (main for core; per-project for contrib).

5. Reads via drupalorg-cli; authenticated writes via drupal-gitlab

Prior-work review and issue/MR reads (issue:show, issue:search, mr:list) use mglaman/drupalorg-cli — the executable on PATH is drupalorg (not drupalorg-cli, which is only the package name); detect it with command -v drupalorg. These are no-auth public reads and work on both the legacy queue and migrated projects. Authenticated GitLab writes — fork provisioning, branch setup, and push — are delegated to the drupal-gitlab skill (§4). See ${CLAUDE_PLUGIN_ROOT}/skills/drupal-ai-contrib/references/drupalorg-cli.md for the tool, install, authentication, and the hybrid split (its §Hybrid model). Confirm exact subcommand names with drupalorg list — names can drift between releases; do not assume.

Pushing needs credentials. Reviewing and reading an issue work over public APIs, but creating the issue-fork branch and git pushing it need an SSH key registered on the contributor's drupal.org account (issue-fork remotes are SSH URLs). If a push is rejected, that missing/unregistered key is the first thing to check — surface it and point at setup §5 and the reference's Authentication section; never fabricate fork or push state.

Use fixed subcommands — never build a subcommand name from user input. Before passing any identifier, validate it: issue IDs must match ^[0-9]+$, project machine-names must match ^[a-z][a-z0-9_]*$ — and reject anything that does not match rather than shelling out with it. Never interpolate unsanitized input into a shell command. Credentials are the contributor's own — never store or transmit them.

6. Report

Summarize: the issue, its system + status, the prior-work finding, the fork/branch state and what was done. Point the contributor at the development phase, then verify.

Examples

Example 1: claiming an issue someone else already forked

Trigger: /drupal-ai-contrib:issue 3456789 Actions:

1. Review comments, status, MRs — find an existing issue fork by another contributor.
2. Surface it; do not create a competing branch. Suggest a coordinating comment. Result: No clobbered work; the contributor decides whether to build on or wait.

Example 2: a fresh issue, no prior work

Trigger: /drupal-ai-contrib:issue 3456789 Actions:

1. Review confirms no prior MR or fork.
2. Claim the issue; provision the fork with /do:fork, then (via drupal-gitlab) add the fork remote and create the issue-number branch. Result: A clean issue branch checked out, ready for development.

Troubleshooting