Add duplicate-check step to create-issue skill

The skill ran straight from template choice to filing, so a new issue
duplicating an open one slipped through unless a human happened to ask
(as with the docs-spec finding that duplicated #2 during PR #4).

Add a search step ahead of drafting: search all issues by keyword, judge
by the work rather than a shared topic, and get explicit confirmation
before filing over a known potential duplicate. Sync the phase-listing
pointers in AGENTS.md and CONTRIBUTING.md and the skill description so
none drift.

Closes #19

Author: jeffhorn-nava

AGENTS.md

@@ -93,7 +93,7 @@ Use the template that best fits the work; GitHub surfaces these on new-issue.
 For `technical-task.md`, fill "Starting point" and "Constraints and gotchas" thoroughly; those are
 what an agent or new developer needs to pick up work cold.
 
-The `create-issue` skill guides choosing the template, wording, labeling, reviewing, and filing.
+The `create-issue` skill guides checking for duplicates, choosing the template, wording, labeling, reviewing, and filing.
 
 ## Architecture and CI
 

CONTRIBUTING.md

@@ -5,8 +5,9 @@
 The short version of how a change moves through this repo:
 
 1. **Start from an issue.** File one with the template that fits the work (epic, story, bug,
-   technical-task, spike, or chore). The `create-issue` skill walks you through choosing a template,
-   wording it for its audience, reviewing it, labeling it, and filing it.
+   technical-task, spike, or chore). The `create-issue` skill walks you through checking for
+   duplicates, choosing a template, wording it for its audience, reviewing it, labeling it, and
+   filing it.
 2. **Branch.** Use the naming shape in [Branching](#branching) below.
 3. **Make your changes.** Keep commits terse and explain why, not what. Wire up the commit template
    (see [Commit message template](#commit-message-template)).

skills/create-issue/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: create-issue
-description: Guides filing a new GitHub issue: picks the right template, writes it in the right register, applies the matching label, reviews the draft, and files it. Use when opening a new issue for this repo.
+description: Guides filing a new GitHub issue: checks for duplicates, picks the right template, writes it in the right register, applies the matching label, reviews the draft, and files it. Use when opening a new issue for this repo.
 ---
 
 # Create Issue
@@ -16,7 +16,39 @@ sure which template fits or how technical the wording should be.
 
 ## Steps
 
-### 1. Choose the template
+### 1. Check for duplicates
+
+Before choosing a template or writing anything, search existing issues for one that already tracks
+this work. Search open and closed together, since a `wontfix` or already-closed duplicate changes
+whether to file at all:
+
+```bash
+gh issue list --repo navapbc/strata-documentation-engine --state all --search "<keywords>"
+```
+
+GitHub numbers issues and PRs together, so `--state all` surfaces PRs too; a PR may already be doing
+the work.
+
+Judge by the work, not the topic: two issues that merely mention the same subject are not
+duplicates. A duplicate tracks the same change or investigation. Then:
+
+- **A near-duplicate is open** → comment on or update it instead of filing, and stop here.
+- **A new issue is still warranted** → proceed, and note in the body why it is not a duplicate of the
+  ones you found (link them).
+- **You still intend to file over a plausible duplicate** → surface it to the person at the keyboard
+  and get their explicit confirmation before continuing. Never file silently over a known potential
+  duplicate.
+
+When resolving this means closing an issue as a duplicate of another, close it with the `duplicate`
+label:
+
+```bash
+gh issue close <n> --repo navapbc/strata-documentation-engine --reason "not planned" \
+  --comment "Duplicate of #<m>."
+gh issue edit <n> --repo navapbc/strata-documentation-engine --add-label duplicate
+```
+
+### 2. Choose the template
 
 Pick the template that matches the work. Templates live in `.github/ISSUE_TEMPLATE/`.
 
@@ -32,7 +64,7 @@ Pick the template that matches the work. Templates live in `.github/ISSUE_TEMPLA
 If two seem to fit, prefer the less technical one for anything a non-engineer might file (`story`
 over `technical-task`, `bug` over `technical-task`).
 
-### 2. Write in the right register
+### 3. Write in the right register
 
 - **Product templates** (`epic`, `story`): plain, outcome-oriented language. Describe user value and
   what success looks like, not the implementation.
@@ -48,18 +80,18 @@ it is optional.
 Write the body one line per paragraph; do not hard-wrap it. See "Formatting issue and PR bodies" in
 `CONTRIBUTING.md` for why.
 
-### 3. Apply the matching label
+### 4. Apply the matching label
 
 Each template declares its label (`epic`, `story`, `bug`, `technical-task`, `spike`, `chore`). Apply
 that label when filing. If the label does not exist yet, create it first.
 
-### 4. Review the draft
+### 5. Review the draft
 
 Run the `review-draft` skill on the issue body before filing. It checks quality, template adherence,
 voice, punctuation (no em dashes), formatting (no hard-wrapped body), and house style. Apply the
 findings you agree with.
 
-### 5. File
+### 6. File
 
 Present the final draft for approval, then file it. Pass the body via a file so multi-line markdown
 survives the shell: