Back to Details

issue-progress-tracking

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Issue Progress Tracking

Issue进度跟踪

Ceremony guide for tracking GitHub issue progress via 
gh
CLI. Ensures issues stay updated as work progresses from start to PR.
通过
gh
CLI跟踪GitHub Issue进度的操作规范指南。确保在工作从启动到创建PR的整个过程中，Issue状态保持更新。

Quick Start

快速开始

bash
/ork:issue-progress-tracking 123
bash
/ork:issue-progress-tracking 123

Phase 1: Start Work

阶段1：开始工作

Label the issue and create a feature branch:
bash
undefined
为Issue添加标签并创建功能分支：
bash
undefined

Move issue to in-progress

将Issue标记为进行中

gh issue edit $ARGUMENTS --add-label "status:in-progress" --remove-label "status:todo" gh issue comment $ARGUMENTS --body "Starting work on this issue."
gh issue edit $ARGUMENTS --add-label "status:in-progress" --remove-label "status:todo" gh issue comment $ARGUMENTS --body "开始处理此Issue。"

Create feature branch

创建功能分支

git checkout -b issue/$ARGUMENTS-brief-description

**Rules:**
- Always branch from the default branch (main/dev)
- Branch name format: `issue/<number>-<brief-description>`
- Never work directly on main/dev

---
git checkout -b issue/$ARGUMENTS-brief-description

**规则：**
- 始终从默认分支（main/dev）创建分支
- 分支命名格式：`issue/<编号>-<简短描述>`
- 切勿直接在main/dev分支上工作

---

Phase 2: During Work — Small Commits

阶段2：开发过程——小提交

Commit after each logical step, not at the end. Every commit references the issue:
bash
undefined
完成每个逻辑步骤后即提交，而非等到最后。每次提交都需关联Issue：
bash
undefined

Each commit references the issue number

每次提交都引用Issue编号

git commit -m "feat(#$ARGUMENTS): add user model
Co-Authored-By: Claude noreply@anthropic.com"

**Rules:**
- One logical change per commit (atomic)
- Reference issue in every commit: `type(#N): description`
- Commit early and often — don't accumulate a massive diff

---
git commit -m "feat(#$ARGUMENTS): add user model
Co-Authored-By: Claude noreply@anthropic.com"

**规则：**
- 每次提交对应一个逻辑变更（原子提交）
- 所有提交都需引用Issue：`类型(#编号): 描述`
- 尽早提交、经常提交——不要积累大量差异

---

Phase 3: Report Progress (Long Implementations)

阶段3：汇报进度（长期开发任务）

For multi-step work, post progress updates:
bash
gh issue comment $ARGUMENTS --body "Progress update:
- Completed: database schema, API endpoints
- In progress: frontend components
- Remaining: tests, documentation"
When to post updates:
  • After completing a major milestone
  • When blocked or changing approach
  • Before stepping away from a long task
对于多步骤的工作，发布进度更新：
bash
gh issue comment $ARGUMENTS --body "进度更新：
- 已完成：数据库 schema、API 端点
- 进行中：前端组件
- 待完成：测试、文档"
何时发布更新：
  • 完成重要里程碑后
  • 遇到阻塞或变更方案时
  • 离开长期任务前

Phase 4: Complete Work

阶段4：完成工作

Create the PR and update labels:
bash
undefined
创建PR并更新标签：
bash
undefined

Create PR that closes the issue

创建可关闭Issue的PR

gh pr create
--title "feat(#$ARGUMENTS): brief description"
--body "Closes #$ARGUMENTS
gh pr create
--title "feat(#$ARGUMENTS): brief description"
--body "Closes #$ARGUMENTS

Changes

变更内容

  • Change 1
  • Change 2
  • 变更1
  • 变更2

Test Plan

测试计划

  • Unit tests pass
  • Manual verification"
  • 单元测试通过
  • 手动验证"

Update issue status

更新Issue状态

gh issue edit $ARGUMENTS --add-label "status:in-review" --remove-label "status:in-progress"

---
gh issue edit $ARGUMENTS --add-label "status:in-review" --remove-label "status:in-progress"

---

Rules Quick Reference

规则速查

RuleImpactWhat It Covers
Start Work CeremonyHIGHBranch creation, label updates, initial comment
Small CommitsHIGHAtomic commits referencing issues
Total: 2 rules across 2 categories
规则影响程度涵盖内容
开始工作规范高分支创建、标签更新、初始评论
小提交规则高关联Issue的原子提交
总计：2类共2条规则

Key Decisions

关键决策

DecisionChoiceRationale
Label prefix
status:
Consistent with GitHub conventions
Branch format
issue/<N>-desc
Links branch to issue automatically
Commit reference
type(#N):
Conventional commits + issue linking
Progress commentsManualKeeps humans in the loop
决策选择理由
标签前缀
status:
与GitHub惯例保持一致
分支格式
issue/<N>-desc
自动将分支与Issue关联
提交引用格式
type(#N):
约定式提交 + Issue关联
进度评论手动保持人工参与沟通

Common Mistakes

常见错误

  1. Starting work without labeling — team loses visibility into who is working on what
  2. Giant commits at the end — makes review harder and history useless for bisect
  3. Forgetting to link PR to issue — issue stays open after merge
  4. Not updating labels on PR creation — issue shows "in-progress" during review
  5. Closing issues manually with 
    gh issue close
     — issues are closed ONLY by merging a PR with 
    Closes #N
    in the body. During work, comment progress with 
    gh issue comment
    ; never close directly.
  1. 开始工作却未添加标签——团队无法了解谁在处理什么任务
  2. 最后才提交大量变更——使代码评审更困难，且提交历史对二分查找无用
  3. 忘记将PR与Issue关联——合并后Issue仍保持打开状态
  4. 创建PR时未更新标签——Issue在评审期间仍显示“进行中”
  5. 使用
    gh issue close
    手动关闭Issue    ——仅当PR正文中包含
    Closes #N
    并合并后，才可关闭Issue。开发过程中，使用
    gh issue comment
    提交进度评论；切勿直接关闭Issue。

Related Skills

相关技能

  • ork:commit
    — Commit with conventional format
  • ork:fix-issue
    — Full issue resolution workflow
  • ork:implement
    — Feature implementation with parallel agents
  • ork:create-pr
    — Create pull requests
  • ork:commit
    —— 约定式提交
  • ork:fix-issue
    —— 完整的Issue解决流程
  • ork:implement
    —— 多Agent并行实现功能
  • ork:create-pr
    —— 创建拉取请求