Copilot Instructions for Blood Pressure Tracker
Tunes Copilot and contributors to a blood pressure tracker's stack, style, testing, and CI/CD expectations.
What this file does
Tunes Copilot and contributors to a blood pressure tracker's stack, style, testing, and CI/CD expectations.
When to use it
- Onboarding a new developer to the blood pressure tracker repo
- Setting up Copilot to generate code consistent with existing conventions
- Defining a playbook for common tasks like adding a route or component
- Establishing CI/CD expectations with path-filtered jobs
Assumes this stack
Copilot Instructions for Blood Pressure Tracker
These instructions tune Copilot (and human contributors) to work effectively in this repository. They capture the current tech stack, architecture, coding style, testing approach, and CI/CD expectations so generated changes are correct, consistent, and shippable.
Mandatory
As an autonomous agent you will:
- Call vibe_check after planning and before major actions.
- Provide the full user request and your current plan.
- Optionally, record resolved issues with vibe_learn.
Repo map and responsibilities
frontend/— React app (Vite). Tests with Vitest + Testing Library.backend/— FastAPI app (Python 3.11). Tests with pytest.docs/— Developer notes and project documentation..github/workflows/ci.yml— CI for both frontend and backend, with path-based job filtering.README.md— brief project overview.
Tech stack (as-implemented)
Frontend
- React 19, Vite 7
- Vitest 4, jsdom, @testing-library/react, @testing-library/jest-dom
- ESLint 9 (flat config) with react-hooks and react-refresh plugins
- Node 20 in CI
Backend
- Python 3.11
- FastAPI 0.120, Starlette 0.48, Uvicorn 0.38
- Pytest 8, pytest-cov
- Pydantic v2
CI/CD
- GitHub Actions matrix of two jobs: backend (pytest) and frontend (Vitest)
- dorny/paths-filter determines which job runs based on changed folders
- Node setup uses caching keyed by
frontend/package-lock.json - Python setup uses pip cache, optionally Poetry if
pyproject.tomlexists
Conventions and style
General
- Prefer small, focused PRs with tests. Update docs if behavior changes.
- Keep secrets out of the repo. Use
.envlocally and add.env.exampletemplates. - Do not invent files/paths — verify with a repository search before referencing.
- Use deterministic installs: commit
frontend/package-lock.json(allowed via.gitignorenegation).
Frontend (React + Vite)
- Use function components and React hooks. Avoid class components.
- Co-locate tests under
src/__tests__or alongside files as*.test.jsx. - Testing: use Testing Library queries (role/name/label) over brittle selectors.
- Lint: respect
frontend/eslint.config.js(flat config). Fix lint issues as part of your change. - Vitest config is in
frontend/vite.config.js(test.environment=jsdom, setupFiles=vitest.setup.js). - Keep imports ESM-only; the frontend uses ESM with
"type": "module"inpackage.json. - Prefer
fetchfor HTTP in the frontend (no axios installed yet). If you add a client, install and wire tests.
Backend (FastAPI)
- Organize app code under
backend/. Tests live underbackend/tests/. - Prefer creating an
app/main.pywith the FastAPI instance and modular routes. - Use Pydantic v2 models for request/response schemas.
- Write pytest tests using
TestClientfromfastapi.testclient. - Keep dependencies pinned in
requirements.txt. If you add dev tools, put them inrequirements-dev.txt(one package per line).
Testing policy
- Every feature or bugfix should include at least 1-2 tests (happy path + one edge case).
- Frontend tests use Vitest + Testing Library and run in jsdom.
- Backend tests use pytest; avoid hitting the network or real databases in unit tests.
- If you add a new public API (route/component), add a test demonstrating its contract.
CI/CD expectations and gotchas
- Jobs are filtered by path changes:
- Changes under
frontend/**trigger the frontend job. - Changes under
backend/**trigger the backend job. - If you add shared paths that should trigger both, extend the
filtersblock in.github/workflows/ci.yml.
- Changes under
- Frontend dependency caching uses
frontend/package-lock.json. Ensure it is committed. - Node runs on version 20; keep local Node in the same major version for parity.
- Python runs on 3.11; use that locally when possible.
- If CI fails with "Some specified paths were not resolved, unable to cache dependencies":
- Confirm
frontend/package-lock.jsonis present in the commit. - Ensure
cache-dependency-pathpoints tofrontend/package-lock.json.
- Confirm
Available MCP servers
Only the top-level MCP servers are listed here. Use the server name when requesting integrations or automations.
- GitHub MCP
- Linear MCP
- Browser MCP
- Perplexity MCP
- Semgrep MCP
- Supabase MCP
- Python Environment MCP
- shadcn MCP
- Vibecheck MCP
- Time Management MCP
- Library Documentation MCP
Local development
Frontend
- Install deps:
npm ci(fromfrontend/) - Run dev server:
npm run dev - Run tests:
npm run test - Lint:
npm run lint(or run ESLint via your editor)
Backend
- Create a venv in
backend/and installrequirements.txt. - Run tests:
pytest -q(frombackend/) - Run server locally (example):
uvicorn main:app --reloadonceapp/main.pyexists.
Common tasks (playbook with acceptance criteria)
Add a React component
- Place it under
frontend/src/components/Name/Name.jsx(create folder if missing). - Include a test
Name.test.jsxunderfrontend/src/__tests__/or alongside the component. - Use Testing Library and semantic queries. Ensure the test passes.
- Acceptance: tests and lint pass, component is exported and used (if applicable).
Add a FastAPI route
- Define a Pydantic model if the route has a payload.
- Add the route handler and include it via a router in
app/main.py. - Write pytest tests using
TestClientthat cover 200 and at least one error case. - Acceptance: pytest passes locally and in CI.
Wire frontend to backend
- Use
fetchfrom the frontend to call the API (default). Handle JSON and HTTP errors. - Add a simple integration-style test with msw or mock
fetch(optional to start). - Acceptance: a small UI renders data or confirms submission with a mocked call; tests pass.
Commit / PR guidance
- Prefer Conventional Commits (e.g.,
feat: add reading form,fix: handle network error). - Keep PRs under ~300 lines of diff when possible; include tests and screenshots for UI changes.
- Update docs (
README.mdor/docs) when behavior or setup changes.
Definition of Done
- Lint passes with configured rules.
- All tests pass locally and in CI.
- For new features: adequate test coverage and updated docs.
- No secrets or environment-specific paths committed.
Copilot prompts that work well here
- "Add a FastAPI route POST /readings that validates systolic/diastolic and returns 201; include pytest tests."
- "Create a React component for adding a blood pressure reading with controlled inputs and a submit handler; add a Vitest test."
- "Refactor frontend API calls into a small client module using fetch with JSON helper and error handling; test the helper."
- "Update CI to run code coverage for Vitest and upload artifact; keep the existing job structure."
What's inside
14 sections covering mandatory agent behavior, repo map, tech stack, conventions, testing policy, CI/CD gotchas, MCP servers, local dev, playbook, commit guidance, and definition of done
Change this for your project
- Replace
afk-bro/blood-pressure-trackerwith your own repository name - Replace
frontend/package-lock.jsonwith your lockfile path if different - Replace
backend/requirements.txtwith your dependency file name if different - Replace
frontend/eslint.config.jswith your own lint config path
Where it goes
Keep it in your repository where the agent or team that needs it will read it.
Worth borrowing
- Path-based CI job filtering with dorny/paths-filter to run only relevant checks
- Co-located tests with a clear naming convention and Testing Library queries
- A playbook of common tasks with explicit acceptance criteria
Related Documents
System Prompt
Defines the identity, capabilities, response style, and spec workflow for an AI assistant named Kiro that helps developers build features incrementally.
World Engine AI Coding Instructions
Defines game scope, architecture, ESLint rules, git workflow, and open-source research policy for a strategic fantasy RPG project.
GitHub Copilot Instructions
Defines coding standards, architecture rules, PR expectations, and output format for a Laravel + Inertia + Vue 3 project.
Business Intelligence Dashboard - Comprehensive GitHub Copilot Instructions
Defines the full stack, setup commands, security rules, and testing strategy for a Next.js SaaS analytics platform with multi-tenant isolation.