From cc833fc5bcf33e00c364f2ad80822d571806f91f Mon Sep 17 00:00:00 2001 From: Sergio Alexander Florez Galeano Date: Thu, 16 Jul 2026 21:47:36 +0000 Subject: [PATCH 1/2] fix(ci): run label bootstrap unconditionally to break the Ready chicken-and-egg MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## Summary Round-4 AI review fixes. On a clean installation the labels-bootstrap job was gated on should_run=true, which itself requires the Ready label to already be applied — so the job that creates the Ready label could never run before the label existed. ## Change Log - labels-bootstrap: drop the should_run condition; the job now runs on every opened/labeled event (idempotent, ~4s) - The second round-4 finding (vendored apply-review/open-pr SKILL.md declaring git+gh via requires.anyBins when both are mandatory) is an upstream defect in the skill pack — deferred to DailybotHQ/ai-diff-reviewer#42 rather than hand-editing the vendored tree and drifting it from the skills-lock.json content hash ## Risks - None — one job condition removed; the bootstrap step was already idempotent (`|| true` on existing labels) Co-Authored-By: Claude Fable 5 --- .github/workflows/pr-review.yml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/.github/workflows/pr-review.yml b/.github/workflows/pr-review.yml index 46adc44..f94f051 100644 --- a/.github/workflows/pr-review.yml +++ b/.github/workflows/pr-review.yml @@ -149,9 +149,11 @@ jobs: labels-bootstrap: name: 'Bootstrap review labels' + # Runs on every trigger event, NOT gated on should_run: on a clean + # installation the `Ready` label does not exist yet, and gating this job + # on `Ready` being applied would make the bootstrap unreachable + # (chicken-and-egg). The job is idempotent and costs ~4s. needs: scope - # Only bootstrap when we're actually going to review — no work otherwise. - if: needs.scope.outputs.should_run == 'true' runs-on: ubuntu-latest permissions: issues: write From 57511f23928435183a28750768a5b685b5665203 Mon Sep 17 00:00:00 2001 From: Sergio Alexander Florez Galeano Date: Thu, 16 Jul 2026 21:56:42 +0000 Subject: [PATCH 2/2] docs(release): align RELEASE_AND_DISTRIBUTION.md with the two-case [skip release] policy MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## Summary Round-5 AI review fix: AGENTS.md § 15.a and the auto-release.yml header were expanded to two accepted [skip release] use cases, but docs/RELEASE_AND_DISTRIBUTION.md still said "one accepted use case" and listed CI/workflow-only PRs as forbidden — contradicting case (b) and this PR's own merge policy. ## Change Log - RELEASE_AND_DISTRIBUTION.md § "When (and only when) to use it": two enumerated cases matching AGENTS.md § 15.a; forbidden list narrowed to CLI docs and release/test-pipeline CI (agent-tooling wiring is case (b)) - AGENTS.md § 15.a opening line no longer says "one narrow situation" while rule 3 enumerates two ## Risks - None — policy documentation only Co-Authored-By: Claude Fable 5 --- AGENTS.md | 2 +- docs/RELEASE_AND_DISTRIBUTION.md | 9 ++++++--- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 2dae9d8..75f59db 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -309,7 +309,7 @@ The implementation lives in `dailybot_cli/config.py` (`get_active_env_profile`, > **TL;DR — every PR releases by default. The only way to suppress it is to type `[skip release]` into the squash-commit body in the GitHub merge dialog yourself, on a PR that meets one of the accepted use cases below.** -There is **one** narrow situation in which auto-releasing the CLI is actively harmful: syncing the in-repo vendored copy of the Dailybot agent skill pack at `.agents/skills/dailybot/` to a newly published `DailybotHQ/agent-skill` release. The skill pack pins a `dailybot-cli >= X.Y.Z` floor, so if the dogfood-sync PR triggered a release, the CLI would advance past that floor, the freshly synced skill pack would go stale instantly, and we would enter an infinite loop: +There are **two** narrow situations in which auto-releasing the CLI is wrong (both enumerated in rule 3 below). The motivating one — where a release is actively harmful, not just empty — is syncing the in-repo vendored copy of the Dailybot agent skill pack at `.agents/skills/dailybot/` to a newly published `DailybotHQ/agent-skill` release. The skill pack pins a `dailybot-cli >= X.Y.Z` floor, so if the dogfood-sync PR triggered a release, the CLI would advance past that floor, the freshly synced skill pack would go stale instantly, and we would enter an infinite loop: ``` sync skill pack → merge → CLI auto-bumps → skill pack now references old CLI diff --git a/docs/RELEASE_AND_DISTRIBUTION.md b/docs/RELEASE_AND_DISTRIBUTION.md index cbfdfbe..c647d48 100644 --- a/docs/RELEASE_AND_DISTRIBUTION.md +++ b/docs/RELEASE_AND_DISTRIBUTION.md @@ -156,12 +156,15 @@ If you need a release for commits that don't qualify (e.g. an emergency `chore`- #### When (and only when) to use it -There is **one** accepted use case: a PR whose entire diff is the synchronisation of the in-repo Dailybot agent skill pack at `.agents/skills/dailybot/` to a newly published [`DailybotHQ/agent-skill`](https://github.com/DailybotHQ/agent-skill) release (plus the minimal catalog / `AGENTS.md` updates that reference it). Without the marker, that PR would auto-bump the CLI, which in turn would push the skill pack out of sync with the CLI version it just pinned, creating an infinite sync→bump→resync loop. See [AGENTS.md Rule 15.a](../AGENTS.md#15a-opt-in-release-skip--skip-release-marker) for the full rationale. +There are **two** accepted use cases (mirroring [AGENTS.md Rule 15.a](../AGENTS.md#15a-opt-in-release-skip--skip-release-marker)): + +1. **Dailybot skill-pack dogfood sync** — a PR whose entire diff is the synchronisation of the in-repo Dailybot agent skill pack at `.agents/skills/dailybot/` to a newly published [`DailybotHQ/agent-skill`](https://github.com/DailybotHQ/agent-skill) release (plus the minimal catalog / `AGENTS.md` updates that reference it). Without the marker, that PR would auto-bump the CLI, which in turn would push the skill pack out of sync with the CLI version it just pinned, creating an infinite sync→bump→resync loop. +2. **Vendored agent-tooling sync (maintainer-requested)** — a PR whose entire diff lives in agent/CI tooling that ships nothing to CLI users: vendored skill packs under `.agents/` (DWP, AI Diff Reviewer, …), `.agents/commands/` delegators, `.review/`, `skills-lock.json`, the workflows that wire them, and the docs that reference them. A release would be an empty version bump. This case additionally requires the maintainer to **explicitly request the marker on that specific PR** — there is no standing approval. Any other use of the marker is a bug. In particular, do **not** apply it to: -- Doc-only PRs (let the PATCH go out — the changelog entry is the record that the doc shipped). -- CI-only or workflow-only PRs (same reason). +- Doc-only PRs about the CLI itself (let the PATCH go out — the changelog entry is the record that the doc shipped). +- CI tweaks to the release/test pipelines (same reason). - Dependency-bump PRs (downstream users need to see the bump). - Refactors, test-only PRs, comment-only PRs — same.