Issues

Story

Building-a-house world — same site and crew as every Phase 0 lesson.

On the site wall hangs the job-ticket board. Every task lives there as a physical card: "tile the bathroom," "fix the leaky tap," "install cabinets." The foreman writes a card, pins it up, and assigns it to whoever is doing the work. When the job is done, the card comes down.

Hand one of those cards to the robot worker and you've just assigned an issue to the AI agent. It reads the card, goes off to build a sample (a branch), and eventually brings the result to the approval desk (a PR). The card — the issue — is its spec.

The idea

An issue is a single trackable unit of work or discussion in a repo. The docs put it plainly: "Issues can track bug reports, new features and ideas, and anything else you need to write down or discuss with your team."

source: docs.github.com — About issues · fetched 2026-05-29

Every issue card carries:

1. Title + description — what the work is and why.
2. Labels — colored tags to categorize: bug, enhancement, help wanted.
3. Assignees — who (or what) is responsible: a human, a team, or Copilot.
4. Milestones — group related issues toward a release or goal.
5. Comments — the running discussion thread.
6. State — open (not done) or closed (done).

Issue types, sub-issues, and dependencies — one look

The docs list three ways to add structure on top of a basic issue. Each solves a different problem:

source: docs.github.com — About issues · fetched 2026-05-29

Issue vs pull request — one look

People mix these up constantly. They are two different things that connect in a specific order:

The issue comes first. The PR comes after. A PR can auto-close the issue it fixes: write Fixes #42 in the PR description and issue 42 closes automatically the moment the PR merges.

"Using keywords, like fixes:, in your pull requests will automatically close the associated issues."

source: docs.github.com — About issues · fetched 2026-05-29

Real example — the syntax teaser

Create an issue from the terminal (GitHub CLI):

# Minimal — title + body (will prompt for anything missing)
gh issue create --title "Cart crashes when empty" \
  --body "Steps: open cart, remove all items, click checkout.
Expected: error message. Actual: 500 crash."

# Assign to a specific person at creation
gh issue create --title "Cart crashes when empty" --body "..." --assignee monalisa

# Assign to Copilot (the AI coding agent)
gh issue create --title "Fix empty-cart crash" \
  --body "When all items are removed and the user clicks checkout,
the app 500s. Repro steps: open cart, remove all items, click checkout." \
  --assignee "@copilot"

--assignee "@copilot" is the magic flag — it hands the job card to the robot worker.

source: cli.github.com — gh issue create · fetched 2026-05-29

Assigning via browser: open any existing issue → right sidebar → Assignees → search for and select Copilot.

"You can assign Copilot cloud agent to straightforward issues on your backlog by selecting 'Copilot' as the assignee."

source: docs.github.com — Assigning tasks to Copilot · fetched 2026-05-29

Why this matters for GH-600

Issues are the way you hand work to an AI agent. Here's the full Copilot coding-agent flow, step by step:

1. You write an issue — a clear title + description = the spec. Clear issue → good result. Vague issue → bad one.
2. You assign it to Copilot — browser sidebar or --assignee "@copilot" in the CLI.
3. Copilot works in the background — it "research[es] a repository, create[s] a plan, and make[s] code changes on a branch — all before opening a pull request." It "automate[s] branch creation, commit message writing, and pushing."
4. You review the output — "You can review the diff, iterate, and create a pull request when you're ready." The human stays in the loop.

source: docs.github.com — Assigning tasks to Copilot · fetched 2026-05-29

The exam frames this as issue in → reviewed PR out, with a human approving before merge. The issue is the input; the PR is the output. That two-step pattern — Big for GH-600.

Check-in — three questions

Open-ended. Think first, then peek at the suggested answer.

1. You have a big task: "Build the checkout flow." How would you use sub-issues to organize it? Give a concrete example with two or three sub-issue titles.

   Suggested answer

   Create a parent issue "Build checkout flow" and attach child sub-issues to it, one per chunk of work. Example: sub-issue "Add cart page," sub-issue "Add payment form," sub-issue "Add confirmation screen." Each child can be assigned, tracked, and closed independently while the parent shows overall progress. This keeps the big picture visible without one giant, unsorted issue.

   source: docs.github.com — About issues · fetched 2026-05-29

2. What's the difference between an issue and a pull request, and how do they connect to each other?

   Suggested answer

   An issue is the request — it describes what needs doing ("the cart crashes when empty"). A pull request is the proposed fix — the actual code change up for review. They connect through closing keywords: writing Fixes #42 in a PR's description automatically closes issue 42 the moment the PR merges. So the issue comes first, the PR comes after, and the PR "answers" the issue.

3. Walk through the Copilot coding-agent flow step by step: what do you do, what does Copilot do, and at what point does a human come back into the picture?

   Suggested answer

   You write a clear issue and assign it to Copilot (via the sidebar or --assignee "@copilot"). Copilot reads the issue, researches the repo, creates a plan, makes code changes on a new branch, and pushes. That branch is the output. You then review the diff, iterate if needed, and create (or approve) a pull request. The human comes back at the review + merge step — the agent proposes, the human accepts.

   source: docs.github.com — Assigning tasks to Copilot · fetched 2026-05-29

Mentor marks this lesson verified after you compare answers and say "got it" in chat.