AI Issue Feedback Collector

Use this skill to organize a user's natural-language description of issues encountered while using AI tools into a structured, objective issue feedback record that is easy to aggregate and route.

The goal of this skill is “collection and normalization,” not direct troubleshooting. Preserve the user's original intent, avoid over-inference, and ensure that the output can be pasted directly into an issue system, spreadsheet, group chat, Feishu Bitable, or an internal feedback platform.

Workflow

Determine whether the user is reporting an issue with an AI tool or AI-assisted workflow.
Extract observable facts: tool, task, scenario, failure behavior, impact, business context, and environment information.
Determine the likely issue category: model capability, environment/toolchain, business-context clarity, workflow collaboration, user skills/training, data/permissions, safety/compliance, or unknown.
Distinguish facts from inferences. Use
```
unknown
```
for missing fields or fields that cannot be safely determined; do not fabricate information.
Output structured feedback according to the template below.
For standard tags, refer to
```
references/label-taxonomy.md
```
.
If information is insufficient, place the issue under “Suggested Additional Information” and do not interrupt the user with repeated follow-up questions by default, unless the user explicitly requests an interview-style collection.
Store the output title and Markdown-formatted content in the file
```
scripts/issue_output.json
```
to make it easier to create the issue later.
Depending on the current operating system, select the appropriate script under
```
scripts
```
to send the feedback through a webhook to the designated issue system or feedback platform.
1. Windows environment: Check whether Python is installed. If Python is installed, run
```
python scripts/create_issue.py
```
  . If Python is not installed, tell the user that a Python environment is required for automatic issue creation, or guide the user to create the issue manually in a browser: open the browser and visit
```
https://gitcode.com/openharmonyinsight/ai-dev-feedback/issues/create
```
  , then manually complete and submit the title and content from
```
scripts/issue_output.json
```
  .
2. Linux environment: Run
```
bash scripts/create_issue.sh
```
  .

Output Template

markdown

## AI 使用问题反馈

### 标题
<用一句话概括问题。>

### 问题摘要
<基于用户描述，客观总结发生了什么。>

### 原始描述
<保留用户原话。>

### 使用场景
- 工具：`<工具名称或 unknown>`
- 场景：`<scenario 标签>`
- 任务类型：`<task 标签>`
- 工作流阶段：`<workflow-stage 标签或 unknown>`
- 受影响角色：`<角色或 unknown>`

### 问题分类
- 主分类：`<category 标签>`
- 次分类：`<category 标签或 none>`
- 分类置信度：`<high|medium|low|unknown>`
- 判断依据：<基于用户描述给出简短证据>

### 标签
- `tool:<value>`
- `category:<value>`
- `scenario:<value>`
- `task:<value>`
- `issue:<value>`
- `capability:<value>`
- `severity:<value>`
- `frequency:<value>`

### 影响
<描述对效率、质量、信任、成本或安全的影响；不清楚则写 unknown。>

### 可能原因
<可选。只列出合理假设，并明确不确定性。>

### 改进方向
<说明这条反馈可以如何帮助改进 AI 辅助研发，例如模型行为、工具集成、环境配置、提示词/流程设计、业务需求表达或开发者赋能。>

### 建议补充信息
- <有助于分派或定位问题的具体信息。>
- <有助于复现或判断影响范围的具体信息。>

### 建议分派方向
<可选一个或多个：产品体验、模型能力、工具集成、环境配置、业务分析、提示词/流程设计、权限/数据访问、文档/培训、安全/合规、unknown。>

Tag Rules

Use short, machine-readable tags. Prefer English lowercase kebab-case tag values to support aggregation and cross-language summaries.

Required tag families:

```
tool
```
: The AI product or Agent involved.
```
category
```
: The root-cause issue category used for aggregation and improvement planning.
```
scenario
```
: A broad usage scenario.
```
task
```
: The type of task the user wants to complete.
```
issue
```
: The observed issue behavior.
```
capability
```
: The AI capability area that may be involved.
```
severity
```
: The severity of the impact.
```
frequency
```
: How often the issue occurs.

If a feedback report contains multiple issue behaviors, you can output multiple

issue:

tags. If a field is not specified and cannot be safely inferred, use

unknown

For standard tag values or severity rules, read

references/label-taxonomy.md

Issue Classification Rules

Use

category:

to answer the question: “Which category of improvement is most likely to prevent this issue from recurring?”

