Author name: ITMAITY

Editor’s note: This piece was originally published in our LinkedIn newsletter, Branching Out_. Sign up now for more career-focused content >  AI tools seem to be everywhere. With the tap of a key, they provide ready answers to queries, autocomplete faster than our brains can, and even suggest entire blocks of code. Research has shown that GitHub Copilot enables developers to code up to 55% faster. Junior developers, specifically, may see a 27% to 39% increase in output with AI assistance according to MIT, showing even greater productivity gains from their adoption of AI than more experienced developers.  But here’s the question: you may be coding faster with AI, but when was the last time you asked yourself why before adopting a suggestion from an AI coding assistant?  Being a developer is not just about producing code. It’s about understanding why the code works, how it fits into the bigger picture, and what happens when things break down. The best developers know how to think critically about new problems and take a systems view of solving them. That kind of expertise is what keeps software resilient, scalable, and secure, especially as AI accelerates how quickly we ship. Without it, we risk building faster but breaking more. Our CEO, Thomas Dohmke, put it bluntly at VivaTech: “Startups can launch with AI‑generated code, but they can’t scale without experienced developers.” Developer expertise is the multiplier on AI, not the bottleneck. We’re not saying you have to reject AI to be a great developer. At GitHub, we believe AI is a superpower, one that helps you move faster and build better when used thoughtfully. Your role as a developer in the age of AI is to be the human-in-the-loop: the person who knows why code works, why it sometimes doesn’t, what the key requirements in your environment are, and how to debug, guide AI tools, and go beyond vibe coding.  After all, AI can help you write code a lot faster, but only developer expertise turns that speed into resilient, scalable, and secure software. TL;DR: AI pair‑programming makes you faster, but it can’t replace the judgment that keeps software safe and maintainable. This article offers three concrete ways to level‑up your expertises. AI’s productivity dividend + developer experience = greater impact Benefit How human judgment multiplies the value ⏱️ Faster commits (up to 55 % quicker task completion) Devs run thoughtful code reviews, write tests, and surface edge cases so speed never comes at the cost of quality. 🧠 Lower cognitive load Freed-up mental bandwidth lets developers design better architectures, mentor teammates, and solve higher-order problems. 🌱 Easier onboarding for juniors Senior engineers provide context, establish standards, and turn AI suggestions into teachable moments building long-term expertise. 🤖 Automated boilerplate Devs tailor scaffolding to real project needs, question assumptions, and refactor early to keep tech-debt in check and systems secure. Speed without judgment can mean: Security vulnerabilities that static analysis can’t spot on its own. Architecture choices that don’t scale beyond the demo. Documentation drift that leaves humans and models guessing. The remedy? Double down on the fundamentals that AI still can’t master. Mastering the fundamentals: 3 key parts of your workflow to focus on when using AI As the home for all developers, we’ve seen it again and again: becoming AI-savvy starts with the old-school basics. You know, the classic tools and features you used before AI became a thing (we know, it’s hard to remember such a time!). We believe that only by mastering the fundamentals can you get the most value, at scale, out of AI developer tools like GitHub Copilot.  A junior developer who jumps into their first AI-assisted project without having a foundational understanding of the basics (like pull requests, code reviews, and documentation) may ship fast, but without context or structure, they risk introducing bugs, missing edge cases, or confusing collaborators. That’s not an AI problem. It’s a fundamentals problem. Let’s revisit the core skills every developer should bring to the table, AI or not. With the help of a few of our experts, we’ll show you how to level them up so you can dominate in the age of AI. 1. Push for excellence in the pull request At the heart of developer collaboration, pull requests are about clearly communicating your intent, explaining your reasoning, and making it easier for others (humans and AI alike!) to engage with your work. A well‑scoped PR communicates why a change exists—not just what changed. That context feeds human reviewers and Copilot alike. As GitHub developer advocate Kedasha Kerr advises, start by keeping your pull requests small and focused. A tight, purposeful pull request is easier to review, less likely to introduce bugs, and faster to merge. It also gives your reviewers, as well as AI tools like Copilot, a clean scope to work with. Your pull request description is where clarity counts. Don’t just list what changed—explain why it changed. Include links to related issues, conversations, or tracking tickets to give your teammates the full picture. If your changes span multiple files, suggest where to start reviewing. And be explicit about what kind of feedback you’re looking for: a quick sanity check? A deep dive? Let your reviewers know. Before you ask for a review, review it yourself. Kedasha recommends running your tests, previewing your changes, and catching anything unclear or unpolished. This not only respects your reviewers’ time, it improves the quality of your code and deepens your understanding of the work. A thoughtful pull request is a signal of craftsmanship. It builds trust with your team, strengthens your communication skills, and gives Copilot better context to support you going forward. That’s a win for you, your team, and your future self. Here’s a quick 5‑item PR checklist to reference as you work:  Scope ≤ 300 lines (or break it up). Title = verb + object (e.g., Refactor auth middleware to async). Description answers “why now?” and links to the issue. Highlight breaking changes with ⚠️ BREAKING in bold. Request

