chore(claude): build one target and shorten PR bodies in the pr skill (#28382)

Building both a board and SITL for every PR wastes minutes on changes that
cannot reach either target. Build the one target the diff can affect, or
none. Descriptions get read only if they are short, so cap them at a
sentence or two per section and drop the CI boilerplate.

Assisted-by: Claude:claude-opus-5[1m]

Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>

.claude/skills/pr/SKILL.md

@@ -17,14 +17,23 @@ the PR body.**
    where `<username>` comes from `gh api user --jq .login`.
 2. Gather context: `git status`, `git log --oneline main..HEAD`,
    `git diff main...HEAD --stat`, check for remote tracking branch.
-3. Sanity-build the targets we care about. Fix any build errors before opening
-   the PR:
-   - `make px4_fmu-v6x` — hardware target
-   - `make px4_sitl` — simulation
+3. Sanity-build **one** target the change can actually affect — a board for
+   firmware changes, `px4_sitl` for POSIX-only or simulation changes. Skip the
+   build entirely when the diff cannot reach any target (submodule pointer
+   bumps, docs, ROMFS). Fix any build errors before opening the PR.
 4. PR **title:** `type(scope): description` — under 72 chars, covers the
    overall change across all commits. This becomes the squash-merge commit
    message.
-5. PR **body:** concise and terse — do not restate what the diff already shows (no file-changed lists, no code snippets that reproduce the diff). Use exactly three sections, in order: `## Summary`, `## Problem`, `## Solution`. If the PR closes a GitHub issue, the first line of `## Summary` must be `fixes #<N>`, then a blank line, then the summary text. No `## Test plan` section, no boilerplate, no Claude attribution. Use markdown (links, code blocks, lists) only when warranted. Never state testing that did not happen: ask the user what they actually ran beyond the builds in step 3, report exactly that, and say so plainly when something is untested.
+5. PR **body:** as short as it can be while still landing the point — a
+   reviewer should take it in at a glance, and a long description is one
+   nobody reads. Exactly three sections, in order: `## Summary`, `## Problem`,
+   `## Solution`, a sentence or two each. Do not restate the diff (no
+   file-changed lists, no code snippets), do not mention CI, and do not repeat
+   what the title already says. If the PR closes an issue, the first line of
+   `## Summary` is `fixes #<N>`, then a blank line, then the summary. No
+   `## Test plan` section, no boilerplate, no Claude attribution. Never state
+   testing that did not happen: ask the user what they actually ran, report
+   exactly that, and say plainly when something is untested.
 
 6. Push with `-u` if needed, then `gh pr create`. Default base is `main`
    unless user says otherwise.