chore: remove local .md file references from work-item skill

Make PR descriptions self-contained — reviewers should not need to read
local docs to understand context. Remove hard dependency on
docs/work-items.md and docs/implementation-progress.md from the finalize
stage. Update Step 0 to resolve items from conversation context instead
of a specific file.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: smypmsa

.claude/skills/work-item/SKILL.md

@@ -1,21 +1,21 @@
 ---
 name: work-item
-description: Work item pipeline for pumpfun-cli — investigate, plan, implement (TDD), verify, finalize as PR. MUST use this skill whenever the user wants to start, tackle, pick up, implement, or work on a work item from docs/work-items.md. Triggers on any mention of work items by number ("item 5", "item #5", "#5"), by name ("pre-trade balance validation", "quote command", "health check"), or by sequence ("next work item", "next item on the board", "next undone item", "next P1 item", "whatever is next"). Also triggers on phrases like "let's work on", "start implementing", "tackle item", "knock out", "pick up", "can we do item" when referring to the work items board. Does NOT trigger for: running tests, reviewing PRs, listing remaining items, fixing bugs, or explaining code.
+description: Work item pipeline for pumpfun-cli — investigate, plan, implement (TDD), verify, finalize as PR. MUST use this skill whenever the user wants to start, tackle, pick up, implement, or work on a work item. Triggers on any mention of work items by number ("item 5", "item #5", "#5", "B-06"), by name ("pre-trade balance validation", "quote command", "health check"), or by sequence ("next work item", "next item on the board", "next undone item", "next P1 item", "whatever is next"). Also triggers on phrases like "let's work on", "start implementing", "tackle item", "knock out", "pick up", "can we do item" when referring to work items. Does NOT trigger for: running tests, reviewing PRs, listing remaining items, fixing bugs, or explaining code.
 ---
 
 # Work Item Pipeline
 
-Automate work item execution from `docs/work-items.md` through a 5-stage gated pipeline.
+Automate work item execution through a 5-stage gated pipeline.
 
 ## Invocation
 
 `/work-item <number>` or `/work-item` (picks next undone item).
 
 ## Step 0: Resolve the Target Item
 
-1. Read `docs/work-items.md`
-2. If a number was provided, find the item with that number (e.g., `### 5.` or `### #5`)
-3. If no number was provided, find the lowest-numbered item NOT marked with `~~` strikethrough or `✅ Done`, following the "Recommended Implementation Order" section
+1. Resolve the work item from context — the user may provide a number, ID (e.g., "B-06"), title, or description. The item may come from a backlog, a conversation, or a direct request.
+2. If a specific item was identified, extract its details.
+3. If no specific item was given, ask the user which item to work on.
 4. Extract:
    - `ITEM_NUMBER`: the item number
    - `ITEM_TITLE`: the short title (e.g., "Pre-trade balance validation")
@@ -122,7 +122,7 @@ Automate work item execution from `docs/work-items.md` through a 5-stage gated p
 
 | Failure | Response |
 |---------|----------|
-| Item not found in work-items.md | Report error, list available undone items |
+| Item not found or unclear | Report error, ask the user to clarify |
 | Item already marked Done | Report it's done, ask user to pick another |
 | Stage 1 finds item not feasible | Present findings, recommend abort |
 | Stage 3 cannot get tests green | Present blockers after 2 attempts, offer re-run/abort/manual |

.claude/skills/work-item/prompts/1-investigate.md

@@ -38,7 +38,7 @@ Investigate the current codebase and CLI behavior to understand the gap this wor
    - **Unit** (always): mocked tests in `tests/test_core/`, `tests/test_commands/`, `tests/test_protocol/`
    - **Surfpool** (if touches RPC/transaction logic): integration tests in `tests/test_surfpool/`
    - **Mainnet** (rare — only if surfpool cannot cover it): e2e via `./scripts/mainnet-test.sh`
-7. **Check for combinable items.** Read `docs/work-items.md` and check if any other undone item shares >50% of the same code path. If so, recommend combining.
+7. **Check for combinable items.** Check `docs/backlog.md` (if it exists) or ask the user if any other planned item shares >50% of the same code path. If so, recommend combining.
 
 ## Output Format
 

.claude/skills/work-item/prompts/5-finalize.md

