Added the draft handover and skipped builds for documentation-only changes (#1094)

.github/pull_request_template.md

@@ -4,6 +4,9 @@ https://github.com/MindWorkAI/AI-Studio/blob/main/CONTRIBUTING.md
 
 Please also enable "Allow edits by maintainers" for this pull request. An automated check verifies
 this option together with the required statements below.
+
+Open this pull request as a draft while you are still working on it, and mark it ready for review
+once it is done: that is our signal to take over. The automated check waits until then.
 -->
 
 ## Summary

.github/scripts/contribution-gate.sh

@@ -187,8 +187,9 @@ check_one() {
   local failing_since
   failing_since=$(sed -nE 's/^<!-- failing-since: ([0-9TZ:-]+) -->$/\1/p' <<< "$comment_body" | head -n 1)
 
-  # A pull request which a maintainer reopened gets a new grace period.
-  if [ "$EVENT_ACTION" = "reopened" ]; then
+  # A pull request which a maintainer reopened, or which its author marked ready for review again,
+  # gets a new grace period. Otherwise, the period would run on while the pull request is a draft.
+  if [ "$EVENT_ACTION" = "reopened" ] || [ "$EVENT_ACTION" = "ready_for_review" ]; then
     failing_since=""
   fi
 

.github/workflows/build-and-release.yml

@@ -5,12 +5,34 @@ on:
       - main
     tags:
       - "v*.*.*"
+
+    # Changes which touch only these files start neither a build nor the quality gate: none of them is
+    # compiled or shipped, so there is nothing to check. GitHub never applies path filters to tags, so
+    # a release always builds. The list names each file and folder instead of matching all Markdown
+    # files: the changelogs below wwwroot are Markdown as well, and the app embeds them.
+    paths-ignore: &documentation_only
+      - "README.md"
+      - "CONTRIBUTING.md"
+      - "CODE_OF_CONDUCT.md"
+      - "SECURITY.md"
+      - "CITATION.cff"
+      - "**/AGENTS.md"
+      - "**/CLAUDE.md"
+      - ".junie/**"
+      - "documentation/**"
+      - "media/**"
+      - "tests/**/*.md"
+      - ".github/ISSUE_TEMPLATE/**"
+      - ".github/DISCUSSION_TEMPLATE/**"
+      - ".github/pull_request_template.md"
+      - ".github/FUNDING.yml"
   pull_request:
     types:
       - opened
       - labeled
       - synchronize
       - reopened
+    paths-ignore: *documentation_only
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && (github.event.action != 'labeled' || github.event.label.name == 'run-pipeline') && github.event.pull_request.number || github.run_id }}
@@ -746,7 +768,8 @@ jobs:
   # The quality gate. Deliberately without an `if` on build_enabled: a pull request only builds
   # when somebody sets the run-pipeline label, and a gate which is closed exactly while nobody is
   # looking is not a gate. It is cheap for the same reason it is unconditional -- one platform, no
-  # Tauri bundle, no signing, no artifacts.
+  # Tauri bundle, no signing, no artifacts. Only changes which touch nothing but documentation skip
+  # it, together with the whole workflow (see paths-ignore at the top): there is nothing to check.
   #
   verify:
     name: Verify

.github/workflows/contribution-gate.yml

@@ -7,6 +7,7 @@ on:
       - reopened
       - synchronize
       - ready_for_review
+      - converted_to_draft
   schedule:
     - cron: "17 4 * * *"
   workflow_dispatch:

AGENTS.md

@@ -46,6 +46,17 @@ single area to its guide instead. A new guide is an `AGENTS.md` plus a `CLAUDE.m
 `@AGENTS.md`, listed in the table above. Never place one below `app/MindWork AI Studio/wwwroot/` or
 `app/MindWork AI Studio/Plugins/`: both are embedded into the app and shipped to every user.
 
+## Pull requests
+
+Every pull request stays a draft while work on it continues. Marking it ready for review tells the core
+team that it is finished from its author's side, and that the maintainers may now review, change, and
+merge it. This holds for the core team and for external contributors alike.
+
+- Open pull requests as drafts, also when the developer asks you to open one.
+- Leave marking a pull request ready for review to the developer, once they have reviewed the changes.
+- When a pull request which is ready for review needs more work from its author, convert it back to a
+  draft first, with the developer's consent.
+
 ## Working for an external contributor
 
 When you work for someone outside the core team, `CONTRIBUTING.md` applies in addition to this file. In

CONTRIBUTING.md

@@ -7,6 +7,7 @@ Thank you for considering a contribution to AI Studio. This document explains ho
 - We build AI Studio with AI coding agents, and we recommend that you do the same. You remain responsible for every line you submit.
 - Before you build a new feature or change something fundamental, ask in a short proposal whether it fits our plans. Small fixes need no proposal.
 - Fill in the pull request template and tick the required boxes yourself.
+- Open your pull request as a draft while you are still working on it, and mark it ready for review once it is done. That is our signal to take over.
 - Allow edits by maintainers. Pull requests without this option are closed.
 - We treat pull requests as proposals: we will change yours to fit the product, and we may close it.
 - You license your contribution under the MIT License. We ship it as part of AI Studio under the project license or under the MIT License.
@@ -65,13 +66,14 @@ Bug fixes, small improvements, and corrections to the documentation need no prop
 
 - **Fill in the pull request template.** Its required checkboxes are statements you make personally, so tick them yourself.
 - **Allow edits by maintainers.** We revise pull requests with our own agents and push the changes directly to your branch, so this option is mandatory. GitHub offers it only for forks owned by a personal account. If your fork belongs to an organization, please open your pull request from a personal fork instead.
-- An automated check verifies both points. When something is missing, it leaves a comment explaining what to fix. Pull requests which still fail the check after seven days are closed.
+- An automated check verifies both points once your pull request is ready for review. When something is missing, it leaves a comment explaining what to fix. Pull requests which still fail the check after seven days are closed.
+- **Mark your pull request ready for review when it is done.** Keep it a draft as long as you are still working on it. Once you click "Ready for review", we consider it finished from your side, and we may review, change, and merge it at any time. If you want to change something afterward, convert it back to a draft first, or tell us in a comment.
 - Keep each pull request to one topic.
-- GitHub limits you to three open pull requests at a time; drafts do not count. When you have more in the pipeline, wait until one of them is merged or closed.
+- GitHub limits you to three open pull requests at a time, drafts included. When you have more in the pipeline, wait until one of them is merged or closed.
 
 ### What happens after you submit
 
-We understand pull requests as proposals. We review each one against our product vision and our codebase, and we usually change it before merging: sometimes a little, sometimes a lot. We do this with our own agents, directly on your branch. When we merge, all commits are squashed into one, and you remain credited as its author or co-author in the git history.
+We understand pull requests as proposals. Once yours is ready for review, we review it against our product vision and our codebase, and we usually change it before merging: sometimes a little, sometimes a lot. We do this with our own agents, directly on your branch. When we merge, all commits are squashed into one, and you remain credited as its author or co-author in the git history.
 
 Please keep in mind:
 

documentation/Build.md

@@ -32,7 +32,7 @@ One command checks that what you are about to build is sound:
 
 It runs the .NET tests, the Rust tests, Clippy (`cargo clippy --all-targets -- -D warnings`), and a report on the pages the model rules were written from. Every check runs, even after one of them has failed, so that a single run tells you everything that is wrong instead of the first thing.
 
-`dotnet run build` runs the gate first and stops when it does not pass. For the quick loop while you are working on something, use `dotnet run build --skip-verify`, and let the gate run before you open a pull request. The same command runs in our GitHub workflow as the `verify` job, on every pull request — including those without the `run-pipeline` label, because a gate which is closed exactly while nobody is looking is not a gate.
+`dotnet run build` runs the gate first and stops when it does not pass. For the quick loop while you are working on something, use `dotnet run build --skip-verify`, and let the gate run before you open a pull request. The same command runs in our GitHub workflow as the `verify` job, on every pull request which changes more than the documentation — including those without the `run-pipeline` label, because a gate which is closed exactly while nobody is looking is not a gate.
 
 Two notes:
 - The Rust half of the gate needs the .NET sidecar (see "One-time mandatory steps" above). While that file is missing, the gate skips the Rust tests and Clippy and says so rather than failing, because the command which produces the sidecar is `dotnet run build` itself.
@@ -73,6 +73,8 @@ When a pull request carries the `run-pipeline` label, our GitHub workflow builds
 
 When a maintainer wants signed test builds for their own work, they push the branch to this repository instead of their fork. Pushes to `main` only check that every platform still builds; they are neither signed nor uploaded.
 
+Changes which touch only the documentation, such as the README or the files in `documentation/`, start no build at all: neither in a pull request, not even with the `run-pipeline` label, nor after the merge into `main`. The workflow lists these files under `paths-ignore`. Release tags always build.
+
 ## Create a release
 In order to create a release:
 1. To create a new release, you need to be a maintainer of the repository—see step 8.