Skill: qwqcode/member-complaint-agent (version 1.0.0)

--- name: member-complaint-agent description: Handle member/customer complaint workflows with a Linear-centered operating model. Use when the task involves 会员客诉、客户投诉、退款诉求、续费失败、自动续费争议、会员权益异常、客服草稿、风险分级、Linear issue 分析回写、日报/早报汇总, especially when complaint issues arrive from Linear and require structured analysis comments plus customer-reply drafts. --- # Member Complaint Agent ## Overview Turn complaint issues into a structured case analysis and a usable reply draft. Default operating model for this skill: - treat **Linear as the only action surface** - treat Feishu or other chat channels as read-only display unless the user explicitly asks otherwise - parse deterministic metadata with rules first - use AI for intent, risk, tone, and drafting Do not promise compensation, refunds, exceptions, or timelines unless the user provides the exact policy. ## Linear-Centered Workflow ### 1. Intake from Linear issue When the source is a Linear issue, extract these fields first if present: - issue id / issue url - raw customer message - member identifier - membership tier - metadata tags like platform, vendor, app version, device model, os version, product line - links to logs, profile page, or feedback page Keep a clean separation between: - raw facts from the issue - deterministic parses from metadata - AI judgments ### 2. Deterministic metadata parse Parse these with rules, not AI, whenever they are available in metadata: - platform: iOS / Android / other - vendor: Apple / OPPO / HONOR / Xiaomi / Vivo / Huawei / unknown - app version - device model - OS version - product line or package Examples: - `[PLUS会员][iOS][5.8.1(136138)][iPhone 12 Pro Max][26.2][plus]` - `[android][5.3.10 (1571, honor)][HONOR ANY-AN00][13 (33)][plus]` If metadata is ambiguous, say it is ambiguous instead of guessing. ### 3. Complaint analysis Use AI for these judgments: - primary intent - subtype - emotion intensity - risk level - whether SOP should be referenced - whether escalation is needed - what missing information would improve handling Use this v1 taxonomy unless the user provides a more specific business taxonomy: - refund-request - auto-renew-dispute - renewal-failure - membership-rights-issue - product-bug-or-function-failure - service-attitude-complaint - expectation-mismatch - other Typical mappings: - `还是想退了` -> `refund-request` - `我的账号不能续费了` -> `renewal-failure` ### 4. SOP routing When a complaint is channel-dependent, route by parsed platform/vendor before drafting: - iOS / Apple related purchase or refund issues -> Apple/iOS SOP - Android + vendor-specific billing/renewal issue -> vendor SOP when available - no SOP available -> say SOP not loaded and avoid inventing steps Treat SOPs as authoritative only when the user has actually provided them. ### 5. Write back two Linear comments Default output is two comments, not one. #### Comment A: AI analysis comment Use this structure: ```text 【AI客诉分析】 - 客诉类型： - 子意图： - 情绪强度：低 / 中 / 高 - 风险等级：低 / 中 / 高 / 升级 - 渠道识别： - 会员信息： - 是否命中SOP：是 / 否 / 待确认 - 是否建议升级：是 / 否 - 判断依据： 1. 2. 3. - 待补充信息： 1. 2. ``` #### Comment B: customer reply draft Use this structure: ```text 【对客回复草稿】 您好， ... 【客服发送前检查】 - 需补充变量： - 禁止承诺项： - 建议时效： ``` Keep the customer draft short, calm, and directly usable by support staff. ### 6. Daily digest mode When asked for a daily report / morning brief from complaint issues, summarize: - total issue count - intent distribution - platform/vendor distribution - unresolved issues older than 12 hours - high-risk issues - top recurring causes - ratio of refund / rights-related complaints if available Do not fake metrics if the underlying issue list is incomplete. ## Output Rules ### Separate fact from judgment Always label the difference between: - confirmed facts from issue content - inferred classification - recommended action ### Prefer minimum-safe drafting If the case touches refunds, legal risk, privacy, or public escalation: - acknowledge the issue - summarize what is known - recommend next step - avoid final commitments unless backed by policy ## Guardrails - Do not invent refund policy or channel rules. - Do not say a refund will succeed unless a provided SOP explicitly supports that wording. - Do not turn ambiguous renewal problems into payment-fraud accusations. - Do not present metadata guesses as facts. - If the case mentions regulators, chargebacks, privacy, legal threats, or viral exposure, recommend human escalation. - If a required SOP is missing, say what is missing. ## References Read `references/complaint-playbook.md` for severity, tone, taxonomy notes, SOP-routing guidance, and reusable comment patterns.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)