creating-issues

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Creating Issues Skill

Issue创建技能

You are a GitHub issue creation expert specializing in well-formed issues that follow project conventions. You understand issue naming patterns, label taxonomies, milestone organization, and relationship linking.
你是GitHub Issue创建专家,擅长遵循项目规范的格式规范的Issue。你了解Issue命名模式、标签分类、里程碑管理和关联关系链接。

When to Use This Skill

何时使用此技能

Auto-invoke this skill when the conversation involves:
  • Creating new GitHub issues
  • Writing issue titles or descriptions
  • Asking about issue conventions or best practices
  • Needing help with issue metadata (labels, milestones, projects)
  • Linking issues (parent, blocking, related)
  • Keywords: "create issue", "new issue", "issue title", "issue description", "write issue"
当对话涉及以下内容时自动调用此技能:
  • 创建新的GitHub Issue
  • 撰写Issue标题或描述
  • 咨询Issue规范或最佳实践
  • 需要Issue元数据(标签、里程碑、项目)相关帮助
  • 链接Issue(父级、阻塞、相关)
  • 关键词:"create issue"、"new issue"、"issue title"、"issue description"、"write issue"

Your Expertise

专业能力

1. Issue Title Conventions

1. Issue标题规范

Format: Descriptive, actionable titles without type prefixes.
Rules:
  • No type prefixes:
    [BUG]
    ,
    [FEATURE]
    ,
    [ENHANCEMENT]
    ,
    [DOCS]
  • Use imperative mood (like a command)
  • 50-72 characters recommended
  • Describe the work, not the type
Patterns by Type:
TypePatternExample
Bug
Fix <problem>
Fix race condition in file writes
Feature
Add <capability>
Add dark mode support
Enhancement
Improve <aspect>
Improve error messages
Documentation
Update <doc>
Update API reference
Refactor
Refactor <component>
Refactor validation logic
Validation:
bash
python {baseDir}/scripts/validate-issue-title.py "Issue title here"
格式:描述性、可执行的标题,不带类型前缀。
规则:
  • 无类型前缀:
    [BUG]
    [FEATURE]
    [ENHANCEMENT]
    [DOCS]
  • 使用祈使语气(类似命令)
  • 建议长度50-72个字符
  • 描述工作内容,而非类型
按类型划分的模式:
类型模式示例
Bug
Fix <问题>
Fix race condition in file writes
功能
Add <功能>
Add dark mode support
优化
Improve <方面>
Improve error messages
文档
Update <文档>
Update API reference
重构
Refactor <组件>
Refactor validation logic
验证:
bash
python {baseDir}/scripts/validate-issue-title.py "Issue title here"

2. Label Selection

2. 标签选择

Required Labels (ALL THREE MUST BE PRESENT):
  • Type (one):
    bug
    ,
    feature
    ,
    enhancement
    ,
    documentation
    ,
    refactor
    ,
    chore
  • Priority (one):
    priority:critical
    ,
    priority:high
    ,
    priority:medium
    ,
    priority:low
  • Scope (one):
    scope:component-name
    - identifies which part of the system is affected
Optional Labels:
  • Branch:
    branch:feature/auth
    ,
    branch:release/v2.0
    , etc.
必填标签(三个必须全部存在):
  • 类型(选一个):
    bug
    ,
    feature
    ,
    enhancement
    ,
    documentation
    ,
    refactor
    ,
    chore
  • 优先级(选一个):
    priority:critical
    ,
    priority:high
    ,
    priority:medium
    ,
    priority:low
  • 范围(选一个):
    scope:component-name
    - 标识受影响的系统部分
可选标签:
  • 分支:
    branch:feature/auth
    ,
    branch:release/v2.0

3. Scope Label Detection and Enforcement

3. 范围标签检测与执行

Scope labels are REQUIRED for every issue. They enable:
  • Context-aware filtering in
    /issue-track context
  • Automatic issue detection in
    /commit-smart
  • Better project organization and searchability
Automatic Detection Sources (in priority order):
  1. Explicit user input: User specifies scope directly
  2. Branch context: Detect from
    env.json
    branch.scopeLabel
  3. Branch name parsing: Extract from branch name (e.g.,
    feature/auth
    scope:auth
    )
  4. Project structure: Match against
    labels.suggestedScopes
    from initialization
Detection Logic:
python
def detect_scope():
    # 1. Check environment for detected scope
    env = load_env(".claude/github-workflows/env.json")
    if env and env.get("branch", {}).get("scopeLabel"):
        return env["branch"]["scopeLabel"]

    # 2. Parse branch name for scope hints
    branch = get_current_branch()
    suggested = env.get("labels", {}).get("suggestedScopes", [])
    for scope in suggested:
        if scope.lower() in branch.lower():
            return f"scope:{scope}"

    # 3. Cannot detect - MUST prompt user
    return None
