It’s Blogvent, day 19, where I blog daily in December!

If you’ve bounced around GitHub before, it’s likely you’ve seen a .github/ folder at the top-level of a repository. You might have even seen a .github repository in some organizations!

This is incredibly hard to look up online, as you can imagine. It’s even admittedly a bit challenging to find out all that it can do in the documentation itself because of how it’s named. So, look no further, here’s all you can do (currently!) with .github!

.github everywhere

Long story short: if you see .github, it’s a magical thing that configures GitHub for you.

In a repository, the .github folder is a special directory used to store community health files, repository settings, automation workflows, and GitHub Copilot configuration files. GitHub automatically recognizes and uses specific files within this folder to customize the repository experience for contributors and maintainers!

In an organization, the .github repository is for “default community health files” for the repositories in your org. That means if you have an organization with like… 10 repositories, they will all default to the configurations in the .github folder unless they’re overridden in the individual repos.

I’m going to focus on individual repositories with the .github folder for the rest of this post, but here’s the documentation for the .github repository options for you, and here’s a good example of what that repo can look like!

.github in your repository

There’s some convenient things you can put in this folder to get things configured to your liking. As of now, December 2025, here’s what you can do!

(if something in this list ends with .md, that means it’s a markdown file, if it ends with .yml it’s a YAML file, and if it ends with /, that means it’s a folder for markdown or YAML files)

Issue and pull request templates

• ISSUE_TEMPLATE/: Place YAML or Markdown issue templates here. You can have multiple templates for different issue types.
  • Examples: .github/ISSUE_TEMPLATE/bug_report.md or .github/ISSUE_TEMPLATE/feature_request.md
• PULL_REQUEST_TEMPLATE.md or PULL_REQUEST_TEMPLATE/: Template(s) that pre-fill descriptions when someone opens a new PR.

GitHub Actions/workflows

• workflows/: For YAML files that define GitHub Actions workflows.
  • Example: .github/workflows/ci.yml

You can use these to automate CI/CD, linting, deployments, tests, and a bunch of other nice things. Docs here are handy, and here’s an example I have in one of my repos.

Community Health Files

These files help set standards and support for your repo:

• CODE_OF_CONDUCT.md: Set expectations for community behavior
• CONTRIBUTING.md: Guide for people who want to contribute to the project
• FUNDING.yml: Show ways to financially support the project (example)
• SECURITY.md: How to report security vulnerabilities
• SUPPORT.md: Let users know where to ask questions

As a note, if you have these in your individual repository, they will override whatever is in the .github repository in your organization, if that’s configured.

You can put some of these at the root of your repository for easy visibility (like CONTRIBUTING.md), but either way, GitHub will surface those contents in the repo sidebar in a nice UI for folks to find.

Configuration files

These configure features or bots for you repo:

• dependabot.yml: Configures Dependabot to keep your dependencies up-to-date
• CODEOWNERS: Define who owns certain files or paths. When someone opens a PR that touches those files, GitHub will automatically request a review from the listed people.

GitHub Copilot custom instructions and agents

GitHub Copilot’s configuration settings are newest in the list so far, and help with code completion and guardrails for AI tools working in your repos.

• copilot-instructions.md: Instructions here are automatically included in all Copilot requests for your repo across supported IDEs and platforms. This sets your coding standards, preferred libraries, name conventions, etc. Docs here.
• instructions/: Every file in here should be named *.instructions.md (replace * with the file name). This is for storing multiple, file-specific, or directory-specific instruction files. Each file in here can describe rules for a particular feature, language, file type, or folder. Docs here for what your syntax should look like, and here’s some good examples.
• agents/: Similar to .instructions, every file in here should be named *.agent.md. This is for configuring the Github Copilot coding agent to do specific things. Here’s a repo of a bunch of example custom agents you can use .
  • I literally learned while writing this post that you can make a .github-private repository in your organization specifically for configuring default custom agents. Who knew? Don’t tell my boss. Anyway, here’s a template repo for that and docs about these in general.
• prompts/: Also similar to .instructions! Every file should be named *.prompt.md. This lets you add reusable commands to GitHub Copilot. Docs here and handy examples here.

Oh my word stop

Okay I think that’s it. There’s so many things you can do. I’m exhausted. There’s actually more types of configurations you can add to the .github folder depending on the apps and Actions you have configured in your repository (like this one for labeling PRs lets you add labeler.yml, for example). But I’ll let you explore those on your own.

I hope this was handy for you!