Receber por email
← Voltar para o catálogo

evaluator-write-retest

Internal Auto-Harness evaluator skill for sprint retest and retest report writing. Use only inside the Evaluator subagent during retest mode.

13estrelas
Atualizado há 6 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add redker56/auto-harness

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/evaluator-write-retest/svg)](https://www.skillteca.com.br/skills/evaluator-write-retest)

Skills relacionadas

Ver todas de Desenvolvimento →

Alerta por categoria

Receba novas skills de Desenvolvimento toda segunda

1 email curto, só com as skills novas de Desenvolvimento. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Evaluator Write Retest

This skill governs Evaluator retest mode and the sprint retest report.

At the start of this action, read these harness artifacts from the project:

  • .harness/status.md
  • .harness/intake.md
  • .harness/spec.md
  • .harness/design-direction.md
  • .harness/runtime.md
  • .harness/contracts/sprint-XX-contract.md
  • .harness/contracts/sprint-XX-review.md when a review exists for the sprint.
  • .harness/qa/sprint-XX-qa-report.md
  • .harness/qa/sprint-XX-fix-log.md
  • .harness/qa/sprint-XX-retest.md when rewriting the retest report.

Then inspect the current project implementation relevant to this action:

  • Read the source files, routes, components, services, tests, and config touched by the named fixes and the nearby regression surface.
  • Use the codebase to verify that the intended fix landed where claimed, but keep verdicts grounded in retest evidence.

Then read these skill references:

  • references/protocols/file-ownership.md
  • references/templates/retest-report.md
  • references/rubrics/bug-severity.md
  • references/rubrics/retest-review.md

Follow these rules:

  • Retest only the named fixes and tightly related regression surface.
  • Verify each named fix against the real running app before deciding whether it passed.
  • If the target is a web application, use Playwright MCP and operate the UI like a real user by opening pages, clicking, typing, navigating, submitting forms, and observing visible results.
  • If the target is not a web application, use the most direct real-user interaction path available from the runtime contract and named tools.
  • Use the retest template exactly.
  • Use Result Basis to show why the overall Result: PASS | FAIL follows from the retest evidence.
  • Do not emit a fresh scorecard, thresholds, dimension scores, or numeric regrading in a retest report.
  • If a named fix cannot be verified from runtime behavior or other concrete retest evidence, do not pass it.
  • For web applications, browser-action evidence should describe exactly what was clicked, entered, navigated, submitted, or visibly observed during retest.
  • Always cite concrete retest evidence such as routes, browser actions, commands, visible UI text, network behavior, or source locations.
  • Do not silently upgrade unresolved issues to passed status.
  • Carry forward remaining bugs with severity and notes that match the evidence.
Compartilhar X LinkedIn