home/productivity/copilot-instructions-226

Copilot Instructions

GPTClaudeDeepSeek··331 copies·updated 2026-07-14
copilot-instructions-226.prompt
# Copilot Instructions

GitHub Copilot reads this file as project-level context.
See: https://docs.github.com/en/copilot/customizing-copilot

The rule block below is shared with `AGENTS.md` and `CLAUDE.md` — keep
the three files in sync. The optional GitHub Action in
[ai-coding-rules/examples](https://github.com/xtariohq/ai-coding-rules)
enforces this on every PR.

<!-- ai-coding-rules v1 — https://github.com/xtariohq/ai-coding-rules — MIT -->

## Anti-Hallucination

- Use only functions, types and APIs that demonstrably exist in this repository.
- Before calling a function, verify its signature in the source file. Do not invoke from memory.
- When uncertain about a return type or whether a function exists, ask explicitly instead of guessing.
- Do not invent plausible-looking names (e.g. `getUser()` vs. `getCurrentUser()`).
- Hallucinated route paths, table identifiers or environment variables cause production bugs — look them up.

### Project utilities

Use these helpers correctly. Do not re-implement them.

<!-- TODO: list your project-specific helpers here. Examples (delete and replace):

- `fetchOrder(orderId)` — `src/lib/orders.ts`. Returns `Promise<Order | null>`.
- `createPayment(orderId, amount)` — `src/lib/payments.ts`. Throws on insufficient stock.
- `Order` type — `src/types/order.ts`.
- Table names — always import from `src/db/tables.ts`. Never hardcode.

-->

## Personal Data & Privacy

- No personal data (names, email addresses, usernames, IP addresses, phone numbers) in logs or AI prompts.
- Treat internal identifiers as non-public by default; never expose them in user-facing errors, URLs or analytics events.
- Logger calls only with non-personal fields. `{ orderId, productId }` yes — `{ email, customerName }` no.
- Personal fields may be used for server-side business logic only (auth, billing, notifications), never for diagnostic logging.

## Error Handling & Logging

- Wrap every `fetch()` (or equivalent HTTP client call) in `try/catch` and check the response status before reading the body.
- No `console.log` in production code paths. Use a structured logger with log levels.
- `console.log` is acceptable only in local dev scripts (e.g. `scripts/`).
- Capture third-party and AI-provider errors in your error tracker inside every relevant `catch` block.
- HTTP error responses return a structured JSON shape with an explicit status code. Never leak raw exceptions, stack traces or internal identifiers outward.

<!-- /ai-coding-rules -->

fill the variables

This prompt has 2 variables. Pro fills them into a ready-to-paste prompt for you — no manual find-and-replace.

{orderId, productId}{email, customerName}
Unlock with Pro →

when to use it

Community prompt sourced from the open-source GitHub repo xtariohq/ai-coding-rules (MIT). A "Copilot Instructions" style prompt — adapt the placeholders and specifics to your task. Imported as-is and not independently retested here, so check the output before relying on it.

tags

productivitycommunitydeveloper

source

xtariohq/ai-coding-rules · MIT