An engineering team maintains a payment API, an analytics service and a mobile client in one repository. Its AI assistant writes code that looks correct in isolation but uses the wrong error format, ignores the payment project’s lint rules, and changes files the mobile team owns. The developers try to fix this by pasting a page of instructions into every chat. A better approach is to provide reusable, appropriately scoped project guidance and explicitly identify the tools and trusted context that each task may use.
GitHub’s current customization reference describes repository instructions, path-specific instructions, prompt files, custom agents and skills. The GH-300 exam guide also calls out context crafting, reusable prompts, agent sessions and the Model Context Protocol (MCP). These mechanisms differ in persistence, supported surfaces and tool authority; they should not be described as interchangeable ways to make a model “remember everything.”
Use repository instructions for stable conventions
A repository-wide instruction can state supported runtime versions, coding standards, testing commands, security expectations, and architectural boundaries. Its value is consistency across related requests. An instruction that says all database access must enforce tenant scope is more durable than one giving a one-time fix for a specific failing test.
Keep the file concise enough to remain useful. Explain how to discover the correct conventions and where detailed standards live. A hundred contradictory rules can reduce clarity. GitHub documents a commonly supported .github/copilot-instructions.md file, but support differs by surface and should be checked rather than presumed identical across every tool.
Apply path-specific guidance to genuinely different modules
A monorepo may have Python services, a TypeScript frontend, and deployment configuration. Path-specific instructions allow appropriate tools to use conventions relevant to a target path. A Python package may require strict type checks and integration tests; a frontend component may follow separate accessibility rules. Broad repository guidance should establish shared safety requirements, while local instructions add the relevant details.
Test the intended matching behavior before relying on it. A document in a path not consulted by a particular surface may never affect the request. Explicitly mention the appropriate source file when uncertain, and ask the assistant to identify which instructions it used. Do not assume that a file sitting in a repository automatically reached the current model context.
Use prompt files for repeatable tasks, not global policy
A reusable prompt is useful when engineers regularly review APIs, generate test plans, or prepare release notes with the same output shape. It can ask the tool to list endpoint changes, compatibility risks, required negative tests and unverified behavior. That is a repeatable workflow rather than a permanent repository-wide rule.
A release checklist prompt should not have authority to disable code scanning because a single project failed. Similarly, a security-review prompt can direct the assistant to inspect authentication boundaries but cannot grant the assistant access to restricted secrets or production systems. The most useful distinction is whether the text describes enduring policy or one task invocation.
Separate MCP tools from plain-language context
Model Context Protocol integrations can give a supported assistant structured access to data or actions from external systems. A retrieved issue, test result or deployment status can improve context, but a tool that can create branches or edit tickets also introduces operational authority. Before connecting a tool, decide which resources it may read, which actions it may take, and who approves mutations.
MCP output should be treated as lower-trust data. A ticket description could contain malicious instructions to export an environment file. A tool call that can read confidential resources may return more than the actual question requires. The prompt-injection security treatment clarifies why tool access and instruction priority must remain distinct.
Preserve the difference between agent skills and permissions
Specialized agents and reusable skills may supply procedures, domain context or task preferences, but they do not replace permission checks. An agent configured to perform code review can explain risks, propose a patch, or identify tests. Whether it may merge a pull request or call a cloud API should still depend on the platform's authorization, repository policy, and human approvals.
Review where instruction files apply in each environment. GitHub’s support matrix identifies differences between IDEs, cloud agents, CLI and code review. This matters when an organization tells developers that one exclusion or customization works “everywhere”: the same file may be recognized by one surface and ignored by another.
Keep sensitive context out of convenience documentation
Never place secrets, private signing keys or live customer records in a prompt file simply to make repeated AI requests easier. A stable instruction can instead direct developers to a nonsecret test fixture or explain how to request approved access. Developer tools frequently read repository files as context, so a broadly available instruction file is an inappropriate secret store.
The secure build secrets article addresses the same separation: shared development instructions may point to credential-handling practice, but credentials themselves belong in controlled stores. This protects both human collaborators and agent workflows.
Measure customization by prevented errors
Choose one recurring failure, such as the wrong API error schema, then introduce a concise repository instruction with the true contract and a link to its tests. Ask the assistant to implement a narrow change, run the tests, and inspect whether the mistake still occurs. If it does, confirm that the relevant tool consumed the instruction and whether the prompt supplied conflicting constraints.
Do not respond to every failure by adding more text. Sometimes the codebase’s test suite is inadequate or the assistant simply needs a small example. Sometimes a permission policy, not an instruction file, should prevent the dangerous action. GH-300 asks developers to choose the mechanism that addresses the real source of the error: context, repeatability, tool reach, or independent verification.