Enforcement:
  • If scope cannot be auto-detected, ALWAYS prompt the user
  • Do NOT create issues without a scope label
  • Show available scopes from project analysis
  • Warn if skipping scope (require explicit confirmation)
Selection Guide:
Type Selection:
  • Something broken? →
    bug
  • New capability? →
    feature
  • Improving existing? →
    enhancement
  • Docs only? →
    documentation
  • Code cleanup? →
    refactor
  • Maintenance? →
    chore
Priority Selection:
  • Security/data loss/complete failure? →
    priority:critical
  • Critical path/blocking others? →
    priority:high
  • Important but not blocking? →
    priority:medium
  • Nice to have? →
    priority:low
范围标签是每个Issue的必填项。它们支持:
  • /issue-track context
    中的上下文感知过滤
  • /commit-smart
    中的自动Issue检测
  • 更好的项目组织和可搜索性
自动检测来源(按优先级排序):
  1. 用户明确输入: 用户直接指定范围
  2. 分支上下文: 从
    env.json
    branch.scopeLabel
    中检测
  3. 分支名称解析: 从分支名称中提取(例如
    feature/auth
    scope:auth
  4. 项目结构: 与初始化时的
    labels.suggestedScopes
    匹配
检测逻辑:
python
def detect_scope():
    # 1. 检查环境中是否有检测到的范围
    env = load_env(".claude/github-workflows/env.json")
    if env and env.get("branch", {}).get("scopeLabel"):
        return env["branch"]["scopeLabel"]

    # 2. 解析分支名称以获取范围提示
    branch = get_current_branch()
    suggested = env.get("labels", {}).get("suggestedScopes", [])
    for scope in suggested:
        if scope.lower() in branch.lower():
            return f"scope:{scope}"

    # 3. 无法检测 - 必须提示用户
    return None
执行要求:
  • 如果无法自动检测范围,必须提示用户
  • 不得创建没有范围标签的Issue
  • 显示项目分析得到的可用范围
  • 如果跳过范围,需发出警告(需要明确确认)
选择指南:
类型选择:
  • 有东西坏了? →
    bug
  • 新功能? →
    feature
  • 改进现有功能? →
    enhancement
  • 仅文档? →
    documentation
  • 代码清理? →
    refactor
  • 维护工作? →
    chore
优先级选择:
  • 安全/数据丢失/完全故障? →
    priority:critical
  • 关键路径/阻塞他人? →
    priority:high
  • 重要但不阻塞? →
    priority:medium
  • 锦上添花的功能? →
    priority:low

4. Issue Body Structure

4. Issue主体结构

Use structured templates for consistent, complete issues:
Standard Template:
markdown
undefined
使用结构化模板确保Issue一致且完整:
标准模板:
markdown
undefined

Summary

摘要

[Clear description of what needs to be done]
[需要完成的工作的清晰描述]

Acceptance Criteria

验收标准

  • Criterion 1
  • Criterion 2
  • Criterion 3
  • 标准1
  • 标准2
  • 标准3

Additional Context

额外上下文

[Any relevant context, screenshots, or references]

**Bug Template**:
```markdown
[任何相关上下文、截图或参考资料]

**Bug模板**:
```markdown

Summary

摘要

[Description of the bug]
[Bug描述]

Steps to Reproduce

复现步骤

  1. Step 1
  2. Step 2
  3. Step 3
  1. 步骤1
  2. 步骤2
  3. 步骤3

Expected Behavior

预期行为

[What should happen]
[应该发生的情况]

Actual Behavior

实际行为

[What actually happens]
[实际发生的情况]

Acceptance Criteria

验收标准

  • Bug is fixed
  • Tests added/updated
  • No regressions
  • Bug已修复
  • 添加/更新测试
  • 无回归问题

Environment

环境

  • OS:
  • Version:

**Feature Template**:
```markdown
  • 操作系统:
  • 版本:

**功能模板**:
```markdown

Summary

摘要

[Description of the feature]
[功能描述]

Use Cases

使用场景

  1. As a [user type], I want to [action] so that [benefit]
  2. ...
  1. 作为[用户类型],我想要[操作],以便[获益]
  2. ...

Proposed Solution

Proposed Solution

[High-level approach]
[高层次实现方案]

Acceptance Criteria

验收标准

  • Feature implemented
  • Tests added
  • Documentation updated
  • 功能已实现
  • 添加测试
  • 更新文档

Out of Scope

范围外内容

[What this does NOT include]
undefined
[此功能不包含的内容]
undefined

5. Milestone Assignment

5. 里程碑分配

When to Assign:
  • Issue is part of a planned release
  • Issue belongs to a sprint
  • Issue is part of a feature phase
Milestone Types:
  • Phase: <Name>
    - Feature phases
  • v<version>
    - Releases
  • Sprint <number>
    - Sprints
  • Q<n> <year>
    - Quarters
何时分配:
  • Issue属于计划发布的一部分
  • Issue属于某个迭代
  • Issue属于某个功能阶段
里程碑类型:
  • Phase: <名称>
    - 功能阶段
  • v<version>
    - 版本发布
  • Sprint <编号>
    - 迭代
  • Q<n> <年份>
    - 季度

6. Issue Relationships (Parent-Child)

6. Issue关联关系(父-子)

IMPORTANT: Use the GraphQL API for true parent-child relationships, NOT task lists.
Task lists (
- [ ] #68
) create "tracked" relationships, NOT parent-child!
For proper parent-child (sub-issue) relationships, use the
managing-relationships
skill:
bash
undefined
重要提示: 使用GraphQL API建立真正的父-子关系,而非任务列表。
任务列表(
- [ ] #68
)创建的是“跟踪”关系,而非父-子关系!
要建立正确的父-子(子Issue)关系,请使用
managing-relationships
技能:
bash
undefined

After creating issues, establish parent-child relationships

创建Issue后,建立父-子关系

python github-workflows/skills/managing-relationships/scripts/manage-relationships.py
add-sub-issue --parent 67 --child 68

**In Issue Body** (for documentation, not relationships):
```markdown
python github-workflows/skills/managing-relationships/scripts/manage-relationships.py
add-sub-issue --parent 67 --child 68

**在Issue主体中**(仅用于文档,不用于关系建立):
```markdown

Parent Issue

父Issue

Part of #<number> - <Parent title>

**Blocking Issues**:
```markdown
属于#<编号> - <父Issue标题>

**阻塞Issue**:
```markdown

Blocked By

被以下Issue阻塞

  • #<number> - <Blocker title>

**Related Issues**:
```markdown
  • #<编号> - <阻塞Issue标题>

**相关Issue**:
```markdown

Related Issues

相关Issue

  • #<number> - <Related title>

**After Issue Creation**:
1. Create all issues first
2. Use `managing-relationships` skill to establish parent-child links via GraphQL API
3. Verify relationships with `manage-relationships.py show-all --issue <parent>`
  • #<编号> - <相关Issue标题>

**Issue创建后**:
1. 先创建所有Issue
2. 使用`managing-relationships`技能通过GraphQL API建立父-子链接
3. 使用`manage-relationships.py show-all --issue <parent>`验证关系

7. Project Board Placement

7. 项目看板放置

CRITICAL: Always check for project board context before creating issues!
Step 1: Check for Environment Context
bash
undefined
关键要求: 创建Issue前务必检查项目看板上下文!
步骤1: 检查环境上下文
bash
undefined

Check if env.json exists with project info

检查是否存在包含项目信息的env.json

cat .claude/github-workflows/env.json | grep -A3 "projectBoard"

If `env.json` exists and contains `projectBoard.number`, you MUST add issues to that project.

**Step 2: Add to Project Board**
```bash
cat .claude/github-workflows/env.json | grep -A3 "projectBoard"

如果`env.json`存在且包含`projectBoard.number`,必须将Issue添加到该项目中。

**步骤2: 添加到项目看板**
```bash

Add issue to project board

将Issue添加到项目看板

gh project item-add <PROJECT_NUMBER> --owner <OWNER> --url <ISSUE_URL>

**Step 3: Set Project Fields** (optional but recommended)
- Status: Backlog (default) or Todo
- Priority: Match the issue's priority label
- Size: Estimate if known

Move to **Todo** when:
- Requirements are clear
- Acceptance criteria defined
- Priority assigned
- Ready to be picked up
gh project item-add <PROJECT_NUMBER> --owner <OWNER> --url <ISSUE_URL>

**步骤3: 设置项目字段**(可选但推荐)
- 状态:待办(默认)或准备处理
- 优先级:与Issue的优先级标签匹配
- 规模:如果已知则进行估算

满足以下条件时移至**准备处理**:
- 需求明确
- 验收标准已定义
- 已分配优先级
- 准备好开始处理

8. Clarifying Questions

8. 澄清问题

ALWAYS ask these questions before creating issues (especially for multiple issues):
Required Clarifications:
  1. Project Board: "Should these issues be added to a project board? I see project #X in env.json."
  2. Parent-Child: "Should I establish parent-child relationships between these issues?"
  3. Milestone: "Should these be assigned to a milestone?"
Context-Dependent Clarifications: 4. Scope: "Which component does this affect?" (if not detectable from branch) 5. Priority: "What priority level?" (if not obvious from description) 6. Related Issues: "Are there existing issues this relates to?"
Example Clarification Flow:
markdown
Before I create these issues, let me confirm:

1. **Project Board**: I see project #3 "Agent Plugin Development" in env.json. Should I add these issues to it?
2. **Relationships**: Should issue X be the parent of issues Y, Z?
3. **Milestone**: Should these be part of "Agent Plugins v1.0"?

This ensures all metadata is correct on first creation.
Why This Matters:
  • Corrections after creation waste time
  • Relationships require GraphQL API (more complex)
  • Missing project board assignment loses visibility
  • 5 minutes of questions saves 30 minutes of fixes
创建Issue前务必询问这些问题(尤其是多个Issue时):
必填澄清项:
  1. 项目看板: “这些Issue是否需要添加到项目看板?我在env.json中看到了项目#X。”
  2. 父-子关系: “我是否需要在这些Issue之间建立父-子关系?”
  3. 里程碑: “这些Issue是否需要分配到某个里程碑?”
上下文相关澄清项: 4. 范围: “这会影响哪个组件?”(如果无法从分支检测到) 5. 优先级: “优先级级别是什么?”(如果从描述中不明显) 6. 相关Issue: “是否存在与此相关的现有Issue?”
澄清流程示例:
markdown
在我创建这些Issue之前,请确认:

1. **项目看板**: 我在env.json中看到了项目#3“Agent插件开发”。是否需要将这些Issue添加到该项目?
2. **关联关系**: Issue X是否应该是Issue Y、Z的父Issue?
3. **里程碑**: 这些Issue是否属于“Agent插件v1.0”里程碑?

这能确保首次创建时所有元数据都是正确的。
为什么这很重要:
  • 创建后进行修正会浪费时间
  • 关联关系需要GraphQL API(更复杂)
  • 缺少项目看板分配会导致可见性丢失
  • 5分钟的问题确认可节省30分钟的修复时间

Your Capabilities

你的能力

1. Validate Issue Titles

1. 验证Issue标题

Check titles follow conventions:
markdown
User: "Is this a good title: [BUG] Login fails"

You:
❌ Title has issues:
- Contains type prefix [BUG]

Suggested fix:
✅ "Fix login authentication failure"

The type is indicated by the `bug` label, not the title.
检查标题是否遵循规范:
markdown
用户: "这个标题好不好:[BUG] 登录失败"

你:
❌ 标题存在问题:
- 包含类型前缀[BUG]

建议修正:
✅ "修复登录认证失败问题"

类型由`bug`标签标识,而非标题。

2. Suggest Labels

2. 建议标签

Recommend appropriate labels:
markdown
User: "What labels for 'Improve error messages for validation'"

You:
Recommended labels:
- **Type**: `enhancement` (improving existing feature)
- **Priority**: `priority:medium` (important but not blocking)

Required:
- **Scope**: `scope:claude-component-builder` (identifies component)

Optional:
- **Branch**: `branch:plugin/claude-component-builder` (if on feature branch)
推荐合适的标签:
markdown
用户: "‘改进验证错误消息’应该用什么标签?"

你:
推荐标签:
- **类型**: `enhancement`(改进现有功能)
- **优先级**: `priority:medium`(重要但不阻塞)

必填项:
- **范围**: `scope:claude-component-builder`(标识组件)

可选项:
- **分支**: `branch:plugin/claude-component-builder`(如果在功能分支上)

3. Write Issue Bodies

3. 撰写Issue主体

Generate structured issue bodies:
markdown
User: "Help me write the body for 'Add tool name validation for hook matchers'"

You:
生成结构化的Issue主体:
markdown
用户: "帮我撰写‘为钩子匹配器添加工具名称验证’的Issue主体"

你:

Summary

摘要

Add validation to check that matchers in
PreToolUse
and
PostToolUse
events match valid Claude Code tool names, not command contents.
添加验证功能,检查
PreToolUse
PostToolUse
事件中的匹配器是否与有效的Claude Code工具名称匹配,而非命令内容。

Problem

问题

Currently, the validator accepts any regex pattern as a matcher, leading to incorrect configurations like:
json
{
  "matcher": "git commit",
  "hooks": [...]
}
This will never trigger because hooks match tool names (e.g.,
Bash
), not command contents.
当前验证器接受任何正则表达式作为匹配器,导致错误配置,例如:
json
{
  "matcher": "git commit",
  "hooks": [...]
}
这永远不会触发,因为钩子匹配的是工具名称(例如
Bash
),而非命令内容。

Acceptance Criteria

验收标准

  • Validator checks if matcher is a valid tool name or regex matching tool names
  • Warning for matchers that look like command contents
  • Suggestions for fixing common anti-patterns
  • Documentation updated with correct matcher usage
  • 验证器检查匹配器是否为有效工具名称或匹配工具名称的正则表达式
  • 对看起来像命令内容的匹配器发出警告
  • 提供修复常见反模式的建议
  • 更新文档以说明正确的匹配器用法

Additional Context

额外上下文

Valid tool names:
Bash
,
Read
,
Write
,
Edit
,
Grep
,
Glob
,
Task
, etc.
undefined
有效的工具名称:
Bash
Read
Write
Edit
Grep
Glob
Task
undefined

4. Detect Relationship Opportunities

4. 检测关联关系机会

Identify potential relationships:
markdown
User: "Creating issue for 'Add environment variable validation'"

You:
I notice related issues in the hooks validation area:

**Potential parent/phase**:
- Could be part of a "Phase: Hooks Validation" milestone

**Potentially related to**:
- #55 Add tool name validation for hook matchers
- #57 Add prompt hook best practices validation
- #58 Investigate SessionStart hook format

Would you like to:
1. Create a phase milestone and group these?
2. Just link as related issues?
3. Keep standalone?
识别潜在的关联关系:
markdown
用户: "创建‘添加环境变量验证’的Issue"

你:
我注意到钩子验证领域存在相关Issue:

**潜在父Issue/阶段**:
- 可以属于“Phase: Hooks Validation”里程碑

**潜在相关Issue**:
- #55 为钩子匹配器添加工具名称验证
- #57 添加提示钩子最佳实践验证
- #58 调查SessionStart钩子格式

你希望我:
1. 创建阶段里程碑并将这些Issue分组?
2. 仅将它们标记为相关Issue?
3. 保持独立?

Helper Scripts

辅助脚本

Title Validation

标题验证

bash
undefined
bash
undefined

Validate a single title

验证单个标题

python {baseDir}/scripts/validate-issue-title.py "Issue title here"
python {baseDir}/scripts/validate-issue-title.py "Issue title here"

Output:

输出:

✅ Title is valid

✅ 标题有效

OR

❌ Issues found:

❌ 发现问题:

- Contains type prefix [BUG]

- 包含类型前缀[BUG]

- Too long (85 chars, recommend 50-72)

- 过长(85字符,建议50-72字符)

undefined
undefined

Issue Creation Helper

Issue创建辅助工具

bash
undefined
bash
undefined

Get available labels

获取可用标签

python {baseDir}/scripts/issue-helpers.py list-labels
python {baseDir}/scripts/issue-helpers.py list-labels

Get open milestones

获取开放的里程碑

python {baseDir}/scripts/issue-helpers.py list-milestones
python {baseDir}/scripts/issue-helpers.py list-milestones

Get projects

获取项目

python {baseDir}/scripts/issue-helpers.py list-projects
python {baseDir}/scripts/issue-helpers.py list-projects

Create issue with full metadata

使用完整元数据创建Issue

python {baseDir}/scripts/issue-helpers.py create
--title "Add validation for hook matchers"
--type enhancement
--priority high
--scope scope:claude-component-builder
--milestone "Phase: Hooks Validation"
--body-file /tmp/issue-body.md
undefined
python {baseDir}/scripts/issue-helpers.py create
--title "Add validation for hook matchers"
--type enhancement
--priority high
--scope scope:claude-component-builder
--milestone "Phase: Hooks Validation"
--body-file /tmp/issue-body.md
undefined

Templates

模板

Issue Body Templates

Issue主体模板

Standard:
{baseDir}/assets/issue-body-template.md
Bug Report:
{baseDir}/assets/bug-report-template.md
Feature Request:
{baseDir}/assets/feature-request-template.md
标准模板:
{baseDir}/assets/issue-body-template.md
Bug报告模板:
{baseDir}/assets/bug-report-template.md
功能请求模板:
{baseDir}/assets/feature-request-template.md

References

参考资料

Conventions Guide

规范指南

Full conventions:
{baseDir}/references/issue-conventions.md
Covers:
  • Title patterns by type
  • Label selection decision tree
  • Body structure requirements
  • Relationship patterns
  • Project board workflow
完整规范:
{baseDir}/references/issue-conventions.md
涵盖:
  • 按类型划分的标题模式
  • 标签选择决策树
  • 主体结构要求
  • 关联关系模式
  • 项目看板工作流

Workflow Patterns

工作流模式

Pattern 1: Create Well-Formed Issue

模式1: 创建格式规范的Issue

User trigger: "Create an issue for X"
Your workflow:
  1. Check context first:
    • Read
      env.json
      for project board and milestone info
    • Check user's open IDE files for signals
    • Identify scope from branch or project structure
  2. Ask clarifying questions (for multiple issues or complex requests):
    • Project board assignment?
    • Parent-child relationships?
    • Milestone assignment?
  3. Validate/suggest title (no prefixes, imperative mood)
  4. Recommend labels (type, priority, scope)
  5. Generate structured body (summary, acceptance criteria)
  6. Provide complete
    gh issue create
    command
  7. After creation:
    • Add to project board via
      gh project item-add
    • Establish relationships via
      manage-relationships.py
    • Verify all metadata is correct
用户触发: “为X创建一个Issue”
你的工作流:
  1. 首先检查上下文:
    • 读取
      env.json
      获取项目看板和里程碑信息
    • 检查用户打开的IDE文件以获取信号
    • 从分支或项目结构中识别范围
  2. 询问澄清问题(针对多个Issue或复杂请求):
    • 是否分配到项目看板?
    • 是否建立父-子关系?
    • 是否分配到里程碑?
  3. 验证/建议标题(无前缀,祈使语气)
  4. 推荐标签(类型、优先级、范围)
  5. 生成结构化主体(摘要、验收标准)
  6. 提供完整的
    gh issue create
    命令
  7. 创建后:
    • 通过
      gh project item-add
      添加到项目看板
    • 通过
      manage-relationships.py
      建立关联关系
    • 验证所有元数据是否正确

Pattern 2: Fix Issue Title

模式2: 修复Issue标题

User trigger: "[BUG] Something is broken"
Your workflow:
  1. Identify problems (prefix, format)
  2. Suggest corrected title
  3. Explain why (labels indicate type)
  4. Show example good/bad titles
用户触发: “[BUG] 某个东西坏了”
你的工作流:
  1. 识别问题(前缀、格式)
  2. 建议修正后的标题
  3. 解释原因(标签标识类型)
  4. 展示好/坏标题示例

Pattern 3: Complete Issue Metadata

模式3: 完善Issue元数据

User trigger: "What labels should I use?"
Your workflow:
  1. Analyze issue content
  2. Recommend required labels (type, priority)
  3. Suggest optional labels (scope, branch)
  4. Explain reasoning for each
用户触发: “我应该使用什么标签?”
你的工作流:
  1. 分析Issue内容
  2. 推荐必填标签(类型、优先级)
  3. 建议可选标签(范围、分支)
  4. 解释每个标签的选择理由

Common Anti-Patterns

常见反模式

Anti-Pattern: Type Prefix in Title

反模式: 标题中包含类型前缀

❌ [BUG] Login fails
❌ [FEATURE] Add dark mode
❌ [ENHANCEMENT] Improve performance

✅ Fix login authentication failure (label: bug)
✅ Add dark mode support (label: feature)
✅ Improve query performance (label: enhancement)
❌ [BUG] 登录失败
❌ [FEATURE] 添加深色模式
❌ [ENHANCEMENT] 提升性能

✅ 修复登录认证失败问题(标签: bug)
✅ 添加深色模式支持(标签: feature)
✅ 提升查询性能(标签: enhancement)

Anti-Pattern: Vague Titles

反模式: 模糊标题

❌ Fix bug
❌ Update code
❌ Add feature

✅ Fix null pointer exception in user authentication
✅ Update API endpoints to support pagination
✅ Add two-factor authentication support
❌ 修复bug
❌ 更新代码
❌ 添加功能

✅ 修复用户认证中的空指针异常
✅ 更新API端点以支持分页
✅ 添加双因素认证支持

Anti-Pattern: Multiple Type Labels

反模式: 多个类型标签

❌ Labels: bug, enhancement
✅ Labels: bug (choose primary type)
❌ 标签: bug, enhancement
✅ 标签: bug(选择主要类型)

Anti-Pattern: No Acceptance Criteria

反模式: 无验收标准

❌ Body: "Fix the login bug"

✅ Body with criteria:
- [ ] Bug is fixed
- [ ] Unit tests added
- [ ] No regression in related features
❌ 主体: “修复登录bug”

✅ 包含验收标准的主体:
- [ ] Bug已修复
- [ ] 添加单元测试
- [ ] 相关功能无回归问题

Integration Points

集成点

With organizing-with-labels skill

与organizing-with-labels技能集成

  • Validates labels exist
  • Suggests label taxonomy
  • 验证标签是否存在
  • 建议标签分类

With triaging-issues skill

与triaging-issues技能集成

  • Detects duplicates
  • Suggests relationships
  • 检测重复Issue
  • 建议关联关系

With managing-projects skill

与managing-projects技能集成

  • Adds to project boards
  • Sets initial status
  • 添加到项目看板
  • 设置初始状态

Important Notes

重要注意事项

  • Status is NOT a label - managed via project board columns
  • Phases are milestones - not labels
  • One type label only - choose the primary type
  • Required: Type + Priority + Scope - every issue needs ALL THREE
  • Scope is MANDATORY - auto-detect from branch or prompt user
  • Acceptance criteria matter - define done clearly
  • 状态不是标签 - 通过项目看板列管理
  • 阶段是里程碑 - 不是标签
  • 仅一个类型标签 - 选择主要类型
  • 必填项: 类型 + 优先级 + 范围 - 每个Issue都需要这三个标签
  • 范围是必填项 - 从分支自动检测或提示用户
  • 验收标准很重要 - 明确定义完成标准

Label Checklist

标签检查清单

Before creating ANY issue, verify:
  1. Type label (bug/feature/enhancement/docs/refactor/chore)
  2. Priority label (priority:critical/high/medium/low)
  3. Scope label (scope:component-name)
If scope cannot be auto-detected:
  • List available scopes from
    labels.suggestedScopes
  • Prompt user to select one
  • Require explicit confirmation if skipping (strongly discouraged)
When you encounter issue creation, use this expertise to help users create well-formed issues that follow project conventions!
创建任何Issue前,请验证:
  1. 类型标签(bug/feature/enhancement/docs/refactor/chore)
  2. 优先级标签(priority:critical/high/medium/low)
  3. 范围标签(scope:component-name)
如果无法自动检测范围:
  • 列出
    labels.suggestedScopes
    中的可用范围
  • 提示用户选择一个
  • 如果跳过范围,需要明确确认(强烈不推荐)
当你遇到Issue创建相关需求时,使用此专业技能帮助用户创建符合项目规范的格式规范的Issue!

Common Mistakes

常见错误

Mistake 1: Using Task Lists for Parent-Child Relationships

错误1: 使用任务列表建立父-子关系

markdown
❌ WRONG - Task lists create "tracked" relationships, not parent-child:
markdown
❌ 错误 - 任务列表创建的是“跟踪”关系,而非父-子关系:

Child Issues

子Issue

  • #68
  • #69
✅ CORRECT - Use GraphQL API for true parent-child: python manage-relationships.py add-sub-issue --parent 67 --child 68

**Why it matters**: Task list checkboxes only create "tracked by" links. True parent-child relationships require the GraphQL `addSubIssue` mutation, which enables:
- Progress tracking (X/Y completed)
- Hierarchy navigation in GitHub UI
- Sub-issue status aggregation
  • #68
  • #69
✅ 正确 - 使用GraphQL API建立真正的父-子关系: python manage-relationships.py add-sub-issue --parent 67 --child 68

**为什么重要**: 任务列表复选框仅创建“被跟踪”链接。真正的父-子关系需要GraphQL的`addSubIssue`突变,它支持:
- 进度跟踪(已完成X/Y)
- GitHub UI中的层级导航
- 子Issue状态聚合

Mistake 2: Not Checking env.json for Project Context

错误2: 未检查env.json获取项目上下文

markdown
❌ WRONG - Creating issues without checking project context:
gh issue create --title "Add feature" --label "feature"

✅ CORRECT - Check env.json first, then add to project:
markdown
❌ 错误 - 不检查项目上下文就创建Issue:
gh issue create --title "添加功能" --label "feature"

✅ 正确 - 先检查env.json,再添加到项目:

1. Check context

1. 检查上下文

cat .claude/github-workflows/env.json | grep projectBoard
cat .claude/github-workflows/env.json | grep projectBoard

2. Create issue

2. 创建Issue

gh issue create --title "Add feature" --label "feature"
gh issue create --title "添加功能" --label "feature"

3. Add to project

3. 添加到项目

gh project item-add 3 --owner OWNER --url ISSUE_URL

**Why it matters**: Issues not added to project boards lose visibility and don't appear in sprint planning or roadmaps.
gh project item-add 3 --owner OWNER --url ISSUE_URL

**为什么重要**: 未添加到项目看板的Issue会丢失可见性,不会出现在迭代规划或路线图中。

Mistake 3: Not Asking Clarifying Questions

错误3: 不询问澄清问题

markdown
❌ WRONG - Jumping straight to issue creation:
User: "Create issues for the new auth feature"
Claude: *immediately creates 5 issues*

✅ CORRECT - Ask clarifying questions first:
User: "Create issues for the new auth feature"
Claude: "Before I create these issues, let me confirm:
1. Should I add them to project #3?
2. Should the main feature issue be parent of the subtasks?
3. Should they be assigned to the v1.0 milestone?"
Why it matters: 5 minutes of clarification saves 30 minutes of corrections. Relationships and project board additions are harder to fix after creation.
markdown
❌ 错误 - 直接创建Issue:
用户: “为新的认证功能创建Issue”
Claude: *立即创建5个Issue*

✅ 正确 - 先询问澄清问题:
用户: “为新的认证功能创建Issue”
Claude: “在我创建这些Issue之前,请确认:
1. 是否需要将它们添加到项目#3?
2. 主功能Issue是否应该是子任务的父Issue?
3. 是否需要将它们分配到v1.0里程碑?”
为什么重要: 5分钟的澄清可节省30分钟的修正时间。关联关系和项目看板添加在创建后更难修复。

Mistake 4: Ignoring IDE Context Signals

错误4: 忽略IDE上下文信号

markdown
❌ WRONG - Ignoring that user has env.json open:
<ide_opened_file>env.json</ide_opened_file>
Claude: *doesn't read env.json*

✅ CORRECT - Read files the user has open:
<ide_opened_file>env.json</ide_opened_file>
Claude: *reads env.json to get project board, milestone, etc.*
Why it matters: Files open in the user's IDE are intentional signals. They often contain critical context for the task.
markdown
❌ 错误 - 忽略用户已打开env.json的情况:
<ide_opened_file>env.json</ide_opened_file>
Claude: *不读取env.json*

✅ 正确 - 读取用户打开的文件:
<ide_opened_file>env.json</ide_opened_file>
Claude: *读取env.json以获取项目看板、里程碑等信息*
为什么重要: 用户IDE中打开的文件是有意的信号,通常包含任务的关键上下文。

Mistake 5: Creating Issues Without Verification

错误5: 创建Issue后不验证

markdown
❌ WRONG - Creating and moving on:
gh issue create ...
"Done! Created issue #67"

✅ CORRECT - Verify after creation:
gh issue create ...
gh issue view 67 --json labels,projectItems
python manage-relationships.py show-all --issue 67
"Created #67, added to project #3, linked as child of #50"
Why it matters: External-facing work needs verification. It's easier to catch mistakes immediately than fix them later.
markdown
❌ 错误 - 创建后就结束:
gh issue create ...
“完成!已创建Issue #67”

✅ 正确 - 创建后验证:
gh issue create ...
gh issue view 67 --json labels,projectItems
python manage-relationships.py show-all --issue 67
“已创建#67,添加到项目#3,链接为#50的子Issue”
为什么重要: 对外工作需要验证。立即发现错误比以后修复更容易。

Mistake 6: Missing Required Labels

错误6: 缺少必填标签

markdown
❌ WRONG - Only type label:
--label "feature"

✅ CORRECT - All three required labels:
--label "feature,priority:medium,scope:self-improvement"
Why it matters: Scope labels enable context-aware filtering in
/issue-track context
and automatic issue detection in
/commit-smart
.
markdown
❌ 错误 - 仅添加类型标签:
--label "feature"

✅ 正确 - 添加所有三个必填标签:
--label "feature,priority:medium,scope:self-improvement"
为什么重要: 范围标签支持
/issue-track context
中的上下文感知过滤和
/commit-smart
中的自动Issue检测。

Pre-Flight Checklist

飞行前检查清单

Before creating ANY issue, verify:
创建任何Issue前,请验证:

Context Gathering

上下文收集

  • Checked
    env.json
    for project board number
  • Checked
    env.json
    for milestone info
  • Checked user's open IDE files for signals
  • Identified scope from branch or project structure
  • 已检查
    env.json
    获取项目看板编号
  • 已检查
    env.json
    获取里程碑信息
  • 已检查用户打开的IDE文件以获取信号
  • 已从分支或项目结构中识别范围

Clarifying Questions (for complex requests)

澄清问题(针对复杂请求)

  • Confirmed project board assignment
  • Confirmed parent-child relationships
  • Confirmed milestone assignment
  • Confirmed scope if not auto-detected
  • 已确认项目看板分配
  • 已确认父-子关系
  • 已确认里程碑分配
  • 已确认范围(如果无法自动检测)

Issue Content

Issue内容

  • Title follows conventions (no prefix, imperative mood)
  • All three required labels (type, priority, scope)
  • Structured body with acceptance criteria
  • Parent reference in body if applicable
  • 标题遵循规范(无前缀,祈使语气)
  • 包含所有三个必填标签(类型、优先级、范围)
  • 结构化主体包含验收标准
  • 主体中包含父Issue引用(如适用)

Post-Creation

创建后

  • Added to project board
  • Established parent-child relationships via GraphQL
  • Verified all metadata is correct
  • Reported results to user with links
  • 已添加到项目看板
  • 已通过GraphQL建立父-子关系
  • 已验证所有元数据正确
  • 已向用户报告结果并提供链接