Check open PRs for in-progress drafts before scaffolding a new skill/agent

[d-morrison]

Summary

• skill-builder and agent-builder already scan local branches and worktrees for in-flight duplicate work, but that scan misses a branch already pushed and opened as a PR (it's never fetched into local refs).
• Adds a new shared fragment, shared/workflow/check-open-prs-before-duplicating.md, spelling out an open-PR check (gh pr list / mcp__github__list_pull_requests) and what to do when a match is found: pick up a stalled draft, or redirect the caller to an active one instead of building a competing second draft.
• Wires the fragment into skill-builder's and agent-builder's step 0 (extend/reuse-before-create), their frontmatter descriptions, and their anti-patterns lists.
• spot-skill-opportunities's existing-coverage check now also names the open-PR case, pointing to the same fragment, without duplicating the full procedure (it still hands off the actual check to skill-builder/agent-builder).

Test plan

• Reviewed the new fragment against the existing branch/worktree-scan style in skill-builder step 0 for consistency.
• Confirmed the gh pr list / MCP fallback mapping (LIST_PRS) already exists in tool-mappings.md.
• Verified relative markdown-link paths (../../shared/workflow/...) match the convention used elsewhere in skills/*/SKILL.md.

🤖 Generated with Claude Code

---

Generated by Claude Code

[claude]

mcp__github__search_pull_requests is referenced here but is not registered in tool-mappings.md or tool-mappings.yml — only mcp__github__list_pull_requests is (as LIST_PRS). The "see tool-mappings.md" pointer is accurate for mcp__github__list_pull_requests but misleading for mcp__github__search_pull_requests: a reader who looks there won't find it.

This also violates skill-builder's own standing convention (skills/skill-builder/SKILL.md:136–144):

If the procedure names a GitHub MCP tool … not already in tool-mappings.yml … add it there.

(The same anti-pattern is listed at line 286 of that skill: "Naming a GitHub MCP tool the skill uses without registering it in tool-mappings.yml.")

The tool is real — it already appears in skills/gi/SKILL.md:209, skills/gip/SKILL.md:58, and memories/tools.md:148 — so this isn't a hallucination, just an incomplete registration.

Suggested fix: add an entry to tool-mappings.yml (and the table in tool-mappings.md) for mcp__github__search_pull_requests, e.g.:

- id: SEARCH_PRS
  description: Search pull requests by keyword / query string.
  cli: gh pr list --search "<query>"
  github_mcp: mcp__github__search_pull_requests

Then regenerate the Codex wrappers so the new op appears in the tool-mapping tables of codex-skills/skill-builder/SKILL.md and codex-skills/agent-builder/SKILL.md.

[claude]

Claude finished @d-morrison's task in 1m 36s —— View job

---

Re-review of PR #348

• Update comment with in-progress status
• Read key changed files (tool-mappings, new fragment, wired skills)
• Verify prior finding is addressed
• Check for new issues
• Post verdict

---

Verdict: clean

The one finding from the prior review — mcp__github__search_pull_requests unregistered in tool-mappings — is fully resolved by commit 7bacd2b:

• tool-mappings.yml lines 44–47: SEARCH_PRS entry added.
• tool-mappings.md line 26: the generated table row appears.
• codex-skills/skill-builder/SKILL.md and codex-skills/agent-builder/SKILL.md line 31: the SEARCH_PRS row is present in the embedded tool-mapping tables.

No new issues found. The new fragment, its wiring into all three skills, and the full Codex wrapper regeneration are all structurally sound.