mit einem Klick
sparq-assistant
sparq-assistant enthält 21 gesammelte Skills von STUkh, mit Repository-Berufsabdeckung und Skill-Detailseiten auf SkillsMP.
Skills in diesem Repository
Generate automated E2E tests from scratch for a feature or bug ticket (Playwright or Cypress per config). Combines requirements analysis with automated test generation. Use when: (1) creating E2E tests for a new feature, (2) generating E2E tests from Jira ticket, (3) building automation suite from requirements, (4) creating a regression test from a bug ticket — orchestrator auto-detects and applies REG- IDs + inline-append behavior.
Generating both manual test cases AND automated E2E tests in a single pipeline. Combines requirements analysis, manual test generation, and E2E code generation. Use when: (1) creating complete test coverage for a feature, (2) generating manual tests and automated E2E together, (3) full QA pipeline from requirements to E2E code, (4) need both QA documentation and automation, (5) generating tests for multiple Jira tickets in batch.
Bootstrap SparQ configuration. Use when: starting SparQ for the first time, re-initializing config, or switching projects.
Convert manual test cases into automated E2E tests. Use when: (1) automating existing manual tests, (2) transforming TMS test cases to E2E tests, (3) automating a manual test suite, (4) converting TestRail or Qase test cases to Playwright E2E via MCP. Accepts test cases as text, file path, TMS reference (TestRail XML, Qase JSON, local JSON), CSV export, or live TMS connection (TestRail MCP, Qase MCP).
Consulting Playwright enterprise best practices — architecture, authentication, assertions, mocking, CI/CD, accessibility, visual regression, and anti-patterns. Providing production-ready patterns and code examples for Playwright test suites. Use when: user asks about Playwright best practices, test architecture, auth patterns, assertion strategies, CI setup, accessibility testing, visual regression, or wants to avoid common Playwright anti-patterns.
Advanced prompt optimization for Claude Code agents. Token budgeting, context engineering, Claude 4.6 specifics, data format selection, and prompt compression. Use when writing or refining skills, CLAUDE.md rules, multi-agent prompts, or debugging verbose/irrelevant output. Complements base formatting rules in CLAUDE.md.
Validating existing E2E tests against current UI, codebase, and designs. Detecting broken selectors, stale flows, UI drift, and technical freshness issues. Use when: (1) tests exist but may be outdated, (2) after UI refactoring, (3) periodic health checks, (4) checking if tests still match current state.
Reviewing pull requests for SparQ project compliance. Checking code standards, quality gates, agent/skill prompt quality, and security. Use when: reviewing a PR, preparing changes for merge, validating contributions, or running a pre-push review.
View, edit, or validate SparQ configuration interactively. Use when: changing Jira project key, enabling/disabling integrations, adjusting checkpoint level, or troubleshooting config issues.
Exporting test cases to TMS (TestRail/Qase/Zephyr Scale/local), Jira, or Confluence. Use when: (1) pushing test cases to a TMS provider, (2) linking test coverage to Jira tickets, (3) publishing test plans to Confluence, (4) syncing QA artifacts with external tools.
Guiding teams to add performance testing (k6, Artillery) alongside their SparQ-generated E2E tests. Covers Web Vitals assertions, load test scripts, Lighthouse CI integration, and converting Playwright tests to k6 browser scripts. Use when: user asks about performance testing, load testing, k6, artillery, web vitals, lighthouse, performance regression, lcp fid cls, or wants to measure speed and load capacity.
Publishing E2E test execution results from Playwright/Cypress back to TestRail, Qase, or Zephyr Scale TMS after CI runs. Use when: (1) posting pass/fail results from a completed CI run to a TMS, (2) creating a test run record in TestRail or Qase from Playwright JSON or JUnit XML output, (3) syncing CI results back to the test management system.
Direct Qase REST API v1 reference for HTTP calls via curl/Bash. Use when Qase MCP server is unavailable, broken, or returning errors and direct API interaction is needed. Covers all endpoint groups (cases, suites, runs, results, projects, milestones, environments, defects, shared steps/parameters, configs, custom fields, attachments, users, search) with curl examples. Project code: from outputs.tms.qase.projectCode in sparq.config.json (env: QASE_DEFAULT_PROJECT). Triggered by: MCP broken, use Qase API directly, curl Qase, bypass MCP, or when mcp__qase__ tools fail and Qase operations are needed.
Updating E2E test files after codebase refactoring. Bulk renaming selectors, imports, class names, and string references across test suites.
Resuming an interrupted SparQ workflow from the precise interruption point. Use when: a previous session ended mid-workflow, the user wants to continue where they left off, or workflow state shows in-progress or failed status. Supports mid-phase, mid-parallel-dispatch, and mid-merge recovery.
Conversational QA workflow router — the primary entry point for SparQ. Detecting user intent from natural language and routing to the correct SparQ skill automatically. Triggering on any QA-related request including: generating tests from Jira tickets or requirements, creating E2E tests for features, converting manual tests to automated Playwright tests, validating existing tests after UI changes, updating tests when requirements changed, creating regression tests for bugs, exporting results to TestRail or Qase or Jira, checking test coverage, and configuring SparQ settings. Use when: user asks to test a ticket, generate tests, create E2E tests, validate tests, sync requirements, write regression tests, export results, cover a feature with tests, check if tests are valid, or describes any QA testing need in plain language. Also use when: user provides a Jira ticket ID like EP-142, mentions test generation or test creation, says tests are broken or outdated, asks what tests they need, wants to convert manual t
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.
Direct TestRail REST API v2 reference for HTTP calls via curl/Bash. Use when TestRail MCP server is unavailable, broken, or returning errors and direct API interaction is needed. Covers all endpoint groups (projects, suites, sections, cases, tests, runs, results, plans, milestones, users, priorities, statuses, case types/fields, configs, attachments) with curl examples. Project ID: from outputs.tms.testrail.projectId in sparq.config.json (env: TESTRAIL_PROJECT_ID). Triggered by: MCP broken, use TestRail API directly, curl TestRail, bypass MCP, or when mcp__testrail__ tools fail and TestRail operations are needed.
Gather and consolidate requirements from Jira, Confluence, Figma, and local files. Use when: (1) analyzing a Jira ticket for testing, (2) extracting requirements from Confluence specs, (3) understanding UI flows from Figma designs, (4) preparing requirements for test generation. Triggers: Jira ticket ID, Confluence page URL, Figma link, or feature description.
Consulting Cypress enterprise best practices — architecture, authentication, mocking, assertions, CI/CD, accessibility, visual regression, component testing, and anti-patterns. Providing production-ready patterns and code examples for Cypress test suites. Use when: user asks about Cypress best practices, test architecture, auth patterns, cy.intercept strategies, assertion chains, CI setup, accessibility testing, visual regression, component testing, or wants to avoid common Cypress anti-patterns.
Generate comprehensive manual test cases from requirements. Covers happy path, validation, security, edge cases, and accessibility. Outputs markdown and TMS-importable formats. Use when: (1) creating manual test cases, (2) building QA checklist, (3) preparing test plan for a feature, (4) generating TMS-importable test cases.