Software development has always been a deeply human, collaborative process. When we introduced GitHub Copilot in 2021 as an “AI pair programmer,” it was designed to help developers stay in the flow, reduce boilerplate work, and accelerate coding. But what if Copilot could be more than just an assistant? What if it could actively collaborate with you—working alongside you on synchronous tasks, tackling issues independently, and even reviewing your code? That’s the future we’re building. Our vision for what’s next  Today, AI agents in GitHub Copilot don’t just assist developers but actively solve problems through multi-step reasoning and execution. These agents are capable of: Independent problem solving: Copilot will break down complex tasks and take the necessary steps to solve them, providing updates along the way. Adaptive collaboration: Whether working in sync with you or independently in the background, Copilot will iterate on its own outputs to drive progress. Proactive code quality: Copilot will proactively assist with tasks like issue resolution, testing, and code reviews, ensuring higher-quality, maintainable code. Rather than fitting neatly into synchronous or asynchronous categories, the future of Copilot lies in its ability to flexibly transition between modes—executing tasks independently while keeping you informed and in control. This evolution will allow you to focus on higher-level decision-making while Copilot takes on more of the execution. Let’s explore what’s already here—and what’s coming next. Why independent agents—and why now? Modern development isn’t linear. We context switch between features, bug fixes, dependency bumps, and reviews every day. A truly useful AI must: Act independently: plan multi‑step tasks and execute them without hand holding. Stay transparent: share its plan and progress, so you can intervene instantly. Earn trust: test its own work and explain every change. Copilot’s new agentic architecture is designed around these guardrails. Copilot in action: Taking steps toward our vision  Agent mode: A real-time AI teammate inside your IDE If you’ve used agent mode with GitHub Copilot (and you should, because it’s fantastic), you’ve already experienced an independent AI agent at work.  Agent mode lives where you code and feels like handing your computer to a teammate for a minute: it types on your screen while you look on, and can grab the mouse. When you prompt it, the agent takes control, works through the problem, and reports its work back to you with regular check-in points. It can: Read your entire workspace to understand context. Plan multi‑step fixes or refactors (and show you the plan first). Apply changes, run tests, and iterate in a tight feedback loop. Ask for guidance whenever intent is ambiguous. Run and refine its own work through an “agentic loop”—planning, applying changes, testing, and iterating. Rather than just responding to requests, Copilot in agent mode actively works toward your goal. You define the outcome, and it determines the best approach—seeking feedback from you as needed, testing its own solutions, and refining its work in real time.  Think of it as pair programming in fast forward: you’re watching the task unfold in real time, free to jump in or redirect at any step. ✨ Coding agent: An AI teammate that works while you don’t  Not all coding happens in real time. Sometimes, you need to hand off tasks to a teammate and check back later. That’s where our coding agent comes in—and it’s our first step in transforming Copilot into an independent agent. Coding agent spins up its own secure dev environment in the cloud. You can assign multiple issues to Copilot, then dive into other work (or grab a cup of coffee!) while it handles the heavy lifting. It can: Clone your repo and bootstrap tooling in isolation. Break the issue into steps, implement changes, and write or update tests. Validate its work by running your tests and linter. Open a draft PR and iterate based on your PR review comments. Stream progress updates so you can peek in—or jump in—any time. Working with coding agent is like asking a teammate in another room—with their own laptop and setup—to tackle an issue. You’re free to work on something else, but you can pop in for status or feedback whenever you like. Less TODO, more done: The next stage of Copilot’s agentic future The next stage of Copilot is being built on three converging pillars: Smarter, leaner models. Ongoing breakthroughs in large language models keep driving accuracy up while pushing latency and cost down. Expanded context windows now span entire monoliths, giving Copilot the long-range “memory” it needs to reason through complex codebases and return answers grounded in your real code. Deeper contextual awareness. Copilot increasingly understands the full story behind your work—issues, pull-request history, dependency graphs, even private runbooks and API specs (via MCP). By tapping this richer context, it can suggest changes that align with project intent, not just syntax. Open, composable foundation. We’re designing Copilot to slot into your stack—not the other way around. You choose the editor, models, and tools; Copilot plugs in, learns your patterns, and amplifies them. You’re in the driver’s seat, steering the AI to build, test, and ship code faster than ever. Taken together, these pillars move Copilot beyond a single assistant toward a flexible AI teammate—one that can help any team, from three developers in a garage to thousands in a global enterprise, plan, code, test, and ship with less friction and more speed. So, get ready for what’s next. The next wave is already on its way.  Learn more about GitHub Copilot > The post From pair to peer programmer: Our vision for agentic workflows in GitHub Copilot appeared first on The GitHub Blog. ​ News & insights, Product, agentic AI, generative AI, GitHub Copilot The GitHub Blog

