Run any Skill in Manus with one click

qa-release-auditor

Stars2

Forks0

UpdatedMay 12, 2026 at 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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

AyushGupta05

AyushGupta05/OpenCityLog

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

File Explorer

2 files

SKILL.md

readonly

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.

More from this repository

same repository

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.