Fastapi qa

Skill steph-dove/klaussy-agents/examples/fastapi/.gemini/skills/fastapi-qa

A multi-agent context, rules, and hooks boilerplate generator. With a single command, it scaffolds conventions, namespaced skills, stack-appropriate settings, and interactive guardrails for seven major AI coding environments, matching each agent's native file formats and capability profiles.

Install

npx -y skills add steph-dove/klaussy-agents --skill fastapi-qa

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when the user wants the current change QA'd and PR-ready evidence captured. Classifies the diff and runs the verification that actually fits it — screenshots for UI/frontend changes, endpoint or e2e runs for backend, command output for a CLI, tests for a library — then saves artifacts and writes a QA summary. Right-sizes QA to the change; it does not write features or fix bugs.

SKILL.md

5.4 KB, as published. Nobody here has run it

QA the current change and capture evidence a reviewer can trust. The point is to run the QA that's valid for this change — a UI tweak needs screenshots, a backend fix needs the endpoint exercised and the suite run, a CLI change needs its commands run. Don't screenshot a database migration; don't run the full browser e2e suite for a one-line helper.

Steps

Read CLAUDE.md for how this project builds, runs, and tests, plus any e2e/screenshot tooling it already has. Read any .claude/rules/*.md whose paths: glob covers the changed files — they often name the ports, fixtures, or QA conventions for that layer.
See what changed. git diff master...HEAD for the branch's work, plus git diff / git diff --cached for uncommitted edits. Classify each surface the diff touches (a change can span more than one — QA each with its own method):
- UI / frontend — components, styles, templates, pages, client-side behavior.
- Backend / API / service — routes, handlers, business logic, jobs, DB.
- CLI / tool — command entrypoints, flags, output.
- Library / SDK — importable code with no runtime surface of its own.
- Docs / config / infra only — no runtime behavior to observe.
Run the QA that fits each surface (use fastapi-run whenever you need to bring the app or service up):
- UI / frontend → capture screenshots. Prefer the repo's own tooling (Playwright, Cypress, Storybook, a visual-test harness) — it already knows how to reach each screen. Otherwise launch the app via fastapi-run and drive a headless browser (Playwright/Puppeteer) if one is installed. Capture the states the change actually affects: the default view, the changed interaction, and empty/error or responsive breakpoints when layout or state handling changed. Grab a before shot from master too when the branch point is cheap to check out, so the diff is visible. Note what changed visually.
- Backend / API / service → run the test suite and any integration/e2e that covers the area, then exercise the changed path for real: bring the service up, hit the endpoint (curl/httpie/the project's client), and capture the request → response and any relevant log lines.
- CLI / tool → run the representative commands that exercise the change (not just --help); capture stdout, stderr, and exit codes.
- Library / SDK → run the unit tests plus a small usage snippet that calls the changed API.
- Docs / config / infra only → there's nothing to observe at runtime. Say so and stop — don't manufacture QA.
Save the artifacts where the user can actually open them — a subfolder named <repo>-<branch> inside their Downloads folder (e.g. myapp-feature-login/), so screenshots land somewhere they'll look. Resolve the destination for the OS you're on:
- macOS / Linux: ~/Downloads/<repo>-<branch>/
- Windows: %USERPROFILE%\Downloads\<repo>-<branch>\ (PowerShell: $env:USERPROFILE\Downloads\...)
Derive <repo> from the repo root's folder name and <branch> from the current branch (git rev-parse --show-toplevel and git rev-parse --abbrev-ref HEAD), replacing any / in the branch with - so it's one valid folder name. Create the folder if it doesn't exist, then write screenshots as PNGs and captured command/HTTP output as text into it — keep artifacts out of the repo tree; they're evidence for a human, not source to commit. If there's no Downloads folder (a headless CI box), fall back to the user's home directory. Report the absolute folder path so the user can find it.
Write a QA summary suited to drop into a PR's Test Plan / QA section: which surfaces changed, what QA ran for each, the evidence (screenshot paths, captured output, test results), pass/fail, and anything you could NOT cover and why. Lead with the result, keep it tight.

Rules

Right-size QA to the diff. Only exercise what the change touches. A reviewer doesn't need forty screenshots or a full e2e run for a two-line fix — capture the states that actually changed, and skip surfaces the diff doesn't reach.
Never fabricate evidence. If you can't capture a screenshot (no browser tooling, no display, no fixture data), say so plainly and give the manual repro steps a human would follow — a described gap beats a faked artifact.
Don't change code to make QA pass. A failure here is a real signal — that's a bug for the debug skill, not something to patch around. Report it.
Local / dev only. Never QA against production or with production credentials unless the user explicitly says so. Tear down any app or server you started.

When NOT to use