issue
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseGitHub Issue Creation
GitHub Issue 创建规范
Create well-structured GitHub issues following repository conventions.
遵循仓库约定创建结构清晰的GitHub Issue。
Issue Title Format
Issue 标题格式
Use semantic prefixes matching conventional commits:
text
feat(scope): short description # New feature
fix(scope): short description # Bug fix
docs(scope): short description # Documentation
chore(scope): short description # Maintenance
refactor(scope): short description # Code refactoring
perf(scope): short description # Performance improvement使用符合Conventional Commits的语义化前缀：
text
feat(scope): short description # 新功能
fix(scope): short description # Bug修复
docs(scope): short description # 文档更新
chore(scope): short description # 维护工作
refactor(scope): short description # 代码重构
perf(scope): short description # 性能优化Issue Body Structure
Issue 正文结构
For Feature Requests
功能请求
markdown
undefinedmarkdown
undefinedSummary
概述
One paragraph describing the feature and its value.
用一段文字描述该功能及其价值。
Problem
问题
What problem does this solve? What's the current limitation?
该功能解决了什么问题？当前存在哪些限制？
Proposed Solution
拟议解决方案
Detailed description with:
- Code examples showing desired behavior
- ASCII diagrams or mockups if applicable
- Configuration examples
详细描述内容包括：
- 展示预期行为的代码示例
- 适用的ASCII图表或原型图
- 配置示例
Implementation Notes
实现说明
- Key files to modify
- Dependencies or prerequisites
- Potential challenges
- 需要修改的关键文件
- 依赖项或前置条件
- 潜在挑战
Benefits
收益
- Bullet points of user/developer benefits
undefined- 用户/开发者收益的要点列表
undefinedFor Bug Reports
Bug报告
markdown
undefinedmarkdown
undefinedSummary
概述
One paragraph describing the bug.
用一段文字描述Bug情况。
Problem
问题
What's happening vs what should happen?
Include:
- Steps to reproduce
- Error messages or screenshots
- Environment details if relevant
实际发生了什么？预期应该发生什么？
请包含：
- 复现步骤
- 错误信息或截图
- 相关的环境细节（如有）
Proposed Solution
拟议解决方案
How to fix it (if known).
修复方案（如果已知）。
References
参考资料
- Links to related issues, docs, or resources
undefined- 相关Issue、文档或资源的链接
undefinedLabels
标签
Apply appropriate labels based on issue type:
| Issue Type | Labels |
|---|---|
| New feature | |
| Bug fix | |
| Documentation | |
| Security issue | |
| CI/CD related | |
| New tool (lintro) | |
根据Issue类型添加合适的标签：
| Issue类型 | 标签 |
|---|---|
| 新功能 | |
| Bug修复 | |
| 文档更新 | |
| 安全问题 | |
| CI/CD相关 | |
| 新工具（lintro） | |
AI Implementation Prompt
AI实现提示
For issues that involve code changes, add a comment with an AI implementation prompt:
markdown
undefined对于涉及代码修改的Issue，添加一条包含AI实现提示的评论：
markdown
undefinedAI Implementation Prompt
AI实现提示
Use this prompt in a new agent session to implement this feature:
```
[Concise implementation instructions including:]
在新的Agent会话中使用以下提示来实现该功能：
```
[简洁的实现说明包括：]
Requirements
需求
1. [First Component]
1. [第一个组件]
- What to create/modify
- Code examples
- 需要创建/修改的内容
- 代码示例
2. [Second Component]
2. [第二个组件]
- What to create/modify
- Code examples
- 需要创建/修改的内容
- 代码示例
Files to Modify
需要修改的文件
- - description of changes
/path/to/file.py
- - 修改说明
/path/to/file.py
Tests
测试
- Test requirements (pytest style, NO test classes)
- Use assertpy, fixtures
- 测试要求（pytest风格，禁止使用测试类）
- 使用assertpy、fixtures
Before Submitting
提交前检查
- Run - must pass
uv run lintro chk - Run - must pass
uv run lintro fmt - Run - must pass ```
uv run pytest
undefined- 运行 - 必须通过
uv run lintro chk - 运行 - 必须通过
uv run lintro fmt - 运行 - 必须通过 ```
uv run pytest
undefinedUsage
使用方法
When asked to create an issue:
-
Gather requirements - Ask clarifying questions if needed
-
Review existing issues - Check for duplicates with
gh issue list -
Create the issue:bash
gh issue create \ --title "feat(scope): description" \ --label "enhancement" \ --body "$(cat <<'EOF' ## Summary ... EOF )" -
Add AI prompt comment (for implementation issues):bash
gh issue comment <issue-number> --body "$(cat <<'EOF' ## AI Implementation Prompt ... EOF )" -
Return the issue URL to the user
当被要求创建Issue时：
-
收集需求 - 如有需要，询问澄清问题
-
检查现有Issue - 使用检查是否存在重复
gh issue list -
创建Issue：bash
gh issue create \ --title "feat(scope): description" \ --label "enhancement" \ --body "$(cat <<'EOF' ## Summary ... EOF )" -
添加AI提示评论（针对需要实现的Issue）：bash
gh issue comment <issue-number> --body "$(cat <<'EOF' ## AI Implementation Prompt ... EOF )" -
将Issue链接返回给用户
Backlog Stewardship
待办事项管理规则
Rules for managing an existing backlog, not just creating new issues.
- Comment before closing. Every closed issue gets a comment explaining
why it's closed and linking to whatever supersedes it (issue, PR, or
commit).
- Don't: with no comment.
gh issue close 42 - Do: then
gh issue comment 42 --body "Superseded by #57, merged in a1b2c3d.".gh issue close 42
- Don't:
- "Done" means merged to . Work that exists only on a branch is not done. Never close an issue because a branch has the fix — reopen or repurpose the issue instead until it lands on
main.main - Repurpose before minting. When scope evolves, prefer retargeting an existing issue number over closing it and opening a new one — it preserves history and discussion.
- Placeholder convention for duplicates. For issues that are redundant or
would only duplicate another: prefer closing with a supersession comment
(see above) when the issue has useful comments, an implementation prompt,
or a useful body (repro steps, scoped feature spec, acceptance criteria)
— do not wipe history that other links or workflows may still need. Only
convert to a (empty body, title
placeholder, comments cleared) when the issue has no useful body and no useful discussion to preserve and you are explicitly reserving the number for reuse.placeholder - Never churn the backlog silently. Announce close/reopen/create/edit changes as you make them — the backlog should stay visible, not shift underneath readers.
- Keep content correct. Issues must carry accurate scope and follow the
format above. When an assessment (audit, review, incident) surfaces a real gap — bug, security issue, tech debt — add a spec-formatted, labeled issue for it rather than leaving it undocumented.
/issue - Dependency-update issues/PRs (Renovate, Dependabot): follow the
dependency-triage rule in the skill.
stand-general
管理现有待办事项的规则，不仅仅是创建新Issue。
- 关闭前添加评论：每个关闭的Issue都需要添加评论，解释关闭的原因，并链接到替代它的内容（Issue、PR或提交记录）。
- 错误做法：直接执行 而不添加评论。
gh issue close 42 - 正确做法：先执行 ，再执行
gh issue comment 42 --body "被#57替代，已合并至提交a1b2c3d。"。gh issue close 42
- 错误做法：直接执行
- “完成”指合并至分支：仅存在于分支上的工作不算完成。绝不能因为分支上有修复就关闭Issue——需重新打开或调整该Issue的用途，直到代码合并至
main分支。main - 调整用途而非新建：当需求范围变更时，优先调整现有Issue的用途，而非关闭后新建Issue——这样可以保留历史记录和讨论内容。
- 重复Issue的占位符约定：对于冗余或重复的Issue：如果该Issue包含有用的评论、实现提示或有价值的正文（复现步骤、明确的功能规格、验收标准），优先添加替代说明后关闭（见上述规则）；只有当该Issue没有有用的正文和讨论内容，且你明确需要保留该Issue编号以便复用，才将其转换为（清空正文，标题改为
placeholder，删除评论）。placeholder - 禁止静默修改待办事项：进行关闭/重新打开/创建/编辑操作时，需同步告知相关人员——待办事项应保持可见，不能在用户不知情的情况下变更。
- 保持内容准确：Issue必须包含准确的范围，并遵循上述格式。当评估（审计、审查、事件）发现实际存在的问题——Bug、安全漏洞、技术债务时，需添加符合规格格式、带有标签的Issue，而非不做记录。
/issue - 依赖更新Issue/PR（Renovate、Dependabot）：遵循技能中的依赖分类规则。
stand-general
Examples
示例
Good Issue Titles
优秀的Issue标题
feat(cli): add watch mode for continuous lintingfix(parser): handle empty input without crashingdocs(readme): add installation instructions for Windowsrefactor(core): simplify plugin loading logic
feat(cli): add watch mode for continuous lintingfix(parser): handle empty input without crashingdocs(readme): add installation instructions for Windowsrefactor(core): simplify plugin loading logic
Bad Issue Titles
糟糕的Issue标题
- (no scope, not descriptive)
Add feature - (not descriptive)
Bug - (vague, no scope)
Update code - (past tense, vague)
Fixed the thing
- （无范围，描述不清晰）
Add feature - （描述不清晰）
Bug - （模糊，无范围）
Update code - （过去式，模糊）
Fixed the thing