Keep wrapped editor rows inside their own box

.agents/skills/pull-request-writing/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: pull-request-writing
+description: "How to title and describe a DxMessaging pull request: short
+  Simplified Technical English, one idea per sentence, and a body that answers
+  why the problem mattered, what the change does, and how we know it is correct.
+  Bans jargon, filler, status narration, and session diaries. Use when opening
+  or editing a pull request, writing its title, rewriting a description a
+  reviewer found hard to read, or deciding what evidence belongs in the body."
+---
+
+<!-- Generated by `npm run llm:index`. Do not edit by hand. -->
+
+Canonical instructions: [`.llm/skills/pull-request-writing/SKILL.md`](../../../.llm/skills/pull-request-writing/SKILL.md)
+
+Read that file and follow it. Supporting detail is in the sibling `references/` directory.

.claude/skills/pull-request-writing/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: pull-request-writing
+description: "How to title and describe a DxMessaging pull request: short
+  Simplified Technical English, one idea per sentence, and a body that answers
+  why the problem mattered, what the change does, and how we know it is correct.
+  Bans jargon, filler, status narration, and session diaries. Use when opening
+  or editing a pull request, writing its title, rewriting a description a
+  reviewer found hard to read, or deciding what evidence belongs in the body."
+---
+
+<!-- Generated by `npm run llm:index`. Do not edit by hand. -->
+
+Canonical instructions: [`.llm/skills/pull-request-writing/SKILL.md`](../../../.llm/skills/pull-request-writing/SKILL.md)
+
+Read that file and follow it. Supporting detail is in the sibling `references/` directory.

.github/pull_request_template.md

@@ -1,12 +1,24 @@
-## Description
+<!--
+Keep this short. Write in plain, simple English: short sentences, common words,
+one idea per sentence. Aim for 200 words, stop at 400.
+Agents: follow .llm/skills/pull-request-writing/SKILL.md.
+-->
 
-<!-- Provide a clear and concise description of your changes -->
+## Why
 
-## Related Issue
+<!-- What went wrong for a user, or what they could not do. One short paragraph. -->
+
+## What changed
 
-<!-- Link to the issue this PR addresses -->
+<!-- What the code does now. A short list if there is more than one part. -->
+
+## How we know
+
+<!-- The test, the measurement, or the run that proves it. -->
+
+## Related Issue
 
-Fixes #
+Closes #
 
 ## Type of Change
 

.llm/context.md

@@ -17,9 +17,9 @@ discover it. `.llm/` is the single source of truth; the mirrors are generated po
 
 <!-- Generated by `npm run llm:index`. Do not edit by hand. -->
 
-31 skills are registered. See [the skill index](./index.md) for the full table.
+32 skills are registered. See [the skill index](./index.md) for the full table.
 
-`allocation-and-leak-coverage`, `api-design-patterns`, `benchmark-methodology`, `cache-eviction`, `changelog-management`, `collection-pooling`, `data-driven-tests`, `dispatch-hot-path`, `documentation-code-samples`, `documentation-style`, `github-access`, `github-workflow-consistency`, `il2cpp-build-configuration`, `markdown-authoring`, `memory-reclamation`, `object-pooling`, `package-publishing`, `serializable-dictionary`, `shell-and-powershell`, `singleton-patterns`, `test-code-quality`, `test-coverage-design`, `test-diagnostics`, `test-failure-investigation`, `test-fixtures-and-cleanup`, `unity-editor-ci`, `unity-editor-conventions`, `unity-licensing`, `unity-mcp-test-loop`, `unity-test-execution`, `value-equality-and-hashing`
+`allocation-and-leak-coverage`, `api-design-patterns`, `benchmark-methodology`, `cache-eviction`, `changelog-management`, `collection-pooling`, `data-driven-tests`, `dispatch-hot-path`, `documentation-code-samples`, `documentation-style`, `github-access`, `github-workflow-consistency`, `il2cpp-build-configuration`, `markdown-authoring`, `memory-reclamation`, `object-pooling`, `package-publishing`, `pull-request-writing`, `serializable-dictionary`, `shell-and-powershell`, `singleton-patterns`, `test-code-quality`, `test-coverage-design`, `test-diagnostics`, `test-failure-investigation`, `test-fixtures-and-cleanup`, `unity-editor-ci`, `unity-editor-conventions`, `unity-licensing`, `unity-mcp-test-loop`, `unity-test-execution`, `value-equality-and-hashing`
 
 <!-- END GENERATED SKILL REGISTRY -->
 
