context-engineering — GitHub Copilot rule: context and code structure
A GitHub Copilot rule on file layout, types and comments, so suggestions match your project instead of drifting into generic answers.
.github/instructions/context-engineering.instructions.mdWhat context-engineering does
This is an instruction file, not code. It sets habits that decide how much context Copilot actually sees: descriptive paths instead of src/utils/m.ts, components kept next to their tests and types, explicit type annotations over inference, named constants instead of magic numbers.
Six sections cover project structure, code patterns, working with Copilot, context hints, multi-file changes, and what to do when suggestions go stale or generic. It also recommends a COPILOT.md file for architecture decisions and pointing the model at an existing file as a pattern to follow.
You install it as .github/instructions/context-engineering.instructions.md, and applyTo: ** makes it apply across the repo. Worth checking when completions come back vague: the rule puts the blame on open tabs and cursor position before it blames the model.
What it helps with
- signal module boundaries to Copilot through index exports
- get typed suggestions instead of guesses
- keep components, tests and hooks in one folder
- document architecture for the agent in
COPILOT.md - refactor one file at a time and verify each change
Example prompts for the agent
- Open the auth files in tabs and tell me what to change in the middleware
- List the files you need to update the User model, the API endpoint and the tests
- Follow the same pattern as
src/api/users.ts
How to install context-engineering
Manually: put the files in place
.github/instructions/context-engineering.instructions.mdThe applyTo field sets which files it applies to
Manually: put the files in place
.claude/rules/context-engineering.mdThe paths frontmatter field limits the files: move applyTo from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.cursor/rules/context-engineering.mdcFrontmatter: description, globs, alwaysApply. Move applyTo from the source into globs, or the rule will not attach on its own
Manually: put the files in place
.devin/rules/context-engineering.mdManually: put the files in place
.clinerules/context-engineering.mdStep by step, with commands for each platform: AGENTS.md vs CLAUDE.md: what they are and which one to use
Questions about context-engineering
How do I install context-engineering in GitHub Copilot?
Add .github/instructions/context-engineering.instructions.md to your repository. The applyTo: ** directive at the top turns the rule on for the whole project.
What does context-engineering do?
It describes how to structure code and a project so Copilot understands the context better. Paths, types, names and comments all act as signals for the model.
Why does Copilot give generic answers?
The rule suggests checking your open tabs and cursor position first, since Copilot treats them as context signals. If the files are closed, add constraints and name the framework.
Source text
context-engineering.instructions.md · MIT
--- description: 'Guidelines for structuring code and projects to maximize GitHub Copilot effectiveness through better context management' applyTo: '**' --- # Context Engineering Principles for helping GitHub Copilot understand your codebase and provide better suggestions. ## Project Structure - **Use descriptive file paths**: `src/auth/middleware.ts` > `src/utils/m.ts`. Copilot uses paths to infer intent. - **Colocate related code**: Keep components, tests, types, and hooks together. One search pattern should find everything related. - **Export public APIs from index files**: What's exported is the contract; what's not is internal. This helps Copilot understand boundaries. ## Code Patterns - **Prefer explicit types over inference**: Type annotations are context. `function getUser(id: string): Promise<User>` tells Copilot more than `function getUser(id)`. - **Use semantic names**: `activeAdultUsers` > `x`. Self-documenting code is AI-readable code. - **Define constants**: `MAX_RETRY_ATTEMPTS = 3` > magic number `3`. Named values carry meaning. ## Working with Copilot - **Keep relevant files open in tabs**: Copilot uses open tabs as context signals. Working on auth? Open auth-related files. - **Position cursor intentionally**: Copilot prioritizes code near your cursor. Put cursor where context matters. - **Use Copilot Chat for complex tasks**: Inline completions have minimal context. Chat mode sees more files. ## Context Hints - **Add a COPILOT.md file**: Document architecture decisions, patterns, and conventions Copilot should follow. - **Use strategic comments**: At the top of complex modules, briefly describe the flow or purpose. - **Reference patterns explicitly**: "Follow the same pattern as `src/api/users.ts`" gives Copilot a concrete example. ## Multi-File Changes - **Describe scope first**: Tell Copilot all files involved before asking for changes. "I need to update the User model, API endpoint, and tests." - **Work incrementally**: One file at a time, verifying each change. Don't ask for everything at once. - **Check understanding**: Ask "What files would you need to see?" before complex refactors. ## When Copilot Struggles - **Missing context**: Open the relevant files in tabs, or explicitly paste code snippets. - **Stale suggestions**: Copilot may not see recent changes. Re-open files or restart the session. - **Generic answers**: Be more specific. Add constraints, mention frameworks, reference existing code.
© github · MIT · github/awesome-copilot
