원클릭으로 Manus에서 모든 스킬 실행

issue-report

스타0

포크0

업데이트2026년 4월 8일 08:29

按业界最佳实践向项目 GitHub 仓库提报 Issue（Bug Report / Feature Request / Improvement）。自动收集项目上下文、生成结构化 Issue 内容、通过 gh CLI 提交。当需要报告问题、提出新功能或改进建议时使用。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

A2C-SMCP

A2C-SMCP/a2c-smcp-skills

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Issue Report — 结构化 Issue 提报

自动收集项目上下文，按 GitHub Issue 最佳实践生成结构化内容，通过 gh CLI 提交到对应仓库。

Step 0：环境检查

gh CLI：执行 gh auth status，确认已认证且有 repo scope
识别当前项目：根据工作目录判断当前所在项目，加载对应 resource 文件

项目识别规则参见 {baseDir}/resources/<project>.md 中的路径模式。

Step 1：确定 Issue 类型

根据用户输入 $ARGUMENTS 判断 Issue 类型：

类型	判定信号	GitHub Label
Bug Report	错误、异常、崩溃、不符合预期、regression	`bug`
Feature Request	新功能、新增、支持 XXX、希望能	`enhancement`
Improvement	优化、改进、重构、性能、体验提升	`improvement`

如果类型不明确，使用 AskUserQuestion 确认。

Step 2：自动收集项目上下文

根据 Issue 类型自动收集相关信息，减少手动填写。

2.1 基础信息（所有类型）

项目版本：从版本文件中读取当前版本号
Git 状态：当前分支、最近 5 条 commit（git log --oneline -5）
相关文件变更：如果用户描述中提到文件/模块，读取相关代码

版本文件和提取方式按项目参见 {baseDir}/resources/<project>.md "版本信息"章节。

2.2 Bug Report 额外信息

错误日志/堆栈：如果用户提供了错误信息，格式化整理
复现路径：分析调用链，定位可能的触发路径
相关测试：搜索是否已有相关测试覆盖（如有，说明测试未覆盖的边界）
环境信息：语言/运行时版本、OS、关键依赖版本

调用链路和测试命令按项目参见 {baseDir}/resources/<project>.md。

2.3 Feature / Improvement 额外信息

现有实现：搜索项目中是否有相关的部分实现或类似功能
架构影响面：分析新功能/改进涉及哪些模块
跨项目影响：检查是否涉及协议变更或跨仓库协调

架构和跨项目关系按项目参见 {baseDir}/resources/<project>.md "架构上下文"章节。

Step 3：生成 Issue 内容

3.1 Bug Report 模板

## Bug 描述

[一句话描述 Bug 的表象]

## 复现步骤

1. [具体操作步骤]
2. ...

## 期望行为

[应该发生什么]

## 实际行为

[实际发生了什么]

## 环境信息

- 项目版本：`vX.Y.Z`
- 语言/运行时：[如 Python 3.11, Rust 1.82, Node 22]
- 操作系统：[如 macOS 15.x, Ubuntu 24.04]
- 相关依赖：[如有]

## 分析

### 可能的根因

[基于代码分析的根因推断，引用具体文件和行号]

### 相关代码

[关键代码片段，用 permalink 或代码块引用]

### 影响范围

[受影响的功能/模块列表]

## 建议修复方向（可选）

[如果有初步思路，简述修复方向]

3.2 Feature Request 模板

## 功能概述

[一句话描述期望的新功能]

## 动机与场景

[为什么需要这个功能？解决什么问题？]

## 详细描述

[功能的具体行为描述]

## 设计考量

### 架构影响

[涉及哪些模块，需要什么新增/修改]

### 跨项目影响

[是否涉及协议变更、是否需要其他仓库配合]

### 替代方案

[考虑过的其他实现方式及其优劣]

## 验收标准

- [ ] [具体的可验证条件 1]
- [ ] [具体的可验证条件 2]

3.3 Improvement 模板

## 改进目标

[一句话描述要改进什么]

## 现状分析

[当前实现的问题或不足，引用具体代码]

## 改进方案

[具体的改进措施]

## 预期收益

[改进后的效果：性能提升/可维护性/用户体验等]

## 影响范围

[涉及的模块和可能的 breaking changes]

## 验收标准

- [ ] [具体的可验证条件 1]
- [ ] [具体的可验证条件 2]

Step 4：用户确认与调整

使用 AskUserQuestion 向用户展示生成的 Issue 内容，确认：

标题是否准确简洁
内容是否完整且正确
Labels 是否合适
是否需要调整任何部分

未经用户确认，不得提交 Issue。

Step 5：提交 Issue

5.1 确定目标仓库

从当前项目的 resource 文件中获取 GitHub owner/repo（已内联，无需命令查询）。

