Detect Completed Feature Requests

You are helping a WooCommerce Marketplace team member identify open feature requests that have already been fulfilled by a shipped release or documented capability.

Read first:

• .claude/skills/shared/RULES.md
• .claude/skills/shared/DISPLAY.md
• .claude/skills/shared/PHASE_LOOP.md
• .claude/skills/shared/KNOWLEDGE_BASE.md — changelog + docs crawl

Step 1 — Resolve the product

Follow .claude/skills/shared/RESOLVE_PRODUCT.md. Keep the product slug — it is needed by the knowledge base step.

Step 2 — Build the knowledge base

Skip this step if invoked by the orchestrator. The orchestrator passes
kbpath to .triage-state/<id>/knowledgebase.json — load it from there.

Follow .claude/skills/shared/KNOWLEDGEBASE.md in full. Store the result in memory (changelog entries, doc capabilities, latestversion).

Step 3 — Fetch open feature requests

Skip this step if invoked by the orchestrator. Read FRs from
input_path as JSONL.

Call wccom-feature-requests-list with productid: <id>, status: "publish", and perpage: 100. Paginate until a page returns fewer than 100 items. Collect id, title, description, status, votes, date, url.

URL carry-through is mandatory — see RULES.md.

If the first page returns 0 results, stop and report: "No open feature requests found for this product."

Step 4 — DETECTION STARTS HERE — Match ALL FRs against the knowledge base

(Orchestrator subagent: begin reading from this step.)

One pass over every FR. For each FR, reason about whether any knowledge base entry (changelog or docs) describes a shipped or documented feature that fulfils the FR's core ask.

A match means: a user who submitted this FR would consider their request addressed. Be conservative — only flag matches you're reasonably confident about.

Assign confidence per RULES.md:

• High — the knowledge base directly and fully addresses the FR
• Low — partially addressed, or likely addressed but with ambiguity

For each match record:

• FR fields: id, title, votes, date, url
• Source: changelog version + date, OR docs page URL
• The specific line / feature description that addresses it
• Confidence and a one-sentence reason
• Excerpt: first 1–3 sentences of the FR description, trimmed

Docs source rule — see KNOWLEDGE_BASE.md. A docs match may only cite a URL fetched and verified in Step 2 (HTTP 200, content read). Never infer or construct a docs URL.

Do not present partial results mid-pass. Complete the full pass, then present all matches.

Flagged record schema (for orchestrator output JSONL)

{ "id": <int>, "title": "<str>", "url": "<str>",
  "reason": "<one sentence>", "confidence": "High" | "Low",
  "excerpt": "<first 1–3 sentences of description>",
  "shipped_version": "<vX.Y.Z>" | null,
  "shipped_date": "<YYYY-MM-DD>" | null,
  "source": "changelog" | "docs",
  "docs_url": "<verified URL>" | null,
  "ship_line": "<specific changelog line or doc excerpt>" }

Step 5 — Present the report

Follow DISPLAY.md pagination. Decode HTML entities. Translate non-English excerpts per RULES.md.

For each match:

## Match [N]: "[FR title]"
Confidence: High / Low
Source: changelog · [Product Name] [version] ([release date])
     OR docs · [docs page URL]
Reason: [one sentence — why this FR is fulfilled]

FR:   ID [id] — "[title]" ([votes] votes · [date])
      [url]
      "[description — first 2–3 sentences, trimmed if long]"
Ship: [specific changelog line or doc excerpt that addresses it]

End with: X open FRs scanned · Y likely completed (Z high confidence, W low confidence).

If no matches, report that and stop.

Step 6 — Confirmation menu

Which matches should I mark as completed?

  [1] "[short FR title]" → [source: version or docs]
  [2] "[short FR title]" → [source: version or docs]
  ...
  [A] All of the above
  [H] High confidence only      ← omit if no High items (see RULES.md)
  [N] None / skip

Reply with numbers (e.g. "1 3"), A for all, H for high confidence only, or N to skip.

Wait for the user's reply.

Step 7 — Preview comments

Plain text only (see RULES.md).

Render a preview for every approved match with placeholders filled in:

📝 Comment preview — ID [id] — "[title]"

---
[full comment text]
---

Changelog-sourced template:

Hi there,

Thank you for your suggestion!

Great news! This feature was shipped in [product_name] [version] ([release_date])!

Therefore, I am marking this request as completed. Please update to [version] or later to access this feature.

Docs-sourced template (feature documented but no specific changelog version):

Hi there,

Thank you for your suggestion!

Great news! This feature is already supported by [product_name] (as of version [latest_version]). You can find more details in our documentation: [docs page URL]

Therefore, I am marking this request as completed.

[docs page URL] must be a URL verified in Step 2. If none, fall back to
the changelog template (or omit the match if no version exists).

After all previews: "Post these comments and mark as completed? (Y / N)" If N, abort.

Step 8 — Close approved matches

For each approved match, in this order:

1. Post a comment via wccom-feature-requests-comment.
2. Update status via wccom-feature-requests-update-status →

"completed".

1. Write failure handling — if either call fails, do not record as

actioned. Report in the summary; continue. If the comment posted but status update failed, note the half-completed state — manual cleanup required.

Step 9 — Confirmation summary

Done.

✅ Completed: ID [id] — "[title]"
   Source: [product_name] [version] ([release_date]) OR [docs page URL]
   [url]

⚠️  Failed: ID [id] — "[title]" — [error]
   [url]

One line per actioned FR, then: N marked as completed · F failed.

Then follow PHASE_LOOP.md.