メニュー
Submit corrections to OSM API v0.6 with full community compliance — proper changeset tags, size limits, rate-limit awareness, and dry-run support.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Run the full TIGER defect audit pipeline for a MetroNow service zone — fetch from Overpass, classify defects, analyze history, generate reports.
Diff OSM geometry and attributes against TIGER/Line 2024 to identify import drift, new roads, and name-field artifacts in MetroNow zones.
Generate a MapRoulette challenge from scan results for defect classes with high false-positive rates. Creates GeoJSON tasks constrained to MetroNow zone polygons.
Deep revision history analysis for specific OSM ways — fetches full version history from OSM API v0.6, identifies import bot vs human edits, classifies review status with confidence scores.
Decompress MetroNow docs so future-you (and fresh AI sessions) can pick the project back up cold without re-deriving everything. Use when the user says docs are confusing, plain, dense, hard to follow, missing context, jargon-heavy, jump straight to conclusions, or are hard to come back to after time away; asks why something is the way it is; says they can't tell what a term means; asks for a walkthrough, explainer, primer, or context refresher; says a section assumes too much; or wants visual aids. Diagnoses missing-middle gaps (undefined jargon, unstated WHY, skipped bridge steps, prose where a picture is needed) and rewrites sections using a fixed template — definition first, then bridge steps, then a load-bearing diagram, then code citations. Outputs to docs/explainers/<topic>.md or in-place edits. No VitePress, no static-site generator — just markdown that GitHub renders.
Unified code review and audit standards for the MetroNow Atlas TIGER Audit Console (https://github.com/AICincy/MetroNow.git). Use this skill when auditing any code in the MetroNow project, doing a PR review, checking code quality, validating accessibility, reviewing Docker config, or when someone asks "review this code," "audit the frontend," "check my PR," "what's wrong with this file," or "does this meet our standards." The codebase is vanilla JavaScript (IIFE pattern, no framework), single-file HTML with inline CSS/JS, IBM Plex typography, Leaflet maps, and an Express.js backend on port 3000 that shells out to the Python `osm` CLI. Covers JS, HTML, CSS, and Dockerfile review with severity-classified findings.
| name | changeset-submit |
| description | Submit corrections to OSM API v0.6 with full community compliance — proper changeset tags, size limits, rate-limit awareness, and dry-run support. |
| when_to_use | User says submit, push corrections, fix, create changeset, dry run, or wants to apply corrections to OpenStreetMap |
| allowed-tools | Read Grep Glob Bash(python *) |
| argument-hint | [zone] [--dry-run] |
| arguments | ["zone","flags"] |
Submit corrections for zone $zone with flags: $flags
Before ANY changeset submission, verify:
/community-prep firstwiki.openstreetmap.org/wiki/Automated_edits/<username>talk-us@ discussion has been posted_cincyimport-convention account is configured!test -f "$HOME/.config/osm/token.json" && echo "Token file exists" || echo "NO TOKEN - authenticate first at http://localhost:3000"
| Limit | Value | Source |
|---|---|---|
| Elements per changeset | 10,000 (CGImap hard limit) | OSM API v0.6 docs |
| Community norm | ~500 elements | Mechanical edit convention |
| New account first day | 1,000 changes/hour | PR #4319 ramp curve |
| Established account | 100,000 changes/hour | After ~1 week |
| Tag value length | 255 Unicode codepoints | API spec |
Every changeset MUST include:
<tag k="comment" v="TIGER defect correction in MetroNow {zone_name} zone: {description}"/>
<tag k="source" v="survey;CAGIS Open Data Hub"/>
<tag k="mechanical" v="yes"/>
<tag k="created_by" v="MetroNow TIGER Audit Pipeline"/>
<tag k="description" v="https://wiki.openstreetmap.org/wiki/Automated_edits/{username}"/>
review.py output or scan results/api/0.6/capabilities before each batch/osmcha-monitor {changeset_id} to verifyWith --dry-run, the pipeline generates the OsmChange XML and displays the diff without opening a changeset. Always do a dry run first.