5.2 提交

gh issue create \
  --repo <owner/repo> \
  --title "<Issue 标题>" \
  --label "<label1>,<label2>" \
  --body "$(cat <<'EOF'
<Issue 正文内容>
EOF
)"

5.3 确认结果

输出创建的 Issue URL
如果创建失败（如 label 不存在），自动去掉不存在的 label 重试

Step 6：跨项目联动（如适用）

当 Issue 涉及跨仓库影响时：

场景	动作
Bug 根因在上游依赖	向上游仓库也提一个 Issue，并在两个 Issue 中互相引用
Feature 需要协议变更	先向协议仓库提 Issue/RFC，在本项目 Issue 中引用
影响配对项目（如 office4ai ↔ office-editor4ai）	在关联项目创建对应 Issue，互相引用

使用 AskUserQuestion 确认是否需要跨项目联动，确认后才创建关联 Issue。

强制约束

禁止未确认提交 — Issue 内容必须经用户审阅
禁止空洞描述 — 每个 Issue 必须有具体的上下文和可操作的信息
禁止跳过上下文收集 — 自动收集步骤不可省略，这是 Issue 质量的保障
GitHub URL 内联 — 仓库地址从 resource 文件读取，不通过命令查询

이 저장소의 다른 Skills

같은 저장소

add-feature

A2C-SMCP/a2c-smcp-skills

A2C-SMCP 体系新增功能的流程门控。强制协议先行——任何涉及协议的 Feature 必须先在协议仓库通过评审、合并、发布后，代码仓库才可跟进实现。当用户提出新功能需求或 Feature Request 时调用。

2026-07-100

code-review

A2C-SMCP/a2c-smcp-skills

以架构师视角审查代码变更，关注模块边界、DRY 复用性、测试完整性、协议合规和长期可维护性。当需要审查 PR、工作区变更或提交代码时使用。

2026-07-100

fix-issue

A2C-SMCP/a2c-smcp-skills

以架构师视角分析并修复问题，强制 plan 模式，杜绝补丁式修复。涉及协议时严格按协议来，协议有问题则协议先行调整，代码再跟进。当遇到 Bug 反馈、错误日志或功能异常时使用。

2026-07-100

split-task

A2C-SMCP/a2c-smcp-skills

把一个较大的 A2C-SMCP Epic / Story / GitHub Issue（或 Jira / CNB Issue）科学拆成多个可独立交付的子任务，输出含依赖图与集成回归守护的拆分方案，并在对应平台用 sub-issue 能力下单。A2C 特有：涉及协议的拆分强制「协议先行」——协议子任务置于依赖图根，代码仓库子任务 blocked-by 它。当用户说「拆分这个任务」「把 Epic 拆成子任务」「分解 Story」「给个切刀方案」时触发。

2026-07-090

expose-a2c-resources

A2C-SMCP/a2c-smcp-skills

指导第三方 MCP Server 开发者通过标准 MCP Resource 协议暴露 window://（桌面状态）与 skill://（能力包）资源，接入 A2C-SMCP Desktop / SKILL 通道。当为 MCP Server 增加 A2C-SMCP 集成、把服务实时状态暴露给 Desktop、或通过 MCP 分发 SKILL 时使用。

2026-07-090

enhance-skill

A2C-SMCP/a2c-smcp-skills

反馈 A2C-SMCP Marketplace Skill 的问题或改进建议。自动识别当前会话中使用的 Skill，提取优化点，收集版本信息，提交 GitHub Issue 到 a2c-smcp-skills 仓库。当使用某个 Skill 时发现步骤错误、分支遗漏、文档过时等问题时调用。

2026-05-270

name	issue-report
description	按业界最佳实践向项目 GitHub 仓库提报 Issue（Bug Report / Feature Request / Improvement）。自动收集项目上下文、生成结构化 Issue 内容、通过 gh CLI 提交。当需要报告问题、提出新功能或改进建议时使用。
argument-hint	<问题描述或需求概述>

Issue Report — 结构化 Issue 提报

自动收集项目上下文，按 GitHub Issue 最佳实践生成结构化内容，通过 gh CLI 提交到对应仓库。

Step 0：环境检查

gh CLI：执行 gh auth status，确认已认证且有 repo scope
识别当前项目：根据工作目录判断当前所在项目，加载对应 resource 文件

项目识别规则参见 {baseDir}/resources/<project>.md 中的路径模式。

Step 1：确定 Issue 类型

根据用户输入 $ARGUMENTS 判断 Issue 类型：

类型	判定信号	GitHub Label
Bug Report	错误、异常、崩溃、不符合预期、regression	`bug`
Feature Request	新功能、新增、支持 XXX、希望能	`enhancement`
Improvement	优化、改进、重构、性能、体验提升	`improvement`

