| name | contribution-issue |
| description | Works the Drupal issue lifecycle — reviews prior work on an issue first, then creates / comments on / claims it, and checks out the issue fork + branch with three-way fork handling. Use when the user runs /drupal-ai-contrib:issue or asks to find, create, claim, or check out a Drupal issue or issue fork. Wraps drupalorg-cli for no-auth reads; delegates authenticated GitLab fork/push to the drupal-gitlab skill. |
| version | 0.1.1 |
| model | inherit |
| user-invocable | false |
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:
| State | Action |
|---|
| Your existing fork | Check out your fork's issue branch and continue. |
| Someone else's fork/branch | Surface it. Do not clobber. Coordinate via an issue comment before proceeding — their work may be ahead of yours. |
| No fork yet | Provision the fork first via /do:fork (issue comment) or the Drupal.org management page — a fork is never created by pushing or via the API (a push to a non-existent fork 404s). Then add the remote and branch. |
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:
- Review comments, status, MRs — find an existing issue fork by another contributor.
- 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:
- Review confirms no prior MR or fork.
- 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
| Situation | Handling |
|---|
| Issue ID is non-numeric / malformed | Reject before calling drupalorg; ask for a valid ID. |
drupalorg not installed | Surface the install steps from references/drupalorg-cli.md; do not fabricate fork state. |
| User asks to "create an issue" | There is no issue:create — draft the issue and guide the contributor to file it in the web UI (Drupal.org queue or GitLab); resume with the new issue ID. |
git push to the issue fork is rejected | The drupal.org SSH key is likely missing or unregistered — point at setup §5 and references/drupalorg-cli.md §Authentication; do not fabricate push state. |
| Project uses GitLab, not the classic queue | Use the state::* scoped-label taxonomy per the issue-lifecycle dev-guide. |
| Prior work fully resolves the issue | Surface it — the contribution may be unnecessary; let the contributor decide. |