What if you could spot the weakest link in your software supply chain before it breaks? With GitHub’s dependency graph, you can. By providing a clear, complete view of the external packages your code depends on, both directly and indirectly, it allows you to understand, secure, and manage your project’s true footprint. If you’re like me and sometimes lose track of what’s actually powering your applications (we’ve all been there!), GitHub’s dependency graph is about to become your new best friend.  What is the dependency graph? Here’s the thing: Every modern software project is basically an iceberg. That small manifest file with your direct dependencies seems quite harmless at first glance. But underneath? There’s this massive, hidden world of transitive dependencies that most of us never think about. The GitHub dependency graph maps this entire underwater world. Think of it like a family tree, but for your code. Each package is a family member, and each dependency relationship shows who’s related to whom (and trust me, some of these family trees get really complicated). Each package is a node. Each dependency relationship is an edge. The result? A full visual and structured representation of your software’s external codebase. In some cases, 95–97% of your code is actually someone else’s. The dependency graph helps you make sense of that reality. GitHub engineer Eric Sorenson Let that sink in for a moment. We’re basically curators of other people’s work, and the dependency graph finally helps us make sense of that reality. Why it matters When vulnerabilities are discovered in open source packages, the consequences ripple downstream. If you don’t know a vulnerable dependency is part of your project, it’s hard to take action. The dependency graph isn’t just a cool visualization (though it is pretty neat to look at). It’s the foundation that makes Dependabot alerts possible. When a security issue is found in any of your dependencies (even a transitive one), GitHub notifies you. You get the full picture of what’s in your supply chain, how it got there, and what you can actually do about it. See it in action: From 21 to 1,000 dependencies Eric showed us a project that looked innocent enough: 21 direct dependencies (the ones actually listed in package.json) 1,000 total dependencies (including everything that got pulled in along the way) With the dependency graph, you can finally: Understand which dependencies are direct vs. transitive Trace how a package like Log4j ended up in your codebase. (Spoiler: it probably came along for the ride with something else.) Know what’s yours to fix and what depends on an upstream maintainer Tighten your supply chain with Dependabot Dependabot runs on top of the dependency graph—so enabling the graph is what makes Dependabot’s vulnerability alerts and automatic fix suggestions possible.  Pro tip: Filter for direct dependencies first. These are the ones you can actually control, so focus your energy there instead of pulling your hair out over transitive dependencies that are someone else’s responsibility. How to enable the dependency graph You can enable the dependency graph in your repository settings under Security > Dependency Graph. If you turn on Dependabot, the graph will be enabled automatically. Using GitHub Actions? Community-maintained actions can generate a Software Bill of Materials (SBOM) and submit it to GitHub’s Dependency submission API, even if your language ecosystem doesn’t support auto-discovery. ✅ The best part? Dependency graph is free for all public repositories. Private repos need GitHub Advanced Security to use Dependabot alerts, but the graph itself is free. TL;DR You can’t secure what you can’t see. GitHub’s dependency graph gives you visibility into the 90%+ of your codebase that comes from open source libraries and helps you take action when it counts. Enable it today (seriously, do it now) Use it with Dependabot for automated alerts and fixes Finally discover what’s actually in your software supply chain Your future self (and your security team) will thank you. Want to learn more about the GitHub dependency graph? Explore the documentation > The post Understand your software’s supply chain with GitHub’s dependency graph appeared first on The GitHub Blog. ​ Security, Supply chain security, Dependabot, dependency graph, supply chain The GitHub Blog

