Monorepo Prompt Gives the Wrong Stack

@workspace is a retrieval hint, not a guarantee that Copilot knows your conventions.

The workspace index may be large, stale, or ranked toward recently opened or semantically similar files. Eight open tabs, including a React app and a Java service, add noise: the model sees context, but not necessarily the files that define the payments standard. @workspace can find relevant files, yet it will not infer that Contoso.Http is mandatory or that Thread.Sleep is banned unless that information is present and prominent.

Attach precise context:

• #file for PaymentsClient.cs, one existing usage of Contoso.Http, the package version file, and a representative xUnit/WireMock test.
• #selection for the method to change, so the request is anchored.
• A short statement of conventions in the prompt: use IHttpClientFactory, Polly through Contoso.Http, cancellation tokens, structured logging, no Thread.Sleep, no real network in unit tests.
• An example of an existing retry policy, because a concrete pattern is stronger than an adjective.

Close unrelated tabs or start a new chat to reduce accidental context. If the repo is too large for reliable retrieval, use #codebase deliberately and then verify the cited files, or attach files explicitly.

Prompt outline:

You are editing src/Payments/PaymentsClient.cs in the Fabrikam monorepo. Goal: add retry logic to SendPaymentAsync using the existing Contoso.Http package. Constraints: use IHttpClientFactory; configure retries through Contoso.Http Polly policies; honor CancellationToken; use structured logging; do not use Thread.Sleep, RestSharp, or direct HttpClient construction; do not add new packages. Follow the pattern in src/Orders/OrderClient.cs (attached). Tests: add xUnit tests using WireMock; no real network calls; cover transient 503 then success, timeout, and cancellation. First return a short plan listing files and risks. After I approve, return a unified diff and the exact test command. If a requirement is ambiguous, ask one question before editing.

Why this works: it names the files, the mandatory package, the anti-patterns, the acceptance tests, and the output format. The plan step prevents a large unreviewable patch. The diff request makes review easier than prose. The single clarifying question avoids a long interrogation.

Verification: run the targeted test project, then the full payments test suite; inspect the diff for package changes and logging fields. Do not accept the patch until the retry policy is visible in configuration, not buried in a helper.

Repository instructions vs task prompt file.

.github/copilot-instructions.md is for durable, repo-wide conventions that should apply to almost every chat: 'Use Contoso.Http for all outbound HTTP; never use Thread.Sleep; all public async methods take CancellationToken; tests use xUnit and WireMock; do not add packages without approval.' Keep it short and testable. If it becomes a 10-page style guide, it competes with the actual task context.

A .prompt.md file is for a repeatable task with parameters: 'Add retry to a payments client', with placeholders for the target file, the reference implementation, and the test project. It can include the plan-then-diff workflow and the acceptance checks. Use it when the same request recurs across teams or services.

Do not put secrets, internal hostnames, or customer data in either file. Review both like code: they change model behavior and should have owners. Start with instructions for the three rules that are violated most often, then add a prompt file for the payments migration. Measure whether the generated patches need fewer review comments before expanding.