From 3c4c28a1acae917a228332bf61b725417405519f Mon Sep 17 00:00:00 2001 From: Nikolay Tatarinov Date: Wed, 4 Mar 2026 10:18:43 +0300 Subject: [PATCH] feat: add project release and run tests skills documentation - Introduced SKILL.md files for project release and running tests in the duty-teller project. - Documented the project release workflow, including steps for updating CHANGELOG, committing changes, and tagging releases. - Provided instructions for running backend (pytest) and frontend (Vitest) tests, including prerequisites and failure handling. - Enhanced user guidance for verifying changes and ensuring test coverage. --- .cursor/skills/project-release/SKILL.md | 55 +++++++++++++++++++++++ .cursor/skills/run-tests/SKILL.md | 60 +++++++++++++++++++++++++ 2 files changed, 115 insertions(+) create mode 100644 .cursor/skills/project-release/SKILL.md create mode 100644 .cursor/skills/run-tests/SKILL.md diff --git a/.cursor/skills/project-release/SKILL.md b/.cursor/skills/project-release/SKILL.md new file mode 100644 index 0000000..cb450b5 --- /dev/null +++ b/.cursor/skills/project-release/SKILL.md @@ -0,0 +1,55 @@ +--- +name: project-release +description: Performs a project release by updating CHANGELOG for the new version, committing all changes, and pushing a version tag. Use when the user asks to release, cut a release, publish a version, or to update changelog and push a tag. +--- + +# Project Release + +Release workflow for duty-teller: update changelog, commit, tag, and push. Triggers Gitea Actions (Docker build) on `v*` tags. + +## Prerequisites + +- Decide the **new version** (e.g. `2.1.0`). Use [Semantic Versioning](https://semver.org/). +- Ensure `CHANGELOG.md` has entries under `## [Unreleased]` (or add a short note like "No changes" if intentional). + +## Steps + +### 1. Update CHANGELOG.md + +- Replace the `## [Unreleased]` section with a dated release section: + - `## [X.Y.Z] - YYYY-MM-DD` (use today's date in `YYYY-MM-DD`). +- Leave a new empty `## [Unreleased]` section after it (for future edits). +- At the bottom of the file, add the comparison link for the new version: + - `[X.Y.Z]: https://github.com/your-org/duty-teller/releases/tag/vX.Y.Z` + - (Replace `your-org/duty-teller` with the real repo URL if different.) +- Update the `[Unreleased]` link to compare against this release, e.g.: + - `[Unreleased]: https://github.com/your-org/duty-teller/compare/vX.Y.Z...HEAD` + +Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); keep existing subsections (Added, Changed, Security, etc.) under the new version. + +### 2. Bump version in pyproject.toml (optional) + +- Set `version = "X.Y.Z"` in `[project]` so it matches the release. Skip if the project does not sync version here. + +### 3. Commit and tag + +- Stage all changes: `git add -A` +- Commit with Conventional Commits: `git commit -m "chore(release): vX.Y.Z"` +- Create annotated tag: `git tag -a vX.Y.Z -m "Release vX.Y.Z"` +- Push branch: `git push origin main` (or current branch) +- Push tag: `git push origin vX.Y.Z` + +Pushing the `v*` tag triggers `.gitea/workflows/docker-build.yml` (Docker build and release). + +## Checklist + +- [ ] CHANGELOG: `[Unreleased]` → `[X.Y.Z] - YYYY-MM-DD`, new empty `[Unreleased]`, links at bottom updated +- [ ] pyproject.toml version set to X.Y.Z (if used) +- [ ] `git add -A` && `git commit -m "chore(release): vX.Y.Z"` +- [ ] `git tag -a vX.Y.Z -m "Release vX.Y.Z"` +- [ ] `git push origin main` && `git push origin vX.Y.Z` + +## Notes + +- Do not push tags from unreleased or uncommitted changelog. +- If the repo URL in CHANGELOG links is a placeholder, keep it or ask the user for the correct base URL. diff --git a/.cursor/skills/run-tests/SKILL.md b/.cursor/skills/run-tests/SKILL.md new file mode 100644 index 0000000..5112cba --- /dev/null +++ b/.cursor/skills/run-tests/SKILL.md @@ -0,0 +1,60 @@ +--- +name: run-tests +description: Runs backend (pytest) and frontend (Vitest) tests for the duty-teller project. Use when the user asks to run tests, verify changes, or run pytest/vitest. +--- + +# Run tests + +## When to use + +- User asks to "run tests", "run the test suite", or "verify tests pass". +- After making code changes and user wants to confirm nothing is broken. +- User explicitly asks for backend tests (pytest) or frontend tests (vitest/npm test). + +## Backend tests (Python) + +From the **repository root**: + +```bash +pytest +``` + +If imports fail, set `PYTHONPATH`: + +```bash +PYTHONPATH=. pytest +``` + +- Config: `pyproject.toml` → `[tool.pytest.ini_options]` (coverage on `duty_teller`, 80% gate, asyncio mode). +- Tests live in `tests/`. + +## Frontend tests (Next.js / Vitest) + +From the **repository root**: + +```bash +cd webapp-next && npm test +``` + +- Runner: Vitest (`vitest run`); env: jsdom; React Testing Library. +- Config: `webapp-next/vitest.config.ts`; setup: `webapp-next/src/test/setup.ts`. + +## Running both + +To run backend and frontend tests in sequence: + +```bash +pytest && (cd webapp-next && npm test) +``` + +If the user did not specify "backend only" or "frontend only", run both and report results for each. + +## Scope + +- **Single file or dir:** `pytest path/to/test_file.py` or `pytest path/to/test_dir/`. For frontend, use Vitest’s path args as per its docs (e.g. under `webapp-next/`). +- **Verbosity:** Use `pytest -v` if the user wants more detail. + +## Failures + +- Do not send raw exception strings from tests to the user; summarize failures and point to failing test names/locations. +- If pytest fails with import errors, suggest `PYTHONPATH=. pytest` and ensure the venv is activated and dev deps are installed (`pip install -r requirements-dev.txt` or `pip install -e ".[dev]"`).