如果类型不明确，使用 AskUserQuestion 确认。

Step 2：自动收集项目上下文

根据 Issue 类型自动收集相关信息，减少手动填写。

2.1 基础信息（所有类型）

项目版本：从版本文件中读取当前版本号
Git 状态：当前分支、最近 5 条 commit（git log --oneline -5）
相关文件变更：如果用户描述中提到文件/模块，读取相关代码

版本文件和提取方式按项目参见 {baseDir}/resources/<project>.md "版本信息"章节。

2.2 Bug Report 额外信息

错误日志/堆栈：如果用户提供了错误信息，格式化整理
复现路径：分析调用链，定位可能的触发路径
相关测试：搜索是否已有相关测试覆盖（如有，说明测试未覆盖的边界）
环境信息：语言/运行时版本、OS、关键依赖版本

调用链路和测试命令按项目参见 {baseDir}/resources/<project>.md。

2.3 Feature / Improvement 额外信息

现有实现：搜索项目中是否有相关的部分实现或类似功能
架构影响面：分析新功能/改进涉及哪些模块
跨项目影响：检查是否涉及协议变更或跨仓库协调

架构和跨项目关系按项目参见 {baseDir}/resources/<project>.md "架构上下文"章节。

Step 3：生成 Issue 内容

3.1 Bug Report 模板

## Bug 描述

[一句话描述 Bug 的表象]

## 复现步骤

1. [具体操作步骤]
2. ...

## 期望行为

[应该发生什么]

## 实际行为

[实际发生了什么]

## 环境信息

- 项目版本：`vX.Y.Z`
- 语言/运行时：[如 Python 3.11, Rust 1.82, Node 22]
- 操作系统：[如 macOS 15.x, Ubuntu 24.04]
- 相关依赖：[如有]

## 分析

### 可能的根因

[基于代码分析的根因推断，引用具体文件和行号]

### 相关代码

[关键代码片段，用 permalink 或代码块引用]

### 影响范围

[受影响的功能/模块列表]

## 建议修复方向（可选）

[如果有初步思路，简述修复方向]

3.2 Feature Request 模板

## 功能概述

[一句话描述期望的新功能]

## 动机与场景

[为什么需要这个功能？解决什么问题？]

## 详细描述

[功能的具体行为描述]

## 设计考量

### 架构影响

[涉及哪些模块，需要什么新增/修改]

### 跨项目影响

[是否涉及协议变更、是否需要其他仓库配合]

### 替代方案

[考虑过的其他实现方式及其优劣]

## 验收标准

- [ ] [具体的可验证条件 1]
- [ ] [具体的可验证条件 2]

3.3 Improvement 模板

## 改进目标

[一句话描述要改进什么]

## 现状分析

[当前实现的问题或不足，引用具体代码]

## 改进方案

[具体的改进措施]

## 预期收益

[改进后的效果：性能提升/可维护性/用户体验等]

## 影响范围

[涉及的模块和可能的 breaking changes]

## 验收标准

- [ ] [具体的可验证条件 1]
- [ ] [具体的可验证条件 2]

Step 4：用户确认与调整

使用 AskUserQuestion 向用户展示生成的 Issue 内容，确认：

标题是否准确简洁
内容是否完整且正确
Labels 是否合适
是否需要调整任何部分

未经用户确认，不得提交 Issue。

Step 5：提交 Issue

5.1 确定目标仓库

从当前项目的 resource 文件中获取 GitHub owner/repo（已内联，无需命令查询）。

5.2 提交

gh issue create \
  --repo <owner/repo> \
  --title "<Issue 标题>" \
  --label "<label1>,<label2>" \
  --body "$(cat <<'EOF'
<Issue 正文内容>
EOF
)"

5.3 确认结果

输出创建的 Issue URL
如果创建失败（如 label 不存在），自动去掉不存在的 label 重试

Step 6：跨项目联动（如适用）

当 Issue 涉及跨仓库影响时：

场景	动作
Bug 根因在上游依赖	向上游仓库也提一个 Issue，并在两个 Issue 中互相引用
Feature 需要协议变更	先向协议仓库提 Issue/RFC，在本项目 Issue 中引用
影响配对项目（如 office4ai ↔ office-editor4ai）	在关联项目创建对应 Issue，互相引用

使用 AskUserQuestion 确认是否需要跨项目联动，确认后才创建关联 Issue。

强制约束

禁止未确认提交 — Issue 内容必须经用户审阅
禁止空洞描述 — 每个 Issue 必须有具体的上下文和可操作的信息
禁止跳过上下文收集 — 自动收集步骤不可省略，这是 Issue 质量的保障
GitHub URL 内联 — 仓库地址从 resource 文件读取，不通过命令查询