@@ -55,6 +55,9 @@ discover it. `.llm/` is the single source of truth; the mirrors are generated po
   checkout, commit, branch, fetch, rebase, and push operations. Use `gh` only as the final fallback
   when neither the connector nor `git` covers the required operation. Preserve this order.
 - Never commit repository settings that auto-approve chat-invoked terminal commands.
+- Write pull request titles and descriptions in short Simplified Technical English: say why the
+  problem mattered, what the change does, and how you know it is correct. No jargon, no filler, no
+  session diary. Follow [pull-request-writing](./skills/pull-request-writing/SKILL.md).
 - Ensure fenced markdown examples are closed and do not swallow real sections (for example `## See Also`).
 - Before committing, run the relevant formatters/linters yourself (`npm run format:check`, `npm run lint:markdown`, `npm run check:spelling`, `npm run validate:all` as applicable); hooks are the fast backstop, not the first signal.
 

.llm/index.json

@@ -1,5 +1,5 @@
 {
-  "skillCount": 31,
+  "skillCount": 32,
   "skills": [
     {
       "name": "allocation-and-leak-coverage",
@@ -293,6 +293,19 @@
         ".llm/skills/package-publishing/references/unity-analyzer-shipping.md"
       ]
     },
+    {
+      "name": "pull-request-writing",
+      "path": ".llm/skills/pull-request-writing/SKILL.md",
+      "description": "How to title and describe a DxMessaging pull request: short Simplified Technical English, one idea per sentence, and a body that answers why the problem mattered, what the change does, and how we know it is correct. Bans jargon, filler, status narration, and session diaries. Use when opening or editing a pull request, writing its title, rewriting a description a reviewer found hard to read, or deciding what evidence belongs in the body.",
+      "metadata": {
+        "category": "process",
+        "tags": "pull-request, writing, simplified-technical-english, ste, review, communication"
+      },
+      "lineCount": 97,
+      "references": [
+        ".llm/skills/pull-request-writing/references/pull-request-examples.md"
+      ]
+    },
     {
       "name": "serializable-dictionary",
       "path": ".llm/skills/serializable-dictionary/SKILL.md",
@@ -317,7 +330,7 @@
         "category": "scripting",
         "tags": "cross-platform, case-sensitivity, testing, powershell, javascript, ci-cd, linux, windows, macos"
       },
-      "lineCount": 124,
+      "lineCount": 128,
       "references": [
         ".llm/skills/shell-and-powershell/references/cross-platform-compatibility.md",
         ".llm/skills/shell-and-powershell/references/powershell-best-practices-part-1.md",

.llm/index.md

@@ -2,7 +2,7 @@
 
 <!-- Generated by `npm run llm:index`. Do not edit by hand. -->
 
-31 skills. Each is an [Agent Skills](https://agentskills.io/specification)
+32 skills. Each is an [Agent Skills](https://agentskills.io/specification)
 directory: `SKILL.md` holds the instructions, `references/` holds supporting detail loaded on demand.
 
 | Skill | References | Description |
@@ -24,6 +24,7 @@ directory: `SKILL.md` holds the instructions, `references/` holds supporting det
 | [memory-reclamation](./skills/memory-reclamation/SKILL.md) | 3 | How DxMessaging reclaims empty per-type and per-InstanceId slots through counter-based idle sweeps, IMessageBus.Trim, and DxPools caps, plus the test and documentation duties for any new memory holder. Use when adding a MessageCache field, a dictionary or pool keyed by message type or InstanceId, when slot counts or memory grow over a long session, or when changing DxMessagingRuntimeSettings eviction and buffer settings. |
 | [object-pooling](./skills/object-pooling/SKILL.md) | 6 | Reuse pooled message objects through Rent/Return instead of allocating a new instance per emit, so dispatch stays allocation-free. Use when adding a message type, seeing GC spikes or a rising allocation rate in the Unity profiler, writing an allocation test, or choosing between a pooled class message and a readonly struct message. |
 | [package-publishing](./skills/package-publishing/SKILL.md) | 3 | Controlling what ships in the com.wallstop-studios.dxmessaging npm/UPM package: the package.json files allowlist versus .npmignore exclusions, Unity .meta pairing rules for every shipped file and directory, the issue #204 tarball invariants verified against npm pack --json --dry-run, and where RoslynAnalyzer-labeled DLLs must live (Runtime/Analyzers/, never an editor-only asmdef) so the source generator reaches Assembly-CSharp. Use when adding or excluding files from the package, adding a new output directory, seeing CS0315/CS0452 on consumer [Dx*Message] types, or building and verifying the analyzer payload. |
+| [pull-request-writing](./skills/pull-request-writing/SKILL.md) | 1 | How to title and describe a DxMessaging pull request: short Simplified Technical English, one idea per sentence, and a body that answers why the problem mattered, what the change does, and how we know it is correct. Bans jargon, filler, status narration, and session diaries. Use when opening or editing a pull request, writing its title, rewriting a description a reviewer found hard to read, or deciding what evidence belongs in the body. |
 | [serializable-dictionary](./skills/serializable-dictionary/SKILL.md) | 4 | Back a runtime Dictionary with parallel SerializeField lists through ISerializationCallbackReceiver so key/value config is editable in the Unity Inspector and persists in scenes, prefabs, and ScriptableObjects. Use when a SerializeField Dictionary silently stays empty, when parallel key/value lists are drifting out of sync, or when a designer needs to edit a lookup table in the Inspector. |
 | [shell-and-powershell](./skills/shell-and-powershell/SKILL.md) | 9 | Writing bash and PowerShell that survives CI: set -e error handling for grep/diff/rm, quoting, filename case sensitivity on Linux runners, the PowerShell StrictMode 0/1/many gotcha that requires @()-wrapping every captured result before reading .Count or indexing, here-string quoting, WriteAllText encoding, regex non-greedy versus character-class exclusion, accurate regex comments for the g/i/m/s/u flags, Windows PE-binary stub requirements, cross-drive path containment, and tar archive operands. Use when adding or editing a .sh, .ps1, or Node script, or when a script passes locally and fails on a Linux or Windows runner. |
 | [singleton-patterns](./skills/singleton-patterns/SKILL.md) | 5 | Implement Unity global managers with RuntimeSingleton<T> for MonoBehaviours that survive scene loads and ScriptableObjectSingleton<T> for Resources-backed config assets, including duplicate handling and quit-time safety. Use when writing a GameManager or AudioManager, when a static Instance field is null after a scene change or on quit, when two copies of a manager exist, or when bootstrapping a manager before the first scene. |

.llm/skills/pull-request-writing/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: pull-request-writing
+description: "How to title and describe a DxMessaging pull request: short Simplified Technical English, one idea per sentence, and a body that answers why the problem mattered, what the change does, and how we know it is correct. Bans jargon, filler, status narration, and session diaries. Use when opening or editing a pull request, writing its title, rewriting a description a reviewer found hard to read, or deciding what evidence belongs in the body."
+metadata:
+  category: "process"
+  tags: "pull-request, writing, simplified-technical-english, ste, review, communication"
+---
+
+# Pull Request Writing
+
+A pull request is read by a person who was not in the session. They read the title in a list of
+titles, and the body once, to decide whether to trust the change. Write for that reader.
+
+The whole body is written in Simplified Technical English (STE): short sentences, common words,
+one idea per sentence, active voice.
+
+## When to use
+
+- Opening a pull request, or editing its title or description.
+- A reviewer says a description is long, unclear, or hard to follow.
+- Deciding which measurements, tables, or logs belong in the body.
+- Writing the pull request that closes several issues at once.
+
+## Rules
+
+### Title
+
+- One line, at most 72 characters, plain sentence case.
+- Say what the change does, in the words a user would use. Not the mechanism.
+- Start with a verb: `Fix`, `Add`, `Remove`, `Speed up`, `Stop`.
+- No conventional-commit prefixes, no issue numbers, no branch names, no "and" chains that
+  join three unrelated things. If the title needs three clauses, lead with the one a reader
+  cares about most and let the body carry the rest.
+
+Good: `Keep wrapped Flow Graph rows inside their own box`
+Bad: `fix(editor): DxMessagingFlowGraphWindow flexWrap container height resolution on 2021.3`
+
+### Body shape
+
+Three short sections, in this order, and nothing else by default:
+
+1. **Why** - what went wrong for a user, or what they could not do. One short paragraph.
+1. **What changed** - what the code does now. A short list if there is more than one part.
+1. **How we know** - the test, the measurement, or the run that proves it.
+
+Add a `Closes #NNN` line for each issue the change closes. Add a fourth section only when the
+change leaves something open that a reader must know about.
+
+### Length
+
+- Aim for 200 words per block. Stop at 400.
+- A pull request closing several issues has one `Why / What changed / How we know` block per
+  issue, so it is longer overall. The ceiling is per block, not per page. It still does not get a
+  preamble.
+- Move deep evidence to the issue or to a `progress/` record and link it. The body carries the
+  verdict, not the working.
+
+### Simplified Technical English
+
+- One idea per sentence. Under 20 words.
+- Active voice, present tense: "The row now grows", not "The row will have been grown".
+- One word per meaning. Pick `fix` or `repair`, not both, and use it everywhere.
+- Use the plainest word that is still exact: `use` not `utilize`, `so` not `hence`, `before`
+  not `prior to`, `now` not `at this time`.
+- Expand an abbreviation on first use unless it names a file, a type, or a workflow.
+- No nested clauses, no dashes carrying a second thought, no sentence that needs re-reading.
+- ASCII only, exactly as in [documentation-style](../documentation-style/SKILL.md).
+
+### Banned
+
+- Filler and marketing: `comprehensive`, `robust`, `seamless`, `leverage`, `delve`, `simply`,
+  `just`, `note that`, `it is worth noting`.
+- Status narration: `As requested`, `Per the previous session`, `This PR does the following`.
+- Session diaries: what was tried and rejected, how long something took, which agent did what.
+  A rejected approach belongs in the issue only when the next person would otherwise retry it.
+- Restating the diff. The file list is already on the page.
+- Emoji, headings deeper than `###`, and tables with one row.
+
+## Verification
+
+Before you open or update the pull request, read the title and body once as a stranger:
+
+- Does the title alone say what changed?
+- Does the body say why it mattered before it says what you did?
+- Is there a sentence over 20 words, or a word a new contributor would look up?
+- Is there a claim with no evidence behind it?
+
+Fix what fails. Do not add words to fix it.
+
+## See Also
+
+- [Pull Request Examples](./references/pull-request-examples.md) - a rewrite, an issue-closing
+  body, and the fourth-section case.
+- [documentation-style](../documentation-style/SKILL.md) - the ASCII and banned-phrase rules
+  this skill inherits.
+- [changelog-management](../changelog-management/SKILL.md) - what the same change owes
+  `CHANGELOG.md`, which is written for users, not reviewers.