woocommerce/wccom-feature-requests-triage-skills · Archived

detect-support-requests

Scans open feature requests for a WooCommerce Marketplace product and flags ones that are actually support questions (troubleshooting, setup help, bug reports framed as features).

First seen Jul 24, 2026

Installation

$ npx skills add woocommerce/wccom-feature-requests-triage-skills --skill detect-support-requests

Summary

  • Scans open feature requests for a WooCommerce Marketplace product and flags ones that are actually support questions (troubleshooting, setup help, bug reports framed as features).
  • Lets the user select which to close, then posts a closing comment redirecting them to woocommerce.com/contact-us/.
  • Use when asked to find or clean up support questions misfiled as feature requests.

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from woocommerce/wccom-feature-requests-triage-skills.

npx skills add woocommerce/wccom-feature-requests-triage-skills

Browse all from woocommerce/wccom-feature-requests-triage-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Default branch trunk
Open issues 0
Status Archived

Skill metadata

Parsed from SKILL.md frontmatter.

Declared agents claude-code

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 5,429 B
  • docs SUMMARY.md 408 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

Detect Support Requests Posted as Feature Requests

You are helping a WooCommerce Marketplace team member identify and close feature requests that are actually support questions — store-specific issues, troubleshooting, setup help, or bug reports — and redirect those users to the WooCommerce support team.

Read first:

  • .claude/skills/shared/RULES.md
  • .claude/skills/shared/DISPLAY.md
  • .claude/skills/shared/PHASE_LOOP.md

Step 1 — Resolve the product

Follow .claude/skills/shared/RESOLVE_PRODUCT.md.


Step 2 — Fetch all 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.

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


Step 3 — DETECTION STARTS HERE — Identify support requests

(Orchestrator subagent: begin reading from this step.)

A request is likely a support request if any of these patterns apply:

  • Personal/store-specific language — "I can't get X to work on my

store / my checkout / my site", "When I do Y, it errors out for me".

  • Troubleshooting / how-to — "How do I configure…?", "Why isn't X

showing up?", "It stopped working after the update".

  • Bug report framed as a feature — "Please fix X" describing something

that already exists but is broken in their setup.

  • Setup / installation help — questions about activating, connecting,

or migrating data.

  • Diagnostic info present — error messages, screenshots of admin

errors, references to specific orders/products on their site.

  • Direct questions to the team — "Can you help me?", "Where do I

change the settings?", closing with "Thanks!" or "Please help."

A request is NOT a support request (leave it alone) if it:

  • Asks for new functionality, an enhancement, or an integration.
  • Describes a workflow improvement that would benefit other merchants.
  • Is written in product-level language ("Add support for X", "It would be

great if the plugin could Y") rather than store-level.

Be conservative. Only flag where the support framing is clear.

Assign confidence per RULES.md (High / Low).

Flagged record schema

{ "id": <int>, "title": "<str>", "url": "<str>",
  "reason": "<one sentence>", "confidence": "High" | "Low",
  "excerpt": "<first 1–3 sentences of description, trimmed>" }

Step 4 — Present the report

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

## ID [id] — "[title]"
Confidence: High / Low
Reason: [one sentence — what makes this look like a support request]

[votes] vote(s) · opened [date]
[url]

Excerpt: "[1–2 sentences from the description that show the support
framing — verbatim, trimmed if long]"

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

If no requests are flagged, report that and stop.


Step 5 — Confirmation menu

Which requests should I close as support requests?

  [1] "[short title]" (confidence)
  [2] "[short title]" (confidence)
  ...
  [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 before taking any action.


Step 6 — Preview comments

Plain text only (see RULES.md).

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

---
[full comment text]
---

After all previews, ask: "Post these comments and close the requests? (Y / N)" Wait for confirmation. If N, abort.


Step 7 — Close approved requests

For each approved request, in this order:

  1. Post a closing comment via wccom-feature-requests-comment:

`` Hey there! Thank you for getting in touch. This looks like a support question, rather than a feature request. To get help with this, I encourage you to get in touch with our support team at: https://woocommerce.com/my-account/contact-support/. ``

  1. Update status via wccom-feature-requests-update-status → "closed".
  1. Write failure handling — if either call fails, do not record this

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


Step 8 — Confirmation summary

Done.

❌ Closed: ID [id] — "[title]" ([votes] vote(s) · opened [date])
   [url]

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

One line per FR, then: N support requests closed · F failed.

Then follow PHASE_LOOP.md.