Syncing existing tests with updated or changed requirements. Detecting requirement diffs, coverage gaps, and generating test updates based on changed acceptance criteria. Use when: (1) requirements changed after tests were written, (2) new acceptance criteria added to a ticket, (3) Jira/Confluence content updated, (4) before a release to verify requirement coverage.
Installation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Syncing existing tests with updated or changed requirements. Detecting requirement diffs, coverage gaps, and generating test updates based on changed acceptance criteria. Use when: (1) requirements changed after tests were written, (2) new acceptance criteria added to a ticket, (3) Jira/Confluence content updated, (4) before a release to verify requirement coverage.
audience
qa
Sync Tests with Updated Requirements
Config, version check, pattern rules, and E2E code generation preamble per claude/rules/skills.md. Additionally: grep {project.sourceRoot}/ for data-testid, labels, route definitions. Read test registry (.sparq/tracking/test-registry.json) and refresh-patterns.md before modifying tests.
Purpose
Sync existing tests with updated or changed requirements. This skill focuses exclusively on requirement changes -- detecting diffs between current requirements and existing test coverage, then generating test updates. For UI drift and technical freshness checks, use /sparq:validate.
When NOT to Use
If UI/codebase changed but requirements are the same (broken selectors, moved components, route changes): use /sparq:validate instead — it detects technical drift without requiring a requirements source.
/sparq:sync requires an updated requirements source (Jira, Confluence) to perform diff analysis. Without a requirements source, use /sparq:validate.
Input Detection
Parse input to determine:
Target test files: path, directory, or traced from ticket via registry reverse lookup
Requirement source: Jira ticket, Confluence URL, or auto-detect from registry sourceTicket/sourcePages
A requirement source (ticket ID, Confluence URL) is required. If only test files are provided without a requirement source, suggest /sparq:validate instead.
/sparq:sync EP-14 e2e/specs/auth/login.spec.ts
Requirement sync -- ticket ID + test file. Diff requirements, then update tests.
/sparq:sync EP-14
Requirement sync -- ticket ID only. Search test registry for linked tests, then diff requirements.
Workflow: Requirement Diff + Test Update
Parse input to determine: (a) target test files (path, directory, or traced from ticket via registry reverse lookup), (b) requirement source (Jira ticket, Confluence URL, or auto-detect from registry sourceTicket/sourcePages)
If ticket ID only (e.g., EP-14): search test registry entries where sourceTicket === "EP-14". Fallback: grep spec files for ticket ID references. If no tests found, ask user for test file path.
Dual Phase 1 (parallel when Task tool available):
Task A (test-validator): Parse existing test files, read test registry, extract traceability map {TC-ID -> [REQ-IDs]}, catalog assertions and test structure
Task B (requirements-analyst): Fetch CURRENT requirements from enabled sources (Jira/Confluence/Figma). If previous requirements exist at .sparq/requirements/REQ-{feature}.md, copy to .sparq/refresh/REQ-{feature}-previous.md before overwriting
Phase 1.5 -- Diff Analysis (orchestrator): Compare current requirements against test coverage using content hashing and registry data. Classify each requirement as NEW / CHANGED / REMOVED / UNCHANGED. Generate diff report at .sparq/refresh/REFRESH-{feature}-diff.md.
CHECKPOINT -- Present diff analysis: counts by category, each item with detail and recommended action, affected test files and TC IDs. If all hashes match and no timestamp staleness, present "Tests are up to date -- no changes needed." Wait for approval of which changes to apply.
Non-interactive mode: When preferences.interactiveMode is false, checkpoints are auto-approved except when Critical findings or smoke failures occur. See orchestrator Checkpoint Policy.
Phase 2 -- Update Generation: Delegate to sparq-automation-engineer (for E2E specs) or sparq-manual-test-writer (for manual test files) with approved diff and existing test context:
NEW requirements -> generate new test blocks, continue TC ID sequence per category from highest existing (see refresh-patterns.md)
CHANGED-HIGH -> suggest rewrite with before/after comparison, mark // [SYNC] REVIEW
CHANGED-MEDIUM -> update assertions/steps inline, mark // [SYNC] UPDATED
CHANGED-LOW -> add comment // [SYNC] NOTE (auto-applied if refresh.autoApplyLowSeverity is true)
REMOVED -> REMOVAL CHECKPOINT: Before marking // [SYNC] DEPRECATED or deleting, present a numbered list of all tests targeted for removal/deprecation with:
Test ID (e.g., TC-login-HP-003)
Test title
Linked requirement ID(s) that were removed
Recommended action: DEPRECATE (mark comment) or DELETE (remove from file)
Wait for explicit user approval of each removal. User may approve all, approve selectively, or reject all.
When refresh.preserveDeprecated is true: default recommendation is DEPRECATE (never auto-delete).
When refresh.preserveDeprecated is false: default recommendation is DELETE, but still requires user confirmation.
Non-interactive mode (preferences.interactiveMode: false): auto-approve DEPRECATE actions only. DELETE actions always require explicit approval regardless of interactive mode.
After approval: mark approved items // [SYNC] DEPRECATED or remove from file per user choice
CHECKPOINT -- Present proposed changes with before/after for each modified file. Wait for approval.
Apply approved changes, run smoke verification (npx playwright test --list when e2e.framework is playwright), update coverage matrix, update test registry with new lastRefreshedAt, requirementsHash, and any new testIds
Agent selection: E2E test updates use sparq-automation-engineer; manual test updates use sparq-manual-test-writer.
Fallback Behavior
When sources or registry are unavailable, degrade per degradation-strategy.md and error-handling.md (S5 errors). No registry: fall back to coverage matrix, then title matching. See refresh-patterns.md for traceability lookup chain.
If test registry is missing or stale, fall back to: coverage matrix -> file title matching -> treat all requirements as NEW. See error-handling.md S5 errors.
E2E files are updated directly in the project directory per e2e.structure.* config. User reviews via git diff and can revert via git checkout.
<done_criteria>
sparq.config.json read and validated; requirement sources and e2e.structure.* paths resolved
Requirement diff analysis generated at .sparq/refresh/REFRESH-{feature}-diff.md with every requirement classified as NEW, CHANGED, REMOVED, or UNCHANGED
All test removals/deprecations presented to user with explicit approval obtained before any deletion or deprecation marking (per tms-abstraction.md<removal_policy>)
Updated test files pass smoke verify per e2e.framework (npx playwright test --list for Playwright, npx cypress run --spec {path} or npx tsc --noEmit for Cypress) without error
Test registry (.sparq/tracking/test-registry.json) updated with current lastRefreshedAt, requirementsHash, and any new testIds
</done_criteria>
