issue-progress-tracking

$npx mdskill add yonatangross/orchestkit/issue-progress-tracking

Automatically updates GitHub issues with commit progress during development workflow phases.

  • Helps developers maintain issue status and track progress from start to pull request completion.
  • Integrates with GitHub CLI and Git for issue editing, commenting, and branch management.
  • Follows a structured ceremony guide with specific rules for branching and commit referencing.
  • Executes commands via Bash to label issues, create branches, and commit with issue references.

SKILL.md

.github/skills/issue-progress-trackingView on GitHub ↗
---
name: issue-progress-tracking
license: MIT
compatibility: "Claude Code 2.1.76+."
description: "Auto-updates GitHub issues with commit progress. Use when starting work on an issue, tracking progress during implementation, or completing work with a PR."
context: inherit
version: 1.0.0
author: OrchestKit
tags: [git, github, issues, tracking, workflow]
user-invocable: false
disable-model-invocation: true
allowed-tools: [Bash]
complexity: low
persuasion-type: discipline
effort: low
model: haiku
metadata:
  category: workflow-automation
---

# Issue Progress Tracking

Ceremony guide for tracking GitHub issue progress via `gh` CLI. Ensures issues stay updated as work progresses from start to PR.

## Quick Start

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

---

## Phase 1: Start Work

Label the issue and create a feature branch:

```bash
# Move issue to in-progress
gh issue edit $ARGUMENTS[0] --add-label "status:in-progress" --remove-label "status:todo"
gh issue comment $ARGUMENTS[0] --body "Starting work on this issue."

# Create feature branch
git checkout -b issue/$ARGUMENTS[0]-brief-description
```

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

---

## Phase 2: During Work — Small Commits

Commit after each logical step, not at the end. Every commit references the issue:

```bash
# Each commit references the issue number
git commit -m "feat(#$ARGUMENTS[0]): 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

---

## Phase 3: Report Progress (Long Implementations)

For multi-step work, post progress updates:

```bash
gh issue comment $ARGUMENTS[0] --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

---

## Phase 4: Complete Work

Create the PR and update labels:

```bash
# Create PR that closes the issue
gh pr create \
  --title "feat(#$ARGUMENTS[0]): brief description" \
  --body "Closes #$ARGUMENTS[0]

## Changes
- Change 1
- Change 2

## Test Plan
- [ ] Unit tests pass
- [ ] Manual verification"

# Update issue status
gh issue edit $ARGUMENTS[0] --add-label "status:in-review" --remove-label "status:in-progress"
```

---

## Rules Quick Reference

| Rule | Impact | What It Covers |
|------|--------|----------------|
| [Start Work Ceremony](rules/start-work-ceremony.md) | HIGH | Branch creation, label updates, initial comment |
| [Small Commits](rules/small-commits.md) | HIGH | Atomic commits referencing issues |

**Total: 2 rules across 2 categories**

---

## Key Decisions

| Decision | Choice | Rationale |
|----------|--------|-----------|
| 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 comments | Manual | Keeps humans in the loop |

---

## 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.

---

## 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

More from yonatangross/orchestkit

SkillDescription
agent-orchestrationAgent orchestration patterns for agentic loops, multi-agent coordination, alternative frameworks, and multi-scenario workflows. Use when building autonomous agent loops, coordinating multiple agents, evaluating CrewAI/AutoGen/Swarm, or orchestrating complex multi-step scenarios.
ai-ui-generationAI-assisted UI generation patterns for json-render, v0, Bolt, and Cursor workflows. Covers prompt engineering for component generation, review checklists for AI-generated code, design token injection, refactoring for design system conformance, and CI gates for quality assurance. Use when generating UI components with AI tools, rendering multi-surface MCP visual output, reviewing AI-generated code, or integrating AI output into design systems.
analyticsQuery cross-project usage analytics. Use when reviewing agent, skill, hook, or team performance across OrchestKit projects. Also replay sessions, estimate costs, and view model delegation trends.
animation-motion-designAnimation and motion design patterns using Motion library (formerly Framer Motion) and View Transitions API. Use when implementing component animations, page transitions, micro-interactions, gesture-driven UIs, or ensuring motion accessibility with prefers-reduced-motion.
architecture-patternsArchitecture validation and patterns for clean architecture, backend structure enforcement, project structure validation, test standards, and context-aware sizing. Use when designing system boundaries, enforcing layered architecture, validating project structure, defining test standards, or choosing the right architecture tier for project scope.
ascii-visualizerASCII diagram patterns for architecture, workflows, file trees, and data visualizations. Use when creating terminal-rendered diagrams, box-drawing layouts, progress bars, swimlanes, or blast radius visualizations.
assessAssesses and rates quality 0-10 with pros/cons analysis. Use when evaluating code, designs, or approaches.
async-jobsAsync job processing patterns for background tasks, Celery workflows, task scheduling, retry strategies, and distributed task execution. Use when implementing background job processing, task queues, or scheduled task systems.
audit-fullFull-codebase audit using 1M context window. Security, architecture, and dependency analysis in a single pass. Use when you need whole-project analysis.
audit-skillsAudits all OrchestKit skills for quality, completeness, and compliance with authoring standards. Use when checking skill health, before releases, or after bulk skill edits to surface SKILL.md files that are too long, have missing frontmatter, lack rules/references, or are unregistered in manifests.