## Problem/Motivation The GitLab work-item migration left this project maintaining its own account of how drupal.org contribution now works — how forks are provisioned, how issue metadata maps to scoped labels, which `drupalorg` CLI commands still resolve correctly. That account was assembled by trial and error, and several of its findings are workarounds for defects rather than practice worth preserving: `issue:setup-remote` resolving nid 3615648 to an unrelated project (`sdx`), `issue:show` returning empty fields and exit 0 for a bare nid, `mr:list` returning another project's merge requests, `issue:get-fork` producing a malformed remote name. [`drupal/ai_best_practices`](https://git.drupalcode.org/project/ai_best_practices) ships a maintained `drupal-gitlab` Agent Skill covering the same ground: issue-fork workflow, work items and `/do:` commands, labels, merge requests, CI debugging, commit messages, and a drupal.org → GitLab terminology mapping. It is active (60 stars, commits within the last day). **Its tooling premise differs from ours in a way worth noticing:** the skill is built on the GitLab CLI (`glab`) and API, not the `drupalorg` CLI. Most of what this project has been working around is in commands the wider ecosystem appears to be routing past. If that read is right, adopting the skill retires a maintenance burden rather than adding a dependency. ## Proposed resolution Evaluate it properly before adopting or declining — not from the README. 1. `composer require --dev drupal/ai_best_practices` in a **throwaway worktree**, never on `1.0.x`. 2. Run `composer drupal-ai skills-sync` and read `skills/drupal-gitlab/SKILL.md` and every file under `references/` in full. 3. Diff its claims against the workarounds recorded in this project, and against what the CLI actually does today. Where it disagrees, test rather than assume — on both sides. 4. Decide per area: delegate to the skill, keep local, or keep local *and* contribute the finding upstream. ### What it plausibly replaces Migration mechanics, fork provisioning, label/`/do:` handling, MR and CI workflow, terminology translation. ### What it cannot replace Its stated scope is "universal guidance that applies across Drupal projects… **not project-specific configuration**." So the maintainer-local layer stays local regardless: the container/worktree layout and `.shared/` scripts, `campaign-<nid>` remote and ddev project naming, `<nid>-<short-desc>` branch slugs, the `1.0.x` `.ai/**`-only pre-commit guardrail, and the kenkeep / strikethroo wiring. ## Open questions These are the reasons this is an evaluation and not a `composer require`. - **Commit format conflict.** The skill specifies `{type}: #{issue-id} Short summary` with `By: drupal-username` attribution lines. This project uses `feat(campaign): …` with no issue ID, on the documented grounds that credit comes from the issue rather than the commit message. These are incompatible, and existing history follows ours. Adopt, decline, or adopt going forward? - **Credit mechanism — the two sources disagree.** `CLAUDE.md` states, and the maintainer has confirmed, that credit comes from the issue's credit checkboxes. The skill's `references/migration.md` instead describes a *contribution record URL* posted automatically by GitLab in a comment when the work item is created, to be filled in at `new.drupal.org/contribution-record?source_link=…`. Both may exist, or one may be newer. Worth settling directly, since `CLAUDE.md` asserts it. - **`AGENTS.md` collision.** The Composer plugin writes a managed region into the root `AGENTS.md` between `<!-- ai-best-practices:start -->` / `end` markers, and creates `CLAUDE.md` / `GEMINI.md` when missing. This project's `AGENTS.md` already carries kenkeep's own marker-delimited managed block. Two marker-based managers should coexist, but that needs verifying on a disposable checkout before it touches a real one. `AI_BEST_PRACTICES_SKIP_PACKAGE_SYNC=1` suppresses the deferred write during testing. - **No releases.** The repository has no tags; installation is `@dev` against `1.0.x`. Decide whether to depend on a moving target, pin a commit, or wait for a tagged release. - **Scope of adoption.** Skills are agent-facing guidance, and this is a `require-dev` addition to a contrib module. Confirm it earns a place in `composer.json` rather than living in the maintainer's local setup. ## Remaining tasks - Run the evaluation above in a throwaway worktree. - Answer each open question, recording the decisions. - If adopting: wire it in, and delete whatever local guidance it supersedes so the two cannot drift. - If declining: record why, so this is not re-litigated. - Either way, consider contributing the CLI defects found here upstream — they are ecosystem-wide, not specific to this project. - Relates to #3615649: the AI-generated disclosure convention has **no** counterpart in `ai_best_practices` (searched — no matches). If that convention tracks a drupal.org-wide policy rather than a local preference, upstream may be the better home for it. ## User interface changes None — tooling and documentation only. ## API changes None to the module's public API. Possible `composer.json` `require-dev` addition. AI-Generated: Yes (Used Claude Code Opus 5 and/or Fable 5 to generate the text of this issue.)