docs: pin PageSection ownership to the nav-header sibling, capture three items

.claude/skills/issues/SKILL.md

@@ -32,6 +32,16 @@ If a filter is given, filter the open items before rendering steps 2–3, then s
 queued tasks and matching non-queued items: `/issues P1` (by priority), `/issues issues` /
 `/issues recs` / `/issues tasks` (by type), `/issues <keyword>` (summary/detail substring match).
 
+**A row being open is not evidence that nobody is working on it.** Some rows carry a progress marker
+in their prose (`IN PROGRESS`, `IMPLEMENTED in PR #1766`), but there is no structured status field and
+no atomic claim — a marker is written by whoever did the work, usually after the fact, and nothing
+requires or checks one, so its absence means nothing. Two sessions can therefore read the same queued
+item and both build it (PR #1766 and the duplicate PR #1767, four hours apart, 2026-08-09). Before _acting_ on a queued
+item — not before merely reading the list back — check the open PRs for the route, component, or
+surface it touches, since a duplicate PR will rarely quote the ledger id. See the `newtask` skill's
+"Before you start", which makes this the same GitHub read it already does for PR bundling. A plain
+read-only `/issues` needs no such check. Recorded as `#292`.
+
 ## Mutating subcommands
 
 Parse the intent from natural language too — the exact syntax is a convenience, not a requirement.

.claude/skills/newtask/SKILL.md

@@ -17,6 +17,22 @@ one-task-one-PR churn)". Only proceed to the steps below (which create a new bra
 worktree) once bundling doesn't apply: the work isn't independently low-risk by that
 rule's test, or there's no suitable open PR to ride.
 
+**Ask that same open-PR list a second question: is someone already building this?** Some
+ledger rows carry a progress marker in their prose (`IN PROGRESS`, `IMPLEMENTED in PR
+#1766`), but there is no structured status field and no atomic claim — a marker is written
+by whoever did the work, usually after the fact, and nothing requires or checks one, so its
+absence means nothing. Two sessions can read the same queued `/issues` item and both build
+it. That is not hypothetical — on
+2026-08-09 two assistants took the same queued item about four hours apart and shipped the
+same conversion twice (PR #1766, and PR #1767 closed as a duplicate), which also left two
+divergent shapes to adjudicate afterwards. Before starting a queued item, scan the open PRs
+for the **route, component, or surface** it touches, not just for a matching ledger id — the
+duplicate PR will rarely quote the id. If you find one, stop and reconcile with it rather
+than opening a second branch. This is one GitHub read (`mcp__github__list_pull_requests`, or
+`gh pr list` where available) and it falls inside the existing provider-confirmation
+boundary. If GitHub is unreachable, treat it as a warning and continue — an offline session
+must still be able to start work. Recorded as `#292`.
+
 ## Steps
 
 1. **Sync main.** `git fetch --quiet origin main`.

AGENTS.md

@@ -848,6 +848,16 @@ to the recommended queue.
   `docs/outstanding-issues.md` (no push unless the user asks or you are already handing off).
 - Proactively offer to `capture` unresolved follow-ups, deferrals, and known risks into the ledger
   before a session's context is lost — that is what keeps it a memory rather than a stale list.
+- **An open row is not evidence that nobody is building it.** Some rows do carry a progress marker in
+  their prose (`IN PROGRESS`, `IMPLEMENTED in PR #1766`), but there is no structured status field and
+  no atomic claim: a marker is written by whoever did the work, usually after the fact, and nothing
+  requires or checks one. Absence of a marker therefore means nothing.
+  So before _acting_ on a queued item (not before reading the list back), check the open PRs for the
+  route, component, or surface it touches — a duplicate PR will rarely quote the ledger id. Skipping
+  this shipped the same conversion twice on 2026-08-09: PR #1766, and PR #1767 closed as a duplicate,
+  four hours apart, leaving two divergent shapes to adjudicate. It is one GitHub read and falls under
+  the provider-confirmation boundary above; if GitHub is unreachable, warn and continue rather than
+  blocking an offline session. Tracked as `#292`.
 - A `SessionStart` hook (`.claude/hooks/issues-surface.sh`, wired in `.claude/settings.json`)
   auto-surfaces the recommended queue plus open-item counts at the start of every session and, on a
   context reset (`compact`/`resume`/`clear`), nudges a `/issues capture`. It is read-only — it never