docs(contributing): share permanent writing guide

.agents/skills/_shared/pr-follow-up.md

@@ -32,9 +32,8 @@ gh api "repos/NVIDIA/NemoClaw/pulls/${PR_NUMBER}/comments" --paginate \
 
 ## Handle results
 
-- Apply [NemoClaw Technical English](../../../CONTRIBUTING.md#nemoclaw-technical-english) to review comments and proposed rewrites.
-- During the changed-text pilot, block on language only when ambiguity can change behavior, security, data safety, test meaning, or release meaning.
-- Treat other language findings as suggestions. Include a proposed rewrite and do not request unrelated cleanup.
+- Follow the [NemoClaw Writing Guide](../../../WRITING.md) for review comments and proposed rewrites.
+- The guide defines which language findings can block and how to write a suggestion.
 - Before you act on feedback, state the problem and the intended result.
 - Do not add a helper, configuration switch, fallback, migration, or compatibility path only to satisfy reviewer wording.
 - Treat feedback as a suggestion if you cannot connect it to one of these conditions:

.agents/skills/nemoclaw-contributor-create-pr/SKILL.md

@@ -183,8 +183,7 @@ If an issue exists, use `Fixes #NNN` or `Closes #NNN`.
 Read the PR template from the trusted base branch. Use it as the source of truth.
 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.
-Apply [NemoClaw Technical English](../../../CONTRIBUTING.md#nemoclaw-technical-english) to the PR body and other explanatory text that this workflow changes.
-During the changed-text pilot, do not add unrelated prose cleanup to the PR.
+Follow the [NemoClaw Writing Guide](../../../WRITING.md) for the PR body and other explanatory text that this workflow changes.
 
 Complete each section from the diff against the same base ref.
 Select the applicable boxes and leave the other boxes clear.

.agents/skills/nemoclaw-contributor-update-docs/SKILL.md

@@ -148,8 +148,7 @@ Identify where the new content should go. Follow the page's existing structure.
 
 Before writing, verify that the commit was not excluded in Step 1. Do not draft content for commits matched by the skip list or for agent integrations not in the tested agent support matrix. After drafting, scan the content for any `skip-terms` from `docs/.docs-skip`. Remove any sentence or section that contains a skip-term. If in doubt, skip the commit and report it.
 
-Apply [NemoClaw Technical English](../../../CONTRIBUTING.md#nemoclaw-technical-english) to changed documentation and changelog text.
-During the changed-text pilot, do not rewrite unrelated prose.
+Follow the [NemoClaw Writing Guide](../../../WRITING.md) for changed documentation and changelog text.
 
 Write the doc update following these conventions:
 

.agents/skills/nemoclaw-maintainer-day/PR-REVIEW-PRIORITIES.md

@@ -27,9 +27,8 @@ Read its comment and verify each claim against code, tests, and workflow evidenc
 Apply a confirmed problem to the related gate. Ask the user about ambiguous or design-changing advice.
 Advisor labels, absence, and comment source do not affect `check-gates.ts` or `allPass`.
 
-Apply [NemoClaw Technical English](../../../CONTRIBUTING.md#nemoclaw-technical-english) to changed comments, test titles, PR discussion, changelog entries, and Announcements.
-During the changed-text pilot, a language finding blocks only when ambiguity can change behavior, security, data safety, test meaning, or release meaning.
-Treat other findings as suggestions and include a proposed rewrite.
+Follow the [NemoClaw Writing Guide](../../../WRITING.md) for changed comments, test titles, PR discussion, changelog entries, and Announcements.
+The guide defines which language findings can block and how to write a suggestion.
 
 ## Quality expectations (block if violated, but fixable via salvage)
 
@@ -67,7 +66,7 @@ Delete the released label when no open item has it. Do not rename or reuse it.
 ## Not priorities
 
 - **Code style and formatting** — Do not block or delay a PR for style. Do not change unrelated formatting.
-- **Unrelated language cleanup** — Do not expand the PR beyond changed text during the technical-English pilot.
+- **Unrelated language cleanup** — Do not expand the PR beyond changed text.
 - **Documentation completeness** — not required for approval unless the PR changes user-facing behavior.
 - **Architecture style** — Reduce future merge conflicts. Do not add style-only refactors.
 

.agents/skills/nemoclaw-maintainer-policies/SKILL.md

@@ -30,7 +30,7 @@ This package contains policy references. This file is its manifest and index.
 Read the related reference before you answer or apply policy.
 Use plain language for maintainers. Distinguish Issue Type, PR type labels, `needs:*` labels, Project fields, close reasons, and release labels.
 Do not invent labels, statuses, fields, release labels, or workflow states.
-Apply [NemoClaw Technical English](../../../CONTRIBUTING.md#nemoclaw-technical-english) to changed workflow guidance and maintainer-facing text.
+Follow the [NemoClaw Writing Guide](../../../WRITING.md) for changed workflow guidance and maintainer-facing text.
 
 For agent implementation, use `triage-instructions.md` as the payload contract.
 Use `label-taxonomy.json` to validate allowed values.

.agents/skills/nemoclaw-maintainer-release-notes/SKILL.md

@@ -17,9 +17,9 @@ Draft the post-tag NemoClaw Announcement from GitHub tag and compare data. The h
 - external-only contributor thanks,
 - visible `#NNNN` GitHub links.
 
-Apply [NemoClaw Technical English](../../../CONTRIBUTING.md#nemoclaw-technical-english) to new or modified Announcement text.
+Follow the [NemoClaw Writing Guide](../../../WRITING.md) for new or modified Announcement text.
 State the changed behavior, affected users, and required action when one exists.
-During the changed-text pilot, do not rewrite unrelated historical release text.
+Do not rewrite unrelated historical release text.
 
 Create a local Markdown draft. Do not create or update a GitHub Discussion; the maintainer posts the announcement manually.
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,6 @@
 <!-- markdownlint-disable MD041 -->
 ## Summary
-<!-- 1-3 plain sentences: what changes and why. Describe before-and-after behavior when it applies. Use the NemoClaw Technical English profile: https://github.com/NVIDIA/NemoClaw/blob/main/CONTRIBUTING.md#nemoclaw-technical-english. During the changed-text pilot, do not expand this PR to clean up unrelated prose. -->
+<!-- 1-3 plain sentences: what changes and why. Describe before-and-after behavior when it applies. Follow the NemoClaw Writing Guide: https://github.com/NVIDIA/NemoClaw/blob/main/WRITING.md. Do not add unrelated prose cleanup. -->
 
 ## Related Issue
 <!-- Fixes #NNN or Closes #NNN. Remove this section if none. -->

AGENTS.md

@@ -198,8 +198,8 @@ All hooks managed by [prek](https://prek.j178.dev/) (installed via `npm install`
 - Use existing repository vocabulary and name what a thing does.
 - Remove modifiers that do not distinguish a real current case.
 - Use one name for one concept across issues, code, workflows, checks, logs, tests, and docs.
-- Apply [NemoClaw Technical English](CONTRIBUTING.md#nemoclaw-technical-english) to changed comments, test titles, PR text, changelog entries, Announcements, and agent guidance.
-- During the 30-day changed-text pilot, treat language findings as suggestions unless ambiguity can change behavior, security, data safety, test meaning, or release meaning. Do not request unrelated language cleanup.
+- Follow the [NemoClaw Writing Guide](WRITING.md) for changed comments, test titles, PR text, changelog entries, Announcements, and agent guidance.
+  The guide defines the review scope and the conditions that make a language finding blocking.
 - Do not turn one case into a system of categories or a new abstraction.
 - Do not add configuration, fallback, migration, compatibility, or extension layers without a current requirement. Name the current consumer and the test that protects the contract.
 - Report conclusions and evidence, not an analysis transcript.

CONTRIBUTING.md

@@ -62,106 +62,10 @@ outcome, the smallest change, and how it was verified. Explore alternatives only
 change behavior, security, data safety, or a supported contract. Once the smallest safe change is
 clear and testable, stop exploring and implement it.
 
-### NemoClaw Technical English
-
-NemoClaw uses a technical-English profile based on
-[ASD-STE100 Issue 9](https://www.asd-ste100.org/assets/files/ASD-STE100_ISSUE9.pdf).
-The profile applies its plain-language principles to software engineering.
-The project does not claim full ASD-STE100 compliance.
-
-Use repository terms, software identifiers, API names, and necessary domain terms as technical
-nouns or technical verbs. Do not copy the ASD-STE100 dictionary or its examples into this
-repository. Use the rules and examples below as the NemoClaw source of truth.
-
-#### Writing rules
-
-1. Use one term for one concept. Do not use synonyms to add variety.
-2. Use a term with one meaning in a given context.
-3. Use the shortest familiar term that preserves the technical meaning.
-4. Name the actor when known. Use passive voice only when the actor is unknown or does not matter.
-5. Put one instruction in each sentence. Split actions that occur at different times.
-6. Keep instructions at 20 words or fewer when possible. Keep descriptions at 25 words or fewer when possible.
-7. State a condition before the action that depends on it.
-8. Use `must` for a requirement, `may` for permission, `can` for capability, and `should` for a recommendation.
-9. Name the object of relative terms such as `current`, `latest`, `previous`, and `next`.
-10. Replace `ready`, `clean`, `safe`, `small`, and similar judgments with the condition that makes them true.
-11. Remove `just`, `simply`, `obviously`, `clearly`, `easy`, `robust`, and other words that do not change the meaning.
-12. Avoid an idiom or phrasal verb that can have more than one meaning. Use a direct technical term when one is available.
-13. Use a vertical list for three or more conditions, actions, or results.
-14. In a code comment, explain a constraint, invariant, or reason that the code does not show. Do not restate the code.
-
-Sentence lengths are review targets, not mechanical limits. Do not make a sentence less accurate to
-meet a word count. Quoted user text, external text, code, identifiers, commands, URLs, and generated
-content are outside the word and sentence rules.
-
-#### Project word list
-
-Use these terms consistently:
-
-| Term | Meaning | Avoid |
-|---|---|---|
-| PR SHA | The PR-branch commit that the evidence covers. Use its short SHA in reports. Use the full SHA only when a command or API requires it. | relative revision terms without a SHA |
-| base SHA | The target-branch commit used to evaluate the PR. | current base without a SHA |
-| required check | A named GitHub check required by repository policy. | CI gate when no check is named |
-| passing | A command exited with status 0, or a check concluded with `SUCCESS`. | green when the result is not named |
-| approval-ready | All product, contributor, CI, merge-state, review, and test gates pass. | ready, good to go |
-| blocked | A named decision, dependency, access problem, or input prevents progress. | stuck, cannot proceed without a reason |
-| advisory | Information that does not change a gate, approval, or merge state. | warning when no risk requires attention |
-| changed text | Explanatory text added or modified by the diff. | the whole file when unchanged text is out of scope |
-| user-visible change | A change to a command, output, configuration, workflow, or supported behavior. | improvement without the changed behavior |
-| release entry | The dated `docs/changelog/YYYY-MM-DD.mdx` record created before the tag. | release notes when the dated entry is intended |
-| Announcement | The post-tag release communication. | release entry |
-
-Use a different term only when it identifies a different concept. Define that difference where the
-term first appears.
-
-#### Rewrite examples
-
-These examples use recurring NemoClaw concepts. They show the required level of precision.
-
-| Surface | Avoid | Use |
-|---|---|---|
-| Code comment | `// Handle edge case.` | `// GitHub omits headRepository after a fork is deleted.` |
-| Code comment | `// This is needed for safety.` | `// Reject private IP targets to prevent SSRF.` |
-| Code comment | `// Keep this in sync.` | `// This list must match requiredChecks in check-gates.ts.` |
-| Code comment | `// Use the latest state.` | `// Read headRefOid again before approval.` |
-| Code comment | `// Work around a GitHub issue.` | `// GitHub can return no PR association for a deleted fork repository.` |
-| Test title | `handles invalid config correctly` | `rejects a config that has no provider` |
-| Test title | `works after retry` | `retries evidence download after child cancellation` |
-| Test title | `covers edge cases (#1234)` | `rejects an empty policy name (#1234)` |
-| Test title | `fixes issue #1234` | `preserves credentials when a sandbox rebuilds (#1234)` |
-| Test title | `does the right thing for forks` | `does not expose repository secrets to fork code` |
-| PR discussion | `This seems brittle.` | `This catch block hides EACCES. Callers then treat denied access as missing state.` |
-| PR discussion | `Can we clean this up?` | `These two parsers implement the same policy. Use parsePolicy in both call sites.` |
-| PR discussion | `Make this more robust.` | `Return a typed access error for EACCES and add a denial-path test.` |
-| PR discussion | `This is a small change.` | `This change updates one parser and does not change the policy schema.` |
-| PR discussion | `The PR is ready.` | `Required checks pass on 1a2b3c4, and GitHub reports MERGEABLE.` |
-| Announcement | `Improved onboarding.` | `Onboarding now resumes after provider selection fails.` |
-| Announcement | `Added more robust E2E handling.` | `The PR gate now retries evidence download after a child run is cancelled.` |
-| Release entry | `Fixed various issues.` | `The CLI now rejects a provider configuration that has no endpoint.` |
-| Release entry | `Better error handling.` | `The CLI now reports the provider authentication error without a stack trace.` |
-| Procedure | `Refresh and rerun as needed.` | `Fetch origin/main. Rerun the gate after the PR SHA changes.` |
-
-#### Changed-text pilot
-
-The pilot begins when the PR that adds this section merges. It ends 30 calendar days later.
-Use the GitHub merge time as the time source. During the pilot, apply the profile to changed text only:
-
-- Added or modified code comments.
-- Added or modified test titles.
-- PR descriptions and new review comments.
-- New or modified changelog entries and Announcements.
-- Added or modified contributor guidance, agent guidance, and user documentation.
-
-Do not request unrelated language cleanup in a feature, fix, or release PR. Put existing language
-debt in a focused follow-up PR.
-
-During the pilot, language findings are non-blocking suggestions unless the ambiguity can change
-behavior, security, data safety, test meaning, or release meaning. A blocking comment must name that
-effect. A suggestion should include a proposed rewrite.
-
-At the end of the pilot, maintainers should review accepted suggestions, rejected suggestions, and
-false positives before they add an automated check or make a language rule blocking.
+### Writing Guide
+
+Follow the [NemoClaw Writing Guide](WRITING.md) when you add or modify explanatory text.
+The guide defines its scope, terms, rules, examples, and review policy.
 
 ## Before You Open an Issue
 
@@ -402,10 +306,10 @@ issue references in a final suffix such as `(#1234)`. Prefer
 `it("reticulates splines for valid control points (#1234)")` over
 `it("#1234 fixes spline reticulation")`.
 
-Apply the [NemoClaw Technical English](#nemoclaw-technical-english) profile to each added or modified
-test title. During the changed-text pilot, the title checker continues to enforce objective title
-shape only. A language finding can block when ambiguity changes the test meaning. Other findings are
-suggestions. Reviewers must not request unrelated title cleanup.
+Apply the [NemoClaw Writing Guide](WRITING.md) to each added or modified test title.
+The title checker enforces objective title shape only. A language finding can block when ambiguity
+changes the test meaning. Other findings are suggestions. Reviewers must not request unrelated title
+cleanup.
 
 Run `npm run test:spec` to render the suite with Vitest's hierarchical tree reporter. Run
 `npm run test:titles:check` to enforce the objective title-shape conventions without attempting to