agentleFS
MicrosoftKnown publishermicrosoft/Agentic-Shiksha/Agentic Shiksha Platform/Backend/.github/copilot-instructions.md

Agentic-Shiksha / Backend

Copilot instructions1 starsChanged 45 days agoMITView on GitHub

Single-service Python 3.13.5 FastAPI backend on Azure (AI Foundry agents, Cosmos DB, Blob, AI Search), with Python 3.11 compatibility retained in CI. Follow every rule below. Flag any rule you must break and why.

  • Reads credentials
  • Where files are headingNew Copilot instructions files have more rules about branches and pull requests, and fewer about code style.

    Of the Copilot instructions files we read, the 2,336 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

  • In this repositoryOne other file it gives its agents.

The file

We split this copilot-instructions.md into the rules it gives an agent

12 rules. About 0 are common, 4 are distinctive, and 8 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Treat repo memory files as hints only.

    line 7
  2. Distinctive:

    Never guess file locations - search first.

    line 8
  3. Distinctive:

    When generating code, include the matching test in the same output.

    line 9
  4. Very specific:

    Ask which router/domain if placement is ambiguous - never add to backend/main.py.

    line 10
  5. Very specific:

    Never put credentials, tokens, connection strings, or copied .env values in PLAN.md.

    line 13
  6. Distinctive:

    No credential fallbacks in code.

    line 18
  7. Very specific:

    Every endpoint that reads or writes user/org data requires auth via shared dependencies: get_current_active_user() / require_roles(...).

    line 19
  8. Very specific:

    Use SecretStr for secrets in settings.

    line 20
  9. Very specific:

    When touching an existing main.py endpoint, migrate it to its router in the same PR if the change is non-trivial.

    line 26
  10. Very specific:

    All environment access through pydantic_settings.BaseSettings models (Azure, auth, storage, models, CORS).

    line 31
  11. Very specific:

    Every route: typed Pydantic request model and response_model=.

    line 36
  12. Very specific:

    Every bugfix ships a regression test.

    line 66

≈ “Common” is an estimate: at least 1 in 5 of the 3,779 Copilot instructions files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
copilot-instructions.md

Copilot Instructions - EKALAIVA Backend (Python / FastAPI / Azure)

Single-service Python 3.13.5 FastAPI backend on Azure (AI Foundry agents, Cosmos DB, Blob, AI Search), with Python 3.11 compatibility retained in CI. Follow every rule below. Flag any rule you must break and why.

Ground rules for you (the agent)

  • Treat repo memory files as hints only. Re-verify any security, metric, or line-count claim against the working tree (git ls-files, grep) before reporting it.
  • Never guess file locations - search first.
  • When generating code, include the matching test in the same output.
  • Ask which router/domain if placement is ambiguous - never add to backend/main.py.
  • PLAN.md is the tracked source of truth for the compliance refactor. Read it before acting, execute only its active phase, and update each item to accomplished, in_progress, or not_started only after verifying the working tree.
  • Complete one PLAN.md phase per session or PR. Stop after its acceptance checks, record the phase report, and report files changed, checks run, and unresolved work before starting another phase.
  • Never put credentials, tokens, connection strings, or copied .env values in PLAN.md.

Security (non-negotiable)

  • .env must never be tracked. .env.example (value-free) is the contract. If you find a tracked secret file: stop, tell me, do not copy its values anywhere.
  • No credential fallbacks in code. No hardcoded client secrets, JWT secrets, endpoints, or resource IDs. App must fail at startup if a required secret is missing - never fall back to a predictable default.
  • Every endpoint that reads or writes user/org data requires auth via shared dependencies: get_current_active_user() / require_roles(...). These verify JWT -> re-fetch user from Cosmos -> require status == "active" -> enforce role. Missing/invalid auth is 401/403 - NEVER a bypass, NEVER treated as admin. No "Dashboard mode" exceptions.
  • Use SecretStr for secrets in settings. Never log secret values.
  • CORS origins come from settings, never inline, never * with credentials.

Structure

  • backend/main.py is frozen for new routes. New endpoints go in routers/<domain>.py (auth, agents, chat, directory, knowledge, ...), request/response models in schemas/<domain>.py, shared deps in dependencies/. App assembled via create_app() keeping the existing lifespan.
  • When touching an existing main.py endpoint, migrate it to its router in the same PR if the change is non-trivial.
  • __init__.py stays thin: re-exports + __all__ only. Heavy imports (torch, transformers, large SDKs) lazy-load inside the class that needs them.

Config

  • All environment access through pydantic_settings.BaseSettings models (Azure, auth, storage, models, CORS). No new os.getenv calls anywhere.
  • Settings validated at startup; enabled feature + missing secret = crash with a clear message.

API boundaries

  • Every route: typed Pydantic request model and response_model=. No Dict[str, Any] payloads on external endpoints.
  • Write-request models: model_config = ConfigDict(extra="forbid").
  • Field(default_factory=list) - never mutable defaults.
  • model_validate() when ingesting Cosmos records, webhook payloads, or LLM JSON output. Define the Pydantic schema before generating structured output; validate the response against it.
  • Pydantic is for boundaries. Internal temporaries may be dataclasses/plain types.

Reliability

  • Tenacity on transient failures only (429, timeouts, 5xx), exponential backoff, respect Retry-After. NEVER retry non-idempotent creates/writes. Account for Azure SDK built-in retry before stacking your own.
  • Expensive clients (AIProjectClient, SearchClient, BlobServiceClient) come from a singleton registry built at startup and cleaned up in lifespan - never constructed per request. Cosmos client already follows this; match it.
  • Long-running jobs (agent creation, deep research): persist a job record in Cosmos - {id, status: PENDING|RUNNING|COMPLETED|FAILED, attempts, progress, output_ref} - with idempotency keys and resume support. No fire-and-forget daemon threads or bare BackgroundTasks for work that must survive restart. Status via SSE or webhook PLUS a pollable status endpoint.

Logging

  • logging.getLogger(__name__) in all modules. print() forbidden in library/service code (CLI/migration scripts exempt). Include correlation/job IDs in job-related logs.

Prompts

  • Prompts live in prompt_store/ as versioned files, never inline strings in Python. Markdown is fine - do not convert to YAML. Move any remaining inline system prompts into the store. Each prompt states its scope restriction explicitly.

Abstractions

  • ABC + @abstractmethod only for genuinely interchangeable implementations with required contracts. Optional lifecycle hooks (e.g. before_chat/after_chat) stay as overridable no-ops - do not make them abstract.

Packaging

  • Target: pyproject.toml + uv.lock (or Poetry), dev group with pytest + ruff, pinned Python 3.13.5 runtime while retaining Python 3.11 compatibility. Until migrated, keep requirements.txt fully pinned. Do not start a disruptive src/ re-layout without being asked.

Testing & CI

  • Every bugfix ships a regression test. New auth/config/persistence logic ships unit tests. Organize tests by behavior, not one-file-per-class.
  • Priority test areas: auth/authz (including disabled users and missing-token paths), settings validation, job state transitions + idempotency, structured-output validation, Cosmos boundaries.
  • CI on every PR: ruff (format+lint), pytest, gitleaks, CodeQL. No merge on red.

Docs

  • Root README = model card: overview, Mermaid architecture, intended use, out-of-scope, limitations, setup. Per-module READMEs carry copy-paste run commands. Documented endpoints must match actual routes - update docs in the same PR that changes behavior.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.