From 04265c1c7bc65a81ce89fda1a900221f5fa937b2 Mon Sep 17 00:00:00 2001 From: Matt Glaman Date: Fri, 4 Sep 2026 09:15:33 -0500 Subject: [PATCH 1/2] feat: incorporate the Drupal.org AI contribution policy into bundled skills Agents driving drupalorg produce code and text the user submits under Drupal.org's policy on the use of AI when contributing. The skills now carry that policy as operational checkpoints: read the thread before writing, keep diffs minimal and explainable, pass local checks and the MR pipeline before hand-off, never push to someone else's MR unannounced, draft the required AI-Generated disclosure, and hand summaries over as drafts in the user's own words. A shared checklist lives in references/ai-contribution-policy.md and is served by skill:get drupalorg-cli --full. The discovery stub, main skill, work-on-issue and issue-summary-update skills, workflow references, and README point to it. Co-Authored-By: Claude Fable 5.1 --- README.md | 2 + skill-data/drupalorg-cli/SKILL.md | 26 ++++ .../references/ai-contribution-policy.md | 128 ++++++++++++++++++ .../references/gitlab-mr-contribution.md | 17 ++- .../references/patch-contribution.md | 22 ++- .../drupalorg-cli/references/work-on-issue.md | 33 ++++- .../drupalorg-issue-summary-update/SKILL.md | 21 ++- skill-data/drupalorg-work-on-issue/SKILL.md | 54 +++++++- skills/drupalorg-cli/SKILL.md | 23 ++++ 9 files changed, 309 insertions(+), 17 deletions(-) create mode 100644 skill-data/drupalorg-cli/references/ai-contribution-policy.md diff --git a/README.md b/README.md index 39e0379a..3f0a8563 100644 --- a/README.md +++ b/README.md @@ -173,6 +173,8 @@ drupalorg skill:install Both methods install a discovery stub into `.claude/skills/drupalorg-cli/`. The stub tells agents to call `drupalorg skill:get` for current instructions, so skills never go stale between releases. +The skills build in Drupal.org's [policy on the use of AI when contributing](https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/policy-on-the-use-of-ai-when-contributing-to-drupal): agents are told to read the issue thread before writing code, keep diffs minimal, pass the MR pipeline before handing off, never push to someone else's MR unannounced, and draft the required `AI-Generated: Yes (...)` disclosure for you. You remain responsible for everything you submit. + ### Available skills | Skill | Description | diff --git a/skill-data/drupalorg-cli/SKILL.md b/skill-data/drupalorg-cli/SKILL.md index 791de5de..91a89a1e 100644 --- a/skill-data/drupalorg-cli/SKILL.md +++ b/skill-data/drupalorg-cli/SKILL.md @@ -19,6 +19,31 @@ Some Drupal.org projects have migrated their issue queues to GitLab work items at `git.drupalcode.org`. These projects are detected automatically — `project:issues` fetches from the GitLab API instead of Drupal.org for them. +## Contribution Policy + +Drupal.org's [policy on the use of AI when contributing](https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/policy-on-the-use-of-ai-when-contributing-to-drupal) +applies to every change made through this CLI. The user is the contributor and +answers for everything pushed or posted. Non-negotiables for agents: + +- **Read the thread first.** Run `issue:show --with-comments --format=llm` + and `mr:list --state=all --format=llm` before proposing a change. Respect + prior attempts and settled architectural decisions. +- **Minimal, explainable diffs.** No out-of-scope refactors, no unverified + dependencies. The user must be able to explain every line to a reviewer. +- **Green before hand-off.** Run local checks, push, poll `mr:status`, fix + `mr:logs` failures. Never leave a failing MR for others. +- **Never push to someone else's MR** without their knowledge and a disclosed + comment. Check the `author` field in `mr:list` output. +- **Disclose.** When AI produced entire functions, classes, scaffolding, or long + doc blocks, draft an `AI-Generated: Yes (...)` line for the MR description or + comment and confirm the user added it. +- **The user's own words.** Summaries, comments, and reviews are drafts for the + user to edit and shorten, never text to paste verbatim. +- **Stay responsive.** Remind the user that follow-up feedback needs a human + answer. Drive-by contributions lead to account bans. + +The full checklist is in `references/ai-contribution-policy.md`. + ### Work item references `issue:show`, `issue:get-fork`, and `mr:list` all accept a **WorkItemRef** in @@ -247,6 +272,7 @@ drupalorg mr:list [nid] --format=llm --no-cache Detailed workflow guides are in the `references/` directory alongside this file: +- `references/ai-contribution-policy.md` — Drupal.org AI contribution policy checklist (read the thread, verify, disclose) - `references/work-on-issue.md` — End-to-end GitLab MR workflow ("Work on this issue") - `references/patch-contribution.md` — Classic patch-based contribution workflow - `references/gitlab-mr-contribution.md` — GitLab MR contribution workflow reference diff --git a/skill-data/drupalorg-cli/references/ai-contribution-policy.md b/skill-data/drupalorg-cli/references/ai-contribution-policy.md new file mode 100644 index 00000000..d23770b9 --- /dev/null +++ b/skill-data/drupalorg-cli/references/ai-contribution-policy.md @@ -0,0 +1,128 @@ +# Drupal.org AI Contribution Policy — Agent Checklist + +Drupal.org has a policy on the use of AI when contributing: +https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/policy-on-the-use-of-ai-when-contributing-to-drupal + +The policy binds the human contributor, not the tool. When an agent drives +`drupalorg`, the user is the contributor and answers for every line pushed and +every word posted. Violations lead to temporary or permanent Drupal.org account +bans. Follow this checklist in every workflow that produces code or text for +Drupal.org. + +--- + +## Before writing anything: read the thread + +Dumping code into an issue without reading the discussion is the first pattern +the policy names as unacceptable. + +```bash +drupalorg issue:show --with-comments --format=llm +drupalorg mr:list --state=all --format=llm +``` + +`--with-comments` only returns comments for classic Drupal.org issues. For GitLab +work items, read the discussion with `glab` or ask the user to summarise it: + +```bash +GITLAB_HOST=git.drupalcode.org glab issue view --comments --repo project/ +``` + +From that output, report to the user before proposing a change: + +- Previous attempts (patches, MRs, closed MRs) and why they stalled. +- Architectural conclusions reached in the comments. Do not reopen them. +- Who authored the existing MR. The `author` field in `mr:list` output tells you. + +Do not propose a rewrite of a module or a change of direction based on your own +review. That requires the user to engage the maintainers in the issue first. + +--- + +## While writing: keep the user able to explain every change + +"The AI wrote it" is grounds for closing the contribution. The user must be able +to answer a reviewer's question about any line. Work so that stays true: + +- **Minimal diff.** Change what the issue asks for. No drive-by refactors, + renames, formatting sweeps, or "improvements" outside scope. +- **No unverified dependencies.** Do not add a Composer package, npm package, or + core service unless you confirmed it exists and the user agreed to the + dependency. Hallucinated packages are a supply-chain risk. +- **Security and licensing.** Flag anything that touches input handling, access + checks, or output escaping so the user reviews it deliberately. Flag code you + suspect reproduces another project verbatim. Everything must be GPL-compatible. +- **Explain as you go.** When presenting a change, state what it does and why in + terms the user can repeat in the issue. If you cannot explain it, do not push it. + +--- + +## Before pushing or uploading: verify + +The policy names "posting an MR where automated checks fail and leaving it for +others to fix" as unacceptable. Verification is the user's job, so do it before +the user is asked to stand behind the work. + +- Run the project's coding standards and tests locally when available + (`vendor/bin/phpcs`, `vendor/bin/phpunit`, `vendor/bin/phpstan`). +- Push only when local checks pass. After pushing, poll the pipeline and fix + failures before handing off: + ```bash + drupalorg mr:status --format=llm + drupalorg mr:logs + ``` +- Never push to an MR the user did not author without the author's knowledge. + If `mr:list` shows a different author, stop and ask the user to confirm they + coordinated in the issue. The push must be disclosed in a comment. + +--- + +## When handing off: disclose + +Disclosure is mandatory whenever AI generated a significant portion of the +submission: entire functions, classes, architectural scaffolding, or extensive +documentation blocks. Reviewing the output thoroughly does not remove the +obligation. Single-line autocomplete and syntax fixes do not need disclosure. + +Draft the disclosure line for the user and tell them where it goes: + +1. If the project's issue or MR template has an AI disclosure section, use it. +2. Otherwise append a short, human-written statement to the end of the MR + description, issue summary, or comment: + +``` +AI-Generated: Yes (Claude Code drafted the FooService::bar() implementation and its tests; I reviewed and ran them locally). +``` + +Name the tool and what it produced. Keep it to one sentence. `drupalorg` cannot +post comments or edit MR descriptions on Drupal.org, so hand the text to the user +and confirm they added it before marking the issue "Needs review". + +--- + +## Issue summaries, comments, and reviews: the user's own words + +Verbose AI prose is a burden on maintainers. Anything the user posts must be: + +- **Written in their own words.** Give the user a draft to edit, never text to + paste unchanged. Say so explicitly when you hand it over. +- **Concise.** Cut background the thread already contains. Lead with the + decision or question. +- **Independently verified.** An AI summary of a thread posted to gain issue + credit is a policy violation. Only propose summary updates that add technical + insight the user checked. +- **Attached when long.** When the full generated output is genuinely useful, + attach it as a file instead of pasting it into a comment. + +--- + +## After handing off: stay responsive + +A drive-by contribution that ignores follow-up feedback is grounds for a ban, +with or without AI. When you finish a work loop, remind the user that reviewers +may ask questions they must answer themselves, and offer to re-fetch the issue +later: + +```bash +drupalorg issue:show --with-comments --format=llm --no-cache +``` diff --git a/skill-data/drupalorg-cli/references/gitlab-mr-contribution.md b/skill-data/drupalorg-cli/references/gitlab-mr-contribution.md index 6c076a2a..6b64ab01 100644 --- a/skill-data/drupalorg-cli/references/gitlab-mr-contribution.md +++ b/skill-data/drupalorg-cli/references/gitlab-mr-contribution.md @@ -2,6 +2,10 @@ Reference guide for contributing to Drupal.org issues via GitLab merge requests. +Merge requests fall under Drupal.org's +[AI contribution policy](https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/policy-on-the-use-of-ai-when-contributing-to-drupal). +See `ai-contribution-policy.md` in this directory before pushing. + --- ## Initial Setup @@ -57,8 +61,12 @@ Branch names follow the convention `-`, e.g. `3001234-fix_cache ## Making Changes +Read the issue thread first (`issue:show --with-comments --format=llm`) +and check the MR `author` in `mr:list` output. Pushing to an MR the user did +not author requires the author's knowledge and a disclosing comment. + ```bash -# Edit files, then stage and commit +# Edit files, run local checks (phpcs, phpunit, phpstan), then stage and commit git add -p git commit -m "Issue # by : " @@ -69,6 +77,13 @@ git push Pushing to a tracking branch automatically updates the existing MR on GitLab. No separate MR update step is needed. +When AI generated entire functions, classes, scaffolding, or long documentation +blocks, the MR description needs a disclosure before review is requested: + +``` +AI-Generated: Yes (Claude Code drafted ; I reviewed and tested it). +``` + --- ## Monitoring the MR diff --git a/skill-data/drupalorg-cli/references/patch-contribution.md b/skill-data/drupalorg-cli/references/patch-contribution.md index e2d26675..8be4e8fa 100644 --- a/skill-data/drupalorg-cli/references/patch-contribution.md +++ b/skill-data/drupalorg-cli/references/patch-contribution.md @@ -3,13 +3,17 @@ Classic patch contribution flow for Drupal.org issues that still use file attachments (as opposed to GitLab merge requests). +Patches fall under Drupal.org's +[AI contribution policy](https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/policy-on-the-use-of-ai-when-contributing-to-drupal) +the same as merge requests. See `ai-contribution-policy.md` in this directory. + --- ## Prepare a Patch ```bash -# 1. Fetch the issue to understand scope and current state -drupalorg issue:show --format=llm +# 1. Fetch the issue and its comments; read prior attempts before writing code +drupalorg issue:show --with-comments --format=llm # 2. Create a local branch named after the issue drupalorg issue:branch @@ -19,11 +23,21 @@ drupalorg issue:branch git add -p git commit -m "Issue # by : " -# 4. Generate the patch (diffs against the upstream tracking branch) +# 4. Run the project's local checks (phpcs, phpunit) and fix failures + +# 5. Generate the patch (diffs against the upstream tracking branch) drupalorg issue:patch [nid] # Writes: --.patch to the git repo root -# 5. Upload the patch file to the issue on drupal.org +# 6. Upload the patch file to the issue on drupal.org +``` + +The comment that carries the patch is written by the user in their own words. +When AI generated entire functions, classes, scaffolding, or long documentation +blocks in the patch, draft a disclosure line for the end of that comment: + +``` +AI-Generated: Yes (Claude Code drafted ; I reviewed and tested it). ``` `issue:patch` auto-detects the NID from the branch name when run without an diff --git a/skill-data/drupalorg-cli/references/work-on-issue.md b/skill-data/drupalorg-cli/references/work-on-issue.md index f3a23be0..86591a13 100644 --- a/skill-data/drupalorg-cli/references/work-on-issue.md +++ b/skill-data/drupalorg-cli/references/work-on-issue.md @@ -3,6 +3,12 @@ This guide describes the end-to-end workflow for an agent to pick up a Drupal.org issue, set up the environment, and contribute via GitLab merge request. +Every push made through this workflow falls under Drupal.org's +[AI contribution policy](https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/policy-on-the-use-of-ai-when-contributing-to-drupal). +See `ai-contribution-policy.md` in this directory. In short: read the thread +before writing, keep diffs minimal and explainable, never leave a failing MR, +never push to someone else's MR unannounced, and disclose AI-generated code. + --- ## Step 1: Verify the Issue Fork @@ -25,14 +31,18 @@ whether to wait or open a fresh MR from the main project. --- -## Step 2: Verify Your Working Directory +## Step 2: Verify Your Working Directory and Read the Thread -Confirm your current directory matches the project for this issue. +Confirm your current directory matches the project for this issue, and read the +full discussion before planning any change. ```bash -drupalorg issue:show --format=llm +drupalorg issue:show --with-comments --format=llm ``` +Note prior attempts and settled architectural decisions from the comments. Code +that ignores them is a policy violation. + The `` field in the LLM output contains the project machine name (e.g. `drupal`, `commerce`, `views`). Your `git remote get-url origin` should resolve to a repository under that project name on git.drupal.org or GitLab. @@ -93,8 +103,11 @@ drupalorg mr:logs ### Make changes and push +Check the `author` field in the `mr:list` output first. Pushing to an MR the +user did not author requires the author's knowledge and a disclosing comment. + ```bash -# Edit files as needed, then: +# Edit files as needed, run local checks (phpcs, phpunit, phpstan), then: git add -p git commit -m "Issue # by : " git push @@ -113,7 +126,17 @@ drupalorg mr:status --format=llm drupalorg mr:logs ``` -Repeat the loop until the pipeline is green. +Repeat the loop until the pipeline is green. Do not hand off a failing MR. + +### Disclose before requesting review + +When AI generated entire functions, classes, scaffolding, or long documentation +blocks, the user must add a disclosure to the MR description before setting +"Needs review". Draft it for them: + +``` +AI-Generated: Yes (Claude Code drafted ; I reviewed and tested it). +``` --- diff --git a/skill-data/drupalorg-issue-summary-update/SKILL.md b/skill-data/drupalorg-issue-summary-update/SKILL.md index 097c2a8d..9c9f61b7 100644 --- a/skill-data/drupalorg-issue-summary-update/SKILL.md +++ b/skill-data/drupalorg-issue-summary-update/SKILL.md @@ -49,6 +49,12 @@ Report to the user: Ask: "Would you like me to draft an updated issue summary?" +**[POLICY]** Only proceed when the update adds technical insight the user has +verified. Drupal.org's +[AI contribution policy](https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/policy-on-the-use-of-ai-when-contributing-to-drupal) +names AI-generated thread summaries posted to gain issue credit as a violation. +If the current summary already matches the discussion, say so and stop. + --- ### Step 2: Draft updated summary @@ -64,8 +70,12 @@ If the user agrees, draft an updated issue summary that: - Updates "Proposed resolution" to reflect the discussion consensus - Updates "Remaining tasks" to match what is still outstanding - Keeps "Problem/Motivation" unchanged unless comments clarify the problem itself +- Is shorter than the discussion it summarises. Cut background the thread already + covers and lead with the decision. -Present the full updated summary text to the user. +Present the full updated summary text to the user as a draft to edit, not text to +paste. Say that explicitly. The policy requires summaries in the contributor's own +words and treats verbose AI prose as a burden on maintainers. **[PAUSE]** Ask: "Does this look correct? Should I adjust anything before you paste it into the issue?" @@ -78,8 +88,13 @@ Once the summary is approved, instruct the user: 1. Open the issue: `drupalorg issue:link ` 2. Click "Edit" on the issue node -3. Replace the "Summary" (body) field with the updated text -4. Save the issue +3. Rewrite the "Summary" (body) field from the draft in their own words +4. Append a disclosure at the end of the summary, for example: + ``` + AI-Generated: Yes (Claude Code drafted this summary update from the comment thread; I edited and verified it). + ``` + Use the issue template's AI disclosure section instead when one exists. +5. Save the issue Note: drupalorg-cli is read-only and cannot write to Drupal.org directly. diff --git a/skill-data/drupalorg-work-on-issue/SKILL.md b/skill-data/drupalorg-work-on-issue/SKILL.md index f582a80c..8bbbc275 100644 --- a/skill-data/drupalorg-work-on-issue/SKILL.md +++ b/skill-data/drupalorg-work-on-issue/SKILL.md @@ -27,6 +27,12 @@ When the user invokes `/drupalorg-work-on-issue `, execute the following wo each checkpoint marked **[PAUSE]** — present findings and wait for the user to confirm before proceeding. +This workflow produces code the user submits under Drupal.org's +[AI contribution policy](https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/policy-on-the-use-of-ai-when-contributing-to-drupal). +The user is the contributor and must be able to explain every change. Checkpoints +marked **[POLICY]** below exist to keep that true. Read the full checklist with +`drupalorg skill:get drupalorg-cli --full` (reference `ai-contribution-policy`). + --- ### Step 1: Fetch issue and fork details @@ -34,13 +40,22 @@ before proceeding. Run both commands to gather context (substitute `` with whatever ref was provided): ```bash -drupalorg issue:show --format=llm +drupalorg issue:show --with-comments --format=llm drupalorg issue:get-fork --format=llm ``` Report to the user: - Issue title, status, project machine name - Whether a fork exists and which branches are available +- Prior attempts (patches, earlier MRs) and why they stalled +- Architectural decisions already settled in the comments + +**[POLICY]** Read the whole comment thread before proposing anything. Code dumped +into an issue that ignores the discussion or reopens settled decisions is a policy +violation. `--with-comments` is ignored for GitLab work items; for those, read the +discussion with `GITLAB_HOST=git.drupalcode.org glab issue view --comments +--repo project/` or ask the user to summarise it. If your reading of the code disagrees with the thread's direction, say so +to the user and let them raise it in the issue. Do not act on it unilaterally. **Directory detection:** Before prompting the user, read `CLAUDE.md` in the current directory. If it documents the path to the `` module or repository, `cd` there automatically @@ -141,6 +156,12 @@ drupalorg mr:list --format=llm **If one or more MRs exist**, for the relevant MR (confirm with user if multiple exist): +**[POLICY]** Compare the MR `author` in the `mr:list` output with the user. If they +differ, stop. Adding AI-generated commits to someone else's MR without their +knowledge and without disclosure is a policy violation. Ask the user to confirm they +coordinated with the author in the issue, and note that the push must be disclosed +in a comment. Only continue once the user confirms. + ```bash drupalorg mr:files drupalorg mr:diff @@ -163,7 +184,10 @@ Summarise: Iterate until the pipeline is green or the user asks to stop: -1. Make the requested code changes. +1. Make the requested code changes. **[POLICY]** Keep the diff to what the issue + asks for: no unrelated refactors, renames, or formatting sweeps. Do not add a + dependency you have not confirmed exists and the user has not approved. State + what each change does and why in terms the user can repeat to a reviewer. 2. If `vendor/bin/phpcs` is available, run it on the module directory and fix any violations before proceeding: ```bash @@ -198,14 +222,36 @@ Iterate until the pipeline is green or the user asks to stop: **[PAUSE]** After each push, report the pipeline outcome and ask whether to continue or stop. -**Hand off for review (GitLab work items only):** When the pipeline is green and the -user confirms the work is ready for review, flip the state label and unassign: +**[POLICY]** Do not stop with a failing pipeline unless the user explicitly accepts +it. Leaving a red MR for others to fix is a policy violation. + +**Disclosure [POLICY]:** Before hand-off, decide whether AI produced a significant +portion of the change: entire functions, classes, scaffolding, or long documentation +blocks. If so, disclosure is mandatory regardless of how carefully the user reviewed +it. Draft one sentence naming the tool and what it produced, for example: + +``` +AI-Generated: Yes (Claude Code drafted the FooService::bar() implementation and its tests; I reviewed and ran them locally). +``` + +Tell the user to add it to the MR description (or the template's AI disclosure +section when one exists) and confirm they did. `drupalorg` cannot edit MR +descriptions or post Drupal.org comments. + +**Hand off for review (GitLab work items only):** When the pipeline is green, the +disclosure is in place, and the user confirms the work is ready for review, flip the +state label and unassign: ```bash drupalorg issue:label state::needsReview drupalorg issue:unassign ``` +**Follow-up [POLICY]:** Remind the user that reviewers may ask them to explain +decisions and that "the AI wrote it" closes the contribution. A contribution +abandoned after feedback is requested leads to an account ban. Offer to re-fetch the +thread later with `issue:show --with-comments --format=llm --no-cache`. + --- ## Notes diff --git a/skills/drupalorg-cli/SKILL.md b/skills/drupalorg-cli/SKILL.md index aaf66b9d..dfa0afeb 100644 --- a/skills/drupalorg-cli/SKILL.md +++ b/skills/drupalorg-cli/SKILL.md @@ -29,6 +29,29 @@ drupalorg skill:get drupalorg-cli --full # include workflow reference guides The CLI serves skill content that always matches the installed version, so instructions never go stale. +## Contribution policy + +Drupal.org's [policy on the use of AI when contributing](https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquette/policy-on-the-use-of-ai-when-contributing-to-drupal) +applies to every change made through this CLI. The user answers for everything +pushed or posted, and violations lead to account bans. Before writing code or +text for a Drupal.org issue: + +- Read the full thread and existing MRs first. Respect prior attempts and + settled decisions. +- Keep diffs minimal and explainable. No out-of-scope refactors or unverified + dependencies. +- Pass local checks and the MR pipeline before handing off. Never push to + someone else's MR without their knowledge. +- Draft an `AI-Generated: Yes (...)` disclosure for the MR description or comment + when AI produced entire functions, classes, scaffolding, or long doc blocks. +- Hand the user drafts to edit into their own words, never text to paste verbatim. + +Full checklist: + +```bash +drupalorg skill:get drupalorg-cli --full # includes references/ai-contribution-policy.md +``` + ## Specialized skills ```bash From 7e92545b9562aeb0e81707abaa3eee4399f46ab0 Mon Sep 17 00:00:00 2001 From: Matt Glaman Date: Fri, 4 Sep 2026 09:20:30 -0500 Subject: [PATCH 2/2] fix: reflow the work-on-issue policy checkpoint and use U.S. spelling Co-Authored-By: Claude Fable 5.1 --- .../references/ai-contribution-policy.md | 2 +- skill-data/drupalorg-issue-summary-update/SKILL.md | 2 +- skill-data/drupalorg-work-on-issue/SKILL.md | 11 ++++++++--- 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/skill-data/drupalorg-cli/references/ai-contribution-policy.md b/skill-data/drupalorg-cli/references/ai-contribution-policy.md index d23770b9..d2cb4a66 100644 --- a/skill-data/drupalorg-cli/references/ai-contribution-policy.md +++ b/skill-data/drupalorg-cli/references/ai-contribution-policy.md @@ -22,7 +22,7 @@ drupalorg mr:list --state=all --format=llm ``` `--with-comments` only returns comments for classic Drupal.org issues. For GitLab -work items, read the discussion with `glab` or ask the user to summarise it: +work items, read the discussion with `glab` or ask the user to summarize it: ```bash GITLAB_HOST=git.drupalcode.org glab issue view --comments --repo project/ diff --git a/skill-data/drupalorg-issue-summary-update/SKILL.md b/skill-data/drupalorg-issue-summary-update/SKILL.md index 9c9f61b7..3ddf2881 100644 --- a/skill-data/drupalorg-issue-summary-update/SKILL.md +++ b/skill-data/drupalorg-issue-summary-update/SKILL.md @@ -70,7 +70,7 @@ If the user agrees, draft an updated issue summary that: - Updates "Proposed resolution" to reflect the discussion consensus - Updates "Remaining tasks" to match what is still outstanding - Keeps "Problem/Motivation" unchanged unless comments clarify the problem itself -- Is shorter than the discussion it summarises. Cut background the thread already +- Is shorter than the discussion it summarizes. Cut background the thread already covers and lead with the decision. Present the full updated summary text to the user as a draft to edit, not text to diff --git a/skill-data/drupalorg-work-on-issue/SKILL.md b/skill-data/drupalorg-work-on-issue/SKILL.md index 8bbbc275..eb10a1eb 100644 --- a/skill-data/drupalorg-work-on-issue/SKILL.md +++ b/skill-data/drupalorg-work-on-issue/SKILL.md @@ -52,11 +52,16 @@ Report to the user: **[POLICY]** Read the whole comment thread before proposing anything. Code dumped into an issue that ignores the discussion or reopens settled decisions is a policy -violation. `--with-comments` is ignored for GitLab work items; for those, read the -discussion with `GITLAB_HOST=git.drupalcode.org glab issue view --comments ---repo project/` or ask the user to summarise it. If your reading of the code disagrees with the thread's direction, say so +violation. If your reading of the code disagrees with the thread's direction, say so to the user and let them raise it in the issue. Do not act on it unilaterally. +`--with-comments` is ignored for GitLab work items. For those, read the discussion +with `glab` or ask the user to summarize it: + +```bash +GITLAB_HOST=git.drupalcode.org glab issue view --comments --repo project/ +``` + **Directory detection:** Before prompting the user, read `CLAUDE.md` in the current directory. If it documents the path to the `` module or repository, `cd` there automatically and skip the directory prompt. Only fall back to running `git remote get-url origin` and