The open source Git project just released Git 2.50 with features and bug fixes from 98 contributors, 35 of them new. We last caught up with you on the latest in Git back when 2.49 was released. 💡 Before we get into the details of this latest release, we wanted to remind you that Git Merge, the conference for Git users and developers is back this year on September 29-30, in San Francisco. Git Merge will feature talks from developers working on Git, and in the Git ecosystem. Tickets are on sale now; check out the website to learn more. With that out of the way, let’s take a look at some of the most interesting features and changes from Git 2.50. Improvements for multiple cruft packs When we covered Git 2.43, we talked about newly added support for multiple cruft packs. Git 2.50 improves on that with better command-line ergonomics, and some important bugfixes. In case you’re new to the series, need a refresher, or aren’t familiar with cruft packs, here’s a brief overview: Git objects may be either reachable or unreachable. The set of reachable objects is everything you can walk to starting from one of your repository’s references: traversing from commits to their parent(s), trees to their sub-tree(s), and so on. Any object that you didn’t visit by repeating that process over all of your references is unreachable. In Git 2.37, Git introduced cruft packs, a new way to store your repository’s unreachable objects. A cruft pack looks like an ordinary packfile with the addition of an .mtimes file, which is used to keep track of when each object was most recently written in order to determine when it is safe1 to discard it. However, updating the cruft pack could be cumbersome–particularly in repositories with many unreachable objects–since a repository’s cruft pack must be rewritten in order to add new objects. Git 2.43 began to address this through a new command-line option: git repack –max-cruft-size. This option was designed to split unreachable objects across multiple packs, each no larger than the value specified by –max-cruft-size. But there were a couple of problems: If you’re familiar with git repack’s –max-pack-size option, –max-cruft-size’s behavior is quite confusing. The former option specifies the maximum size an individual pack can be, while the latter involves how and when to move objects between multiple packs. The feature was broken to begin with! Since –max-cruft-size also imposes on cruft packs the same pack-size constraints as –max-pack-size does on non-cruft packs, it is often impossible to get the behavior you want. For example, suppose you had two 100 MiB cruft packs and ran git repack –max-cruft-size=200M. You might expect Git to merge them into a single 200 MiB pack. But since –max-cruft-size also dictates the maximum size of the output pack, Git will refuse to combine them, or worse: rewrite the same pack repeatedly. Git 2.50 addresses both of these issues with a new option: –combine-cruft-below-size. Instead of specifying the maximum size of the output pack, it determines which existing cruft pack(s) are eligible to be combined. This is particularly helpful for repositories that have accumulated many unreachable objects spread across multiple cruft packs. With this new option, you can gradually reduce the number of cruft packs in your repository over time by combining existing ones together. With the introduction of –combine-cruft-below-size, Git 2.50 repurposed –max-cruft-size to behave as a cruft pack-specific override for –max-pack-size. Now –max-cruft-size only determines the size of the outgoing pack, not which packs get combined into it. Along the way, a bug was uncovered that prevented objects stored in multiple cruft packs from being “freshened” in certain circumstances. In other words, some unreachable objects don’t have their modification times updated when they are rewritten, leading to them being removed from the repository earlier than they otherwise would have been. Git 2.50 squashes this bug, meaning that you can now efficiently manage multiple cruft packs and freshen their objects to your heart’s content. [source, source] Incremental multi-pack reachability bitmaps ​​Back in our coverage of Git 2.47, we talked about preliminary support for incremental multi-pack indexes. Multi-pack indexes (MIDXs) act like a single pack *.idx file for objects spread across multiple packs. Multi-pack indexes are extremely useful to accelerate object lookup performance in large repositories by binary searching through a single index containing most of your repository’s contents, rather than repeatedly searching through each individual packfile. But multi-pack indexes aren’t just useful for accelerating object lookups. They’re also the basis for multi-pack reachability bitmaps, the MIDX-specific analogue of classic single-pack reachability bitmaps. If neither of those are familiar to you, don’t worry; here’s a brief refresher. Single-pack reachability bitmaps store a collection of bitmaps corresponding to a selection of commits. Each bit position in a pack bitmap refers to one object in that pack. In each individual commit’s bitmap, the set bits correspond to objects that are reachable from that commit, and the unset bits represent those that are not. Multi-pack bitmaps were introduced to take advantage of the substantial performance increase afforded to us by reachability bitmaps. Instead of having bitmaps whose bit positions correspond to the set of objects in a single pack, a multi-pack bitmap’s bit positions correspond to the set of objects in a multi-pack index, which may include objects from arbitrarily many individual packs. If you’re curious to learn more about how multi-pack bitmaps work, you can read our earlier post Scaling monorepo maintenance. However, like cruft packs above, multi-pack indexes can be cumbersome to update as your repository grows larger, since each update requires rewriting the entire multi-pack index and its corresponding bitmap, regardless of how many objects or packs are being added. In Git 2.47, the file format for multi-pack indexes became incremental, allowing multiple multi-pack index layers to be layered on top of one another forming a chain of MIDXs. This made it much easier to add objects to your repository’s MIDX, but the incremental MIDX format at the time did not

