feature-reviewlisted

Full review of a new feature or branch before merge/release — verification against requirements (YouTrack/a requirements file, if any; otherwise the agent reconstructs the scope of changes from the git diff itself), code review, hunting for inconsistencies in use cases, checking adjacent modules for regression, and live UI testing in the browser, with a final prod-ready verdict. Use whenever asked to check a feature/branch/PR for readiness to merge or release, review/test new functionality, walk through use cases live, check adjacent screens for regression, or do QA/acceptance before prod — even if there is no explicit reference to requirements/an issue in the request.
smirnovalex-qa/qa-skills · ★ 1 · Code & Development · score 75

Install: claude install-skill smirnovalex-qa/qa-skills

# Review and testing of a new feature (code review + logic + use cases + regression) ## INPUTS Parse `$ARGUMENTS` and the dialog context to extract what is given; everything not given explicitly, determine yourself from the code and requirements — do not wait for the user to list it out for you: - **Requirements (YouTrack issue)** — a link of the form `https://youtrack.example.com/issue/...`, if present in the arguments or in the dialog. - **Requirements (file in the repository)** — a path of the form `docs/qa/requirements/**/requirements.md`, if present. - **Branch / commit range to review** — if not specified, take the current branch relative to `main`/`dev`. - **Affected functionality / module(s)** — an optional hint; do not limit yourself to it, find all actually affected modules yourself (step 2). - **Adjacent integrations that must not break** — an optional hint; supplement it with your own dependency analysis. - **URL/command to run the UI locally** — if not specified, determine it yourself from the README/package.json/docker-compose of the relevant service. If none of the inputs are given at all (no issue link, no requirements file, no branch) — before starting a full review, briefly ask the user for at least one source of requirements; without a source of requirements, step 3 (matching "requirement → implementation") is impossible. ## TASK There were changes in the repository — the developer attempted to implement one or more new features. The l