Back to Details

client-feedback

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Client Feedback Processor

客户反馈处理器

Transform client feedback emails into tracked, investigated, and resolved GitHub issues with professional response emails.
This workflow uses a Script-First approach: a deterministic Python script handles the "labor" of fetching and parsing emails, leaving the agent to handle the "judgment" of triaging and fixing issues.
将客户反馈邮件转化为可追踪、可调查并已解决的GitHub议题，同时生成专业的回复邮件。
此工作流采用Script-First（脚本优先）方法：由确定性Python脚本负责完成邮件获取与解析这类“劳力”工作，而由Agent负责处理分类与问题修复这类“判断”工作。

Usage

使用方法

When the user asks to "process feedback", "check emails from [domain]", or "turn feedback into issues":
  1. Run the processor script:
    bash
    python3 ~/.agents/skills/client-feedback/scripts/process_feedback.py \
  --domain "<client-domain>" \
  --days 7 \
  --out "./feedback-batch-$(date +%F)"
  2. Read the report: Load the generated 
    report.json
    and the full body text files to understand the feedback.
  3. Triage to GitHub: For each distinct piece of feedback in the report, create a GitHub issue or update an existing one.
当用户要求“处理反馈”、“检查来自[域名]的邮件”或“将反馈转化为议题”时：
  1. 运行处理器脚本：
    bash
    python3 ~/.agents/skills/client-feedback/scripts/process_feedback.py \
  --domain "<client-domain>" \
  --days 7 \
  --out "./feedback-batch-$(date +%F)"
  2. 读取报告： 加载生成的
    report.json
    文件以及完整的正文文本文件，以理解反馈内容。
  3. 分类至GitHub： 针对报告中每一条不同的反馈，创建一个新的GitHub议题或更新现有议题。

Phase 1: Intake (Script-Driven)

阶段1：收集（脚本驱动）

The 
process_feedback.py
script performs these tasks in seconds:
  • Searches Gmail for emails from the specified domain/sender.
  • Fetches full message payloads.
  • Downloads attachments automatically to a local directory.
  • Extracts plain-text bodies to individual files for easy reading.
  • Generates a 
    report.json
    summarizing threads, participants, and snippets.
process_feedback.py
脚本可在数秒内完成以下任务：
  • 在Gmail中搜索来自指定域名/发件人的邮件。
  • 获取完整的消息内容。
  • 自动将附件下载到本地目录。
  • 将纯文本正文提取到单独文件中，便于阅读。
  • 生成
    report.json
    文件，汇总邮件线程、参与者及内容片段。

Phase 2: Triage — GitHub issues

阶段2：分类——GitHub议题

GitHub issues are the primary work board. One issue per item, not one per email.
GitHub议题是主要的工作看板。每条反馈对应一个议题，而非每封邮件对应一个议题。

Issue body template

议题正文模板

markdown
undefined
markdown
undefined

Reported by

反馈人

[Person name] — [date] "[email subject]" (thread [threadId])
[姓名] — [日期] "[邮件主题]"（线程ID：[threadId]）

Issue

问题描述

[Verbatim quote if short, paraphrase if long]
[若内容简短则直接引用原文，若内容较长则进行转述]

Status

状态

[Open / awaiting client / in progress]

Apply labels based on category: `feedback` (always), `bug`, `content`, `design`, `provider-data`, `question`.
[待处理 / 等待客户回复 / 处理中]

根据类别添加标签：`feedback`（必加）、`bug`、`content`、`design`、`provider-data`、`question`。

Phase 3: Investigate & Fix

阶段3：调查与修复

Verify the feedback against the actual codebase. Grep globally for subjects of claims to ensure full removal or update.
对照实际代码库验证反馈内容。全局搜索反馈中提及的内容，确保已完全移除或更新。

Phase 4: Respond

阶段4：回复

Draft professional responses organized by email thread.
Key Rule: ALWAYS show the draft body text in chat before sending.
按邮件线程撰写专业回复。
核心规则：发送前务必在聊天中展示回复草稿内容。

Signature policy

签名规范

Keep signatures simple and professional. Avoid disclosing AI co-authorship unless the client relationship explicitly welcomes it.
保持签名简洁专业。除非客户关系明确允许，否则不要透露AI参与撰写。

Reference: Gmail multipart upload

参考：Gmail多部分上传

If you need to draft a reply with inline images (e.g. before/after proofs), use the 
gws
multipart upload flow documented in the script comments or 
process_feedback.py
logic.
undefined
若需要撰写包含内嵌图片的回复（例如前后对比图），可使用脚本注释或
process_feedback.py
逻辑中记录的
gws
多部分上传流程。
undefined