Implementing a feature from a GitHub Issue

GitHub Copilot CLI can read a GitHub issue, propose an implementation plan, and draft code changes that satisfy the requirements. Because the workflow is conversational, you can correct assumptions, point to relevant files, and refine the approach as GitHub Copilot CLI works.

Example scenario

Imagine you work on a platform team that maintains an internal Node.js billing API that powers customer subscriptions. A product manager opens an issue requesting a new GET /subscriptions/{id}/plan endpoint that returns the plan attached to a given subscription, along with unit tests and an update to the OpenAPI specification. The issue includes the desired response shape, error cases for missing or cancelled subscriptions, and a link to the existing /subscriptions/{id} endpoint to follow as a pattern. You can hand the issue to GitHub Copilot CLI and have it scaffold the route, controller, and tests, then open a pull request.

Example workflow

GitHub Copilot CLI can read the issue directly from GitHub, plan the work, write the code, run your tests, and open a pull request.

Pull the issue into context

Start in the root of the repository and reference the issue by URL or owner/repo#number. GitHub Copilot CLI uses the GitHub MCP server to fetch the issue body, comments, and linked items, then keeps that context available for the rest of the session.

Draft an implementation plan with /plan

Switch to plan mode so GitHub Copilot CLI thinks through the change before touching any files.

GitHub Copilot CLI returns a plan similar to:

1. Add a `getPlanForSubscription` method in `src/services/subscriptionService.ts` that reuses the existing billing client, throws `NotFoundError` when the subscription or plan does not exist, and throws `CancelledSubscriptionError` when the subscription has been cancelled. 1. Add a `GET /subscriptions/:id/plan` route in `src/routes/subscriptions.ts`, mirroring the error handling in the sibling `GET /subscriptions/:id` route and mapping `CancelledSubscriptionError` to a `410` response. 1. Update `openapi/subscriptions.yaml` with the new path, response schema, and `404` and `410` responses. 1. Add unit tests in `test/services/subscriptionService.test.ts` and `test/routes/subscriptions.test.ts` covering the success case, missing subscription, cancelled subscription, and missing plan. 1. Run the test suite and update the changelog entry.

Review the plan, push back on anything that looks off, and ask GitHub Copilot CLI to revise it before you approve. For example, you might reply with Use the existing error classes in src/errors—NotFoundError for missing subscriptions or plans and CancelledSubscriptionError for cancelled subscriptions rather than introducing new ones and have it update the affected steps.

Kick off the implementation and steer as needed

Approve the plan to start coding. GitHub Copilot CLI works through the steps one at a time, showing each edit before applying it. If it heads in the wrong direction, interrupt and redirect.

For example, suppose GitHub Copilot CLI adds a new database query in your getPlanForSubscription method instead of reusing the billing client your team standardized on. You can stop and steer it:

GitHub Copilot CLI revises the code and continues with the remaining plan steps.

Generate and run unit tests

When GitHub Copilot CLI reaches the testing step, it scaffolds tests that match the patterns in your existing test files. For the plan endpoint, it might add cases like:

• Returns the plan record for an active subscription.
• Returns 404 when the subscription does not exist.
• Returns 410 when the subscription has been cancelled.
• Returns 404 when the subscription has no plan attached.

After writing the tests, GitHub Copilot CLI runs them in the terminal so you can see the results immediately.

If a test fails, GitHub Copilot CLI reads the failure output, updates the implementation, and re-runs until the test suite is green. Review each fix to make sure it's addressing the root cause rather than masking it.

Review the changes with /diff

Use /diff to see a consolidated view of changes made across the session.

If something looks wrong, ask GitHub Copilot CLI to revise it before you commit. For example, you might reply with Revert the formatting changes in src/routes/subscriptions.ts to only keep the new route handler to scope the diff back to the intended changes.

Open a pull request

Once the feature is implemented, tested, and reviewed, ask GitHub Copilot CLI to open a pull request. It uses the GitHub MCP server to push the branch and create the pull request

GitHub Copilot CLI reports back with the pull request's URL so you can move it forward from there.

Further reading

• GitHub Copilot CLI