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.
설치
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
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>
