Linear Feedback Triage

Use this skill for the Tide-style feedback workflow that lives in Linear.

Quick start

When the user asks about recent feedback, membership complaints, duplicates, or FB issues:

1. 1. Use exec with npx -y mcporter ... from /Users/claw/.openclaw/workspace.
2. Query the Linear MCP server configured in config/mcporter.json.
3. Prefer read-only queries first.
4. Summarize findings before proposing writes.
5. Only mutate Linear when the user clearly asks, or when the workflow explicitly calls for it.

Useful commands:

CODEBLOCK0

Core workflow

1. Query first

For broad requests, start with linear.list_issues.

Good filters:

• - team=FB for 用户反馈
• INLINECODE6 for membership/payment complaints
• INLINECODE7 / query=续费 / query=支付失败 for narrower searches
• INLINECODE10 unless the user asks for more

If descriptions are truncated, follow up with linear.get_issue on the specific IDs.

2. Normalize the feedback type

Map issues into a small set before deciding action:

• - 建议: product/content suggestion, feature request, request for a new payment method
• BUG: broken flow, payment failure, renewal failure, login/register issue, crash, data problem
• 内容反馈: meditation/sleep/sound/content quality issues
• 其他: unclear but not obviously a bug or suggestion

Keep labels to at most 3, mixing platform + primary class + one secondary domain when helpful.

Label guidance

Zero-level labels

• - Android
• iOS
• Web
• 重要

First-level labels

• - 建议
• 功能故障
• 内容反馈
• 会员支付
• 注册登录
• 其他

Second-level labels

• - 专注功能
• 睡眠功能
• 帐号数据
• 网络问题
• 闪退崩溃
• 播放功能
• 冥想内容
• 声音内容
• 睡眠内容

Status guidance

Use the user's workflow vocabulary when recommending or applying statuses:

• - 待处理: raw incoming feedback
• 待跟进: assigned and entering workflow
• 沟通中: active user communication
• 处理中: analysis, fixing, discussion, or investigation underway
• 挂起: blocked or dormant short-term
• 已解决: issue resolved or recorded elsewhere and no further user question remains
• 已归档: duplicate/aged-out/archive state
• 无效反馈: spam or meaningless feedback; use sparingly

Duplicate-handling rules

For suspected duplicates:

1. 1. Compare issue title, complaint theme, platform, account hints, and timestamps.
2. If it is the same user and same complaint, treat it as a likely duplicate.
3. If it matches an existing unresolved bug:

1. 4. If it matches an existing resolved bug:

When confidence is low, say so explicitly instead of forcing a merge.

Membership/payment complaint guidance

Common membership/payment buckets:

• - refund / cancellation request
• auto-renewal complaint
• payment failure
• renewal failure
• purchase blocked by account conflict
• payment-method suggestion

Heuristic:

• - payment method request → usually 建议 + 会员支付
• cannot pay / renew / buy → usually BUG or transactional failure + 会员支付
• refund / cancel auto-renewal → usually support/payment workflow item; still tag 会员支付

Reply drafting

If the user asks for a reply draft, produce text that can be used with Tide Bot:

CODEBLOCK1

Default tones:

• - unresolved known/active issue: acknowledge receipt, say it is being handled
• resolved issue: suggest updating/retrying on latest version
• suggestion: thank the user and say it has been recorded for evaluation

Do not claim a fix is shipped unless Linear evidence supports it.

Mutation commands

Only use these when needed:

CODEBLOCK2

Before writes, briefly state what you are about to change.

Output format

For analysis requests, prefer:

• - issue ID
• short title
• status
• labels
• why it matches the request
• duplicate/main-issue recommendation if relevant

For grouping requests, prefer buckets such as:

• - 退款 / 退订
• 自动续费争议
• 支付失败
• 无法购买 / 无法续费
• 支付方式建议

Keep summaries compact and decision-oriented.