Managing issues in software development can be tedious and time-consuming. But what if your AI peer programmer could streamline this process for you? GitHub Copilot‘s latest issue management features can help developers create, organize, and even solve issues. Below, we’ll dig into these features and how they can save time, reduce friction, and maintain consistency across your projects. 1. Image to issue: Turn screenshots into instant bug reports Writing detailed bug reports is often repetitive and frustrating, leading to inconsistent documentation. Copilot’s image to issue feature significantly reduces this friction. Simply paste a screenshot of the bug into Copilot chat with a brief description prompt Copilot to create an issue for you, then Copilot will analyze the image and generate a comprehensive bug report for you. No more struggling to describe visual glitches or UI problems—the image will speak for itself, and Copilot will handle the documentation. For example, if you encounter a UI alignment issue or a visual glitch that’s hard to describe, just capture a screenshot, paste it into Copilot, and briefly mention the problem. In the animation above, the user’s prompt was “create me a bug issue because markdown tables are not rendering properly in the comments.” Copilot then automatically drafted a report, including steps to reproduce the bug. To get the most out of this feature, consider annotating your screenshots clearly—highlighting or circling the problematic area—to help Copilot generate even more precise issue descriptions. Dive into the documentation to learn more. 2. Get the details right: Templates, tags, and types Projects quickly become disorganized when team members skip adding proper metadata. Incorrect templates, missing labels, or wrong issue types make tracking and prioritization difficult. Copilot solves this by automatically inferring the best template based on your prompt. It also adds appropriate labels and issue types without requiring you to navigate multiple dropdown menus or memorize tagging conventions. Need something specific? Simply ask Copilot to add particular labels or switch templates. If you change templates after drafting, Copilot will automatically reformat your content—no manual copying required. 3. Stay organized with versioning and milestones Keeping issues updated and properly categorized is crucial for clear communication, maintaining project velocity, and ensuring visibility into progress. But with so much else to do, it’s easy to let this work fall by the wayside. With Copilot, adding projects and milestones is as simple as typing a prompt. You can also specify exactly how you want issues organized. For example, ask Copilot to use the “Bug Report” or “Feature Request” template, add labels like priority: high, frontend, or needs-triage, or set the issue type to “Task” or “Epic.” Copilot will apply these details automatically, ensuring your issues are consistently categorized. Additionally, Copilot tracks all changes, making them easily referenceable. You can review issue history and revert changes if needed, ensuring nothing important gets lost. 4. Batch create multiple issues at once Sometimes you need to log several issues after a customer meeting, user testing session, or bug bash. Traditionally, this means repeating the same creation process multiple times. Copilot supports multi-issue drafting, allowing you to create multiple issues in a single conversation. Whether logging feature requests or documenting bugs, batch creation saves significant time. Simply prompt Copilot to create the issues, describe each one, and Copilot will draft them all. For example, you could give the following prompt to create two issues at once: Create me issues for the following features: – Line breaks ignored in rendered Markdown despite double-space – Bold and italic Markdown styles not applied when combined You will still need to review and finalize each one, but the drafting process is streamlined into a single workflow. 5. Let AI help fix your bugs with Copilot coding agent Creating issues is only half the battle—fixing them is where the real work begins. You can now assign issues directly to Copilot. Just ask Copilot coding agent to take ownership of the issue, and your AI coding assistant will start analyzing the bug. Copilot can even suggest draft pull requests with potential fixes. This seamless handoff reduces context-switching and accelerates resolution times, allowing your team to focus on more complex challenges. Beyond Copilot: Issues enhancements on GitHub While Copilot is already revolutionizing issue management, we at GitHub are always looking for ways to enhance the overall issues experience. For example, you can now: Standardize issue types across repositories for consistent tracking and reporting. Break down complex tasks into sub-issues for better progress management. Use advanced search capabilities with logical operators to quickly find exactly what you need. Manage larger projects with expanded limits supporting up to 50,000 items. Kickstart enhanced issue management today Ready to transform your issue management workflow with GitHub Copilot? Head to github.com/copilot and try prompts like: “Create me an issue for…” “Log a bug for…” Or simply upload a screenshot and mention you want to file a bug. Experience firsthand how Copilot makes issue management feel less like administrative overhead and more like a conversation with your AI pair programmer. Learn more about creating issues with Copilot > The post 5 tips for using GitHub Copilot with issues to boost your productivity appeared first on The GitHub Blog. ​ AI & ML, GitHub Copilot, generative AI, GitHub Issues The GitHub Blog

