Implementing a feature from a GitHub Issue

Give a GitHub issue to CLI GitHub Copilot, then steer the conversation to implement the feature.

Dans cet article

CLI GitHub Copilot 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 CLI GitHub Copilot 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 CLI GitHub Copilot and have it scaffold the route, controller, and tests, then open a pull request.

Example workflow

CLI GitHub Copilot 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. CLI GitHub Copilot 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.

Text
Read octo-org/billing-api#482 and any issues or PRs it links to. 
Summarize what needs to be implemented before we plan the work.

Draft an implementation plan with /plan

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

Text
/plan Implement the subscription lookup endpoint described in the issue. 
Follow the same conventions as the existing GET /subscriptions/{id} endpoint.

Remarque

La réponse suivante est un exemple. Les réponses Discussion avec Copilot ne sont pas déterministes, vous pouvez donc obtenir une réponse différente de celle affichée ici.

CLI GitHub Copilot 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 CLI GitHub Copilot 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. CLI GitHub Copilot 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 CLI GitHub Copilot 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:

Text
Don't add a new query here. The billing client in 
src/clients/billingClient.ts already exposes a getPlan method. 
Use that and update the service to handle its NotFound response.

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

Generate and run unit tests

When CLI GitHub Copilot 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, CLI GitHub Copilot runs them in the terminal so you can see the results immediately.

Text
Run the test suite for the new endpoint and fix any failures.

If a test fails, CLI GitHub Copilot 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.

Text
/diff

If something looks wrong, ask CLI GitHub Copilot 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 CLI GitHub Copilot to open a pull request. It uses the GitHub MCP server to push the branch and create the pull request

Text
Commit the changes on a new branch, push it, and open a pull request 
against main. Link it to octo-org/billing-api#482 and summarize the 
implementation, the tests added, and any follow-up work.

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

Further reading