Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

qa-release-auditor

Estrelas2

Forks0

Atualizado12 de maio de 2026 às 12:41

Run final Bims-5 ship-readiness checks across docs, data provenance, ETL contracts, frontend smoke tests, accessibility, performance, open-source readiness, and legacy simulation removal/downgrade. Use before merging, tagging, publishing data packs, release notes, demos, or major pull requests.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

AyushGupta05

AyushGupta05/OpenCityLog

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

Explorador de arquivos

2 arquivos

SKILL.md

readonly

Mais deste repositório

mesmo repositório

geospatial-frontend-reviewer

AyushGupta05/OpenCityLog

Review Bims-5 map, timeline, event rail, evidence drawer, filters, source panels, and export UI for planner usefulness, accessibility, performance, and provenance clarity. Use when changing geospatial frontend code, visual encodings, Mapbox/map layers, event selection, timeline replay, source/evidence interactions, or browser smoke tests.

2026-05-122

lightweight-impact-modeler

AyushGupta05/OpenCityLog

Design or review Bims-5 proposal-impact logic as lightweight historical analogue lookup, local-context comparison, confidence labelling, and caveated descriptive summaries. Use when implementing proposal lens, impact lookup, analogue matching, contextual indicators, or confidence rules; avoid predictive simulation, fake precision, generic scores, and unsupported causal claims.

2026-05-122

open-source-maintainer

AyushGupta05/OpenCityLog

Maintain Bims-5 as a trustworthy open-source city change atlas. Use when writing or reviewing README, CONTRIBUTING, methodology docs, data-license docs, issue templates, release notes, examples, citation guidance, correction flows, governance docs, or public-facing project copy for contributors and data users.

2026-05-122

planning-product-critic

AyushGupta05/OpenCityLog

Evaluate whether Bims-5 features, copy, roadmap items, and UI/product ideas serve real urban planners and public-interest users as an evidence-backed city changelog. Use when reviewing proposed features for planner value, bullshit risk, unsupported prediction, fake simulation, causality overclaiming, or scope creep away from the open-source city change atlas mission.

2026-05-122

provenance-etl-builder

AyushGupta05/OpenCityLog

Build or review Bims-5 ETL scripts that produce city-change events, source manifests, provenance artifacts, schemas, and verification fixtures. Use when changing Python or Node data pipelines, normalizing public data, generating event/source/provenance JSON or NDJSON, adding city adapters, or ensuring every displayed claim traces to source rows, files, licenses, retrieval dates, geometry, and transformation methods.

2026-05-122

urban-data-source-auditor

AyushGupta05/OpenCityLog

Audit UK and US city data sources for Bims-5 before ingestion. Use when selecting or reviewing planning, development, transport, environmental, demographic, boundary, basemap, permit, zoning, air-quality, or open-data sources; check license, coverage years, update frequency, geographic scope, reliability, provenance fields, and whether the source supports observed city-change claims without overclaiming.

2026-05-122

name	qa-release-auditor
description	Run final Bims-5 ship-readiness checks across docs, data provenance, ETL contracts, frontend smoke tests, accessibility, performance, open-source readiness, and legacy simulation removal/downgrade. Use before merging, tagging, publishing data packs, release notes, demos, or major pull requests.

QA Release Auditor

Description

Use this skill for the last pass before a branch is merged, demoed, or released. It should surface blockers, residual risks, and exact verification evidence.

When To Use

Before merge or release.
After ETL, frontend, schema, or docs changes.
Before public demos or data-pack publication.
When removing/downgrading legacy simulation paths.

Inputs

Git diff and intended scope.
Commands already run and outputs.
Screenshots or browser smoke logs for UI work.
Source/provenance manifests and release notes.
Known skipped tests or legacy failures.

Output Format

Return:

Release verdict: ship, ship with notes, or block.
Blockers: ordered by severity with file/line when available.
Verification log: commands run and result.
Product/provenance review: overclaims, source lineage, licenses, caveats.
Residual risks and follow-up issues.

Checklist

Does the diff match the stated scope?
Did product code stay untouched for docs-only work?
Do all changed skills/docs have valid frontmatter/links/paths?
Do ETL outputs validate against schemas?
Can every event/layer/number trace to source and license?
Are browser smoke tests run for UI changes?
Are accessibility and performance risks checked?
Are simulator/forecast claims removed, quarantined, or explicitly out of scope?
Are README/docs/release notes updated when public behavior changed?
Does git status --short show only intentional files?

Failure Modes To Avoid

Reporting "tests pass" without naming commands.
Ignoring skipped or legacy-failing checks.
Treating docs-only work as if product behavior was verified.
Letting generated artifacts obscure source changes.
Shipping public copy with forecast, causality, or fake precision.
Merging broad cleanup with unrelated product-code changes.