When generative AI tools guess what you need, the magic only lasts as long as the guesses are right. Add an unfamiliar codebase, a security checklist your team keeps in a wiki, or a one‑off Slack thread that explains why something matters, and even the most and even the most powerful model may fill in gaps with assumptions rather than having access to your specific context and knowledge. GitHub Copilot Spaces fixes that problem by letting you bundle the exact context Copilot should read—code, docs, transcripts, sample queries, you name it—into a reusable “space.” Once a space is created, every Copilot chat, completion, or command is grounded in that curated knowledge, producing answers that feel like they came from your organization’s resident expert instead of a generic model.  In this article, we’ll walk through: A 5‑minute quick‑start guide to creating your first space Tips for personalizing Copilot’s tone, style, and conventions with custom instructions Real‑world recipes for accessibility, data queries, and onboarding Collaboration, security, and what’s next on the roadmap (spoiler: IDE integration and Issues/PR support) Want to learn more? Try our Docs.  We have everything you need to get started—including pro tips on the context that’s most helpful in your workflows. Explore Docs > Why context is the new bottleneck for AI‑assisted development Large language models (LLMs) thrive on patterns, but day‑to‑day engineering work is full of unpatterned edge cases, including: A monorepo that mixes modern React with legacy jQuery Organizational wisdom buried in Slack threads or internal wikis Organization‑specific security guidelines that differ from upstream OSS docs Without that context, an AI assistant can only guess. But with Copilot Spaces, you choose which files, documents, or free‑text snippets matter, drop them into a space, and let Copilot use that context to answer questions or write code. As Kelly Henckel, PM for GitHub Spaces, said in our GitHub Checkout episode, “Spaces make it easy to organize and share context, so Copilot acts like a subject matter expert.” The result? Fewer wrong guesses, less copy-pasting, and code that’s commit-ready. What exactly is a Copilot Space? Think of a space as a secure, shareable container of knowledge plus behavioral instructions: What it holds Why it matters Attachments Code files, entire folders, Markdown docs, transcripts, or any plain text you add Gives Copilot the ground truth for answers Custom instructions Short system prompts to set tone, coding style, or reviewer expectations Lets Copilot match your house rules Sharing & permissions Follows the same role/visibility model you already use on GitHub No new access control lists to manage Live updates Files stay in sync with the branch you referenced Your space stays up to date with your codebase Spaces are available to anyone with a Copilot license (Free, Individual, Business, or Enterprise) while the feature is in public preview. Admins can enable it under Settings  > Copilot > Preview features. TL;DR: A space is like pinning your team’s collective brain to the Copilot sidebar and letting everyone query it in plain language. Quick-start guide: How to build your first space in 5 minutes Navigate to github.com/copilot/spaces and click Create space. Name it clearly. For example, frontend‑styleguide. Add a description so teammates know when—and when not—to use it. Attach context: From repos: Pull in folders like src/components or individual files such as eslint.config.js. Free‑text hack: Paste a Slack thread, video transcript, onboarding checklist, or even a JSON schema into the Text tab. Copilot treats it like any other attachment. Write custom instructions. A sentence or two is enough: “Respond as a senior React reviewer. Enforce our ESLint rules and tailwind class naming conventions.” Save and test it. You’re done. Ask Copilot a question in the Space chat—e.g., “Refactor this <Button> component to match our accessibility checklist”—and watch it cite files you just attached. Pro tip: Keep spaces focused Instead of dumping your entire repo into one space, create smaller, purpose‑built spaces like: Accessibility, Data‑Queries, Auth‑Model, etc. Kelly, the PM behind the feature, uses this pattern internally at GitHub to make subject‑matter expertise reusable.  Personalize Copilot’s coding style (and voice, too)  Custom instructions are the “personality layer” of a space and where spaces shine because they live alongside the attachments. This allows you to do powerful things with a single sentence, including: Enforce conventions  “Always prefer Vue 3 script setup syntax and Composition API for examples.” Adopt a team tone “Answer concisely. Include a one‑line summary before code blocks.” Teach Copilot project‑specific vocabulary  “Call it ‘scenario ID’ (SCID), not test case ID.” During the GitHub Checkout interview, Kelly shared how she built a personal space for a nonprofit side project: She attached only the Vue front‑end folder plus instructions on her preferred conventions, and Copilot delivered commit‑ready code snippets that matched her style guide on the first try. Automate your workflow: three real‑world recipes 1. Accessibility compliance assistant Space ingredients Markdown docs on WCAG criteria and GitHub’s internal “Definition of Done” Custom instruction: “When answering, cite the doc section and provide a code diff if changes are required.” How it helps: Instead of pinging the accessibility lead on Slack, you can use Spaces to ask questions like “What steps are needed for MAS‑C compliance on this new modal?” Copilot summarizes the relevant checkpoints, references the doc anchor, and even suggests ARIA attributes or color‑contrast fixes. GitHub’s own accessibility SME, Katherine, pinned this space in Slack so anyone filing a review gets instant, self‑service guidance. 2. Data‑query helper for complex schemas Space ingredients YAML schema files for 40+ event tables Example KQL snippets saved as .sql files Instruction: “Generate KQL only, no prose explanations unless asked.” How it helps: Product managers and support engineers who don’t know your database structures can ask, “Average PR review time last 7 days?” Copilot autocompletes a valid KQL query with correct joins and lets them iterate. Result: lets PMs and support self-serve without bugging data science teams. 3. Onboarding Hub and knowledge base in one link Space ingredients Key architecture diagrams exported as SVG text ADRs and design docs from multiple repos Custom instruction: