{"id":91300,"date":"2025-10-08T09:00:00","date_gmt":"2025-10-08T16:00:00","guid":{"rendered":"https:\/\/github.blog\/?p=91300"},"modified":"2025-10-07T15:08:31","modified_gmt":"2025-10-07T22:08:31","slug":"completing-urgent-fixes-anywhere-with-github-copilot-coding-agent-and-mobile","status":"publish","type":"post","link":"https:\/\/github.blog\/developer-skills\/github\/completing-urgent-fixes-anywhere-with-github-copilot-coding-agent-and-mobile\/","title":{"rendered":"Completing urgent fixes anywhere with GitHub Copilot coding agent and mobile"},"content":{"rendered":"\n

In a video game, a single upgrade enhances your abilities, while combining multiple can create an unstoppable power-up. In the world of software development, this combined power does something similar: At GitHub, we believe it can empower developers with an incredible force to tackle any challenge, whether that’s fixing a critical bug, adding a new feature, or shipping your release to production.<\/p>\n\n\n\n

My recent quest<\/h1>\n\n\n\n

“Stay a while and listen,” as the old Diablo line goes. <\/p>\n\n\n\n

One morning, while on a walk, I received an urgent call. A critical feature on a website I collaborate on  was displaying errors. This happened just before a high-visibility demo. I was miles from my laptop, and a traditional fix seemed hours away. That would be far too late to address this immediate need. Rolling back wasn’t an option, as it would remove functionality vital for the presentation.<\/p>\n\n\n\n

The only tool I had available was my cell phone. Instead of rushing home, I realized I could leverage two powerful GitHub features: GitHub Copilot coding agent<\/a> and the GitHub Mobile<\/a> app. I could quickly create an issue on mobile and delegate the problem to Copilot, in order to expedite a resolution.<\/p>\n\n\n\n

From GitHub Mobile, I scanned recent pull requests and identified a likely culprit: a pull request that added markdown rendering and a rich text editor. I created a new issue, describing the problem and referencing the suspicious pull requests, while also relying on my repository’s copilot-instructions<\/strong> to help guide the agent. With a few taps, I assigned the issue to GitHub Copilot coding agent.<\/p>\n\n\n\n

Just six minutes later, a notification appeared on GitHub Mobile. GitHub Copilot had generated a pull request with a fix! I reviewed it immediately from my phone. It was a clear, simple solution to the problem. Leveraging existing workflows, I could even test the fix on a preview branch right from my mobile device. <\/p>\n\n\n\n

Satisfied, I approved the pull request, which was deployed to production through automated workflows managed with GitHub Actions in my repository. By the time I reached my car, the director confirmed the issue was resolved, and they were ready to proceed with their demo. <\/p>\n\n\n\n

This experience, all managed from my phone, revealed a powerful capability within the GitHub Platform<\/strong>. Combining these two features—GitHub Copilot coding agent and GitHub Mobile—unlocked a new ability for me, and prompted me to explore what other combinations within the platform could further power-up <\/strong>my work.<\/p>\n\n\n\n

Here is a view from my phone using the GitHub Mobile app after reviewing the pull request and approving. We see a summary of Copilot’s fixes for the issue.<\/p>\n\n\n\n

\"Copilot<\/figure>\n\n\n\n

Using the right tool at the right time<\/h1>\n\n\n\n

It’s important to clarify that I’m not suggesting you delegate all development to Copilot from your mobile device, nor that every fix can be approved instantly from your phone. However, my experience highlights a crucial point: having the right tools for the right situation makes all the difference. GitHub Copilot as an AI pair programmer is a game-changer. By incorporating GitHub Copilot coding agent<\/a> and GitHub Mobile<\/a> into my workflow, alongside existing features like GitHub Issues<\/a> and GitHub Actions<\/a>, I’ve discovered a new level of efficiency. Here’s how you can gain this same power-up.  <\/p>\n\n\n\n

Keys to unlock this power-up <\/h1>\n\n\n\n

Key 1: Leverage instructions files<\/h2>\n\n\n\n

There is a plethora of knowledge available on how you can effectively use GitHub Copilot. One area you’ll certainly come across is custom instructions<\/a> for GitHub Copilot. These instructions are the guidelines and rules that can influence the results you get from Copilot. A well-defined set of instructions can go a long way.  <\/p>\n\n\n\n

In my scenario, I used repository custom instructions<\/a> to give Copilot additional context for understanding important information about my repository. This included the core purpose of the repository, the tech stack used, architecture constraints, coding standards, testing strategy, dependency management, observability, documentation, error handling, and more. It’s important to define the things that are important for GitHub Copilot to have and to understand about your project.<\/p>\n\n\n\n

For me, identifying things like directory structure, coding standards, and project dependencies were important for identifying a fix with less churn. Custom instructions are written using markdown and including them provide specific guidance to GitHub Copilot Coding Agent, Copilot Chat, and Copilot code review. It’s important to note that instructions in this file apply to all chat requests for the repository. This file exists in the .github directory in your repository right off of the root level. <\/p>\n\n\n\n

\"Location<\/figure>\n\n\n\n

EXAMPLE<\/strong>: Here’s an example of an instructions file you might see in the .github\/copilot-instructions.md<\/code> <\/strong>file. Remember to tailor these to your project.<\/p>\n\n\n

\n
# Copilot Instructions\n\n- Use Next.js App Router with React and TypeScript across the project.\n- Use pnpm for all package management commands (not npm or yarn).\n- Use Tailwind CSS v4 with a mobile-first approach; enhance with sm:\/md:\/lg:\/xl: as needed.\n- Prefer shadcn\/ui components before creating new UI; place shadcn\/ui in src\/components\/ui and shared components in src\/components\/shared.\n- Always use next\/link for internal navigation and next\/image for images.\n- Prefer server components by default; add \"use client\" only when needed (event handlers, browser APIs).\n- Implement server actions where appropriate; place them in src\/lib\/actions.\n- Put utilities in src\/utils and Supabase utilities in src\/utils\/supabase; define shared types in src\/types.\n- Write tests with Vitest for critical business logic and components; place tests in __tests__ directories.\n- Follow Next.js performance best practices and implement proper error boundaries and error handling.\n- Use environment variables (NEXT_PUBLIC_ for client exposure); keep secrets server-side only.\n- Use Vercel for deploys and GitHub Actions for CI\/CD with pnpm scripts (pnpm dev\/build\/test).\n- Keep code idiomatic: functional components + hooks, async\/await for async, and idiomatic Next.js\/React patterns.\n\n## Folder structure reference (high-level)\n\n```text\n.\n├─ app\/                         # Next.js App Router: route groups, page.tsx, layout.tsx, loading.tsx, error.tsx, route.ts\n├─ public\/                      # Static assets served at \/\n├─ src\/\n│  ├─ components\/\n│  │  ├─ ui\/                    # shadcn\/ui components\n│  │  └─ shared\/                # Shared app-specific components\n│  ├─ lib\/\n│  │  └─ actions\/               # Server actions (\"use server\") and server-side logic\n│  ├─ utils\/\n│  │  ├─ supabase\/              # Supabase client utilities (server-side)\n│  │  └─ index.ts               # General utilities (example)\n│  └─ types\/                     # Shared TypeScript types\n├─ __tests__\/                    # Vitest tests (or co-located __tests__ near source)\n├─ docs\/                         # Project documentation\n└─ .github\/                      # Workflows, issue templates, Copilot instructions\n```\n\n### Directory-specific conventions\n\n- app\/: Follow App Router conventions (page.tsx, layout.tsx, route.ts, loading.tsx, error.tsx). Use the Metadata API for SEO.\n- src\/components\/ui: Prefer existing shadcn\/ui components; extend consistently if needed.\n- src\/components\/shared: Reusable app-specific components; keep presentational components server-rendered if possible.\n- src\/lib\/actions: Mark server actions with \"use server\" and keep client-only imports out.\n- src\/utils\/supabase: Reuse a shared Supabase client; do not re-instantiate ad hoc clients.\n- __tests__: Use Vitest; write descriptive, focused tests for critical logic and components.\n\n## Commands\n\n- pnpm install — Install project dependencies.\n- pnpm dev — Start the Next.js development server with hot reloading.\n- pnpm build — Create a production build of the app.\n- pnpm start — Run the production server locally from the built output (if defined).\n- pnpm test — Run the Vitest test suite.\n- pnpm lint — Lint the codebase (if defined in package.json).\n- pnpm typecheck — Type-check the codebase using TypeScript only (no emit), if defined.\n- pnpm format — Format files with Prettier (if defined).<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
TIP: <\/strong>If you don’t already have an instructions file and are using VS Code, navigate to Configure Chat<\/strong> and choose Generate Instructions <\/strong>as noted at use custom instructions in VS Code<\/a>. 
<\/p>\n\n\n\n
\"Generate<\/figure>\n\n\n\n
In addition to repository-wide custom instructions<\/a>, you can define path-specific custom instructions<\/a> and make use of the applyTo<\/code> keyword to target only the directories, file patterns, languages or task contexts you care about. Path-specific instructions files allow you to scope the guidance you provide to Copilot with details relevant to a specific scenario based on what is provided in the applyTo<\/code> keyword.<\/p>\n\n\n\n
EXAMPLE:<\/strong> Here is one example of a path specific instructions file that I use to ensure any components Copilot helps create follow already established conventions. A file like this gets placed in the .github\/instructions<\/code> folder as noted at adding repository custom instructions<\/a>. <\/p>\n\n\n
\n
---\napplyTo: \"src\/components\/ui\/**\/*.tsx,src\/components\/shared\/**\/*.tsx\"\n---\n\n- Prefer existing shadcn\/ui components; check for an existing component before creating a new one.\n- Style with Tailwind v4 using mobile-first classes; add responsive variants for larger screens.\n- Use Lucide React icons (import from 'lucide-react'); avoid inline SVGs unless necessary.\n- Ensure accessible interactions (keyboard focus, ARIA where applicable) and touch targets ≥44px.\n- Avoid client components unless interactivity is required; keep pure presentational pieces server-rendered.\n- Co-locate component tests in __tests__ where applicable; use Vitest.<\/code><\/pre>\n<\/path><\/path><\/svg><\/path><\/svg><\/clipboard-copy><\/div>\n\n\n
IMPORTANT: <\/strong>When it comes to writing good instruction files, check out some community-contributed instructions, prompts, and more<\/a> for examples and inspiration. <\/p>\n\n\n\n
TAKEAWAY: <\/strong>Instructions help provide concrete context such as rules, standards, and preferences that GitHub Copilot can follow. Well written instructions noticeably improve the quality and relevance of its suggestions. By helping Copilot to internalize your project and coding standards, you’ll see higher-quality output and can finish tasks faster.  <\/p>\n\n\n\n
Key 2: Get acquainted with copilot coding agent<\/h2>\n\n\n\n
Treat Copilot coding agent like you would any team member: Everyone has skills and abilities in which they are strong, and those are the skills you want to leverage the most. Check out the post GitHub Copilot: Meet the new coding agent<\/a> for more details on where the coding agent excels. <\/p>\n\n\n\n
In order to become better acquainted with Copilot coding agent, assign Copilot to work on an issue<\/a>, create a pull request<\/a>, and track Copilot’s sessions<\/a> in your repository. The more you know about what this teammate can do, the more comfortable you’ll get delegating tasks. <\/p>\n\n\n\n
Just like the guidelines and rules you establish in the instructions files are important, it’s also important to provide specific instructions <\/strong>when creating issues to assign to Copilot. <\/p>\n\n\n\n
When you create a new issue in your repository, before you assign it to Copilot, be sure that the description accomplishes the following: <\/p>\n\n\n\n