@@ -1,6 +1,6 @@
 # Stage 5: Finalize Work Item #{{ITEM_NUMBER}} — {{ITEM_TITLE}}
 
-You are finalizing the implementation of a work item for the pumpfun-cli project. Commit the changes, create a PR, and update documentation.
+You are finalizing the implementation of a work item for the pumpfun-cli project. Commit the changes and create a PR.
 
 ## Verification Results
 
@@ -12,62 +12,41 @@ You are finalizing the implementation of a work item for the pumpfun-cli project
 
 ## Steps
 
-### 1. Update docs/work-items.md
+### 1. Stage and commit
 
-Mark item #{{ITEM_NUMBER}} as done. Change the heading from:
-```
-### N. Title
-```
-to:
-```
-### N. ~~Title~~ ✅ Done — PR [#X](URL)
-```
-
-The PR URL will be filled in after step 5. For now, use a placeholder `TBD`.
-
-### 2. Update docs/implementation-progress.md
-
-Add a new section for this work item with:
-- Task name and status (Done)
-- Files modified
-- Key details about the implementation
-- Number of new tests added
-
-Follow the existing format in the file.
-
-### 3. Stage and commit
-
-Stage only the files that were changed during implementation plus the docs you just updated. Do NOT use `git add -A` or `git add .`.
+Stage only the files that were changed during implementation. Do NOT use `git add -A` or `git add .`. Do NOT stage files in `docs/` or `idl/`.
 
 ```bash
-git add <each file from FILES_CHANGED> docs/work-items.md docs/implementation-progress.md
+git add <each file from FILES_CHANGED>
 git status
 ```
 
-Verify no `.env`, `wallet.enc`, `idl/`, or credential files are staged.
+Verify no `.env`, `wallet.enc`, `idl/`, `docs/`, or credential files are staged.
 
 Commit with conventional commit format:
 ```bash
-git commit -m "feat: <short description of the feature>
+git commit -m "fix: <short description>
 
-Implements work item #{{ITEM_NUMBER}} ({{ITEM_TITLE}}).
+<2-3 sentence explanation of what was done and why>
 
 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>"
 ```
 
-### 4. Push the feature branch
+### 2. Push the feature branch
 
 ```bash
 git push -u origin HEAD
 ```
 
-### 5. Create PR
+### 3. Create PR
+
+The PR description must be **self-contained** — a reviewer should understand the full context without needing to read any external files. Do NOT reference `docs/backlog.md`, `docs/work-items.md`, or any other local documentation files in the PR title or body.
 
 ```bash
-gh pr create --title "feat: {{ITEM_TITLE}}" --body "$(cat <<'EOF'
+gh pr create --title "fix: {{ITEM_TITLE}}" --body "$(cat <<'EOF'
 ## Summary
 
-Implements work item #{{ITEM_NUMBER}} from `docs/work-items.md`.
+<Explain the problem that existed and why it matters — a reviewer unfamiliar with the backlog should understand the context from this section alone.>
 
 <1-3 bullet points describing what was added/changed>
 
@@ -92,17 +71,7 @@ EOF
 )"
 ```
 
-### 6. Update work-items.md with PR link
-
-Now that you have the PR URL, go back and update `docs/work-items.md` to replace the `TBD` placeholder with the actual PR link. Create a second commit (do NOT amend):
-
-```bash
-git add docs/work-items.md
-git commit -m "docs: add PR link for work item #{{ITEM_NUMBER}}"
-git push
-```
-
-### 7. Report
+### 4. Report
 
 Output the PR URL.
 
@@ -113,12 +82,10 @@ Output the PR URL.
 **Branch:** <branch name>
 **Title:** <PR title>
 
-## Docs Updated
-- work-items.md: item #{{ITEM_NUMBER}} marked Done
-- implementation-progress.md: section added
-
 ## CONSTRAINTS
 
 - Do NOT commit `.env`, `wallet.enc`, or credential files.
+- Do NOT stage or commit files in `docs/` or `idl/`.
 - Do NOT push to `main` directly. Always use feature branch + PR.
 - Do NOT merge the PR. That is the user's decision.
+- Do NOT reference local .md files (backlog, work-items, etc.) in the PR description. The PR must be self-contained.