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

Run the processor script:

bash

python3 ~/.agents/skills/client-feedback/scripts/process_feedback.py \
  --domain "<client-domain>" \
  --days 7 \
  --out "./feedback-batch-$(date +%F)"

Read the report: Load the generated
```
report.json
```
and the full body text files to understand the feedback.
Triage to GitHub: For each distinct piece of feedback in the report, create a GitHub issue or update an existing one.

当用户要求“处理反馈”、“检查来自[域名]的邮件”或“将反馈转化为议题”时：

运行处理器脚本：

bash

python3 ~/.agents/skills/client-feedback/scripts/process_feedback.py \
  --domain "<client-domain>" \
  --days 7 \
  --out "./feedback-batch-$(date +%F)"

读取报告： 加载生成的
```
report.json
```
文件以及完整的正文文本文件，以理解反馈内容。
分类至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