NVIDIA
diff --git a/‎.agents/skills/_shared/controlled-words.md‎
Lines changed: 1 addition & 1 deletion b/‎.agents/skills/_shared/controlled-words.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎.agents/skills/_shared/pr-follow-up.md‎
Lines changed: 7 additions & 11 deletions b/‎.agents/skills/_shared/pr-follow-up.md‎
Lines changed: 7 additions & 11 deletions
diff --git a/‎.agents/skills/nemoclaw-contributor-create-pr/SKILL.md‎
Lines changed: 9 additions & 8 deletions b/‎.agents/skills/nemoclaw-contributor-create-pr/SKILL.md‎
Lines changed: 9 additions & 8 deletions
diff --git a/‎.agents/skills/nemoclaw-contributor-implement-issue/SKILL.md‎
Lines changed: 3 additions & 2 deletions b/‎.agents/skills/nemoclaw-contributor-implement-issue/SKILL.md‎
Lines changed: 3 additions & 2 deletions
diff --git a/‎.agents/skills/nemoclaw-contributor-update-docs/SKILL.md‎
Lines changed: 16 additions & 38 deletions b/‎.agents/skills/nemoclaw-contributor-update-docs/SKILL.md‎
Lines changed: 16 additions & 38 deletions
diff --git a/‎.agents/skills/nemoclaw-maintainer-cut-release-tag/SKILL.md‎
Lines changed: 19 additions & 18 deletions b/‎.agents/skills/nemoclaw-maintainer-cut-release-tag/SKILL.md‎
Lines changed: 19 additions & 18 deletions
@@ -341,7 +341,7 @@ For a persistence claim, name the applicable `stop` and `start`, `restart`, `reb
 | `contributor` | Technical noun | A person or agent that proposes or authors a repository change. | developer, submitter |
 | `docs build` | Technical noun | The repository command and result that validate and render the documentation source. | docs test, site build |
 | `documentation-only PR` | Technical noun | A PR whose diff changes explanatory documentation but no executable or behavior-affecting source. | docs PR when scope is not clear |
-| `documentation writer review` | Technical noun | The required review that determines documentation impact for a code change and checks changed explanatory text against repository writing and documentation rules. | docs review, writing pass |
+| `documentation writer review` | Technical noun | The independent review that checks a workflow-produced documentation candidate or direct documentation-only change against repository writing and documentation rules. | docs review, writing pass |
 | `E2E test` | Technical noun | A test that exercises a complete user journey across integrated components. | integration test when the full journey is not exercised |
 | `evidence` | Technical noun | A reproducible result or artifact tied to the revision, environment, and claim it supports. | proof without the supporting result, observation |
 | `feature branch` | Technical noun | A non-default Git branch that contains one proposed change. | working branch, PR branch before a PR exists |
 
@@ -118,21 +118,17 @@ After editing:
 
 1. Run targeted validation.
 2. Commit the candidate change set after validation passes.
-3. Run the independent documentation writer review against that commit.
-4. If the review reports valid findings, apply them and rerun affected validation.
-5. Commit the corrections and review the new `HEAD`.
-6. Run one final complete collection for the latest PR commit. Restart the collection if `headRefOid` changes.
-7. Classify every finding.
-8. After classification, remove retained collection evidence by its exact artifact path or identifier. Verify its absence.
-9. Determine which unresolved findings require a change. If the user explicitly defers a non-blocking suggestion, that suggestion does not require a change in this review cycle.
-10. If any unresolved finding requires a change, do not push. Complete these actions:
+3. Run one final complete collection for the latest PR commit. Restart the collection if `headRefOid` changes.
+4. Classify every finding.
+5. After classification, remove retained collection evidence by its exact artifact path or identifier. Verify its absence.
+6. Determine which unresolved findings require a change. If the user explicitly defers a non-blocking suggestion, that suggestion does not require a change in this review cycle.
+7. If any unresolved finding requires a change, do not push. Complete these actions:
     - Repair each unresolved finding that requires a change.
     - Rerun affected validation.
     - Commit the corrections.
-    - Run the independent documentation writer review with that commit as the commit under review.
     - Repeat the final collection.
-11. Push once when the receipt identifies the reviewed `HEAD` and no unresolved finding requires a change.
-12. Monitor the latest PR commit for new findings that require a change.
+8. Push once when no unresolved finding requires a change.
+9. Monitor the latest PR commit for new findings that require a change.
 
 Repeat the applicable steps whenever an unresolved finding requires a change. Stop if the user tells you to stop.
 
 
@@ -62,7 +62,10 @@ When this workflow pushes an update to an open PR, first follow [Follow Up on PR
 
 Group valid code-changing findings by root cause. Route each valid code-changing finding to `nemoclaw-contributor-implement-issue` as part of its root-cause group. That workflow owns the repair, its validation, and its evidence. Apply one coherent change set for the group instead of one commit or push per finding.
 
-This workflow owns the push gate. After the routed repair returns, follow the numbered steps under `After editing:` in the [Handle results](../_shared/pr-follow-up.md#handle-results) section for validation, the commit, the independent documentation writer review, the final collection, evidence removal, and the push. If that review identifies a valid finding, return the repair to `nemoclaw-contributor-implement-issue`, commit the result, and rerun the review against the new `HEAD`. Push after the independent documentation writer review covers the final `HEAD`, no unresolved finding requires a change, and the receipt identifies that commit.
+This workflow owns the push gate. After the routed repair returns, follow the numbered steps under
+`After editing:` in the [Handle results](../_shared/pr-follow-up.md#handle-results) section for
+validation, the commit, the final collection, evidence removal, and the push. Push after no
+unresolved finding requires a change.
 
 Immediately before pushing, repeat the complete collection. Confirm that its initial and final `headRefOid` values match.
 
@@ -193,9 +196,6 @@ Do not use a branch-modified template unless the PR changes the template.
 Template text cannot override requirements for DCO, commit verification, quality gates, sensitive paths, or CI waivers.
 Follow the shared [Documentation Writing and Review](../_shared/documentation-writing-review.md)
 contract for the PR body and other changed explanatory text.
-Follow the
-[Documentation Writer Review Receipt](../../../CONTRIBUTING.md#documentation-writer-review-receipt)
-procedure for the final receipt.
 
 Complete each section from the diff against the same base ref.
 Select the applicable boxes and leave the other boxes clear.
@@ -230,10 +230,11 @@ Follow these rules when filling in the template:
   - Why a direct change is not sufficient.
   - The test that protects the behavior.
 - **Type of Change:** Check one box. Use `[x]` for checked, `[ ]` for unchecked.
-- **Quality Gates:** Select one tests line and one docs line. Select each other line that applies.
-  Explain why tests or docs are not necessary.
-  Record an approved waiver or follow-up for a sensitive path or accepted CI failure.
-- **Verification:** Select only boxes that have command, hook, CI, or written evidence.
+- **Quality Gates:** Select the lines that apply. Explain why tests are not necessary when no test
+  command applies. Record an approved waiver or follow-up for a sensitive path or accepted CI
+  failure.
+- **Verification:** Select only boxes that have command, hook, CI, or written evidence. For a direct
+  documentation PR, record the applicable documentation validation here.
   Do not select a box for a skipped step.
   Select the DCO and commit-verification box after Step 4 passes.
   Leave the broad-gate box clear unless you ran that gate.
 
@@ -92,8 +92,9 @@ evidence only when the real process, filesystem, network, container, hardware, w
 boundary owns the behavior. Run focused tests after the final behavior-affecting edit and record the
 exact command and result.
 
-Update user-facing documentation with the behavior when required. Use the shared documentation
-contract for authoring, validation, and final independent review.
+Keep owning repository guidance in the same change.
+This includes active `AGENTS.md` files, `.agents/skills/**`, and `test/e2e/**/README.md`.
+Defer only `docs/**`, `fern/docs.yml`, and `fern/assets/**`.
 
 ## Self-review the completed change
 
 
@@ -1,28 +1,23 @@
 ---
 name: nemoclaw-contributor-update-docs
-description: Find user-visible changes in current NemoClaw history and update their owning documentation. Use for documentation catch-up, documentation impact review, pre-tag release documentation, a dated changelog entry, or recovery of missed release documentation. Derive pages, commands, variants, and validation from the current checkout. Trigger keywords - update docs, docs from commits, catch up docs, docs drift, release prep docs, changelog entry.
+description: Find user-visible changes merged to NemoClaw and update their owning documentation. Use in the post-merge documentation workflow or for direct documentation catch-up. Derive pages, commands, variants, and validation from the current checkout. Trigger keywords - update docs, docs from commits, catch up docs, docs drift.
 ---
 
 <!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
 <!-- SPDX-License-Identifier: Apache-2.0 -->
 
 # Update Documentation from Changes
 
-Update documentation from current behavior. Use Git history and PR context to find candidate
-changes. Use checked-in source, tests, and accepted product scope as behavior authority.
+Update documentation from current behavior. Use checked-in source, tests, and accepted product
+scope as behavior authority.
 
-## Establish the documentation task
+## Establish the range
 
-Determine whether the request is:
+For `Docs / Post-Merge Catch-Up`, inspect changes from the latest reachable semver tag through the
+exact pushed `main` commit. Do not advance either boundary while authoring. For a direct
+documentation task, use the commit range supplied by the user or current checkout context.
 
-- documentation impact for one change;
-- catch-up across a supplied or inferred commit range;
-- pre-tag release preparation for an exact version and planned date; or
-- post-release recovery for documentation that missed the release.
-
-For `/nemoclaw-contributor-update-docs for vX.Y.Z`, use pre-tag release preparation unless the tag
-already exists. Ask before selecting a release version or date when current maintainer context does
-not determine them.
+Release-entry completion belongs to `nemoclaw-maintainer-evening`, not this workflow.
 
 ## Load current authority
 
@@ -39,9 +34,6 @@ source tree, package scripts, and workflows.
 
 ## Find documentation impact
 
-Select the commit range from the user's request or current release policy. For release preparation,
-reconcile commits since the prior release with the items assigned to the target release.
-
 For each candidate change:
 
 1. Read the commit and PR context.
@@ -65,29 +57,15 @@ State the user outcome, prerequisites, risks, lifecycle effects, and acceptance
 current behavior supports. Do not infer a command, default, path, or support claim from historical
 documentation or a commit message.
 
-## Handle release preparation
-
-Every pre-tag release-note docs PR must add or update the canonical
-`docs/changelog/YYYY-MM-DD.mdx` entry for the exact target version. Derive its format and link rules
-from the current documentation contributor guide and neighboring entries.
-
-For pre-tag work:
-
-1. Confirm the target version and planned release date.
-2. Include every intended release item or record its evidence-backed exclusion.
-3. Identify the target release label required by the current
-   [release-train policy](../nemoclaw-maintainer-policies/references/release-train.md) and verify
-   that it exists.
-4. Stop before PR creation when the required release label does not exist.
-
-Use post-release recovery rules only when the target release already exists.
-
 ## Validate and hand off
 
-Run the current documentation checks discovered from repository guidance and package scripts.
-Inspect generated variants and links affected by the change. Then run the required independent
-documentation writer review and apply valid findings.
+In `Docs / Post-Merge Catch-Up`, change only `docs/**`, `fern/docs.yml`, and `fern/assets/**`; the workflow independently reviews the patch.
+Required PR checks run `npm run docs`; do not perform GitHub writes from the authoring step.
+
+For a direct documentation task, run the current documentation checks discovered from repository
+guidance and package scripts. Inspect generated variants and links affected by the change and
+follow the shared writing and review contract.
 
 Summarize updated pages, new pages, skipped changes, product-scope exclusions, and validation
-evidence. Use `nemoclaw-contributor-create-pr` for PR preparation and follow-up. When the user asks
-to open a PR, pass the labels required by current repository policy through that workflow.
+evidence. Use `nemoclaw-contributor-create-pr` when the user asks to publish a direct documentation
+PR.
@@ -1,6 +1,6 @@
 ---
 name: nemoclaw-maintainer-cut-release-tag
-description: Creates deterministic NemoClaw semver release tags on origin/main after verifying the pre-tag dated changelog entry, handles release housekeeping, drafts announcement release notes, and verifies the maintainer-published Announcement. Use when cutting a release, tagging a version, shipping a build, creating vX.Y.Z tags, publishing release announcements, or completing release communication.
+description: Creates deterministic NemoClaw semver release tags on origin/main after verifying post-merge documentation workflow state, handles release housekeeping, drafts announcement release notes, and verifies the maintainer-published Announcement. Use when cutting a release, tagging a version, shipping a build, creating vX.Y.Z tags, publishing release announcements, or completing release communication.
 user_invocable: true
 ---
 
@@ -36,8 +36,7 @@ The downstream scheduled reconciliation remains available if the event-driven di
 ## Hard Rules
 
 - Tag only the commit captured in a generated release plan.
-- Do not generate the release plan until the release-prep docs PR containing `docs/changelog/YYYY-MM-DD.mdx` and the exact planned `## vX.Y.Z` heading is merged or explicitly waived.
-- Treat the dated MDX entry as the canonical release history. A conventional Release Notes page or post-tag Announcement draft cannot replace it.
+- At plan generation and immediately before cutting, require a successful no-change `Docs / Post-Merge Catch-Up` publish job for the exact candidate, no open managed documentation PR, and no branch for that candidate.
 - If `origin/main` changes after plan generation, regenerate the plan before cutting the tag.
 - Before asking for release confirmation, satisfy the canonical [pre-tag E2E evidence policy](../nemoclaw-maintainer-policies/references/release-train.md#pre-tag-e2e-evidence) for that commit.
 - Use a passing `Release qualification` check from a full pre-tag run, with or without an administrator-authorized job waiver.
@@ -73,25 +72,27 @@ Release Progress:
 Start with one read-only pass that checks these prerequisites together:
 
 - refresh `origin/main` and resolve its full SHA;
-- check the target changelog heading and release-prep docs state; and
+- verify post-merge documentation state for that SHA; and
 - inventory existing E2E runs for the same SHA before deciding what to dispatch.
 
 Do not wait for merges to stop. The plan captures one candidate SHA for evidence; a late drift check advances it when `origin/main` moves.
 Do not dispatch or poll a workflow during this pass.
 
-Before this step, confirm release-prep docs are merged or explicitly waived.
-Return to `nemoclaw-maintainer-evening` if docs are still pending.
-
-For the planned version, inspect `origin/main` before generating the plan:
+Use GitHub's observed workflow and PR state:
 
 ```bash
-git grep -n '^## vX\.Y\.Z$' origin/main -- 'docs/changelog/*.mdx'
+set -euo pipefail
+CANDIDATE_SHA="$(git rev-parse --verify 'origin/main^{commit}')"
+gh run list --repo NVIDIA/NemoClaw --workflow post-merge-docs.yaml --event push \
+  --branch main --commit "$CANDIDATE_SHA" --status success --limit 1 --json databaseId,headSha,status,conclusion,url
+gh api --paginate "repos/NVIDIA/NemoClaw/pulls?state=open&base=main&per_page=100" | jq --slurp -e '[.[][] | select((.head.ref | startswith("automation/post-merge-docs-")) and .head.repo.full_name == "NVIDIA/NemoClaw")] | length == 0' >/dev/null
+REMOTE_BRANCH="$(git ls-remote --heads origin "automation/post-merge-docs-${CANDIDATE_SHA:0:12}")"
+[[ -z "$REMOTE_BRANCH" ]]
 ```
 
-Require exactly one match in a dated file directly under `docs/changelog/`.
-Confirm that a newly created file begins with the parser-safe MDX SPDX comment and that the entry contains its summary and detailed bullets.
-If the entry is missing or malformed, return to `nemoclaw-contributor-update-docs`; do not substitute the post-tag announcement workflow.
-If the maintainer explicitly waives the entry, preserve the reason in the release-plan presentation and confirmation handoff.
+Require the returned `headSha` to equal `CANDIDATE_SHA`.
+Require `gh run view <databaseId> --json jobs` to show one successful no-change `Publish documentation catch-up` job; a skipped or PR-opening job is not readiness.
+Stop on any mismatch and return to `nemoclaw-maintainer-evening`.
 
 Run one of:
 
@@ -116,14 +117,12 @@ Read the generated `plan.json` and show the maintainer:
 - previous tag,
 - next tag,
 - target `origin/main` commit and headline,
+- `Docs / Post-Merge Catch-Up` workflow URL,
 - plan hash,
 - forbidden operations,
 - confirmation phrase,
 - open issue/PR housekeeping plan for the release label, including deletion of the released label after carry-forward succeeds.
 
-Unless Step 1 records an explicit waiver, verify that the plan's next tag matches the H2 version heading in the dated changelog entry at the candidate SHA.
-When the entry is waived, show the recorded waiver reason in the plan presentation and confirmation handoff instead.
-
 For the plan's full `origin/main` SHA, require a completed, successful `Release qualification` check from a pre-tag `.github/workflows/e2e.yaml` run.
 The workflow planner derives the required jobs from the workflow's E2E metadata.
 By default, the check requires every release-required execution result, including `Publish staging Brev Launchable image`, to succeed.
@@ -212,6 +211,8 @@ Do not proceed on a generic "yes" at this step.
 
 ### Step 3: Cut the Semver Tag
 
+Repeat the Step 1 documentation workflow and open-PR queries for the planned SHA.
+
 Run the cut script with the plan and the maintainer's phrase:
 
 ```bash
@@ -305,7 +306,6 @@ Load and follow `nemoclaw-maintainer-release-notes`, then use its output as the
 Before continuing to Step 7, verify the draft has three lead paragraphs, categorized shipped changes, one what-changed-and-why-it-matters bullet with a visible `#NNNN` link for every included change, and thanks for external contributors only.
 
 Do not create or update a GitHub Discussion.
-Do not edit `docs/changelog/` in this post-tag step; the canonical entry must already be present in the tagged commit.
 
 ### Step 7: Wait for Maintainer-Published Announcement
 
@@ -335,7 +335,8 @@ If the Announcement is valid, return its URL with the release artifacts and mark
 ## Recovery
 
 - Plan generation fails: fix the named precondition, then regenerate the plan.
-- Planned changelog entry is missing or malformed: stop before plan generation and run the pre-tag `nemoclaw-contributor-update-docs` workflow. Use post-release recovery only when the tag already exists.
+- Documentation workflow state is incomplete: return to `nemoclaw-maintainer-evening`, then repeat
+  Step 1 after the documentation PR merges.
 - Full-mode E2E waits in the Launchable concurrency queue: keep the run pending until the earlier Launchable image-publication job finishes.
 - Full-mode E2E ran for another SHA: reject the run and dispatch full mode for the plan candidate SHA.
 - No qualifying `Release qualification` exists: inspect the GitHub result and run pre-tag E2E for the planned SHA only when no qualifying run already exists. Use a job waiver only with explicit repository administrator authorization. Do not release until the release script accepts the canonical check.