Linear Feedback Triage

Triage user-feedback issues in Linear, especially FB team / 用户反馈 workflows. Use when asked to query Linear issues, list recent complaints, find duplicate fee...

Security Scan

The skill's instructions clearly expect local Linear credentials and a workspace (config/mcporter.json and /Users/claw/.openclaw/workspace) and run arbitrary remote code via npx, but the skill declares no required credentials, config paths, or install steps — this mismatch is concerning.

Purpose & Capability

The skill claims to triage Linear issues, which legitimately requires access to Linear credentials/config. However the manifest declares no required env vars, primary credential, or config paths, while the SKILL.md directly references config/mcporter.json and an absolute workspace path. The declared requirements do not match what the instructions actually need.

Instruction Scope

Runtime instructions tell the agent to exec commands from an absolute local path (/Users/claw/.openclaw/workspace) and to read/use config/mcporter.json. They also include mutation commands that write to Linear. The SKILL.md therefore instructs filesystem access and potential credential use that are not declared or constrained — this broad scope is a red flag.

Install Mechanism

There is no install spec, but the instructions rely on running 'npx -y mcporter' at runtime. Using npx to fetch and run a package each invocation can execute arbitrary remote code and has no integrity/pinning in the skill. That risk should be acknowledged and mitigated (pin version, vet package source).

Credentials

The skill declares no environment variables or primary credential, yet it depends on a local mcporter configuration file that almost certainly contains API tokens or endpoints for Linear. The required access to secrets/config is implicit and not declared, which is disproportionate and hides what the agent will need to access.

Persistence & Privilege

The skill does not request 'always: true' and is user-invocable (defaults apply). Autonomous invocation is allowed by platform default; combined with the above missing declarations (local config access + remote npx execution) this increases blast radius. The skill does not request persistent installation, which is appropriate.

What to consider before installing

Do not install/run this skill without clarifying how it will access Linear credentials and where it will execute. Specific checks to request or perform before using: 1) Ask the skill author to declare required config paths or env vars (e.g., LINEAR_API_KEY or path to mcporter.json). 2) Inspect the referenced config/mcporter.json and confirm it does not expose sensitive tokens you don't want the agent to read. 3) Avoid running unpinned 'npx -y mcporter' — ask for a pinned package version or a vetted binary and verify the package source. 4) Prefer running the skill in a sandboxed environment or with least-privilege credentials (read-only Linear scope) until you trust it. 5) If you cannot verify where the skill will run and what mcporter.json contains, consider this skill risky because it implicitly requires secret access not declared in the manifest.

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. 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:

cd /Users/claw/.openclaw/workspace && npx -y mcporter call linear.list_issues team=FB limit=10
cd /Users/claw/.openclaw/workspace && npx -y mcporter call linear.get_issue id=FB-12345
cd /Users/claw/.openclaw/workspace && npx -y mcporter call linear.list_issue_statuses team=FB
cd /Users/claw/.openclaw/workspace && npx -y mcporter call linear.list_issue_labels team=FB

Core workflow

1. Query first

For broad requests, start with linear.list_issues.

Good filters:

• team=FB for 用户反馈
• label=会员支付 for membership/payment complaints
• query=退款 / query=续费 / query=支付失败 for narrower searches
• limit=10 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. 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:
   • recommend the new issue be archived
   • recommend linking it under the main issue as a sub-issue
   • reply to the user that the problem has been received and is being handled
4. If it matches an existing resolved bug:
   • recommend archive/sub-issue under the solved main issue
   • reply asking the user to update to the solved version or re-check

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:

@tidebot /reply <reply text>

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:

cd /Users/claw/.openclaw/workspace && npx -y mcporter call linear.save_issue id=FB-12345 state=处理中
cd /Users/claw/.openclaw/workspace && npx -y mcporter call linear.save_issue id=FB-12345 labels='["会员支付","Android"]'
cd /Users/claw/.openclaw/workspace && npx -y mcporter call linear.save_comment issueId=FB-12345 body='处理中，已复现。'

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.