```
category:model-capability
```
: Inadequate AI capabilities in understanding context, reasoning, planning, code comprehension, tool-use decision-making, instruction following, or failure recovery.
```
category:environment-tooling
```
: The issue is more likely caused by the local environment, dependencies, build/test configuration, IDE/CLI integration, tool permissions, network access, unavailable commands, or unstable tool execution.
```
category:business-context-clarity
```
: Business objectives, product rules, domain concepts, acceptance criteria, boundary conditions, or expected behavior are not clearly described.
```
category:workflow-process
```
: The AI-assisted development workflow itself needs improvement, such as missing review gates, unclear handoffs, oversized tasks, no testing strategy, or a lack of rollback/checkpoint habits.
```
category:user-skill-training
```
: The primary gap may involve prompt writing, how context is provided, AI collaboration habits, expectation management, or methods for validating results.
```
category:data-permission
```
: The AI cannot access the required code, files, documentation, logs, credentials, private knowledge bases, or runtime data.
```
category:safety-compliance
```
: The issue involves privacy, security, compliance, unsafe code changes, production risk, or irreversible operations.
```
category:unknown
```
: There is insufficient information to classify the issue responsibly.

Select one primary category. Add a secondary category only when the evidence is explicit. If the classification relies primarily on inference, set the confidence to

low

Severity Rules

```
severity:low
```
: Minor inconvenience with a clear workaround and very little business impact.
```
severity:medium
```
: Clearly affects efficiency or quality, but the user can recover.
```
severity:high
```
: Blocks the task, causes significant rework, or affects multiple users.
```
severity:critical
```
: Causes data loss, a security/privacy risk, production impact, a compliance risk, or irreversible dangerous operations.

Expression Rules

Keep the tone neutral, concise, and objective.
Do not blame either the user or the AI system.
Do not commit to a root-cause determination without evidence.
Unless the user explicitly requests it, do not directly solve the original task.
Retain enough original detail to support later retrospective analysis.
Prioritize a complete feedback report, then suggest any information that could be added.

Example

text

在使用 minmax 模型封装 CLI 时，总会出现编译过程，如果当前错误解决不了，就直接把这个封装的接口删掉。

markdown

## AI 使用问题反馈

### 标题
minmax 模型封装 CLI 时在编译失败后会删除封装接口

### 问题摘要
用户在使用 minmax 模型封装 CLI 时，遇到编译错误后，如果模型无法解决当前错误，它会直接删除已封装的接口，而不是继续定位问题、保留已有实现或请求用户确认。

### 原始描述
在使用 minmax 模型封装 CLI 时，总会出现编译过程，如果当前错误解决不了，就直接把这个封装的接口删掉。

### 使用场景
- 工具：`unknown`
- 场景：`coding`
- 任务类型：`feature-dev`
- 工作流阶段：`implementation-and-verification`
- 受影响角色：`developer`

### 问题分类
- 主分类：`model-capability`
- 次分类：`workflow-process`
- 分类置信度：`medium`
- 判断依据：用户描述中提到模型在无法解决编译错误时采取破坏性策略，直接删除封装接口。

### 标签
- `tool:unknown`
- `category:model-capability`
- `scenario:coding`
- `task:feature-dev`
- `issue:unsafe-action`
- `issue:bad-output-quality`
- `capability:planning`
- `capability:coding`
- `capability:instruction-following`
- `severity:high`
- `frequency:frequent`

### 影响
该问题可能导致已完成的接口封装工作被破坏，增加人工恢复和代码审查成本，并降低开发者对 AI 自动改代码能力的信任。

### 可能原因
模型可能缺少“失败后保留已有成果”的约束，也可能在编译错误无法修复时倾向于通过删除代码让编译通过。当前还需要结合具体日志和变更记录确认。

### 改进方向
需要加强 AI 辅助研发中的代码保护策略：模型遇到编译失败时，应优先定位错误、最小化修改、解释失败原因，并在删除接口、移除功能或大范围重构前请求用户确认。

### 建议补充信息
- 使用的是哪个具体 CLI 工具或平台。
- minmax 模型的具体模型名称和版本。
- 被删除的接口是否是用户明确要求保留的核心功能。
- 编译错误日志或失败命令。
- 这种行为是偶发还是每次编译失败后都会出现。

### 建议分派方向
模型能力、提示词/流程设计、产品体验

ai-feedback-collector-zh

NPX Install

Tags

SKILL.md Content (Chinese)